From nobody Tue Sep 1 10:08:45 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 9CDBD3A0B54; Tue, 1 Sep 2020 10:08:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF-Announce" Cc: rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159898012342.27610.8003517532242730450@ietfa.amsl.com> Date: Tue, 01 Sep 2020 10:08:43 -0700 Archived-At: Subject: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2020-09-15 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 17:08:44 -0000 The RFC Editor Future Development (rfcefdp) Program will hold a virtual interim meeting on 2020-09-15 from 23:00 to 01:00 GMT (23:00 to 01:00 UTC). Agenda: We will compare and contrast the following drafts: draft-thomson-rfced-model-01 draft-carpenter-rfced-model-00 draft-stjohns-rfced-rseb-00 and perhaps one more The group will take a sense of the room as to whether there is one draft that is preferred as a starting point for adoption (which will of course be confirmed on list). Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m1337e3af9b39bc2ce78932daea000cda Meeting number (access code): 171 361 7996 Meeting password: iabrfc Join by phone: 1-650-479-3208 From nobody Tue Sep 1 12:17: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 613EA3A0F6E for ; Tue, 1 Sep 2020 12:17:00 -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 SOEq0sCHOeYB for ; Tue, 1 Sep 2020 12:16:58 -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 28F9B3A0F47 for ; Tue, 1 Sep 2020 12:16:58 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id b19so2899896lji.11 for ; Tue, 01 Sep 2020 12:16:58 -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=z3ZQhJkehuk026McpoV709TOgo/kfzFE8vxfDuDs4Bo=; b=b8IZMLs0BTHIML5pz4i2eprXOGx7cmCd50X0R3CUnMGwG21Bva97LQOlgipcU8+BQN aRUuT4xB/W3lnnTO9IZUTfTix/U4HwIfhMRtw7TyTtTx5OnAC14OYblhIrNrSgKOrpw3 abDC5AOEuNS5C2kyZqTjC75RBzB2bN6X0JZH+/Avy0wtMvMqKxkDNZAEEvBDltj5b38B 5Eh4xtSxoZkAWCeo5L9H0af3AatZ0UIkBHRDevvJfWvxUWCPR1xKmAg6YcyY0ZVzDwud fEYMG6c0YpbhuGM/msVyq1Mv1mjQW8qoU6hNJKLCfEw1gqMcIhTUVyQarqmCQAb2zK65 dG8w== 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=z3ZQhJkehuk026McpoV709TOgo/kfzFE8vxfDuDs4Bo=; b=HjMEb60q/Fa3CAV3e4jsI5YVlUyyEl2XXzCYPb30ZWlg36ZIaAl0K7VbrI41Zy1noh mwdogQflGFEQKMFcY/b05mMAtQ7Zzc4xDQ++7uJDN9VNKI7wnl/+VBCooOP6gqm3jMC3 35jSzhxE+yMxCF7z/oKrv3s8KUhwRRQy117jTaDGjJdkSiI18h9EFJ7Dy/7Jk99bS3DS 6beuGfhjhyZYyk5MQl/2irw18omVk8nDfb4tTD3ddG/x9zmvb1Bo34/jdlcpTVi5Td0w Z5WgUig1uCOfkhporQr9bRPTvxjH9lgofIkD3qYzZoDIaTGEgZc6JiEBv+KrB8RWsR7p 65DA== X-Gm-Message-State: AOAM5324k6H3w7uGlE6jzXadzwt9u26Mo0oj7f4QEvjCcvU5tKH9r9Gu O6nnfoQ+6BDdGoAx8Rz8en1QoklOCb12VN8OJnLZklIA+K31xnV5 X-Google-Smtp-Source: ABdhPJx5mh7k0bY2+XDP47ZCsqQGtifHPElbcFCJXkslnnBnd2JjbGXU+VwoJzihcUoZqn+cykQ2e2MHYuxe/sW7rB8= X-Received: by 2002:a2e:3609:: with SMTP id d9mr1254715lja.17.1598987816062; Tue, 01 Sep 2020 12:16:56 -0700 (PDT) MIME-Version: 1.0 References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> In-Reply-To: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> From: Eric Rescorla Date: Tue, 1 Sep 2020 12:16:19 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000c6edd305ae455c9b" Archived-At: Subject: Re: [Rfced-future] Posted my draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 Sep 2020 19:17:00 -0000 --000000000000c6edd305ae455c9b Content-Type: text/plain; charset="UTF-8" Mike, Thanks for posting this document. As you say, it's probably best to focus on big picture principles rather than details With that in mind, there are several pieces of this that do not sit well with me, as noted below. RSE ACCOUNTABILITY As I understand this document, the intent is to largely insulate the RSE from external forces. Specifically: 1. The RSEB (which nominally represents the RFC community) does not seem to have any hiring and firing authority [0] 2. While this is a bit more unclear, the LLC does not seem to be chartered to replace the RSE based on concerns about their strategic choices. [1] 3. Section 4.3 says: While it is ultimately the LLC's decision, the RSE should be engaged via either a personal services contract or an employment contract for a given term. Engagement as an at-will employee would not be appropriate for a senior-level resource with these strategic responsibilities and would not provide any measure of consistency and continuity over the RFC Series. While I can certainly understand how this arrangement might be appealing to prospective RSEs, I do not believe it provides an appropriate level of accountability to the community. Specifically, I believe it is necessary to have the ultimate authority for stratetic decisions be vested in the community (in this case this would be the RSEB, ignoring for the moment its composition), but that does not appear to be the case here. This issue is exacerbated by the fact that the RSE is themselves a member of the RSEB. On the specific topic of the nature of the contract, ignoring the specific question of at-will, it is quite common for senior level executives (CEOs, etc.) to be simply replaced by the board, so I don't think it follows that a senior-level resource with strategic responsibilities should have high levels of security of employment. THE IETF'S ROLE This structure seems to cast the IETF in a fairly small role, for instance making the ISE chair. I recognize that there are differences of opinion in how much weight we should give the non-IETF portions of the RFC series, but given that the IETF is by far the largest customer of the RFC series, I believe that any structure should be designed to ensure that the IETF's needs are met. This structure does not seem to me to do so. -Ekr [0] "Note: As the RSEB has no contractual relationship with the RSE, the RSEB does not exercise any form of work direction over the RSE nor does it have any role in evaluating the RSE's performance." [1] "For avoidance of doubt: The LLC has no oversight or management role with respect to the strategic development of the RFC Series. The funding of the RSE, RPC and other tasks within the RSO does not expand the LLC's current administrative remit to oversight of the RFC Series." On Mon, Aug 24, 2020 at 10:34 AM Michael StJohns wrote: > See https://datatracker.ietf.org/doc/draft-stjohns-rfced-rseb/ > > My intent is to ignore comments for a few days rather than jump in and > defend each comma and clause. > > Basically, this mostly leaves intact the operation of the RFC Series > Function while splitting the functions previously held by the IAB into > two specific ones: Strategic evolution of the series goes to a purpose > built organization - the RFC Series Editorial Board, while the > contractual nitty gritty of paying for things gets firmly homed under > the LLC. > > Enjoy - Mike > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000c6edd305ae455c9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike,

Thanks for posting this document. As you say,= it's probably
best to focus on big picture principles rather than d= etails
With that in mind, there are several pieces of this that
do no= t sit well with me, as noted below.


RSE ACCOUNTABILITY
As I u= nderstand this document, the intent is to largely insulate the
RSE from = external forces.

Specifically:

1. The RSEB (which nominally r= epresents the RFC community) does not
seem to have any hiring and firing= authority [0]

2. While this is a bit more unclear, the LLC does not= seem to be
chartered to replace the RSE based on concerns about theirstrategic choices. [1]

3. Section 4.3 says:

=C2=A0 =C2=A0Wh= ile it is ultimately the LLC's decision, the RSE should be engaged
= =C2=A0 =C2=A0via either a personal services contract or an employment contr= act for
=C2=A0 =C2=A0a given term.=C2=A0 Engagement as an at-will employ= ee would not be
=C2=A0 =C2=A0appropriate for a senior-level resource wit= h these strategic
=C2=A0 =C2=A0responsibilities and would not provide an= y measure of consistency and
=C2=A0 =C2=A0continuity over the RFC Series= .

While I can certainly understand how this arrangement might be
= appealing to prospective RSEs, I do not believe it provides an
appropria= te level of accountability to the community. Specifically, I
believe it = is necessary to have the ultimate authority for stratetic
decisions be v= ested in the community (in this case this would be the
RSEB, ignoring fo= r the moment its composition), but that does not
appear to be the case h= ere. This issue is exacerbated by the fact
that the RSE is themselves a = member of the RSEB.

On the specific topic of the nature of the contr= act, ignoring the
specific question of at-will, it is quite common for s= enior level
executives (CEOs, etc.) to be simply replaced by the board, = so I
don't think it follows that a senior-level resource with strate= gic
responsibilities should have high levels of security of employment.<= br>

THE IETF'S ROLE
This structure seems to cast the IETF in = a fairly small role,
for instance making the ISE chair. I recognize that= there are
differences of opinion in how much weight we should give
t= he non-IETF portions of the RFC series, but given that the
IETF is by fa= r the largest customer of the RFC series, I
believe that any structure s= hould be designed to ensure that
the IETF's needs are met. This stru= cture does not seem to me
to do so.

-Ekr


[0] "Not= e: As the RSEB has no contractual relationship with the RSE, the
RSEB do= es not exercise any form of work direction over the RSE nor
does it have= any role in evaluating the RSE's performance."

[1] "F= or avoidance of doubt: The LLC has no oversight or management role
with = respect to the strategic development of the RFC Series.=C2=A0 The
fundin= g of the RSE, RPC and other tasks within the RSO does not
expand the LLC= 's current administrative remit to oversight of the RFC
Series."= ;


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0

On Mon, Aug 24, 2020 at 10:34 AM Michael StJohns = <msj@nthpermutation.com>= ; wrote:
See https://datatracker.ietf.org/doc/draft-stjohn= s-rfced-rseb/

My intent is to ignore comments for a few days rather than jump in and
defend each comma and clause.

Basically, this mostly leaves intact the operation of the RFC Series
Function while splitting the functions previously held by the IAB into
two specific ones:=C2=A0 Strategic evolution of the series goes to a purpos= e
built organization - the RFC Series Editorial Board, while the
contractual nitty gritty of paying for things gets firmly homed under
the LLC.

Enjoy - Mike


--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000c6edd305ae455c9b-- From nobody Tue Sep 1 13:08: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 A4A3D3A1022 for ; Tue, 1 Sep 2020 13:08:15 -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 H1serrKZRAq3 for ; Tue, 1 Sep 2020 13:08:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB6D3A1018 for ; Tue, 1 Sep 2020 13:08:13 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kDCZb-0000so-MF; Tue, 01 Sep 2020 16:08:07 -0400 Date: Tue, 01 Sep 2020 16:08:01 -0400 From: John C Klensin To: Joseph Touch , John R Levine cc: rfced-future@iab.org, Eric Rescorla Message-ID: <180AC281843E3ABB781A5FEE@PSB> In-Reply-To: <1858EDDB-1940-43DD-83FC-45EBFF46C936@strayalpha.com> References: <78d71ac9-41ab-8700-338f-81a74912a28e@gmail.com> <20200828204636.3B7941F3DEBC@ary.qy> <4e34ce5d-4d6-bea1-543-8462fac4f13@taugh.com> <74d67cf5-4cd3-746e-9110-319e85285c2@taugh.com> <1858EDDB-1940-43DD-83FC-45EBFF46C936@strayalpha.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] My hard constraints X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 Sep 2020 20:08:16 -0000 --On Friday, August 28, 2020 17:34 -0700 Joseph Touch wrote: > > >> On Aug 28, 2020, at 4:03 PM, John R Levine >> wrote: >> >> To perhaps clarify, I think that xml2rfc is an OK publication >> format because of all the semantic tagging, but it's a >> terrible authoring format. If it were up to me (and I had >> 20/20 hindsight) I would put more effort into thinking about >> the entire document creation process and better tools to let >> people use the editing tools they use for other stuff. > > That's why I support the Word format, FWIW. > > I understand the back-end pubs process is harder when it goes > to RFC, but that's a 1x investment. Word (or word-like, e.g. > OpenOffice) makes it impossible to generate "non-compiling > XML" that can't easily be untangled. I think I've already commented on a different aspect of this and am still trying to sort out how to explain what I think is an even more basic problem, but... The big advantage of Word and its ilk is that it is more or less WYSIWYG. Many of us who dislike Word dislike it because it tries to infer what you want to see, sometimes gets that wrong, but is unwilling to be overridden about it, at least in any obvious way. Vint has referred to some such systems as "WYGIWYIG" (what you get is what you get). And, because one is editing both text and page layout at the same time, sometimes going to a different format works well and sometimes it doesn't. So-called generic markup systems, going back to GML and SGML, are intended to take page layout and similar decisions out of the hands of authors and move them to experts on those subjects (plus or minus so-called style sheets, which are also things that experts should probably be designing. And, again, switching styles in Word for different presentation arrangements sometimes works... and sometimes doesn't, perhaps depending on understanding them and their implications much more deeply than seems typical of Word users. And, while Word can export something XML-ish (and, with some versions, that is the default) that will never be as satisfactory as true generic markup because, at best, it is using more or less complicated, and more or less accurate, heuristics to get from a presentation form (e.g., a string in italics) to information about what it actually is (a book title? a string in a different language that one wants to set of? A form of emphasis? In the most general of cases, only the author knows what was intended. In that sense, the long-ago choice of ASCII text was about stability by deciding on certain types of layout (US-format pages, although some special decisions were made to accommodate A4). A decision to go with PDF/A is a similar sort of decision -- very specific layout. HTML does not avoid forcing us into a box; it is just a different box and on for which, maybe, more kinds of devices have been optimized and more people have gotten used to the rough edges. And, in an ideal or even reasonable world, one does not try to author documents in either. When we decided we wanted to be able to display output reasonably well on other types of devices --very different ones-- then generic markup, with either author-specified elements or some person iterating on element definitions with the author, is a necessity [1]. And, of course, it is possible to design editing tools that are far more friendly to, e.g., XML with a particular schema than either generic XML editing tools, my emacs/epsilon macros, or just writing markup in an ordinary text editor. For those who like Word (or anything similar), it seems perfectly reasonable (if we are willing to incur the costs which, so far, we've said we are) to use it to generate plausible output files, hand those output files over to the RPC, and have them convert those files to acceptable XML2RFC format, with or without the aid of markdown and asking the author questions if needed. That is more or less what publishers who accept typescript (or Word) have been doing since many of them shifted to SGML three decades ago as part of the process leading to page layout. But let's be clear that is what we are doing and talking about. Otherwise, it a choice between discussing how to find or make better tools for creating and editing the specific XML2RFC schema or abandoning the idea of multiple-format output. Finally, to predict part of the explanation I'm having trouble putting together without a message longer than anyone will read, I assume that everyone reading this knows all of the above already, can discuss the tradeoffs between XML and other SGML dialects for publications, has an in-depth understanding of the difference between format and generic markup and the tradeoffs involved, etc. best, john [1] Markdown is a different way to get there, but with far more knowledge of how to derive XML from RFC formats than is possibly with a generic tool like Word) From nobody Tue Sep 1 13:56: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 9F5B53A1095 for ; Tue, 1 Sep 2020 13:56:25 -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=iecc.com header.b=JEp6AwSN; dkim=pass (2048-bit key) header.d=taugh.com header.b=pkBJGIur Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IR7d0Xm3Rgp for ; Tue, 1 Sep 2020 13:56:23 -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 A35913A1092 for ; Tue, 1 Sep 2020 13:56:23 -0700 (PDT) Received: (qmail 81176 invoked from network); 1 Sep 2020 20:56:22 -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; s=13d15.5f4eb576.k2009; i=johnl-iecc.com@submit.iecc.com; bh=xpGRPbiwRHUtLjyJLANu+DflGRgZEFSQVCpaiRBHQLg=; b=JEp6AwSNBofZHfqwxX7dIp+pBrbL2N820hbXOS3sNtt1wsnvJJnDOwUE6UULcH/4CmFKY1V/1c4lpQZ90LqCBVfSy2pcWiis/Tq2UEOCriyvpCVa3Bn3/CGadbMe2Cxp1/XkSnkJio9sgCXrzaaTKbwZGud2M1te73ndcAohDTKnqmWFm1K6IECd89D9ZXDhfXHnuOZcf5PG+MlrRnoSyzJZm1DBdoz7514+oCmEKEQus3i1ROlqjR1bgbb/76SsIohg7kwaCfyRuLjvmiZW5LXszO03q7mbCE0xc47y62XT51o9MB3k37eAgALID/d2uTyNKrs1mR4mzlnHj51Wog== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=13d15.5f4eb576.k2009; olt=johnl-iecc.com@submit.iecc.com; bh=xpGRPbiwRHUtLjyJLANu+DflGRgZEFSQVCpaiRBHQLg=; b=pkBJGIurZjTv7pw82X3x8JxjSFi78m2rs1JKZ5JKLtATYeSZHQv/8HLr4H61DzWeUjH/s9XK5FLQd6amEFMby6PpwdDbtR97G93PVOl+OmIITaTLEtupR8dqAOmHoFcsUxW9L63VrpoDJTxZnf+Ujvj1eXKpcABRQ+XFFL+sD10EVnPJH7fII9a25vJGWJjZqbLbpDnm8yDXf6vk1PzUcyWH99U9qHPZiy4iSpLuebDtTn/VlbA/f0LmAzJiG9N8CZ1sjeT4S37pfOX+i75KuWYKeGp0toYr81LkeH7xpPbmlZ0JTkdymXlbUnV2yIXM4i6LVD2NZc90lgwXTSSplw== 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; 01 Sep 2020 20:56:21 -0000 Date: 1 Sep 2020 16:56:21 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" Cc: rfced-future@iab.org In-Reply-To: <180AC281843E3ABB781A5FEE@PSB> References: <78d71ac9-41ab-8700-338f-81a74912a28e@gmail.com> <20200828204636.3B7941F3DEBC@ary.qy> <4e34ce5d-4d6-bea1-543-8462fac4f13@taugh.com> <74d67cf5-4cd3-746e-9110-319e85285c2@taugh.com> <1858EDDB-1940-43DD-83FC-45EBFF46C936@strayalpha.com> <180AC281843E3ABB781A5FEE@PSB> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Rfced-future] My hard constraints X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 Sep 2020 20:56:26 -0000 On Tue, 1 Sep 2020, John C Klensin wrote: > And, while Word can export something XML-ish (and, with some > versions, that is the default) that will never be as > satisfactory as true generic markup because, at best, it is > using more or less complicated, and more or less accurate, > heuristics to get from a presentation form (e.g., a string in > italics) to information about what it actually is (a book title? > a string in a different language that one wants to set of? ... Word has a very powerful stylesheet feature so you can define styles for semantic tags for titles of code or whatever, and they're visible to export tools. At least 20 years ago the publisher wanted to put a CD in one of my books which had all of the contents and screen shots as HTML pages. The text was all written in Word, a file per chapter, so I exported the Word files as RTF (this was back when Word's native format was undocumented tokens), and wrote some perl scripts that read the RTF and turn it into HTML files with suitable links and tags and so forth. It worked because it was my own Word, edited by editors who understood that the style tags needed to be there and the figure links needed to be in a fixed format, but it was extremely fragile. The problem with this approach is that very few Word users actually use styles beyond section headers to get the TOC and I doubt we can change that. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Sep 1 16:39: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 E01813A095A for ; Tue, 1 Sep 2020 16:39:05 -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 Qpza9AMQCORK for ; Tue, 1 Sep 2020 16:39:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59D53A0598 for ; Tue, 1 Sep 2020 16:39:04 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kDFri-0001gT-R3; Tue, 01 Sep 2020 19:39:02 -0400 Date: Tue, 01 Sep 2020 19:38:56 -0400 From: John C Klensin To: John R Levine cc: rfced-future@iab.org Message-ID: <43586E70768309C10CFB6634@PSB> In-Reply-To: References: <78d71ac9-41ab-8700-338f-81a74912a28e@gmail.com> <20200828204636.3B7941F3DEBC@ary.qy> <4e34ce5d-4d6-bea1-543-8462fac4f13@taugh.com> <74d67cf5-4cd3-746e-9110-319e85285c2@taugh.com> <1858EDDB-1940-43DD-83FC-45EBFF46C936@strayalpha.com> <180AC281843E3ABB781A5FEE@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] My hard constraints X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 Sep 2020 23:39:06 -0000 --On Tuesday, September 1, 2020 16:56 -0400 John R Levine wrote: > On Tue, 1 Sep 2020, John C Klensin wrote: >> And, while Word can export something XML-ish (and, with some >> versions, that is the default) that will never be as >> satisfactory as true generic markup because, at best, it is >> using more or less complicated, and more or less accurate, >> heuristics to get from a presentation form (e.g., a string in >> italics) to information about what it actually is (a book >> title? a string in a different language that one wants to set >> of? ... > > Word has a very powerful stylesheet feature so you can define > styles for semantic tags for titles of code or whatever, and > they're visible to export tools. At least 20 years ago the > publisher wanted to put a CD in one of my books which had all > of the contents and screen shots as HTML pages. The text was > all written in Word, a file per chapter, so I exported the > Word files as RTF (this was back when Word's native format was > undocumented tokens), and wrote some perl scripts that read > the RTF and turn it into HTML files with suitable links and > tags and so forth. It worked because it was my own Word, > edited by editors who understood that the style tags needed to > be there and the figure links needed to be in a fixed format, > but it was extremely fragile. > > The problem with this approach is that very few Word users > actually use styles beyond section headers to get the TOC and > I doubt we can change that. John, Thanks. That is consistent with what I was trying to say; the details are appreciated. Having tried to do some things with RTF many years ago and trying unsuccessfully to adapt styles to things I needed (yes, beyond a TOC) more recently, you have my admiration as well. john From nobody Wed Sep 2 11:23: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 80D463A0C50 for ; Wed, 2 Sep 2020 11:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, 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 08rLPitdMuc2 for ; Wed, 2 Sep 2020 11:23:03 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 DA5583A0C4C for ; Wed, 2 Sep 2020 11:23:02 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id p25so645369qkp.2 for ; Wed, 02 Sep 2020 11:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=xQzbVyY2RVkfyoSCsq6r8NOX4LyR7HTTAFq4dV0sMMI=; b=PV7WKQBSYXmC9Q/IBcyEhTQWF1o6r/DPrcB00zGtSl5jifpOAtosxdgS0lHP688Xww +9gx40PL0LoJLop+naH+fToTkouRtAHnn+afghsFN1GisalHEKynC68/7/HgUErSubFr 8QswD6YWuBk1ouJTBu29b7WV720QVYmPfLr5VFOC87kZVkn0ItarP1DGFYeMun7FdGDt 9ii5ytVHNKBDZSCuBQwrkq7noxmxw45dLoEFmvzlvkh97RO0018cBIYRLuDRlQmuBFlo JJWANryT6/mvqN5DWQbCJ3ZpN/Wo3A27VGR6NFp2SM+YXml5r7YrV5BhRfkzgUjlzNu3 NJXQ== 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; bh=xQzbVyY2RVkfyoSCsq6r8NOX4LyR7HTTAFq4dV0sMMI=; b=KnBJ9s5Gwii5yxjxs2p5qr1Ac9KMGQPmomYQWLCF7J6PxWZLsi3212+6IEVDojUNam bTfKxWiKT1FCOphfj0M57ESFJyvRrnl8IT4gyh6zUbcUjebIiNcwJ+9pFHR4XaLaDZ0z M6/cyWFd1zuv3225qNgO2CamnoUasoH4CFBV+aIq1cs5QAfFHkuepTYJiVQ6+75M7irV 9zHlsFmpnOb5vaNQY82SGUN2FOpDVhnhMzgpFbng5RTdUilXWxLjo8iWPSZcaF3nkO+t o3sTHDDRz12mbu35ug6eymn9I8AMDVmFFIDVgwU+OTnLCmqDwNSvQMMh/mZXHXodI/+e sliA== X-Gm-Message-State: AOAM531t7HsAoCd+4NVMhnNrmx91jUnMB/K+9zxY8pffdSAMDVOx1Xm0 rXOxp1lyIpNvK/0QB/woiSeOx1yqUH2liME6 X-Google-Smtp-Source: ABdhPJyxcJ3GeR+haXH6BoUDPIfbMjPfpIw+fNOrB69hWpwGwZEQzA8gAIvDGfapVrAThA8TQwTIsQ== X-Received: by 2002:ae9:f80f:: with SMTP id x15mr3241701qkh.341.1599070979764; Wed, 02 Sep 2020 11:22:59 -0700 (PDT) Received: from [192.168.1.20] (pool-71-114-22-128.washdc.fios.verizon.net. [71.114.22.128]) by smtp.gmail.com with ESMTPSA id a3sm152503qtj.21.2020.09.02.11.22.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2020 11:22:59 -0700 (PDT) To: Eric Rescorla Cc: rfced-future@iab.org References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> From: Michael StJohns Message-ID: <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> Date: Wed, 2 Sep 2020 14:22:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E1D1812CE8CE08A4188593E4" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Posted my draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Sep 2020 18:23:06 -0000 This is a multi-part message in MIME format. --------------E1D1812CE8CE08A4188593E4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/1/2020 3:16 PM, Eric Rescorla wrote: > Mike, > > Thanks for posting this document. As you say, it's probably > best to focus on big picture principles rather than details > With that in mind, there are several pieces of this that > do not sit well with me, as noted below. I figured. > > > RSE ACCOUNTABILITY > As I understand this document, the intent is to largely insulate the > RSE from external forces. I can see how you might think that, but I wouldn't put it that way.   Instead, its to make sure each participant in this process understands their authorities and responsibilities and to prevent the levels of unaccountability we currently have with respect to the RSOC and to a lesser extent the IAB. > > Specifically: > > 1. The RSEB (which nominally represents the RFC community) does not > seem to have any hiring and firing authority [0] Well, contrary to popular belief, neither the IAB nor the RSOC has ever had hiring or firing authority.  In the ISOC era, that rested with the HR department I believe.  In the LLC era it rests with the LLC .  What the IAB and RSOC did have was the ability to recommend or request the selection of a particular candidate by the hiring entity.  A good portion of the problem we encountered was them not understanding those limitations.   The LLC has indicated an intent to defer to the wishes of the IAB in this matter, but legally, the role still resides with the LLC. With respect to hiring, in the "new" model, the RSEB can recommend RSE candidates to the LLC, but if the LLC isn't able to come to an agreement on terms with that candidate, there's nothing the RSEB can do to change that.  That again was no different than before.  The LLC - legally, but probably not ever going to happen practically - could actually hire whoever they wanted irrespective of any input from the RSEB, IAB, IESG etc. > > 2. While this is a bit more unclear, the LLC does not seem to be > chartered to replace the RSE based on concerns about their > strategic choices. [1] > The LLC decides how it decides, and this document doesn't try to force them into any given model.   Once the contract  between the LLC and the RSE is written, it controls a good part of those decisions.  I would expect any contract to support termination for malfeasance, or not doing the work contracted.   I would expect any contract lawyer to yell at any attempt where the LLC attempts to control the "how" of the work being done. In any event, the LLC handles personnel and contract issues, and the  RSEB is the one that approves the publication of the RSE's work  and never the twain shall meet.  I doubt that the RSEB is going to approve said documents so if the strategy espoused by the RSE is at odds with what the RSEB members believe is the correct path.  If the RSEB is mostly against the RSE time and again, and the members of the RSEB make those concerns known to the LLC, its unlikely that the LLC will extend the contract.   Legally, this is no different that the current model, but with a black box warning being made to the LLC and RSEB on the limits of their authorities. > 3. Section 4.3 says: > >    While it is ultimately the LLC's decision, the RSE should be engaged >    via either a personal services contract or an employment contract for >    a given term.  Engagement as an at-will employee would not be >    appropriate for a senior-level resource with these strategic >    responsibilities and would not provide any measure of consistency and >    continuity over the RFC Series. > > While I can certainly understand how this arrangement might be > appealing to prospective RSEs, I do not believe it provides an > appropriate level of accountability to the community. Specifically, I > believe it is necessary to have the ultimate authority for stratetic > decisions be vested in the community (in this case this would be the > RSEB, ignoring for the moment its composition), but that does not > appear to be the case here. This issue is exacerbated by the fact > that the RSE is themselves a member of the RSEB. 1) Strategic decisions ARE vested in the community.  It takes at least  5 members of the RSEB  (which may or may not include the RSE) to approve a new document that describes changes in strategy.  The RSEB represents the community.  If it isn't written down, it didn't happen. 2) How is the fact that the RSEB is one member of 8, 6 of which are appointed either by the Nomcom, or by the streams exacerbating any issue (which AFAICT doesn't actually exist)? 3) The IETF has more of a republic feel to it than a democracy. We select various folk and delegate authority to them.  We hope they do what we want, but more times than not they do what they need to do.   The community has never had the ultimate authority for strategic decisions related to the RFC series - instead it's delegated to (actually wrong word - powers were claimed by) the IAB the right to select where standards were published.   When ISI got out of the RSE business, we put the "authority" into an appointed RSE (and later a hired RSE) who was required by the terms of their contract and the whole host of documents describing the relationship between the RSE and the community, to actually listen to what the community said, evaluate it with respect to what they knew about both the IETF and the needs of publication, and to synthesize  a solution that mostly met the needs of both. I don't expect that last part to change. 4) Continuity is important in this space - perhaps more so that you're willing to admit.  The model of an on-call consultant who sometimes comes in and answers questions does not support the idea of a dynamic and world-class publication system.  We can coast a while on the work that Heather and her predecessors have done, but I don't think we can do that for long and maintain the publication standards. 5) The RSE is accountable to their contract.  AFAICT the contracts in the past have been written to ensure the RSE pays attention to what the community says.   The community can yell at the RSE all it wants and the RSE will listen, but in the end, its the LLC that has to determine whether or not the RSE is fulfilling their contract.   You may not think of that as accountable to the community, but you seem to be implying that you want the RSE directly accountable to yourself in a way that's not legally possible. > > On the specific topic of the nature of the contract, ignoring the > specific question of at-will, it is quite common for senior level > executives (CEOs, etc.) to be simply replaced by the board, so I > don't think it follows that a senior-level resource with strategic > responsibilities should have high levels of security of employment. *sigh* No.   Senior level executives may generally be replaced by the board, but there's a cost to doing so and that cost is written into the contract.  Absent the executive failing to meet goals agreed to in the contract, the board either has to honor the contract, pay a kill fee, or go to court (or in one case I'm aware of - massively accelerate stock vesting).    That said, contracts do support probationary periods and terminations for convenience - all depends. > > > THE IETF'S ROLE > This structure seems to cast the IETF in a fairly small role, > for instance making the ISE chair. I recognize that there are > differences of opinion in how much weight we should give > the non-IETF portions of the RFC series, but given that the > IETF is by far the largest customer of the RFC series, I > believe that any structure should be designed to ensure that > the IETF's needs are met. This structure does not seem to me > to do so. *sheesh*  The RSEB contains 3 stream managers selected by the IAB, IESG and IRSG, an ISE selected by the IAB, 2 at large members selected by the Nomcom and 1 at large member selected by the ISOC.    Out of 8 members, 6 of them are selected either directly or indirectly by the IETF community.   I fail to see why you think that the IETF is being give short-shrift here? The RSEB is the body that signs off on documents that describe the RFC Series, its proceedures, publication process and evolution.   The RSE will in general be the author of those documents, but there is NOTHING preventing the RSEB from drafting its own documents, or asking for a third party to do so.   Those documents basically become the BCPs that control the RFC system. Later, Mike > > -Ekr > > > [0] "Note: As the RSEB has no contractual relationship with the RSE, the > RSEB does not exercise any form of work direction over the RSE nor > does it have any role in evaluating the RSE's performance." > > [1] "For avoidance of doubt: The LLC has no oversight or management role > with respect to the strategic development of the RFC Series. The > funding of the RSE, RPC and other tasks within the RSO does not > expand the LLC's current administrative remit to oversight of the RFC > Series." > > > > > On Mon, Aug 24, 2020 at 10:34 AM Michael StJohns > > wrote: > > See https://datatracker.ietf.org/doc/draft-stjohns-rfced-rseb/ > > My intent is to ignore comments for a few days rather than jump in > and > defend each comma and clause. > > Basically, this mostly leaves intact the operation of the RFC Series > Function while splitting the functions previously held by the IAB > into > two specific ones:  Strategic evolution of the series goes to a > purpose > built organization - the RFC Series Editorial Board, while the > contractual nitty gritty of paying for things gets firmly homed under > the LLC. > > Enjoy - Mike > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --------------E1D1812CE8CE08A4188593E4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/1/2020 3:16 PM, Eric Rescorla wrote:
Mike,

Thanks for posting this document. As you say, it's probably
best to focus on big picture principles rather than details
With that in mind, there are several pieces of this that
do not sit well with me, as noted below.

I figured.




RSE ACCOUNTABILITY
As I understand this document, the intent is to largely insulate the
RSE from external forces.

I can see how you might think that, but I wouldn't put it that way.   Instead, its to make sure each participant in this process understands their authorities and responsibilities and to prevent the levels of unaccountability we currently have with respect to the RSOC and to a lesser extent the IAB.



Specifically:

1. The RSEB (which nominally represents the RFC community) does not
seem to have any hiring and firing authority [0]

Well, contrary to popular belief, neither the IAB nor the RSOC has ever had hiring or firing authority.  In the ISOC era, that rested with the HR department I believe.  In the LLC era it rests with the LLC .  What the IAB and RSOC did have was the ability to recommend or request the selection of a particular candidate by the hiring entity.  A good portion of the problem we encountered was them not understanding those limitations.   The LLC has indicated an intent to defer to the wishes of the IAB in this matter, but legally, the role still resides with the LLC.

With respect to hiring, in the "new" model, the RSEB can recommend RSE candidates to the LLC, but if the LLC isn't able to come to an agreement on terms with that candidate, there's nothing the RSEB can do to change that.  That again was no different than before.  The LLC - legally, but probably not ever going to happen practically - could actually hire whoever they wanted irrespective of any input from the RSEB, IAB, IESG etc.




2. While this is a bit more unclear, the LLC does not seem to be
chartered to replace the RSE based on concerns about their
strategic choices. [1]

The LLC decides how it decides, and this document doesn't try to force them into any given model.   Once the contract  between the LLC and the RSE is written, it controls a good part of those decisions.  I would expect any contract to support termination for malfeasance, or not doing the work contracted.   I would expect any contract lawyer to yell at any attempt where the LLC attempts to control the "how" of the work being done.

In any event, the LLC handles personnel and contract issues, and the  RSEB is the one that approves the publication of the RSE's work  and never the twain shall meet.  I doubt that the RSEB is going to approve said documents so if the strategy espoused by the RSE is at odds with what the RSEB members believe is the correct path.  If the RSEB is mostly against the RSE time and again, and the members of the RSEB make those concerns known to the LLC, its unlikely that the LLC will extend the contract.   Legally, this is no different that the current model, but with a black box warning being made to the LLC and RSEB on the limits of their authorities.


3. Section 4.3 says:

   While it is ultimately the LLC's decision, the RSE should be engaged
   via either a personal services contract or an employment contract for
   a given term.  Engagement as an at-will employee would not be
   appropriate for a senior-level resource with these strategic
   responsibilities and would not provide any measure of consistency and
   continuity over the RFC Series.

While I can certainly understand how this arrangement might be
appealing to prospective RSEs, I do not believe it provides an
appropriate level of accountability to the community. Specifically, I
believe it is necessary to have the ultimate authority for stratetic
decisions be vested in the community (in this case this would be the
RSEB, ignoring for the moment its composition), but that does not
appear to be the case here. This issue is exacerbated by the fact
that the RSE is themselves a member of the RSEB.

1) Strategic decisions ARE vested in the community.  It takes at least  5 members of the RSEB  (which may or may not include the RSE) to approve a new document that describes changes in strategy.  The RSEB represents the community.  If it isn't written down, it didn't happen.

2) How is the fact that the RSEB is one member of 8, 6 of which are appointed either by the Nomcom, or by the streams exacerbating any issue (which AFAICT doesn't actually exist)?

3) The IETF has more of a republic feel to it than a democracy.  We select various folk and delegate authority to them.  We hope they do what we want, but more times than not they do what they need to do.   The community has never had the ultimate authority for strategic decisions related to the RFC series - instead it's delegated to (actually wrong word - powers were claimed by) the IAB the right to select where standards were published.   When ISI got out of the RSE business, we put the "authority" into an appointed RSE (and later a hired RSE) who was required by the terms of their contract and the whole host of documents describing the relationship between the RSE and the community, to actually listen to what the community said, evaluate it with respect to what they knew about both the IETF and the needs of publication, and to synthesize  a solution that mostly met the needs of both.  I don't expect that last part to change.

4) Continuity is important in this space - perhaps more so that you're willing to admit.  The model of an on-call consultant who sometimes comes in and answers questions does not support the idea of a dynamic and world-class publication system.  We can coast a while on the work that Heather and her predecessors have done, but I don't think we can do that for long and maintain the publication standards.

5) The RSE is accountable to their contract.  AFAICT the contracts in the past have been written to ensure the RSE pays attention to what the community says.   The community can yell at the RSE all it wants and the RSE will listen, but in the end, its the LLC that has to determine whether or not the RSE is fulfilling their contract.   You may not think of that as accountable to the community, but you seem to be implying that you want the RSE directly accountable to yourself in a way that's not legally possible.


On the specific topic of the nature of the contract, ignoring the
specific question of at-will, it is quite common for senior level
executives (CEOs, etc.) to be simply replaced by the board, so I
don't think it follows that a senior-level resource with strategic
responsibilities should have high levels of security of employment.

*sigh* No.   Senior level executives may generally be replaced by the board, but there's a cost to doing so and that cost is written into the contract.  Absent the executive failing to meet goals agreed to in the contract, the board either has to honor the contract, pay a kill fee, or go to court (or in one case I'm aware of - massively accelerate stock vesting).    That said, contracts do support probationary periods and terminations for convenience - all depends.



THE IETF'S ROLE
This structure seems to cast the IETF in a fairly small role,
for instance making the ISE chair. I recognize that there are
differences of opinion in how much weight we should give
the non-IETF portions of the RFC series, but given that the
IETF is by far the largest customer of the RFC series, I
believe that any structure should be designed to ensure that
the IETF's needs are met. This structure does not seem to me
to do so.

*sheesh*  The RSEB contains 3 stream managers selected by the IAB, IESG and IRSG, an ISE selected by the IAB, 2 at large members selected by the Nomcom and 1 at large member selected by the ISOC.    Out of 8 members, 6 of them are selected either directly or indirectly by the IETF community.   I fail to see why you think that the IETF is being give short-shrift here?

The RSEB is the body that signs off on documents that describe the RFC Series, its proceedures, publication process and evolution.   The RSE will in general be the author of those documents, but there is NOTHING preventing the RSEB from drafting its own documents, or asking for a third party to do so.   Those documents basically become the BCPs that control the RFC system.

Later, Mike



-Ekr


[0] "Note: As the RSEB has no contractual relationship with the RSE, the
RSEB does not exercise any form of work direction over the RSE nor
does it have any role in evaluating the RSE's performance."

[1] "For avoidance of doubt: The LLC has no oversight or management role
with respect to the strategic development of the RFC Series.  The
funding of the RSE, RPC and other tasks within the RSO does not
expand the LLC's current administrative remit to oversight of the RFC
Series."


                       

On Mon, Aug 24, 2020 at 10:34 AM Michael StJohns <msj@nthpermutation.com> wrote:
See https://datatracker.ietf.org/doc/draft-stjohns-rfced-rseb/

My intent is to ignore comments for a few days rather than jump in and
defend each comma and clause.

Basically, this mostly leaves intact the operation of the RFC Series
Function while splitting the functions previously held by the IAB into
two specific ones:  Strategic evolution of the series goes to a purpose
built organization - the RFC Series Editorial Board, while the
contractual nitty gritty of paying for things gets firmly homed under
the LLC.

Enjoy - Mike


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


--------------E1D1812CE8CE08A4188593E4-- From nobody Fri Sep 4 00:08: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 711073A0F23 for ; Fri, 4 Sep 2020 00:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.948, 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 ogC3SuQ9pKcf for ; Fri, 4 Sep 2020 00:08:54 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400112.outbound.protection.outlook.com [40.107.140.112]) (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 BD7FA3A0F1F for ; Fri, 4 Sep 2020 00:08:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cfXTFFebJ8KjKjIC+RwIiAYpg2VEoVdIYiTdzFuIflwydr+gCeabfVdWXfmGCHnXwcSuc+TscRRPOMyCUYAB5rqdKgKIOOX8B7+q7Tm0R153IaZ3zKMcSvHIfYMMOXOggLMM8jW+5x5cGqWYIw8uVw3K5ejkujT6RaNzuQ/HbtCUQu+XjP7eEaAfHn9Gb+aeedffMJxIjeGiUChNcv1bEO1PdPDlbB9e/sND2Oo+DEzZqkG0Lm5UNboe817e/aSbAqcSpFGic3OEW7raI+bgFCeGWBMYC5oC1Jaa0wTGBVDMCdF/yBThWmVGYmI/MaPCbihLYGEyawyorDs2DNF9lg== 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=gusSVEqlfgo+ll4jz3hwhYXY3y0KrZFfSKbJoqr73cg=; b=eKqQ1dH51uOAAvluC6wiREq5l7i/ez+4hjsD6eKwgn17yQEgkcfyHYXTfCiHh4J5G3aKEbSAeJXGi3KtC82gPgxt9azhhy8CuCcCpx5kXP9cavAx6435Q0Tt9DLv99k1YVhMzp6sO9lIFKKLR3L2XaywJuHLIZ+xbvb1u8r/KEAFcTgkJ4GKEOSLuGI5/09hVDMSYzeSRYqxgP9OS2aYGJxdofUmtvRzfWzNibHX4XE/pdUURg3ymejkfmzRNCTwl5iqPbi34xJe6ZTDrBMyGl7d+yOlJK8ZJoMgqtsh48lUzwXP6JA92/ZloF0FAk8LGWDPVzXcRNeONyk3hv0QiQ== 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=gusSVEqlfgo+ll4jz3hwhYXY3y0KrZFfSKbJoqr73cg=; b=NzzHNUZ1HKl3PIRyn4TN/qMmYXQPBqkz5MYCoybRkkQ0PkWVeL6/OdmAbv/6f7Kxnb10weqk2WoFCjeAA2RkkrgqmQxCVQERWK7OVEEnM/smZ0IDNuRNiUloUbfTVyN+L785tR0VhbKVeKeMIdDOnGL3Z8DTig0FfdwKkWyOaGc= 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 OSAPR01MB1780.jpnprd01.prod.outlook.com (2603:1096:603:32::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.16; Fri, 4 Sep 2020 07:08:47 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::50b8:6d53:1b35:2ef7]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::50b8:6d53:1b35:2ef7%6]) with mapi id 15.20.3348.016; Fri, 4 Sep 2020 07:08:47 +0000 To: Martin Thomson , Brian E Carpenter , rfced-future@iab.org References: <159702718090.11663.7570202119633420369@ietfa.amsl.com> <18b04242-0867-4abc-ac9d-7dc7875675e2@www.fastmail.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <5c28ddcd-7d48-9c73-a2da-68084963ce4d@it.aoyama.ac.jp> Date: Fri, 4 Sep 2020 16:08:43 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 In-Reply-To: <18b04242-0867-4abc-ac9d-7dc7875675e2@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYAPR01CA0206.jpnprd01.prod.outlook.com (2603:1096:404:29::26) 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] (114.182.253.12) by TYAPR01CA0206.jpnprd01.prod.outlook.com (2603:1096:404:29::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.20 via Frontend Transport; Fri, 4 Sep 2020 07:08:47 +0000 X-Originating-IP: [114.182.253.12] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c3df9b76-4315-433d-8bb6-08d850a15e2a X-MS-TrafficTypeDiagnostic: OSAPR01MB1780: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OCwCiJO0adQoF92sx2mokwVz5qGTj6XnGIcanKOw2EEOrVlBR8MMYBcjNBfQF1op+rI6Qk40+RKH0plScE4oRDeOOf4FF7BAFc4HBJCiqwU2R8ZLFnQveG+QuFt+A355O5pqDMkHFfepLItsjp/E2S8kocvTIFrGwQMXVdR0twlS2iq8CbsJ+zSudkCHEI9lQ5snbyi3bbmsNoL+SV6Ama6GGMx/if29oS1WZyR4tKUe18F5ib3GNtvttUHIMgNcg49kgUGFkQks0n6BT9wXC9UpgtbUhs3ce/e/Ojo1LYtO/23Re2yGNhUPuhI91lMlqueTevJWleTAGQd54vQTutKcw52f1umf2F9s3zi8US5LYjoMq3lPrZRSjWLaoojQ 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; SFS:(376002)(396003)(346002)(39840400004)(136003)(366004)(83380400001)(8676002)(478600001)(36916002)(4744005)(8936002)(52116002)(53546011)(86362001)(26005)(186003)(6666004)(16526019)(2906002)(66946007)(66476007)(110136005)(66556008)(16576012)(2616005)(31686004)(6486002)(956004)(316002)(786003)(5660300002)(31696002)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: eRPWBKtzE/ze36ftnF9h9AekLIim062Ps1CdutMcON/oPmH72I8VwJeGsrXXVKiaqQAcQZz1wDn2lxHyr6zzfosesGyXy2UAvI141vN8nZDdSm7SytjYua8/8WUQSPF4J0yxPdULVeKWK6ozszbGWJOTfSxnajTVPSr3tJtpEppbdcHwliBNQRoYNFuWzL0mPbM0lOvWuQPoX7m0/aO2jFpH2kkDW2RqlvdmuhT+iTz7LmEeK/6gRGxzdn4JUlTHGsh8svavLz/sHTOljWk3GwsgAfYpNnSzpKgHb5D/7AiE9162luDLQL0Ow6CbBxrHoqaKG7/Q/Pj+rsEHYPmV4GMHpILJbEUBQdUu5SvEEworeinmM+igRXmfzalGQtNorXPtvke2xzwyCjsusD9kKBVoSxJqXF+d6U+KHEoV3oT61UTVqO4b/qESVnqPc4Q6/9BANBuxr6Fwxva4sLGf0ID+uT4nVsA6GPSsAoWH1J0XSyAZwfUTTEBJ27LR5FyfBEOfM9dQnlrvGn/qzk6yAHVG5PlXkkm1zL9trQNNqkzDXRnFHCr2FTNSRQbRKkdec9neN9WjGzehEUb0D8wIGefzvhtuicxJJ61WT7gMX8fe0ps3IlDgscl5TosUp0Axf3jBLk7h6xkoL1asQ91MWQ== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: c3df9b76-4315-433d-8bb6-08d850a15e2a X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2020 07:08:47.4637 (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: E4hnKjnl7MU1ugVWxi3WtiltOtjRhlZQddIrBqNU+Lv1G+D+5cm3I8JPJFxwtUnE96a1CZNbphnNnJCBOMeluw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB1780 Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-thomson-rfced-model-01.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 07:08:55 -0000 Hello Martin, Brian, others, Sorry to be very late with a reply on a thread. On 17/08/2020 10:27, Martin Thomson wrote: > Hi Brian, > > I'm glad to see that we only disagree on relatively minor points. > > I think that your main points are: > 2. You are concerned about style guide (and similar) maintenance. I had imagined that this would follow the usual model for things that are ostensibly developed in working groups. Those most invested in its maintenance would supply the work, but the product would be discussed and approved by the working group. I can easily imagine that this could be made to work for an overall style guide that is updated once a year or so. But it doesn't work for for more day-to-day issues, which I understand come up quite regularly. Regards, Martin. From nobody Fri Sep 4 09:47: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 B7F7C3A0A9C for ; Fri, 4 Sep 2020 09:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okO4U7LbqM0Y for ; Fri, 4 Sep 2020 09:47:20 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A666F3A0906 for ; Fri, 4 Sep 2020 09:47:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Bjk9h3QpBz1pBFX for ; Fri, 4 Sep 2020 09:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1599238040; bh=sNS4Z2wxmXQbjww1ZcrZag4Kyph/0ruQLnWrSLq7RDI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=eHRv9IS6DH/PoCNLsBjs+AlIfRBy8pH3WRlgwribWpolw8BEnvHOGh+C1uzaNhI36 /Y63v2+OrTtbGVyMbZxq/8hnt5ttGB6Xli7Uh4dZXQ5esjqLi8uXx5Q+UqDdZ1Af96 8GkWey5d+8jGKgdQ/xecJqHPKRRdl/TqQafCb4Ao= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4Bjk9h0S7Nz1nvbC for ; Fri, 4 Sep 2020 09:47:19 -0700 (PDT) To: rfced-future@iab.org References: <159702718090.11663.7570202119633420369@ietfa.amsl.com> <18b04242-0867-4abc-ac9d-7dc7875675e2@www.fastmail.com> <5c28ddcd-7d48-9c73-a2da-68084963ce4d@it.aoyama.ac.jp> From: "Joel M. Halpern" Message-ID: <77b8542e-c57b-ba81-c3f4-785143884ab7@joelhalpern.com> Date: Fri, 4 Sep 2020 12:47:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <5c28ddcd-7d48-9c73-a2da-68084963ce4d@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-thomson-rfced-model-01.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 16:47:22 -0000 From my perspective there is one aspect that makes Martin Thomsom's suggestion for using a WG to do the style guide almost workable, and several aspects that do not. The good thing is that we do not update the style guide annually. The first bad thing is that I have not seen a working group that can update a document even bi-annually. The next problem that occurs to me is that a style guide is often a judgement call. There is not a technical right answer. But an answer is generally needed. The IETF WG process is consistently very bad at that sort of decision. Witness the mess for almost every process decision in the IETF. And the WG process does not allow the chairs to simply declare a conclusion when there is not rough consensus. Yes, in general we want the RFC series decisions to be responsive to the broad community rough consensus. But we also need a mechanism that actually makes informed decisions to drive the publication process. Yours, Joel On 9/4/2020 3:08 AM, Martin J. Dürst wrote: > Hello Martin, Brian, others, > > Sorry to be very late with a reply on a thread. > > On 17/08/2020 10:27, Martin Thomson wrote: >> Hi Brian, >> >> I'm glad to see that we only disagree on relatively minor points. >> >> I think that your main points are: > >> 2. You are concerned about style guide (and similar) maintenance.  I >> had imagined that this would follow the usual model for things that >> are ostensibly developed in working groups.  Those most invested in >> its maintenance would supply the work, but the product would be >> discussed and approved by the working group. > > I can easily imagine that this could be made to work for an overall > style guide that is updated once a year or so. But it doesn't work for > for more day-to-day issues, which I understand come up quite regularly. > > Regards,   Martin. > From nobody Fri Sep 4 15:26:33 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D163A0C77 for ; Fri, 4 Sep 2020 15:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, 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 Rdeq-fcxOafg for ; Fri, 4 Sep 2020 15:26:30 -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 D96CA3A0C75 for ; Fri, 4 Sep 2020 15:26:30 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id n3so5665052pjq.1 for ; Fri, 04 Sep 2020 15:26:30 -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=cRvsZgNW2OAc/yR+AlWZSyCa+XYhKaowveC7wwm47xc=; b=WArhHK0ICivlqSzLg7fVp9whrKX+/bJmyL3wlZkHTBYm40b+32hamNYW9LXvlnllVl 3Uitzw0fvxBtFHjaJDW74JZtHI/RKAvv4mIWei7KapWobC2xmTSjUFifqk49q7m4zloc 3OCm2QWMBdjbp2ox8mWXhWU+9pDDRZFslGgrvW35jnRAh90PbSpSzyXaT9sde4flEjk/ Ru/I6v5XOd53RMWumLSxHvOfxUrU1dOrobSRC6mISjHI5uUSoMj3G/GwtH0EsDk8u7KG gXKEPp4fyQHFFf5rKHUYOe+g8uIOVJi7BLE3csPRjcujQVQofGlVogDvZvqDvf3Khn/b o2dg== 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=cRvsZgNW2OAc/yR+AlWZSyCa+XYhKaowveC7wwm47xc=; b=BNPP0lCi6zA0QtdhhTM0Ympf2gVokoEO0SLg+qOFtPWsByD3Z9R630ElUMg+B+pD5f iNHylmwPyETi6lHp339AqQF0E/Ln2Ys9pdxB1mRlbo+2tYc1PqTcJRV9EKV/ZgbPaAMO UHyOTIXeimZqhoaLbkSMo3+eFoVqDV8JXGASkwqaMyxtYwWlKGWeHhHg4X9uOD7hBQ9/ ACxuh7GLs1OXCqbdFo0cKuksdNDkcGrmcaiGPuy7B1iSq1zDBtZ8smKWXkRmdBU9+qmB mNsG9HJaMC7/1aMr2me87oqrhIQK8Yrk8LH1QS2ehafOJSYyWj+RLQzrFgBLZtFVg5xJ Zq1Q== X-Gm-Message-State: AOAM532JkQhSfMT8+DJR5RWu0x4TK8y0m/DBtArXC6TrH97HvGtkGuR4 u6ThAYYHKhgmvAmaruc8chXML8ZKjFbwLA== X-Google-Smtp-Source: ABdhPJxlavOJ4XE+E8sLVoC3rPA/5sQwcuL0344J7GDE82VHvtbTCz9diP4qgzif0dCSqCX87A80hA== X-Received: by 2002:a17:90a:c7:: with SMTP id v7mr10030246pjd.139.1599258389997; Fri, 04 Sep 2020 15:26:29 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id n2sm7648293pfa.182.2020.09.04.15.26.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Sep 2020 15:26:29 -0700 (PDT) To: "Joel M. Halpern" , rfced-future@iab.org References: <159702718090.11663.7570202119633420369@ietfa.amsl.com> <18b04242-0867-4abc-ac9d-7dc7875675e2@www.fastmail.com> <5c28ddcd-7d48-9c73-a2da-68084963ce4d@it.aoyama.ac.jp> <77b8542e-c57b-ba81-c3f4-785143884ab7@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Sat, 5 Sep 2020 10:26: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: <77b8542e-c57b-ba81-c3f4-785143884ab7@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-thomson-rfced-model-01.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 22:26:32 -0000 Hi Joel, On 05-Sep-20 04:47, Joel M. Halpern wrote: > From my perspective there is one aspect that makes Martin Thomsom's=20 > suggestion for using a WG to do the style guide almost workable, and=20 > several aspects that do not. >=20 > The good thing is that we do not update the style guide annually. >=20 > The first bad thing is that I have not seen a working group that can=20 > update a document even bi-annually. That's where I believe that a nominated RFC Series Advisor comes in. See https://tools.ietf.org/html/draft-carpenter-rfced-model-00#section-8 and in particular (emphasis added): Further, the RSA is expected to ensure that RSAWG consensus is well documented and communicated to the community, the LLC, and the REP. *This may include document authorship.* The RSA is expected to be a thought leader for improvements to the RFC Series, for developing vision and policy documents, and for *establishing community consensus for them.* I would indeed expect the style guide to remain a living document, as it is today. Given that style guide issues have often been discussed on rfc-interest@rfc-editor.org (an open list) I don't even see much of a change in practice here. > The next problem that occurs to me is that a style guide is often a=20 > judgement call. There is not a technical right answer. But an answer = > is generally needed. The IETF WG process is consistently very bad at=20 > that sort of decision. Witness the mess for almost every process=20 > decision in the IETF. And the WG process does not allow the chairs to = > simply declare a conclusion when there is not rough consensus. On the other hand, they are supposed to facilitate the process. > Yes, in general we want the RFC series decisions to be responsive to th= e=20 > broad community rough consensus. But we also need a mechanism that=20 > actually makes informed decisions to drive the publication process. Agreed. But on the other hand, we say we don't want monarchs and presiden= ts. Brian >=20 > Yours, > Joel >=20 > On 9/4/2020 3:08 AM, Martin J. D=C3=BCrst wrote: >> Hello Martin, Brian, others, >> >> Sorry to be very late with a reply on a thread. >> >> On 17/08/2020 10:27, Martin Thomson wrote: >>> Hi Brian, >>> >>> I'm glad to see that we only disagree on relatively minor points. >>> >>> I think that your main points are: >> >>> 2. You are concerned about style guide (and similar) maintenance.=C2=A0= I=20 >>> had imagined that this would follow the usual model for things that=20 >>> are ostensibly developed in working groups.=C2=A0 Those most invested= in=20 >>> its maintenance would supply the work, but the product would be=20 >>> discussed and approved by the working group. >> >> I can easily imagine that this could be made to work for an overall=20 >> style guide that is updated once a year or so. But it doesn't work for= =20 >> for more day-to-day issues, which I understand come up quite regularly= =2E >> >> Regards,=C2=A0=C2=A0 Martin. >> >=20 From nobody Sat Sep 5 15:50: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 110163A134B for ; Sat, 5 Sep 2020 15:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, 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=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 e-glHmoHZhTq for ; Sat, 5 Sep 2020 15:50:53 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 AC37E3A134A for ; Sat, 5 Sep 2020 15:50:52 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id w3so11938277ljo.5 for ; Sat, 05 Sep 2020 15:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9KPtPAnTK3c1tjGYdJhCRaDwVWGf6ZVzUwuOnZUPajA=; b=YAycJLcPgp1G+5s7J3k+o4Yo26rwa4viE8GLFnqQxsEPGcdHzT5lL4XlMq9VU1NPwV trP+z6Beu8aezzZETJdV73pXcwQVOOMOeNEmUug1nvvUoMzgvDR6dHfEfyRcPS/fAMnd HsdS0mof4MQ0oFpzbRFKiZAjydMOYZfAQLPxIAbZRrnVhrMpXD53DPPigFY+ndaRlStJ mtgrN1MhImVKkYapAQNKQsptI4TIFe8eahrWKjii79jdY6bpNWnDweO5kQ+foWKCnaVK Wu9YvpF+/EcPUORJpQ0mTLwFlW18krPpJpdDHEiWgaewQNrvYJTwO/kmeEtL9WwifZMn DqFg== 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=9KPtPAnTK3c1tjGYdJhCRaDwVWGf6ZVzUwuOnZUPajA=; b=MBTtmALou2s4AQXTjJzbaPoO8+Wof6uj0Vt0QEf09iilOZ8lBoqPhToHCeFxwC4lay FU+aYS7NTf8fV61tn8PvMcFNDANmxz1rKR6ZbnzgPEDnibyGLibTrA0cknx1S59UUQof x3LppV7ynfX7vrJibyMBtdCRBC85MuMze1zdK2Vlw8J36gU/b3oHatDcReQntRuB3OjK 7WDs8xnz5GlWHeUJEuOwLMNnAJwvP5ij1iM/mfKdLIetd1ly/UFKhXWtm27vWAkoYElM 1Mn1LuTLOzb9Ax7Wr0ezagw5NmvuHICSQsGj3TrS3ZVV1i7oE+DBg6a/aNi7drJuHi5o 297Q== X-Gm-Message-State: AOAM5314fC0bmooYwIYZyU0U6niuxDmTH/7dDUXUp63mMYzXcdHNbUe+ OUvkB5wRLgR6OzAjKj4msbtvDmVT+VSDWJ9Nw1fg7g== X-Google-Smtp-Source: ABdhPJwnDqtyHzbaBRcOHUfq1GlRB/68bp0QCyEeGRxHKJtOljzEX1CNtGdmmvfSpn9yP6HFw4KnbmJapTnLB+hovjw= X-Received: by 2002:a2e:8850:: with SMTP id z16mr6718439ljj.184.1599346250640; Sat, 05 Sep 2020 15:50:50 -0700 (PDT) MIME-Version: 1.0 References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> In-Reply-To: <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> From: Eric Rescorla Date: Sat, 5 Sep 2020 15:50:13 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000002480ff05ae98d172" Archived-At: Subject: Re: [Rfced-future] Posted my draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 Sep 2020 22:50:55 -0000 --0000000000002480ff05ae98d172 Content-Type: text/plain; charset="UTF-8" [Trying to cut down to the points that I think are at the heart of the matter, which does not mean that I necessarily agree with your responses.] On Wed, Sep 2, 2020 at 11:23 AM Michael StJohns wrote: > On 9/1/2020 3:16 PM, Eric Rescorla wrote: > > Specifically: > > > > 1. The RSEB (which nominally represents the RFC community) does not > > seem to have any hiring and firing authority [0] > > Well, contrary to popular belief, neither the IAB nor the RSOC has > ever had hiring or firing authority. In the ISOC era, that rested > with the HR department I believe. In the LLC era it rests with the > LLC . What the IAB and RSOC did have was the ability to recommend > or request the selection of a particular candidate by the hiring > entity. A good portion of the problem we encountered was them not > understanding those limitations. The LLC has indicated an intent to > defer to the wishes of the IAB in this matter, but legally, the role > still resides with the LLC. > > With respect to hiring, in the "new" model, the RSEB can recommend > RSE candidates to the LLC, but if the LLC isn't able to come to an > agreement on terms with that candidate, there's nothing the RSEB can > do to change that. That again was no different than before. The > LLC - legally, but probably not ever going to happen practically - > could actually hire whoever they wanted irrespective of any input > from the RSEB, IAB, IESG etc. I agree with some of this and disagree with other parts: 1. Yes, I imagine that the LLC (and ISOC before it) could legally hire anyone they wanted and give them any title they wanted. However, this would not make them the RSE for the purposes of our process (as was discussed in detail in IASA 2.0). Here is the relevant text from 6635: The RSE is appointed by the IAB, but formally hired by the IAOC. The IAB delegates the direct oversight over the RSE to the RSOC, which it appoints. 2. The purpose of these documents is in part to memorialize our understanding of the terms under which the LLC is expected to act. So, while 6635 I think makes clear that the LLC ought to contract with/hire either the person that the IAB/RSOC selects or nobody, your document appears to change that. But perhaps I've misunderstood you. Hence some questions about your intent: - If the LLC ignored the RSEB's chosen candidate and selected their own, would they be able to act as the RSE for the purposes of this process, such as chairing the RSEB? - If the RSEB wishes to replace the current RSE at the end of their contract, what mechanism do they use to do that and what impact does that have on the LLC (as in the first question)? > In any event, the LLC handles personnel and contract issues, and the > RSEB is the one that approves the publication of the RSE's work and > never the twain shall meet. I doubt that the RSEB is going to > approve said documents so if the strategy espoused by the RSE is at > odds with what the RSEB members believe is the correct path. If the > RSEB is mostly against the RSE time and again, and the members of > the RSEB make those concerns known to the LLC, its unlikely that the > LLC will extend the contract. As noted above, this seems to me to be a material change from the existing 6635 situation in which the LLC would not be expected to independently determine the suitability of an RSE who the RSOC had decided not to engage. Again, I'm speaking here of the implications for our process, not what the LLC's legal rights are. But perhaps this is just a matter of me not understanding what you have written down. Let's consider a concrete case: The RSEB \setminus RSE wants to proceed in a certain strategic direction (inscribing the RSEs on clay tablets say). They ask the RSE to develop the plan to do so, but the RSE opposes it and so refuses to do so in a timely fashion. What, if any, recourse does the RSEB have? > > 3. Section 4.3 says: > > > > While it is ultimately the LLC's decision, the RSE should be engaged > > via either a personal services contract or an employment contract for > > a given term. Engagement as an at-will employee would not be > > appropriate for a senior-level resource with these strategic > > responsibilities and would not provide any measure of consistency and > > continuity over the RFC Series. > > > > While I can certainly understand how this arrangement might be > > appealing to prospective RSEs, I do not believe it provides an > > appropriate level of accountability to the community. Specifically, I > > believe it is necessary to have the ultimate authority for stratetic > > decisions be vested in the community (in this case this would be the > > RSEB, ignoring for the moment its composition), but that does not > > appear to be the case here. This issue is exacerbated by the fact > > that the RSE is themselves a member of the RSEB. > > 1) Strategic decisions ARE vested in the community. It takes at > least 5 members of the RSEB (which may or may not include the RSE) > to approve a new document that describes changes in strategy. The > RSEB represents the community. If it isn't written down, it didn't > happen. Sure, and that prevents the RSE from unilaterally doing bad things but it does not prevent the RSE from effectively stalling good things they don't agree with. See the example I gave above. > 4) Continuity is important in this space - perhaps more so that > you're willing to admit. The model of an on-call consultant who > sometimes comes in and answers questions does not support the idea > of a dynamic and world-class publication system. We can coast a > while on the work that Heather and her predecessors have done, but I > don't think we can do that for long and maintain the publication > standards. Indeed, we disagree on this point, but I don't think each of us offering our unsupported assertions is going to get us very far, so I'll refrain from arguing it at present. I will, however, note that neither "dynamic" nor "world-class" are the words that come to mind when I think of our present publication system. -Ekr --0000000000002480ff05ae98d172 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Trying to cut down to the points that I = think are at the heart
of the matter, which does not mean that I necessa= rily agree
with your responses.]

On Wed, Sep 2, 2020 at 11:23 AM = Michael StJohns <msj@nthpermut= ation.com> wrote:
> On 9/1/2020 3:16 PM, Er= ic Rescorla wrote:
> > Specifically:
> >
> > 1. = The RSEB (which nominally represents the RFC community) does not
> &g= t; seem to have any hiring and firing authority [0]
>
> Well, = contrary to popular belief, neither the IAB nor the RSOC has
> ever h= ad hiring or firing authority.=C2=A0 In the ISOC era, that rested
> w= ith the HR department I believe.=C2=A0 In the LLC era it rests with the
= > LLC .=C2=A0 What the IAB and RSOC did have was the ability to recommen= d
> or request the selection of a particular candidate by the hiring<= br>> entity.=C2=A0 A good portion of the problem we encountered was them= not
> understanding those limitations.=C2=A0 The LLC has indicated a= n intent to
> defer to the wishes of the IAB in this matter, but lega= lly, the role
> still resides with the LLC.
>
> With res= pect to hiring, in the "new" model, the RSEB can recommend
>= ; RSE candidates to the LLC, but if the LLC isn't able to come to an> agreement on terms with that candidate, there's nothing the RSEB = can
> do to change that.=C2=A0 That again was no different than befor= e.=C2=A0 The
> LLC - legally, but probably not ever going to happen p= ractically -
> could actually hire whoever they wanted irrespective o= f any input
> from the RSEB, IAB, IESG etc.

I agree with some = of this and disagree with other parts:

1. Yes, I imagine that the LL= C (and ISOC before it) could legally hire
anyone they wanted and give th= em any title they wanted. However, this
would not make them the RSE for = the purposes of our process (as was
discussed in detail in IASA 2.0). He= re is the relevant text from
6635:

=C2=A0 =C2=A0The RSE is appoin= ted by the IAB, but formally hired by the IAOC.=C2=A0 The
=C2=A0 =C2=A0I= AB delegates the direct oversight over the RSE to the RSOC, which it
=C2= =A0 =C2=A0appoints.

2. The purpose of these documents is in part to = memorialize our
understanding of the terms under which the LLC is expect= ed to act.
So, while 6635 I think makes clear that the LLC ought to cont= ract
with/hire either the person that the IAB/RSOC selects or nobody,your document appears to change that. But perhaps I've misunderstoodyou. Hence some questions about your intent:

- If the LLC ignored = the RSEB's chosen candidate and selected
=C2=A0 their own, would the= y be able to act as the RSE for the
=C2=A0 purposes of this process, suc= h as chairing the RSEB?

- If the RSEB wishes to replace the current = RSE at the end
=C2=A0 of their contract, what mechanism do they use to d= o that
=C2=A0 and what impact does that have on the LLC (as in the
= =C2=A0 first question)?


> In any event, the LLC handles perso= nnel and contract issues, and the
> RSEB is the one that approves the= publication of the RSE's work and
> never the twain shall meet. = I doubt that the RSEB is going to
> approve said documents so if the = strategy espoused by the RSE is at
> odds with what the RSEB members = believe is the correct path.=C2=A0 If the
> RSEB is mostly against th= e RSE time and again, and the members of
> the RSEB make those concer= ns known to the LLC, its unlikely that the
> LLC will extend the cont= ract.

As noted above, this seems to me to be a material change from<= br>the existing 6635 situation in which the LLC would not be expected
to= independently determine the suitability of an RSE who the
RSOC had deci= ded not to engage. Again, I'm speaking here of the
implications for = our process, not what the LLC's legal rights
are.

But perhaps= this is just a matter of me not understanding what
you have written dow= n. Let's consider a concrete case:

The RSEB \setminus RSE wants = to proceed in a certain strategic
direction (inscribing the RSEs on clay= tablets say). They ask the RSE
to develop the plan to do so, but the RS= E opposes it and so refuses to
do so in a timely fashion. What, if any, = recourse does the RSEB have?



> > 3. Section 4.3 says:<= br>> >
> > =C2=A0 =C2=A0While it is ultimately the LLC's= decision, the RSE should be engaged
> > =C2=A0 =C2=A0via either a= personal services contract or an employment contract for
> > =C2= =A0 =C2=A0a given term.=C2=A0 Engagement as an at-will employee would not b= e
> > =C2=A0 =C2=A0appropriate for a senior-level resource with th= ese strategic
> > =C2=A0 =C2=A0responsibilities and would not prov= ide any measure of consistency and
> > =C2=A0 =C2=A0continuity ove= r the RFC Series.
> >
> > While I can certainly understan= d how this arrangement might be
> > appealing to prospective RSEs,= I do not believe it provides an
> > appropriate level of accounta= bility to the community. Specifically, I
> > believe it is necessa= ry to have the ultimate authority for stratetic
> > decisions be v= ested in the community (in this case this would be the
> > RSEB, i= gnoring for the moment its composition), but that does not
> > app= ear to be the case here. This issue is exacerbated by the fact
> >= that the RSE is themselves a member of the RSEB.
>
> 1) Strat= egic decisions ARE vested in the community.=C2=A0 It takes at
> least= 5 members of the RSEB (which may or may not include the RSE)
> to ap= prove a new document that describes changes in strategy.=C2=A0 The
> = RSEB represents the community.=C2=A0 If it isn't written down, it didn&= #39;t
> happen.

Sure, and that prevents the RSE from unilatera= lly doing bad things but
it does not prevent the RSE from effectively st= alling good things they
don't agree with. See the example I gave abo= ve.


> 4) Continuity is important in this space - perhaps more= so that
> you're willing to admit.=C2=A0 The model of an on-call= consultant who
> sometimes comes in and answers questions does not s= upport the idea
> of a dynamic and world-class publication system.=C2= =A0 We can coast a
> while on the work that Heather and her predecess= ors have done, but I
> don't think we can do that for long and ma= intain the publication
> standards.

Indeed, we disagree on thi= s point, but I don't think each of us
offering our unsupported asser= tions is going to get us very far, so
I'll refrain from arguing it a= t present. I will, however, note that
neither "dynamic" nor &q= uot;world-class" are the words that come to mind
when I think of ou= r present publication system.

-Ekr



--0000000000002480ff05ae98d172-- From nobody Sat Sep 5 17:02:38 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5172B3A0DBD for ; Sat, 5 Sep 2020 17:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, 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 dCL_PolX3Mtp for ; Sat, 5 Sep 2020 17:02:33 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 91A903A0DAA for ; Sat, 5 Sep 2020 17:02:33 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id o64so9846263qkb.10 for ; Sat, 05 Sep 2020 17:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=/O2fIA1k1Df7uE+DV99uQTRsxpICufRk51zn6jwaSf4=; b=huS5X7qokTvQGf0ssy9+TtJJLu5f56pf1rnXdSfdimdUoqHDUcQ1QKww0r4JR62+Aw IFanbkbfq1QI6r+VJghqPefrjcnwSPbA73QAStNa3/E0YhZSk8t6A6LMfke+6T5qqeAd HNhpNDZTWKvN3pZ7ZOockxq9hIxbbDK2IRURgRFO79OogDsDqYOWvnN80IupU4ugLYza Og4iBCQYe3+8S11sBBL5K3hjtpaNiXtCusN3Wyr8R3cM14NZlP9AIhQcd1GUrb8wt+uw U5gkf4QQzOpH/Iwf3yUM68Nb80UwEbIIQcjBQDWb2YMvcw4BQFFjgUe+87+5yFpZQvdr RFDg== 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; bh=/O2fIA1k1Df7uE+DV99uQTRsxpICufRk51zn6jwaSf4=; b=mYKWMVvzT5XLNAIFjvnyLnmMk8/urM3Ya/7APC8C/p+UBx1ixAS0w9iaIgn5SMhTzY STSvSL+b8oO+fjhXtyRmFMJIItqW9nROMQRgrq+Thb9J+rAVQ3g8giddadFr24BWHiMe I3tcg2GyPgsRCyy3f1X9DTPGmKHLoKyvGaFmQYKmoX4Cxx8hQGajK7inCibBuXM/5PVD Tz643SeHFnC1kpRW8TL2yKQTWzHd40mO3EgPjmiGjY89FThxdvuF2P8OsAyLNbzgAP7U lC6YmUFXp1b2ZzxOiTMzy8Tpgfe32ZaC1rkAWz3CCDhxfzc4PpGHz9LO1bP72pQoX41t g9kg== X-Gm-Message-State: AOAM532CPn1zxdJm37XMkxJmzStciF760fRwWW5fvJ+vfG0SjKMRfD2N 7eGL2IY8oa95ygHUcf7juvuEM39wxFHrl+KdRuo= X-Google-Smtp-Source: ABdhPJx1vxccwVzGeyvJJCUAnBKfqjdcgW6EdR3qVB7bCgD3r7FVmzF5jRB716Nx2wufYku/maV4NQ== X-Received: by 2002:a37:e82:: with SMTP id 124mr13768696qko.77.1599350552118; Sat, 05 Sep 2020 17:02:32 -0700 (PDT) Received: from [192.168.1.20] (pool-71-114-22-128.washdc.fios.verizon.net. [71.114.22.128]) by smtp.gmail.com with ESMTPSA id o72sm7706933qka.113.2020.09.05.17.02.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Sep 2020 17:02:31 -0700 (PDT) To: Eric Rescorla Cc: rfced-future@iab.org References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> From: Michael StJohns Message-ID: Date: Sat, 5 Sep 2020 20:02:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B98ABC982553640CF9A8C414" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Posted my draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 Sep 2020 00:02:36 -0000 This is a multi-part message in MIME format. --------------B98ABC982553640CF9A8C414 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/5/2020 6:50 PM, Eric Rescorla wrote: > [Trying to cut down to the points that I think are at the heart > of the matter, which does not mean that I necessarily agree > with your responses.] > > On Wed, Sep 2, 2020 at 11:23 AM Michael StJohns > > wrote: > > On 9/1/2020 3:16 PM, Eric Rescorla wrote: > > > Specifically: > > > > > > 1. The RSEB (which nominally represents the RFC community) does not > > > seem to have any hiring and firing authority [0] > > > > Well, contrary to popular belief, neither the IAB nor the RSOC has > > ever had hiring or firing authority.  In the ISOC era, that rested > > with the HR department I believe.  In the LLC era it rests with the > > LLC .  What the IAB and RSOC did have was the ability to recommend > > or request the selection of a particular candidate by the hiring > > entity.  A good portion of the problem we encountered was them not > > understanding those limitations.  The LLC has indicated an intent to > > defer to the wishes of the IAB in this matter, but legally, the role > > still resides with the LLC. > > > > With respect to hiring, in the "new" model, the RSEB can recommend > > RSE candidates to the LLC, but if the LLC isn't able to come to an > > agreement on terms with that candidate, there's nothing the RSEB can > > do to change that.  That again was no different than before.  The > > LLC - legally, but probably not ever going to happen practically - > > could actually hire whoever they wanted irrespective of any input > > from the RSEB, IAB, IESG etc. > > I agree with some of this and disagree with other parts: > > 1. Yes, I imagine that the LLC (and ISOC before it) could legally hire > anyone they wanted and give them any title they wanted. However, this > would not make them the RSE for the purposes of our process (as was > discussed in detail in IASA 2.0). Here is the relevant text from > 6635: > >    The RSE is appointed by the IAB, but formally hired by the IAOC.  The >    IAB delegates the direct oversight over the RSE to the RSOC, which it >    appoints. That's what it says.  And you're correct that the RSE might be considered "illegitimate" if the LLC ignored the formal appointment and hired someone to do the work of the RSE, even without the actual title.  But the LLC has the money, and as such has the veto power regardless of what the documents say. Appointing a non-IAB approved (or in my case non-RSEB recommended) RSE could end up with the LLC getting yelled at by the community, but it still doesn't change the reality of how the contracting business works. The recourse here - as noted before - is that the RSEB could refuse to publish the (illegitimate) RSE's work. > > 2. The purpose of these documents is in part to memorialize our > understanding of the terms under which the LLC is expected to act. > So, while 6635 I think makes clear that the LLC ought to contract > with/hire either the person that the IAB/RSOC selects or nobody, > your document appears to change that. But perhaps I've misunderstood > you. Hence some questions about your intent: > > - If the LLC ignored the RSEB's chosen candidate and selected >   their own, would they be able to act as the RSE for the >   purposes of this process, such as chairing the RSEB? That would be an interesting discussion.  In any event the person hired as RSE would be doing the work - the RSEB could either approve it or not for publication.  My guess is that all of that would work itself out either by the RSE being replaced, by the RSEB being replaced, or by the LLC being replaced - whichever made more sense to the community. > > - If the RSEB wishes to replace the current RSE at the end >   of their contract, what mechanism do they use to do that >   and what impact does that have on the LLC (as in the >   first question)? The RSEB and RSEB members may make any comments they want to the LLC.  The LLC can assign those comments as much or as little weight as they feel appropriate.  That may result in the LLC asking the RSEB to set up a search, or for the LLC re-uping the RSE irrespective of the RSEBs desires.   This is pretty much how the IAB takes community comments on the ISE AFAICT.   The point is that the RSEB isn't there to manage the RSE, but to work with the RSE to direct the strategic direction of the RFC series. (Consider for example an RSE that's doing what the community wants, but not what the RSEB wants - if the LLC gets lots of messages of support about the RSE, how much weight should the LLC give to the RSEB's comments suggesting the RSE needs to go?) > > > > In any event, the LLC handles personnel and contract issues, and the > > RSEB is the one that approves the publication of the RSE's work and > > never the twain shall meet. I doubt that the RSEB is going to > > approve said documents so if the strategy espoused by the RSE is at > > odds with what the RSEB members believe is the correct path.  If the > > RSEB is mostly against the RSE time and again, and the members of > > the RSEB make those concerns known to the LLC, its unlikely that the > > LLC will extend the contract. > > As noted above, this seems to me to be a material change from > the existing 6635 situation in which the LLC would not be expected > to independently determine the suitability of an RSE who the > RSOC had decided not to engage. Again, I'm speaking here of the > implications for our process, not what the LLC's legal rights > are. I guarantee that the LLC (and the ISOC before it) made their own determinations of suitability - not necessarily the same ones that the IAB or RSOC made.  You could have someone who looked good on paper and wowed every member of the IAB, but  didn't meet their criteria hen the LLC did its due diligence.  I'd expect that to mostly come from the lawyers working contract issues. I think you're making too much of this - the LLC is the contracting entity.   It's going to try to be doing the right thing for the community, and the RSEB/Search Committee will hopefully provide the LLC with one or more good candidates for that role.  I'd be shocked if they selected someone else - mainly because I don't think they want that much work.  But I could actually see it happening if say the search committee is unable to find someone, and there's a need for an interim.  Maybe expanding Jay's role for a while, or getting the RPC to amend the contract to pick up some of the need - options that the LLC might take to maintain the business of the IETF. > > But perhaps this is just a matter of me not understanding what > you have written down. Let's consider a concrete case: > > The RSEB \setminus RSE wants to proceed in a certain strategic > direction (inscribing the RSEs on clay tablets say). They ask the RSE > to develop the plan to do so, but the RSE opposes it and so refuses to > do so in a timely fashion. What, if any, recourse does the RSEB have? I assume you meant inscribing RFCs on clay tablets not "RSEs"? Well, first if the RSEB was seriously convinced that clay tablets made sense, I'd be trying to figure out how to replace each and every one of the RSEB members, or I'd be looking at the voting record and replacing the 5 RSEB members that said this was a good idea. If the RSEB proposes an idea that the RSE doesn't want to go along with, then the recourse is for the RSEB to approach the LLC or CM and ask them to intercede.  The LLC or CM may or may not choose to intercede and will have to make those decisions based on what the contract says and their perception of reality. Lastly, if the RSEB feels that clay tablets are the way to go, they can always write their own plan and approve it themselves. Alternately, they can ask the LLC to hire someone specifically to write that proposal. > > > > > > 3. Section 4.3 says: > > > > > >    While it is ultimately the LLC's decision, the RSE should be > engaged > > >    via either a personal services contract or an employment > contract for > > >    a given term.  Engagement as an at-will employee would not be > > >    appropriate for a senior-level resource with these strategic > > >    responsibilities and would not provide any measure of > consistency and > > >    continuity over the RFC Series. > > > > > > While I can certainly understand how this arrangement might be > > > appealing to prospective RSEs, I do not believe it provides an > > > appropriate level of accountability to the community. Specifically, I > > > believe it is necessary to have the ultimate authority for stratetic > > > decisions be vested in the community (in this case this would be the > > > RSEB, ignoring for the moment its composition), but that does not > > > appear to be the case here. This issue is exacerbated by the fact > > > that the RSE is themselves a member of the RSEB. > > > > 1) Strategic decisions ARE vested in the community.  It takes at > > least 5 members of the RSEB (which may or may not include the RSE) > > to approve a new document that describes changes in strategy.  The > > RSEB represents the community.  If it isn't written down, it didn't > > happen. > > Sure, and that prevents the RSE from unilaterally doing bad things but > it does not prevent the RSE from effectively stalling good things they > don't agree with. See the example I gave above. And clay tablets are a good thing?  I'd find this question more interesting if you could provide a much better example and explain how "good" is determined. Again, there's nothing preventing the RSEB from doing the work itself if it believes it has the better solution. We actually want someone to say no if the RSEB is making bad decisions - it's reputational on the RSEs part not to do things that a broader community would find .... stupid.    I'd expect at least this model from anyone I'd hire as a contractor - or why would I hire them?  I may not always agree with their choices, but I'm paying them for a specific set of expertise. > > > > 4) Continuity is important in this space - perhaps more so that > > you're willing to admit.  The model of an on-call consultant who > > sometimes comes in and answers questions does not support the idea > > of a dynamic and world-class publication system.  We can coast a > > while on the work that Heather and her predecessors have done, but I > > don't think we can do that for long and maintain the publication > > standards. > > Indeed, we disagree on this point, but I don't think each of us > offering our unsupported assertions is going to get us very far, so > I'll refrain from arguing it at present. I will, however, note that > neither "dynamic" nor "world-class" are the words that come to mind > when I think of our present publication system. > > -Ekr > I've been around long enough to see what a bad system looks like (cf the IDEA series or even PKCS11 by Oasis).   The main problems with the RFC series appear to be pre-publication or so I opine given the data.  The actual publication process and model works reasonably well, with vastly varying qualities of submissions, and many different requirements.   The documents are available world wide and in a manner that allows free and easy access.  The documents are widely cited, and the stability of the references means that those cites are meaningful 20+ years later. So, yes, we disagree. Later, Mike > > --------------B98ABC982553640CF9A8C414 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/5/2020 6:50 PM, Eric Rescorla wrote:
[Trying to cut down to the points that I think are at the heart
of the matter, which does not mean that I necessarily agree
with your responses.]

On Wed, Sep 2, 2020 at 11:23 AM Michael StJohns <msj@nthpermutation.com> wrote:
> On 9/1/2020 3:16 PM, Eric Rescorla wrote:
> > Specifically:
> >
> > 1. The RSEB (which nominally represents the RFC community) does not
> > seem to have any hiring and firing authority [0]
>
> Well, contrary to popular belief, neither the IAB nor the RSOC has
> ever had hiring or firing authority.  In the ISOC era, that rested
> with the HR department I believe.  In the LLC era it rests with the
> LLC .  What the IAB and RSOC did have was the ability to recommend
> or request the selection of a particular candidate by the hiring
> entity.  A good portion of the problem we encountered was them not
> understanding those limitations.  The LLC has indicated an intent to
> defer to the wishes of the IAB in this matter, but legally, the role
> still resides with the LLC.
>
> With respect to hiring, in the "new" model, the RSEB can recommend
> RSE candidates to the LLC, but if the LLC isn't able to come to an
> agreement on terms with that candidate, there's nothing the RSEB can
> do to change that.  That again was no different than before.  The
> LLC - legally, but probably not ever going to happen practically -
> could actually hire whoever they wanted irrespective of any input
> from the RSEB, IAB, IESG etc.

I agree with some of this and disagree with other parts:

1. Yes, I imagine that the LLC (and ISOC before it) could legally hire
anyone they wanted and give them any title they wanted. However, this
would not make them the RSE for the purposes of our process (as was
discussed in detail in IASA 2.0). Here is the relevant text from
6635:

   The RSE is appointed by the IAB, but formally hired by the IAOC.  The
   IAB delegates the direct oversight over the RSE to the RSOC, which it
   appoints.

That's what it says.  And you're correct that the RSE might be considered "illegitimate" if the LLC ignored the formal appointment and hired someone to do the work of the RSE, even without the actual title.  But the LLC has the money, and as such has the veto power regardless of what the documents say.  Appointing a non-IAB approved (or in my case non-RSEB recommended) RSE could end up with the LLC getting yelled at by the community, but it still doesn't change the reality of how the contracting business works.

The recourse here - as noted before - is that the RSEB could refuse to publish the (illegitimate) RSE's work.


2. The purpose of these documents is in part to memorialize our
understanding of the terms under which the LLC is expected to act.
So, while 6635 I think makes clear that the LLC ought to contract
with/hire either the person that the IAB/RSOC selects or nobody,
your document appears to change that. But perhaps I've misunderstood
you. Hence some questions about your intent:

- If the LLC ignored the RSEB's chosen candidate and selected
  their own, would they be able to act as the RSE for the
  purposes of this process, such as chairing the RSEB?

That would be an interesting discussion.  In any event the person hired as RSE would be doing the work - the RSEB could either approve it or not for publication.  My guess is that all of that would work itself out either by the RSE being replaced, by the RSEB being replaced, or by the LLC being replaced - whichever made more sense to the community.


- If the RSEB wishes to replace the current RSE at the end
  of their contract, what mechanism do they use to do that
  and what impact does that have on the LLC (as in the
  first question)?

The RSEB and RSEB members may make any comments they want to the LLC.  The LLC can assign those comments as much or as little weight as they feel appropriate.  That may result in the LLC asking the RSEB to set up a search, or for the LLC re-uping the RSE irrespective of the RSEBs desires.   This is pretty much how the IAB takes community comments on the ISE AFAICT.   The point is that the RSEB isn't there to manage the RSE, but to work with the RSE to direct the strategic direction of the RFC series.

(Consider for example an RSE that's doing what the community wants, but not what the RSEB wants - if the LLC gets lots of messages of support about the RSE, how much weight should the LLC give to the RSEB's comments suggesting the RSE needs to go?)



> In any event, the LLC handles personnel and contract issues, and the
> RSEB is the one that approves the publication of the RSE's work and
> never the twain shall meet. I doubt that the RSEB is going to
> approve said documents so if the strategy espoused by the RSE is at
> odds with what the RSEB members believe is the correct path.  If the
> RSEB is mostly against the RSE time and again, and the members of
> the RSEB make those concerns known to the LLC, its unlikely that the
> LLC will extend the contract.

As noted above, this seems to me to be a material change from
the existing 6635 situation in which the LLC would not be expected
to independently determine the suitability of an RSE who the
RSOC had decided not to engage. Again, I'm speaking here of the
implications for our process, not what the LLC's legal rights
are.

I guarantee that the LLC (and the ISOC before it) made their own determinations of suitability - not necessarily the same ones that the IAB or RSOC made.  You could have someone who looked good on paper and wowed every member of the IAB, but  didn't meet their criteria hen the LLC did its due diligence.  I'd expect that to mostly come from the lawyers working contract issues.

I think you're making too much of this - the LLC is the contracting entity.   It's going to try to be doing the right thing for the community, and the RSEB/Search Committee will hopefully provide the LLC with one or more good candidates for that role.  I'd be shocked if they selected someone else - mainly because I don't think they want that much work.  But I could actually see it happening if say the search committee is unable to find someone, and there's a need for an interim.  Maybe expanding Jay's role for a while, or getting the RPC to amend the contract to pick up some of the need - options that the LLC might take to maintain the business of the IETF.



But perhaps this is just a matter of me not understanding what
you have written down. Let's consider a concrete case:

The RSEB \setminus RSE wants to proceed in a certain strategic
direction (inscribing the RSEs on clay tablets say). They ask the RSE
to develop the plan to do so, but the RSE opposes it and so refuses to
do so in a timely fashion. What, if any, recourse does the RSEB have?

I assume you meant inscribing RFCs on clay tablets not "RSEs"?

Well, first if the RSEB was seriously convinced that clay tablets made sense, I'd be trying to figure out how to replace each and every one of the RSEB members, or I'd be looking at the voting record and replacing the 5 RSEB members that said this was a good idea.

If the RSEB proposes an idea that the RSE doesn't want to go along with, then the recourse is for the RSEB to approach the LLC or CM and ask them to intercede.  The LLC or CM may or may not choose to intercede and will have to make those decisions based on what the contract says and their perception of reality.

Lastly, if the RSEB feels that clay tablets are the way to go, they can always write their own plan and approve it themselves.  Alternately, they can ask the LLC to hire someone specifically to write that proposal.





> > 3. Section 4.3 says:
> >
> >    While it is ultimately the LLC's decision, the RSE should be engaged
> >    via either a personal services contract or an employment contract for
> >    a given term.  Engagement as an at-will employee would not be
> >    appropriate for a senior-level resource with these strategic
> >    responsibilities and would not provide any measure of consistency and
> >    continuity over the RFC Series.
> >
> > While I can certainly understand how this arrangement might be
> > appealing to prospective RSEs, I do not believe it provides an
> > appropriate level of accountability to the community. Specifically, I
> > believe it is necessary to have the ultimate authority for stratetic
> > decisions be vested in the community (in this case this would be the
> > RSEB, ignoring for the moment its composition), but that does not
> > appear to be the case here. This issue is exacerbated by the fact
> > that the RSE is themselves a member of the RSEB.
>
> 1) Strategic decisions ARE vested in the community.  It takes at
> least 5 members of the RSEB (which may or may not include the RSE)
> to approve a new document that describes changes in strategy.  The
> RSEB represents the community.  If it isn't written down, it didn't
> happen.

Sure, and that prevents the RSE from unilaterally doing bad things but
it does not prevent the RSE from effectively stalling good things they
don't agree with. See the example I gave above.

And clay tablets are a good thing?  I'd find this question more interesting if you could provide a much better example and explain how "good" is determined.

Again, there's nothing preventing the RSEB from doing the work itself if it believes it has the better solution.   

We actually want someone to say no if the RSEB is making bad decisions - it's reputational on the RSEs part not to do things that a broader community would find .... stupid.    I'd expect at least this model from anyone I'd hire as a contractor - or why would I hire them?  I may not always agree with their choices, but I'm paying them for a specific set of expertise. 




> 4) Continuity is important in this space - perhaps more so that
> you're willing to admit.  The model of an on-call consultant who
> sometimes comes in and answers questions does not support the idea
> of a dynamic and world-class publication system.  We can coast a
> while on the work that Heather and her predecessors have done, but I
> don't think we can do that for long and maintain the publication
> standards.

Indeed, we disagree on this point, but I don't think each of us
offering our unsupported assertions is going to get us very far, so
I'll refrain from arguing it at present. I will, however, note that
neither "dynamic" nor "world-class" are the words that come to mind
when I think of our present publication system.

-Ekr

I've been around long enough to see what a bad system looks like (cf the IDEA series or even PKCS11 by Oasis).   The main problems with the RFC series appear to be pre-publication or so I opine given the data.  The actual publication process and model works reasonably well, with vastly varying qualities of submissions, and many different requirements.   The documents are available world wide and in a manner that allows free and easy access.  The documents are widely cited, and the stability of the references means that those cites are meaningful 20+ years later.

So, yes, we disagree.

Later, Mike






--------------B98ABC982553640CF9A8C414-- From nobody Sun Sep 6 17:50: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 D34193A1357 for ; Sun, 6 Sep 2020 17:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=pAZmyt6U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=US4d2UL2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYlQj2doRKXB for ; Sun, 6 Sep 2020 17:50:17 -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 A63E23A1355 for ; Sun, 6 Sep 2020 17:50:17 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id BD0586E4 for ; Sun, 6 Sep 2020 20:50:16 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Sun, 06 Sep 2020 20:50:16 -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=fm3; bh=23z6+trOG6qGhyqXyH0Kv5d1NIagZpx rEhQn6cwN5rI=; b=pAZmyt6UNMNIr+mgVK5x4A98KQ6E0+Z8xSX/bJL8gPPSo1b VbxV4HDdP0qQT0ew5pl8zE30l2pEhaOpmgrTgym9HDyZQUGUIfxtcZU7veb9b1dq 6ln5FoyxGkB4MQdErldHxIqvFab552wQq6wFkdtBVRQ36Z7RSGV1XeYittVh/xkd TdL7Y7/NavNG/yNOe9cl0sDCDYabYYA6toEdZr6FuNrfU3yKfeZ7QuDc/F169mDR Z18sVdcaxpgEdmLcW/oxeWnt7c3ZOHMshSDdidZaOvi+O16aDKYRbITL/GgtIZPx 7lsvcp7rE1wxu58wh7M+XXi3wn0TOws1Jkkshvw== 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=23z6+t rOG6qGhyqXyH0Kv5d1NIagZpxrEhQn6cwN5rI=; b=US4d2UL2fERYg3bAsqUeRf i2/59J/5FymroXBeCzT16qcrAFhVqCFp75n1r10R6cD12S0EvRfpGncZ/ZRp5lYy pz4Du1Bfe7E+aJTUiuE+NR2eWlcK9Y7QF1xxbNN1Wb6VoUcymvW4YeEAG9ixwIlm MlpawkURkNvJ7ekWQ2AC4P22ysYu+NGqRJLmaw5OO/eBN436LB+1Hip88smmy89k Q/83N6sIAtfH5YimaC8UfxqODZZSUq2XdYKB/6SbByX6pX2LOIr5ZGPFQCvbQpMT SSldpcZRpIpr8MO+uxbE0vC9RXVxow3sL+zzmn/6TRHZWLyQP8O7NkMYLqD7fGjQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegkedgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2008E2006F; Sun, 6 Sep 2020 20:50:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3 Mime-Version: 1.0 Message-Id: <7087310d-2fb1-40ca-b1b3-22b2b3fa57e0@www.fastmail.com> In-Reply-To: <77b8542e-c57b-ba81-c3f4-785143884ab7@joelhalpern.com> References: <159702718090.11663.7570202119633420369@ietfa.amsl.com> <18b04242-0867-4abc-ac9d-7dc7875675e2@www.fastmail.com> <5c28ddcd-7d48-9c73-a2da-68084963ce4d@it.aoyama.ac.jp> <77b8542e-c57b-ba81-c3f4-785143884ab7@joelhalpern.com> Date: Mon, 07 Sep 2020 10:49:56 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-thomson-rfced-model-01.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 00:50:19 -0000 On Sat, Sep 5, 2020, at 02:47, Joel M. Halpern wrote: > The next problem that occurs to me is that a style guide is often a > judgement call. There is not a technical right answer. But an answer > is generally needed. The IETF WG process is consistently very bad at > that sort of decision. Witness the mess for almost every process > decision in the IETF. And the WG process does not allow the chairs to > simply declare a conclusion when there is not rough consensus. Aside from this point about not attaining consensus, I don't see a problem with working groups making decisions. We routinely make a large number of decisions every week in some working groups. Most of them might require some debate, but they don't end up in paralysis. Even for judgment calls. Paralysis only exists where there are hard constraints or no shared interest in reaching a conclusion (leaving aside for the moment the severe vulnerability of this process to trolling). But I think that you raise a different point about the relation of style guide to the purpose of the system that we are designing here. If the goal is to provide strategy, and maintaining a style guide is not entirely strategic decisions, then we need to ensure that the group only provides strategic input. That is, the process of editing and publication does not depend on the "working group" providing timely decisions. I had envisaged an ownership model that is less direct. That is, the RPC (or whatever they are called) would be empowered to exercise judgment in tactical matters, such as in the example Jay raised. They would own the style guide in the same way that a document editor might own a working group document. They then effectively are proposing changes to the group, based on their own "running code": the practices they actively follow. If the group wants to debate the strategic merit of RPC decisions, that is fine, but the RPC needs to keep the lights on, so once a strategic direction is agreed, I would expect them to eventually move to follow that. Any inconsistencies between practice and direction might then need to be resolved. My expectation is that the RPC will make sensible decisions and any eventual strategic decision will rarely be incompatible with practice. True conflicts between direction and practice can be negotiated as part of contracts, by the LLC. (That isn't always a failure of strategic direction, as some elements of strategic direction might affect contract terms in material ways, such as those that affect the cost of providing the service.) This general split between tactical needs and strategic direction is something that I've observed to cause problems with xml2rfc development as well. The goal there was to run design decisions through a "working group". But that turned out to be unworkable, slow, and fraught with conflict. What we have now is the code (or practice) leading the standardization (or formalization) effort. That's now at the point where I'm uncomfortable with the openness of that process and the extent to which it is responsive to the community. But we have a chance to learn from that process here. From nobody Sun Sep 6 18:13:16 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985C23A1376 for ; Sun, 6 Sep 2020 18:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=bUfXWFrX; dkim=pass (2048-bit key) header.d=taugh.com header.b=eo8T80Di Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETwUiAqnRbPS for ; Sun, 6 Sep 2020 18:13:13 -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 BAF8A3A1375 for ; Sun, 6 Sep 2020 18:13:12 -0700 (PDT) Received: (qmail 61421 invoked from network); 7 Sep 2020 01:13: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=efeb.5f558924.k2009; bh=0t6EZ8hVrBZIOKra72naxzGN/xAzv0w7CqyU8TD/NoQ=; b=bUfXWFrXceqGv0TF3ckgTMmUup6Y/oU0kG8YnZPvmIFMRj/hG2HSR/58/wqADjQBWJzSwialrX1sPvclNhqM7RMr0zbzI2zW6jkuq6OIC1DYhMNFJ7M8moMSN2CLe42T0vrJGYMCdpbcmnkaWtg8npWMm+NRBIRNMloWkFaqEsH2e11UaF2EyVKZfH/qVVapEzD0cG9pUeh67Upqr1zlKbPrzdV+hAB0yzxnz3siyW3uK8/IrgWYSeD/4zfzFIOi+DbKDmY9wNoEktYCDHyrWZXbun+X0x0zaJrP3Tn6nnfEIvSfqddw2xoGovhHO2uAaEl6U9QPCTz/cdxBSnr34Q== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=efeb.5f558924.k2009; bh=0t6EZ8hVrBZIOKra72naxzGN/xAzv0w7CqyU8TD/NoQ=; b=eo8T80Di51e+zuVfUjpzO67/6aGJc0uEBzNmbE98mEh7bngqgMqSvD0XUSw47NhLqPHdk/iGXLtsGEhF5ZebRvHtHS/MVYFtH0zylpvRjbtixf3dU3ecrl5KBN4HHgAuqwDxLNmETa+o1gkNY5bcm2k+OIh4q61USMuqVUcoHru8aeA/Ug9F/6QW/Rq8a8enGilm5ZoqZKhE7UI9CU0ARXv+9HJYLFUButdkmCHPxw7EdBdiUSjMQ6ZmceI3Z8pPnDuT38tqfDV8r261Z++PCz4yYSChbQXkRNrw6Z//0+t2mZ55YPVVZWotxF44MxrLr+OYyheEuh3whf91c/49bA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 07 Sep 2020 01:13:08 -0000 Received: by ary.qy (Postfix, from userid 501) id D78041FD7CA8; Sun, 6 Sep 2020 21:13:07 -0400 (EDT) Date: 6 Sep 2020 21:13:07 -0400 Message-Id: <20200907011307.D78041FD7CA8@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: mt@lowentropy.net In-Reply-To: <7087310d-2fb1-40ca-b1b3-22b2b3fa57e0@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] I-D Action: draft-thomson-rfced-model-01.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 01:13:15 -0000 In article <7087310d-2fb1-40ca-b1b3-22b2b3fa57e0@www.fastmail.com> you write: >On Sat, Sep 5, 2020, at 02:47, Joel M. Halpern wrote: >> The next problem that occurs to me is that a style guide is often a >> judgement call. There is not a technical right answer. But an answer >> is generally needed. The IETF WG process is consistently very bad at >> that sort of decision. Witness the mess for almost every process >> decision in the IETF. And the WG process does not allow the chairs to >> simply declare a conclusion when there is not rough consensus. > >Aside from this point about not attaining consensus, I don't see a problem with working groups making decisions. FYi, the RPC asks me to make small style decisions all the time. These are on the order of whether some chunk of text looks more like artwork or a snippet of source code, or what's the best way to handle nested quoted text in some context. The answers to these are mostly arbitrary, and it is more important that they be answered consistently than that any individual decision be made one way or the other. If this sort of stuff were pushed up to WGs it would not be a good use of WG time, and if different questions were pushed to different WGs, we'd get different answers which would make the series look worse. It's not a bad idea to have one person whose job is to think about this stuff in the context of the whole RFC series, not individual documents. R's, John From nobody Mon Sep 7 11:18: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 641643A0F9A for ; Mon, 7 Sep 2020 11:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, 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=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 8_egtHp1BuQP for ; Mon, 7 Sep 2020 11:18:18 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 6E6AE3A0F99 for ; Mon, 7 Sep 2020 11:18:17 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id y2so7870395lfy.10 for ; Mon, 07 Sep 2020 11:18:17 -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=r3VkXLINSMV0BPtlvn95g9TEUkqtiCTByuRgeau657k=; b=FnSv0rq2VAnrtMitYpxBMZq9WH/OCA6vBfwxVRjpWRxtvjH6lx+0NigIR3k1oX5e+z eHuYLgGWXlvE9dpzA/TfgIRJAtr87t+9lPCkuoyjfaFGAWL2fWZxYtK1xUFcA2vqdcwF MumRUrQS2DkrXppUoCRUlsG6Ef1jMV4bc9VFiHFtOMFSlBVjkbiyu0b7lnRLaMsnLPm0 yw1R+t++ymOP7ATABrDx3BTUvJkU3Op65QqMo5BIGwj2digBzufCMPWLxL+QXZUYVRFf icxqKC0xUVQqBnV4yOP0KxoJakMa4I47eBpkIYU0QN+t8EGVZvz6IG8rcWk3sTnn4Med pU0g== 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=r3VkXLINSMV0BPtlvn95g9TEUkqtiCTByuRgeau657k=; b=KHfH4SI8MaClW3aaAT4hlxYkw8HEnBBfottnznHYCy2VnL5JUc43noh0I4p29e1gEJ erSK2rcSVAY5JTEIhgrwNKL/Pk36akk5yzPNKkNCY2ecnj17MxuefN4ra4rmi1268r7c SYifA9edrxSnonL8QPrXXot6As117PayKx0MkGCb/eCLTDJlDizS2SewCOyTm1wWVRxX A2Hg1LQDATgnR5Mvw/Waw7hDfrbAqfia8CmivZGO7eoslY3bIjL9fZ1dIltyJP5kIuK0 4bsgRO5lj6CgnCHPsvmRZJjeWf70CEdIMqGdoH2NUsA1dmNWfonnIc6WbdAYMMfv4UmN /1rw== X-Gm-Message-State: AOAM5325t5Sx8IfiiN7ZAEQfRQ+LfkNOZ0tRfJru7a6kwM1+BCOgi16T F65B/Cfh+GFUuRc0NrDPe9G1SdudPNvRgNoeA4/uu3+4VhDVFg== X-Google-Smtp-Source: ABdhPJysV4tH+sMHlUt9i66pLKhpLC6Pa4+7zjqEiih6qqVeiplF/+bxgDxFvwq2LL9Zik8bHT3QAoLv4f5UlfPy7x8= X-Received: by 2002:a19:e57:: with SMTP id 84mr10683772lfo.161.1599502695501; Mon, 07 Sep 2020 11:18:15 -0700 (PDT) MIME-Version: 1.0 References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> In-Reply-To: From: Eric Rescorla Date: Mon, 7 Sep 2020 11:17:39 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000fba65505aebd3d34" Archived-At: Subject: Re: [Rfced-future] Posted my draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Sep 2020 18:18:20 -0000 --000000000000fba65505aebd3d34 Content-Type: text/plain; charset="UTF-8" Thanks for your complete response which helps me understand your position As I said in my initial review, I believe that the structure you propose would not allow for a sufficient level of community oversight over the RSE function. In particular, I think the RSOC/IAB/RSEB whatever needs to be empowered to replace the RSE if they do not agree with their strategic direction. I believe that is fairly clearly the case under 6635 and should be the case under any new structure and is not under what you propose. Chairs: sounds like a good topic for the interim. -Ekr On Sat, Sep 5, 2020 at 5:02 PM Michael StJohns wrote: > On 9/5/2020 6:50 PM, Eric Rescorla wrote: > > [Trying to cut down to the points that I think are at the heart > of the matter, which does not mean that I necessarily agree > with your responses.] > > On Wed, Sep 2, 2020 at 11:23 AM Michael StJohns > wrote: > > On 9/1/2020 3:16 PM, Eric Rescorla wrote: > > > Specifically: > > > > > > 1. The RSEB (which nominally represents the RFC community) does not > > > seem to have any hiring and firing authority [0] > > > > Well, contrary to popular belief, neither the IAB nor the RSOC has > > ever had hiring or firing authority. In the ISOC era, that rested > > with the HR department I believe. In the LLC era it rests with the > > LLC . What the IAB and RSOC did have was the ability to recommend > > or request the selection of a particular candidate by the hiring > > entity. A good portion of the problem we encountered was them not > > understanding those limitations. The LLC has indicated an intent to > > defer to the wishes of the IAB in this matter, but legally, the role > > still resides with the LLC. > > > > With respect to hiring, in the "new" model, the RSEB can recommend > > RSE candidates to the LLC, but if the LLC isn't able to come to an > > agreement on terms with that candidate, there's nothing the RSEB can > > do to change that. That again was no different than before. The > > LLC - legally, but probably not ever going to happen practically - > > could actually hire whoever they wanted irrespective of any input > > from the RSEB, IAB, IESG etc. > > I agree with some of this and disagree with other parts: > > 1. Yes, I imagine that the LLC (and ISOC before it) could legally hire > anyone they wanted and give them any title they wanted. However, this > would not make them the RSE for the purposes of our process (as was > discussed in detail in IASA 2.0). Here is the relevant text from > 6635: > > The RSE is appointed by the IAB, but formally hired by the IAOC. The > IAB delegates the direct oversight over the RSE to the RSOC, which it > appoints. > > That's what it says. And you're correct that the RSE might be considered > "illegitimate" if the LLC ignored the formal appointment and hired someone > to do the work of the RSE, even without the actual title. But the LLC has > the money, and as such has the veto power regardless of what the documents > say. Appointing a non-IAB approved (or in my case non-RSEB recommended) > RSE could end up with the LLC getting yelled at by the community, but it > still doesn't change the reality of how the contracting business works. > > The recourse here - as noted before - is that the RSEB could refuse to > publish the (illegitimate) RSE's work. > > > 2. The purpose of these documents is in part to memorialize our > understanding of the terms under which the LLC is expected to act. > So, while 6635 I think makes clear that the LLC ought to contract > with/hire either the person that the IAB/RSOC selects or nobody, > your document appears to change that. But perhaps I've misunderstood > you. Hence some questions about your intent: > > - If the LLC ignored the RSEB's chosen candidate and selected > their own, would they be able to act as the RSE for the > purposes of this process, such as chairing the RSEB? > > That would be an interesting discussion. In any event the person hired as > RSE would be doing the work - the RSEB could either approve it or not for > publication. My guess is that all of that would work itself out either by > the RSE being replaced, by the RSEB being replaced, or by the LLC being > replaced - whichever made more sense to the community. > > > - If the RSEB wishes to replace the current RSE at the end > of their contract, what mechanism do they use to do that > and what impact does that have on the LLC (as in the > first question)? > > The RSEB and RSEB members may make any comments they want to the LLC. The > LLC can assign those comments as much or as little weight as they feel > appropriate. That may result in the LLC asking the RSEB to set up a > search, or for the LLC re-uping the RSE irrespective of the RSEBs desires. > This is pretty much how the IAB takes community comments on the ISE > AFAICT. The point is that the RSEB isn't there to manage the RSE, but to > work with the RSE to direct the strategic direction of the RFC series. > > (Consider for example an RSE that's doing what the community wants, but > not what the RSEB wants - if the LLC gets lots of messages of support about > the RSE, how much weight should the LLC give to the RSEB's comments > suggesting the RSE needs to go?) > > > > > In any event, the LLC handles personnel and contract issues, and the > > RSEB is the one that approves the publication of the RSE's work and > > never the twain shall meet. I doubt that the RSEB is going to > > approve said documents so if the strategy espoused by the RSE is at > > odds with what the RSEB members believe is the correct path. If the > > RSEB is mostly against the RSE time and again, and the members of > > the RSEB make those concerns known to the LLC, its unlikely that the > > LLC will extend the contract. > > As noted above, this seems to me to be a material change from > the existing 6635 situation in which the LLC would not be expected > to independently determine the suitability of an RSE who the > RSOC had decided not to engage. Again, I'm speaking here of the > implications for our process, not what the LLC's legal rights > are. > > I guarantee that the LLC (and the ISOC before it) made their own > determinations of suitability - not necessarily the same ones that the IAB > or RSOC made. You could have someone who looked good on paper and wowed > every member of the IAB, but didn't meet their criteria hen the LLC did > its due diligence. I'd expect that to mostly come from the lawyers working > contract issues. > > I think you're making too much of this - the LLC is the contracting > entity. It's going to try to be doing the right thing for the community, > and the RSEB/Search Committee will hopefully provide the LLC with one or > more good candidates for that role. I'd be shocked if they selected > someone else - mainly because I don't think they want that much work. But > I could actually see it happening if say the search committee is unable to > find someone, and there's a need for an interim. Maybe expanding Jay's > role for a while, or getting the RPC to amend the contract to pick up some > of the need - options that the LLC might take to maintain the business of > the IETF. > > > > But perhaps this is just a matter of me not understanding what > you have written down. Let's consider a concrete case: > > The RSEB \setminus RSE wants to proceed in a certain strategic > direction (inscribing the RSEs on clay tablets say). They ask the RSE > to develop the plan to do so, but the RSE opposes it and so refuses to > do so in a timely fashion. What, if any, recourse does the RSEB have? > > I assume you meant inscribing RFCs on clay tablets not "RSEs"? > > Well, first if the RSEB was seriously convinced that clay tablets made > sense, I'd be trying to figure out how to replace each and every one of the > RSEB members, or I'd be looking at the voting record and replacing the 5 > RSEB members that said this was a good idea. > > If the RSEB proposes an idea that the RSE doesn't want to go along with, > then the recourse is for the RSEB to approach the LLC or CM and ask them to > intercede. The LLC or CM may or may not choose to intercede and will have > to make those decisions based on what the contract says and their > perception of reality. > > Lastly, if the RSEB feels that clay tablets are the way to go, they can > always write their own plan and approve it themselves. Alternately, they > can ask the LLC to hire someone specifically to write that proposal. > > > > > > > > 3. Section 4.3 says: > > > > > > While it is ultimately the LLC's decision, the RSE should be engaged > > > via either a personal services contract or an employment contract > for > > > a given term. Engagement as an at-will employee would not be > > > appropriate for a senior-level resource with these strategic > > > responsibilities and would not provide any measure of consistency > and > > > continuity over the RFC Series. > > > > > > While I can certainly understand how this arrangement might be > > > appealing to prospective RSEs, I do not believe it provides an > > > appropriate level of accountability to the community. Specifically, I > > > believe it is necessary to have the ultimate authority for stratetic > > > decisions be vested in the community (in this case this would be the > > > RSEB, ignoring for the moment its composition), but that does not > > > appear to be the case here. This issue is exacerbated by the fact > > > that the RSE is themselves a member of the RSEB. > > > > 1) Strategic decisions ARE vested in the community. It takes at > > least 5 members of the RSEB (which may or may not include the RSE) > > to approve a new document that describes changes in strategy. The > > RSEB represents the community. If it isn't written down, it didn't > > happen. > > Sure, and that prevents the RSE from unilaterally doing bad things but > it does not prevent the RSE from effectively stalling good things they > don't agree with. See the example I gave above. > > And clay tablets are a good thing? I'd find this question more > interesting if you could provide a much better example and explain how > "good" is determined. > > Again, there's nothing preventing the RSEB from doing the work itself if > it believes it has the better solution. > > We actually want someone to say no if the RSEB is making bad decisions - > it's reputational on the RSEs part not to do things that a broader > community would find .... stupid. I'd expect at least this model from > anyone I'd hire as a contractor - or why would I hire them? I may not > always agree with their choices, but I'm paying them for a specific set of > expertise. > > > > > > 4) Continuity is important in this space - perhaps more so that > > you're willing to admit. The model of an on-call consultant who > > sometimes comes in and answers questions does not support the idea > > of a dynamic and world-class publication system. We can coast a > > while on the work that Heather and her predecessors have done, but I > > don't think we can do that for long and maintain the publication > > standards. > > Indeed, we disagree on this point, but I don't think each of us > offering our unsupported assertions is going to get us very far, so > I'll refrain from arguing it at present. I will, however, note that > neither "dynamic" nor "world-class" are the words that come to mind > when I think of our present publication system. > > -Ekr > > I've been around long enough to see what a bad system looks like (cf the > IDEA series or even PKCS11 by Oasis). The main problems with the RFC > series appear to be pre-publication or so I opine given the data. The > actual publication process and model works reasonably well, with vastly > varying qualities of submissions, and many different requirements. The > documents are available world wide and in a manner that allows free and > easy access. The documents are widely cited, and the stability of the > references means that those cites are meaningful 20+ years later. > > So, yes, we disagree. > > Later, Mike > > > > > > > --000000000000fba65505aebd3d34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your complete response which helps me unde= rstand your position

As I said in my initial revi= ew, I believe that the structure you propose would not allow for a sufficie= nt level of community oversight over the RSE function. In particular, I thi= nk the RSOC/IAB/RSEB whatever needs to be empowered to replace the RSE if t= hey do not agree with their strategic direction. I believe that is fairly c= learly the case under 6635 and should be the case under any new structure a= nd is not under what you propose.

Chairs: soun= ds like a good topic for the interim.

-Ekr



On Sat, Sep 5, 2020 at 5:02 PM Michael StJohn= s <msj@nthpermutation.com&= gt; wrote:
=20 =20 =20
On 9/5/2020 6:50 PM, Eric Rescorla wrote:
=20
[Trying to cut down to the points that I think are at the heart
of the matter, which does not mean that I necessarily agree
with your responses.]

On Wed, Sep 2, 2020 at 11:23 AM Michael StJohns <msj@nthpermutation.com&g= t; wrote:
> On 9/1/2020 3:16 PM, Eric Rescorla wrote:
> > Specifically:
> >
> > 1. The RSEB (which nominally represents the RFC community) does not
> > seem to have any hiring and firing authority [0]
>
> Well, contrary to popular belief, neither the IAB nor the RSOC has
> ever had hiring or firing authority.=C2=A0 In the ISOC era, that rested
> with the HR department I believe.=C2=A0 In the LLC era it rests with the
> LLC .=C2=A0 What the IAB and RSOC did have was the ability t= o recommend
> or request the selection of a particular candidate by the hiring
> entity.=C2=A0 A good portion of the problem we encountered w= as them not
> understanding those limitations.=C2=A0 The LLC has indicated an intent to
> defer to the wishes of the IAB in this matter, but legally, the role
> still resides with the LLC.
>
> With respect to hiring, in the "new" model, the RS= EB can recommend
> RSE candidates to the LLC, but if the LLC isn't able to come to an
> agreement on terms with that candidate, there's nothing the RSEB can
> do to change that.=C2=A0 That again was no different than before.=C2=A0 The
> LLC - legally, but probably not ever going to happen practically -
> could actually hire whoever they wanted irrespective of any input
> from the RSEB, IAB, IESG etc.

I agree with some of this and disagree with other parts:

1. Yes, I imagine that the LLC (and ISOC before it) could legally hire
anyone they wanted and give them any title they wanted. However, this
would not make them the RSE for the purposes of our process (as was
discussed in detail in IASA 2.0). Here is the relevant text from
6635:

=C2=A0 =C2=A0The RSE is appointed by the IAB, but formally hired = by the IAOC.=C2=A0 The
=C2=A0 =C2=A0IAB delegates the direct oversight over the RSE to t= he RSOC, which it
=C2=A0 =C2=A0appoints.

That's what it says.=C2=A0 And you're correct that the RSE m= ight be considered "illegitimate" if the LLC ignored the formal appointment and hired someone to do the work of the RSE, even without the actual title.=C2=A0 But the LLC has the money, and as suc= h has the veto power regardless of what the documents say.=C2=A0 Appointing a non-IAB approved (or in my case non-RSEB recommended) RSE could end up with the LLC getting yelled at by the community, but it still doesn't change the reality of how the contracting business works.

The recourse here - as noted before - is that the RSEB could refuse to publish the (illegitimate) RSE's work.


2. The purpose of these documents is in part to memorialize our
understanding of the terms under which the LLC is expected to act.
So, while 6635 I think makes clear that the LLC ought to contract
with/hire either the person that the IAB/RSOC selects or nobody,
your document appears to change that. But perhaps I've misunderstood
you. Hence some questions about your intent:

- If the LLC ignored the RSEB's chosen candidate and selected=
=C2=A0 their own, would they be able to act as the RSE for the =C2=A0 purposes of this process, such as chairing the RSEB?

That would be an interesting discussion.=C2=A0 In any event the pers= on hired as RSE would be doing the work - the RSEB could either approve it or not for publication.=C2=A0 My guess is that all of that would work itself out either by the RSE being replaced, by the RSEB being replaced, or by the LLC being replaced - whichever made more sense to the community.


- If the RSEB wishes to replace the current RSE at the end
=C2=A0 of their contract, what mechanism do they use to do that =C2=A0 and what impact does that have on the LLC (as in the
=C2=A0 first question)?

The RSEB and RSEB members may make any comments they want to the LLC.=C2=A0 The LLC can assign those comments as much or as little weight as they feel appropriate.=C2=A0 That may result in the LLC asking the RSEB to set up a search, or for the LLC re-uping the RSE irrespective of the RSEBs desires. =C2=A0 This is pretty much how the IAB takes community comments on the ISE AFAICT.=C2=A0=C2=A0 The p= oint is that the RSEB isn't there to manage the RSE, but to work with the RSE to direct the strategic direction of the RFC series.

(Consider for example an RSE that's doing what the community wants, but not what the RSEB wants - if the LLC gets lots of messages of support about the RSE, how much weight should the LLC give to the RSEB's comments suggesting the RSE needs to go?)



> In any event, the LLC handles personnel and contract issues, and the
> RSEB is the one that approves the publication of the RSE's work and
> never the twain shall meet. I doubt that the RSEB is going to
> approve said documents so if the strategy espoused by the RSE is at
> odds with what the RSEB members believe is the correct path.=C2=A0 If the
> RSEB is mostly against the RSE time and again, and the members of
> the RSEB make those concerns known to the LLC, its unlikely that the
> LLC will extend the contract.

As noted above, this seems to me to be a material change from
the existing 6635 situation in which the LLC would not be expected
to independently determine the suitability of an RSE who the
RSOC had decided not to engage. Again, I'm speaking here of the
implications for our process, not what the LLC's legal rights=
are.

I guarantee that the LLC (and the ISOC before it) made their own determinations of suitability - not necessarily the same ones that the IAB or RSOC made.=C2=A0 You could have someone who looked good on paper and wowed every member of the IAB, but=C2=A0 didn't meet th= eir criteria hen the LLC did its due diligence.=C2=A0 I'd expect that= to mostly come from the lawyers working contract issues.

I think you're making too much of this - the LLC is the contracting entity.=C2=A0=C2=A0 It's going to try to be doing the= right thing for the community, and the RSEB/Search Committee will hopefully provide the LLC with one or more good candidates for that role.=C2=A0 I'd be shocked if they selected someone else - m= ainly because I don't think they want that much work.=C2=A0 But I could actually see it happening if say the search committee is unable to find someone, and there's a need for an interim.=C2=A0 Maybe expa= nding Jay's role for a while, or getting the RPC to amend the contract to pick up some of the need - options that the LLC might take to maintain the business of the IETF.



But perhaps this is just a matter of me not understanding what you have written down. Let's consider a concrete case:

The RSEB \setminus RSE wants to proceed in a certain strategic direction (inscribing the RSEs on clay tablets say). They ask the RSE
to develop the plan to do so, but the RSE opposes it and so refuses to
do so in a timely fashion. What, if any, recourse does the RSEB have?

I assume you meant inscribing RFCs on clay tablets not "RSEs&qu= ot;?

Well, first if the RSEB was seriously convinced that clay tablets made sense, I'd be trying to figure out how to replace each and every one of the RSEB members, or I'd be looking at the voting record and replacing the 5 RSEB members that said this was a good idea.

If the RSEB proposes an idea that the RSE doesn't want to go along with, then the recourse is for the RSEB to approach the LLC or CM and ask them to intercede.=C2=A0 The LLC or CM may or may not choose to intercede and will have to make those decisions based on what the contract says and their perception of reality.

Lastly, if the RSEB feels that clay tablets are the way to go, they can always write their own plan and approve it themselves.=C2=A0 Alternately, they can ask the LLC to hire someone specifically to write that proposal.





> > 3. Section 4.3 says:
> >
> > =C2=A0 =C2=A0While it is ultimately the LLC's decis= ion, the RSE should be engaged
> > =C2=A0 =C2=A0via either a personal services contract or= an employment contract for
> > =C2=A0 =C2=A0a given term.=C2=A0 Engagement as an at-wi= ll employee would not be
> > =C2=A0 =C2=A0appropriate for a senior-level resource wi= th these strategic
> > =C2=A0 =C2=A0responsibilities and would not provide any measure of consistency and
> > =C2=A0 =C2=A0continuity over the RFC Series.
> >
> > While I can certainly understand how this arrangement might be
> > appealing to prospective RSEs, I do not believe it provides an
> > appropriate level of accountability to the community. Specifically, I
> > believe it is necessary to have the ultimate authority for stratetic
> > decisions be vested in the community (in this case this would be the
> > RSEB, ignoring for the moment its composition), but that does not
> > appear to be the case here. This issue is exacerbated by the fact
> > that the RSE is themselves a member of the RSEB.
>
> 1) Strategic decisions ARE vested in the community.=C2=A0 It takes at
> least 5 members of the RSEB (which may or may not include the RSE)
> to approve a new document that describes changes in strategy.=C2=A0 The
> RSEB represents the community.=C2=A0 If it isn't written= down, it didn't
> happen.

Sure, and that prevents the RSE from unilaterally doing bad things but
it does not prevent the RSE from effectively stalling good things they
don't agree with. See the example I gave above.

And clay tablets are a good thing?=C2=A0 I'd find this question = more interesting if you could provide a much better example and explain how "good" is determined.

Again, there's nothing preventing the RSEB from doing the work itself if it believes it has the better solution.=C2=A0=C2=A0=C2=A0 <= br>

We actually want someone to say no if the RSEB is making bad decisions - it's reputational on the RSEs part not to do things that a broader community would find .... stupid.=C2=A0=C2=A0=C2=A0 I&= #39;d expect at least this model from anyone I'd hire as a contractor - or why would I hire them?=C2=A0 I may not always agree with their choices, b= ut I'm paying them for a specific set of expertise.=C2=A0




> 4) Continuity is important in this space - perhaps more so that
> you're willing to admit.=C2=A0 The model of an on-call consultant who
> sometimes comes in and answers questions does not support the idea
> of a dynamic and world-class publication system.=C2=A0 We ca= n coast a
> while on the work that Heather and her predecessors have done, but I
> don't think we can do that for long and maintain the publication
> standards.

Indeed, we disagree on this point, but I don't think each of us
offering our unsupported assertions is going to get us very far, so
I'll refrain from arguing it at present. I will, however, not= e that
neither "dynamic" nor "world-class" are the w= ords that come to mind
when I think of our present publication system.

-Ekr

I've been around long enough to see what a bad system looks like (cf the IDEA series or even PKCS11 by Oasis).=C2=A0=C2=A0 The main pr= oblems with the RFC series appear to be pre-publication or so I opine given the data.=C2=A0 The actual publication process and model works reasonably well, with vastly varying qualities of submissions, and many different requirements.=C2=A0=C2=A0 The documents are available = world wide and in a manner that allows free and easy access.=C2=A0 The documents are widely cited, and the stability of the references means that those cites are meaningful 20+ years later.

So, yes, we disagree.

Later, Mike






--000000000000fba65505aebd3d34-- From nobody Mon Sep 7 12:27: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 3CA383A10FD for ; Mon, 7 Sep 2020 12:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRiy4B0CMuJr for ; Mon, 7 Sep 2020 12:27:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50223A10B9 for ; Mon, 7 Sep 2020 12:27:26 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 087JRLYW077083 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Sep 2020 14:27:23 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599506845; bh=tl1rMIoQX1P8UeF4ybRX5S2pVqq8nX5fijHkarYSttA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=sqHiiXQ7+UJwC9Dw9mYGnRlKloG6R/EVFmOOIIH+Du3Tdt8QMDp1qZo3oyprw3v+n YH3jfIe0t8PbSjPWCi8NyL2Ksp1YKQ1AZDkd9xLeZlDaInbRvJYdnY4iY4hTlVpsdw Ujogb/pAKHI16X2zlOt0k6OtFxUyo1+cG6BTx8NU= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> From: Adam Roach Message-ID: Date: Mon, 7 Sep 2020 14:27:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Posted my draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Sep 2020 19:27:29 -0000 I'd like to thank both of you for being clear in your arguments as well. This is shaping up to be two competing, mutually incompatible visions regarding accountability. While there is certainly room for refinement to both visions to make them more palatable to proponents of the other side, we, as a community, are clearly going to have to choose one rough direction over the other. I agree with Eric's general concerns about the path of recourse indicated by draft-stjohns-rfced-rseb and the subsequent clarifying comments. There's one thing in particular that sticks out as highly problematic: On 9/5/2020 7:02 PM, Michael StJohns wrote: > > If the RSEB proposes an idea that the RSE doesn't want to go along > with, then the recourse is for the RSEB to approach the LLC or CM and > ask them to intercede.  The LLC or CM may or may not choose to > intercede and will have to make those decisions based on what the > contract says and their perception of reality. > From the perspective of designed accountability, this is asking the LLC to take on ownership of decisions that are clearly outside of its intended purview. In the IASA2 conversations, the LLC was envisioned as a support function, not a deliberative one (which is why, e.g., it is part of no appeals chain). I'm looking through RFC 8711, and -- aside from the "compliance" bullet, which can bear on contract and personnel decisions in very limited and legally-required ways -- really don't see how one can conclude that it would be appropriate for the LLC to be the sole arbiter of whether an RSE is renewed or dismissed. It seems to me that the primary complaint that initiated this current effort is a belief that the community needs to be more directly involved in determining whether the RSE is performing his or her duties to the satisfaction of the community. This proposal is a giant step away from fixing that. /a From nobody Mon Sep 7 13:43: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 A93E33A1141 for ; Mon, 7 Sep 2020 13:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1dWI8eB4X1OB for ; Mon, 7 Sep 2020 13:43:24 -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 AEBF13A1107 for ; Mon, 7 Sep 2020 13:43:22 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 087KhLO7001972; Mon, 7 Sep 2020 21:43:21 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BB41B22044; Mon, 7 Sep 2020 21:43:20 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id A5D7322042; Mon, 7 Sep 2020 21:43:20 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.219.72]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 087KhJM3024718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Sep 2020 21:43:20 +0100 Reply-To: From: "Adrian Farrel" To: "'Adam Roach'" , "'Michael StJohns'" , "'Eric Rescorla'" Cc: References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> In-Reply-To: Date: Mon, 7 Sep 2020 21:43:19 +0100 Organization: Old Dog Consulting Message-ID: <037801d68557$856d4c70$9047e550$@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: AQICLbJu6pG1mMtcL2fBJMUauQxvzQJ/yLroAtLBF94DJZAf5wI66SZRAs9IhgKomj5uIA== Content-Language: en-gb X-Originating-IP: 87.112.219.72 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-25652.002 X-TM-AS-Result: No--12.194-10.0-31-10 X-imss-scan-details: No--12.194-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25652.002 X-TMASE-Result: 10--12.194100-10.000000 X-TMASE-MatchedRID: HLMPCFyIyBOxq1IXFBRg6HFPUrVDm6jtiRPU6vvejXL0u916xubzsDCy P4NQ0jGdkwn33Vura1KdPaYFEQ4mFRXvKm5vo1Skxuvd33/I/WShKzbbSmEIF9/wHr/wk3HvF0o ZQfaTMIS54eSPeW+/xtTUM2Ywa/hHqqrD2rq6EGCmput5KKcJ04JDF8D6I7sXVMsVgnp5Zx11tL LJvoU65ANjk/ToUaNmlihGkAxyZCa8xM/FoUm4nwmyVrMCuJ9SZAGtCJE23YjgYFyDXEbdFSE9B BikPU1yPq0n0Obl5a0zzEnjv8uWkE0U9PYk07UAYKm742WlIN4B4JHtiamkLE4QgsE4F6YvYmbt 3r48YLJQhJRC6ZF9GcSrUDShtH5vpRU7g3uRB+/M1jffIgQXhkyEf8qljHK7mFIIRNo/mvkkwlc MmOSp1B1NZs6zC5ksSw1CL/P+HQ0OrGzKXrhqUsHpLt99Ld5rDqsMH5ffrWXp8xIip9Al6/Bu1d b/G75RyzXQUyoBQpTd61WLX8gW7KEYauLi+i9Y8eSmTJSmEv2T9iqAum3gUo4iwAQuovtYKdRlq 5NGQtMH+AkmCgBpVFZKmkQxcUYXjzCPumW7aI7gVQAmE08JWt1eFEoaE12nUjwRJy6Lq0M+Squb chsr86fqSnn4w1Y9/dFMiOoWR562zoyRglahHDXKFtsDtZ7Ti+TAnPnbttjHMkjqltnst15XKvM z90rKYV/OOCwVbYmlugrXm5IKcMNOo16VCf1yx/Stmah0FpZ9LQinZ4QefBrZLyuS+0VxsOzOnc rmCoP3FLeZXNZS4DjAdLIal4R6O3+Ianmrj90v+kD+aAvRheSR/85uPP/lGbQKGdaczebelcueg rmEZA== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Posted my draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Sep 2020 20:43:26 -0000 Hi, I agree with Adam that this conversation is bringing a good degree of = clarity. But there's something here I don't understand. If you employ someone and they don't deliver (wilfully or because they = lack the skills) you may choose to fire them. If the hiring is on the recommendation of a person or group, then that = person or group can also recommend firing. But if the contract is held by a body, it is only that body that can = terminate the contract. Thus, are we just debating the strength of a recommendation? In contracts I am used to, one body (usually the "contracts department") = holds the contract: they sign it at the start and they are formally = responsible for termination. But the request to them to start a = contract, the formal acceptance of deliverables or work done, the = authorisation for payment, and any request to terminate comes from = another body (usually the "engineering department"). I can't see how anything we are proposing is different, but we may be = debating how much "community control" there is in the selection, = acceptance, and termination parts. The request for community control may = come from a fear that "the wrong thing may happen" or "I want to be able = to participate in the decision-making and influence the result". If so, = we need to move beyond that and understand delegated authority. When = delegated authority goes wrong, the community can replace the people who = got it wrong. We do not need community micro-management of all delegated = decisions (although consultation and discussion is a fine thing). Best, Adrian -----Original Message----- From: Rfced-future On Behalf Of Adam = Roach Sent: 07 September 2020 20:27 To: Michael StJohns ; Eric Rescorla = Cc: rfced-future@iab.org Subject: Re: [Rfced-future] Posted my draft I'd like to thank both of you for being clear in your arguments as well. = This is shaping up to be two competing, mutually incompatible visions=20 regarding accountability. While there is certainly room for refinement=20 to both visions to make them more palatable to proponents of the other=20 side, we, as a community, are clearly going to have to choose one rough=20 direction over the other. I agree with Eric's general concerns about the path of recourse=20 indicated by draft-stjohns-rfced-rseb and the subsequent clarifying=20 comments. There's one thing in particular that sticks out as highly=20 problematic: On 9/5/2020 7:02 PM, Michael StJohns wrote: > > If the RSEB proposes an idea that the RSE doesn't want to go along=20 > with, then the recourse is for the RSEB to approach the LLC or CM and=20 > ask them to intercede. The LLC or CM may or may not choose to=20 > intercede and will have to make those decisions based on what the=20 > contract says and their perception of reality. > From the perspective of designed accountability, this is asking the LLC = to take on ownership of decisions that are clearly outside of its=20 intended purview. In the IASA2 conversations, the LLC was envisioned as=20 a support function, not a deliberative one (which is why, e.g., it is=20 part of no appeals chain). I'm looking through RFC 8711, and -- aside=20 from the "compliance" bullet, which can bear on contract and personnel=20 decisions in very limited and legally-required ways -- really don't see=20 how one can conclude that it would be appropriate for the LLC to be the=20 sole arbiter of whether an RSE is renewed or dismissed. It seems to me that the primary complaint that initiated this current=20 effort is a belief that the community needs to be more directly involved = in determining whether the RSE is performing his or her duties to the=20 satisfaction of the community. This proposal is a giant step away from=20 fixing that. /a --=20 Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future From nobody Mon Sep 7 13:55: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 DF5F53A11AC for ; Mon, 7 Sep 2020 13:55:22 -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 4AU_eNl5vMoS for ; Mon, 7 Sep 2020 13:55:20 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD963A1175 for ; Mon, 7 Sep 2020 13:55:20 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id c2so17380349ljj.12 for ; Mon, 07 Sep 2020 13:55:20 -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=TMZdL1SoZyJt8GGKd7IbWqdBczJCiwTttWJX08/XmLE=; b=GQKk8qUooEaQBYoD3xag0+0da9tSeC7sDIOO1WpBHL8tDEdbaZ5NZFAvP/7AIQBBSr tuBLOotXTr0q8AJpzTeTvcJ+913qg/aL6xxqJ73fwMOP+6HmGOfhIiYXrhJs8KZ57Pwa 39Y3VVgcWfKpn8nF3aiy9wrlTZE+q1ayoxM3ZivzCJIOY4eiJ2INjrrxnIAkg1bhRut1 /dZYxZwRmlznWq4P7/bGRU2S+FKkusp5dRTfDGyPLvY0pTCmouJrL3qX9hDCvDOWH9KS JAjS+JSJh+Y4ZsH/vixPURzxoyxuff5cYJ0Itxzmbd9A6V24i6pjxgCd6Vt78qyJMqZ7 d+Ww== 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=TMZdL1SoZyJt8GGKd7IbWqdBczJCiwTttWJX08/XmLE=; b=LR1HvqYSGn8wC20hsPFCUot1RDbqV9goySarVMUiGgzgU4YIqh2B6dE6YY78ylq4Mk iK74bJorpaN8kGt1ZPykLcRECkeI9MAiuxgzvrKpdF9H3opCtBk6i1hArHg40/o4kWAz /KOIR0126bTg72LYj7SwGOBXNszSUpeO954FYFSt95HSd3awosv70+hmbmvn7wl4yvED 502sRTdbPn23iRYThRKztvxCi0xJ90REl+m0lUr33K4ScgbIowVKhfNcGxPDQ19EhnFd Gl3HTBvQyxKICFR7yENKX8cjdOs5LSBTRpaEBlWYpbxmOOQOoDplIUAn3NaUyMpw37iv twSw== X-Gm-Message-State: AOAM533IiNedBQryYeHT37YOHIas3q5vA+GrDL+7yJp2SJx2tl56xQBk k/KTsWErBmrJ7fPQt0mTUfP2+cqFs/VcXpfQTPsCGQ== X-Google-Smtp-Source: ABdhPJyLXFCF8targPR2cb0ov9YDah4IlfeGvf4Kou/X3gSOLwVwHBuZlC5vzEaB8A5egT/l5Wpu46iC9wgdyJhZkrA= X-Received: by 2002:a2e:87c7:: with SMTP id v7mr9105797ljj.13.1599512118313; Mon, 07 Sep 2020 13:55:18 -0700 (PDT) MIME-Version: 1.0 References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> <037801d68557$856d4c70$9047e550$@olddog.co.uk> In-Reply-To: <037801d68557$856d4c70$9047e550$@olddog.co.uk> From: Eric Rescorla Date: Mon, 7 Sep 2020 13:54:42 -0700 Message-ID: To: Adrian Farrel Cc: Adam Roach , Michael StJohns , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000a05bb705aebf6fff" Archived-At: Subject: Re: [Rfced-future] Posted my draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Sep 2020 20:55:23 -0000 --000000000000a05bb705aebf6fff Content-Type: text/plain; charset="UTF-8" Hi Adrian, I think there are three questions here: 1. Who is responsible for making the decision to hire? 2. Who is responsible for making the decision to renew a contract? 3. Who is responsible for making the decision to terminate a contract before renewal? Let's take the first two first. In the current structure under 6635, the decision to contract with a given person is made by a community-appointed body which is responsible for strategy (the IAB delegated the RSOC). Without their approval, no hiring can happen. Then once they approve, the LLC is responsible for actually executing a contract. If they can't come to terms, the IAB/RSOC may need to select someone else, but the LLC doesn't have the latitude to just hire someone who the IAB/RSOC hasn't approved (again, they can legally do so but they would be in violation of 6635 and that person wouldn't have any authority within our process). This matches the situation you indicate where there is a contracts/legal department who is responsible for actually negotiating with the contractor who is selected by the department that actually wants the services, but they don't hire people which that department doesn't want. IOW, this isn't about strength of recommendation but rather about who is responsible for vendor selection. The question of termination prior to renewal is more complicated; in some cases contracts are written with easy termination and in some without, and that's a question we should have some opinions on, but is secondary to the question above. -Ekr On Mon, Sep 7, 2020 at 1:43 PM Adrian Farrel wrote: > Hi, > > I agree with Adam that this conversation is bringing a good degree of > clarity. > > But there's something here I don't understand. > > If you employ someone and they don't deliver (wilfully or because they > lack the skills) you may choose to fire them. > If the hiring is on the recommendation of a person or group, then that > person or group can also recommend firing. > But if the contract is held by a body, it is only that body that can > terminate the contract. > > Thus, are we just debating the strength of a recommendation? > > In contracts I am used to, one body (usually the "contracts department") > holds the contract: they sign it at the start and they are formally > responsible for termination. But the request to them to start a contract, > the formal acceptance of deliverables or work done, the authorisation for > payment, and any request to terminate comes from another body (usually the > "engineering department"). > > I can't see how anything we are proposing is different, but we may be > debating how much "community control" there is in the selection, > acceptance, and termination parts. The request for community control may > come from a fear that "the wrong thing may happen" or "I want to be able to > participate in the decision-making and influence the result". If so, we > need to move beyond that and understand delegated authority. When delegated > authority goes wrong, the community can replace the people who got it > wrong. We do not need community micro-management of all delegated decisions > (although consultation and discussion is a fine thing). > > Best, > Adrian > > -----Original Message----- > From: Rfced-future On Behalf Of Adam Roach > Sent: 07 September 2020 20:27 > To: Michael StJohns ; Eric Rescorla > Cc: rfced-future@iab.org > Subject: Re: [Rfced-future] Posted my draft > > I'd like to thank both of you for being clear in your arguments as well. > This is shaping up to be two competing, mutually incompatible visions > regarding accountability. While there is certainly room for refinement > to both visions to make them more palatable to proponents of the other > side, we, as a community, are clearly going to have to choose one rough > direction over the other. > > I agree with Eric's general concerns about the path of recourse > indicated by draft-stjohns-rfced-rseb and the subsequent clarifying > comments. There's one thing in particular that sticks out as highly > problematic: > > On 9/5/2020 7:02 PM, Michael StJohns wrote: > > > > If the RSEB proposes an idea that the RSE doesn't want to go along > > with, then the recourse is for the RSEB to approach the LLC or CM and > > ask them to intercede. The LLC or CM may or may not choose to > > intercede and will have to make those decisions based on what the > > contract says and their perception of reality. > > > > From the perspective of designed accountability, this is asking the LLC > to take on ownership of decisions that are clearly outside of its > intended purview. In the IASA2 conversations, the LLC was envisioned as > a support function, not a deliberative one (which is why, e.g., it is > part of no appeals chain). I'm looking through RFC 8711, and -- aside > from the "compliance" bullet, which can bear on contract and personnel > decisions in very limited and legally-required ways -- really don't see > how one can conclude that it would be appropriate for the LLC to be the > sole arbiter of whether an RSE is renewed or dismissed. > > It seems to me that the primary complaint that initiated this current > effort is a belief that the community needs to be more directly involved > in determining whether the RSE is performing his or her duties to the > satisfaction of the community. This proposal is a giant step away from > fixing that. > > /a > > -- > 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 > --000000000000a05bb705aebf6fff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,

I think there are= three questions here:

1. Who is responsible for m= aking the decision to hire?
2. Who is responsible for making the = decision to renew a contract?
3. Who is responsible for making th= e decision to terminate a contract before renewal?

Let's take the first two first. In the current structure under 6635, t= he decision to contract with a given person is made by a community-appointe= d body which is responsible for strategy (the IAB delegated the RSOC). With= out their approval, no hiring can happen. Then once they approve, the LLC i= s responsible for actually executing a contract. If they can't come to = terms, the IAB/RSOC may need to select someone else, but the LLC doesn'= t have the latitude to just hire someone who the IAB/RSOC hasn't approv= ed (again, they can legally do so but they would be in violation of 6635 an= d that person wouldn't have any authority within our process). This mat= ches the situation you indicate where there is a contracts/legal department= who is responsible for actually negotiating with the contractor who is sel= ected by the department that actually wants the services, but they don'= t hire people which that department doesn't want. IOW, this isn't a= bout strength of recommendation but rather about who is responsible for ven= dor selection.

The question of termination pri= or to renewal is more complicated; in some cases contracts are written with= easy termination and in some without, and that's a question we should = have some opinions on, but is secondary to the question above.
-Ekr




On Mon, Sep 7, 2020 at 1:43 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

I agree with Adam that this conversation is bringing a good degree of clari= ty.

But there's something here I don't understand.

If you employ someone and they don't deliver (wilfully or because they = lack the skills) you may choose to fire them.
If the hiring is on the recommendation of a person or group, then that pers= on or group can also recommend firing.
But if the contract is held by a body, it is only that body that can termin= ate the contract.

Thus, are we just debating the strength of a recommendation?

In contracts I am used to, one body (usually the "contracts department= ") holds the contract: they sign it at the start and they are formally= responsible for termination. But the request to them to start a contract, = the formal acceptance of deliverables or work done, the authorisation for p= ayment, and any request to terminate comes from another body (usually the &= quot;engineering department").

I can't see how anything we are proposing is different, but we may be d= ebating how much "community control" there is in the selection, a= cceptance, and termination parts. The request for community control may com= e from a fear that "the wrong thing may happen" or "I want t= o be able to participate in the decision-making and influence the result&qu= ot;. If so, we need to move beyond that and understand delegated authority.= When delegated authority goes wrong, the community can replace the people = who got it wrong. We do not need community micro-management of all delegate= d decisions (although consultation and discussion is a fine thing).

Best,
Adrian

-----Original Message-----
From: Rfced-future <rfced-future-bounces@iab.org> On Behalf Of Adam Roach<= br> Sent: 07 September 2020 20:27
To: Michael StJohns <msj@nthpermutation.com>; Eric Rescorla <ekr@rtfm.com>
Cc: rfced-future@= iab.org
Subject: Re: [Rfced-future] Posted my draft

I'd like to thank both of you for being clear in your arguments as well= .
This is shaping up to be two competing, mutually incompatible visions
regarding accountability. While there is certainly room for refinement
to both visions to make them more palatable to proponents of the other
side, we, as a community, are clearly going to have to choose one rough direction over the other.

I agree with Eric's general concerns about the path of recourse
indicated by draft-stjohns-rfced-rseb and the subsequent clarifying
comments. There's one thing in particular that sticks out as highly problematic:

On 9/5/2020 7:02 PM, Michael StJohns wrote:
>
> If the RSEB proposes an idea that the RSE doesn't want to go along=
> with, then the recourse is for the RSEB to approach the LLC or CM and =
> ask them to intercede.=C2=A0 The LLC or CM may or may not choose to > intercede and will have to make those decisions based on what the
> contract says and their perception of reality.
>

=C2=A0From the perspective of designed accountability, this is asking the L= LC
to take on ownership of decisions that are clearly outside of its
intended purview. In the IASA2 conversations, the LLC was envisioned as a support function, not a deliberative one (which is why, e.g., it is
part of no appeals chain). I'm looking through RFC 8711, and -- aside <= br> from the "compliance" bullet, which can bear on contract and pers= onnel
decisions in very limited and legally-required ways -- really don't see=
how one can conclude that it would be appropriate for the LLC to be the sole arbiter of whether an RSE is renewed or dismissed.

It seems to me that the primary complaint that initiated this current
effort is a belief that the community needs to be more directly involved in determining whether the RSE is performing his or her duties to the
satisfaction of the community. This proposal is a giant step away from
fixing that.

/a

--
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
--000000000000a05bb705aebf6fff-- From nobody Mon Sep 7 13:56:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055113A117A for ; Mon, 7 Sep 2020 13:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awR5wn42gvNT for ; Mon, 7 Sep 2020 13:56:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B543A1175 for ; Mon, 7 Sep 2020 13:56:22 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 087KuKGr008747 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Sep 2020 15:56:21 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599512182; bh=+qXM1okXxHlIClGwAEDkKWnpALvzNMX8m3Hh454dONY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Z7whpiDXjfAgUQ6F5NaQ37L6JgB50WOeKHy+COa5IVAe+hrYXfJPZkV+A60RWAPKp AG9UDbvsMvuOJSHIsXoONypm7XvzhVqIbnRv0sH/580FkaQAl4KVn8MsXFORyCLw9M BZt65FPaLEEEFSABMW5uZarmQLF4wn3NeA29bXJ0= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: adrian@olddog.co.uk, "'Michael StJohns'" , "'Eric Rescorla'" Cc: rfced-future@iab.org References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> <037801d68557$856d4c70$9047e550$@olddog.co.uk> From: Adam Roach Message-ID: <417539a3-cde0-857b-640c-5078ed9a0723@nostrum.com> Date: Mon, 7 Sep 2020 15:56:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <037801d68557$856d4c70$9047e550$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Posted my draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Sep 2020 20:56:24 -0000 On 9/7/2020 3:43 PM, Adrian Farrel wrote: > When delegated authority goes wrong, the community can replace the people who got it wrong. We do not need community micro-management of all delegated decisions (although consultation and discussion is a fine thing). I think we're largely on the same page here. My key concern about the proposal that this thread is discussing is that it is pushing for the LLC to be "the people who get it right/wrong," and that's entirely the wrong body. Yes, they legally hold the contract because that's what the LLC is defined to be: the thing that legally owns the stuff that the IETF needs to have legally owned. But, again, the LLC doesn't have any deliberative functions, and it's pretty clear (both from the IASA2 conversations and the text in RFC 8711) that this was entirely intentional. If we want to re-open discussions on the role of the LLC to this degree, I think we're moving way outside the scope of this IAB activity and towards an "IASA3" proposal. /a From nobody Mon Sep 7 13:57: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 4C55C3A117A for ; Mon, 7 Sep 2020 13:57:38 -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 Mi180hee6nvG for ; Mon, 7 Sep 2020 13:57:37 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9723A1175 for ; Mon, 7 Sep 2020 13:57:37 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id w186so8531461pgb.8 for ; Mon, 07 Sep 2020 13:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uBwCTwK2AfPnwGmZ6k6v3aociIXvS2rFXFXRLlLCoYY=; b=EdCN8WeWtVrl5I8o7mKB1AmPIcDCBlBDx59poxjmpxB5thvAbqHLRjsNssmEYZegzl E5eLw7prvZgobnXFgFgBv/x4J2NyicqbJHIeWZ+zSMNM3Ylea8dXVOd/ti1to5jm0fT2 nw5/ueyhoyID+ktVKp40H8EeG7qIHrj3+XfBX4rlZQ6b8tPXET6e8+HvUUTQUupf7/1n 1dy90t/3+ysrNtMqSm6miBqcpppv95QgwPiGTkNCwgbNhnNFPzzMqNIbPsjipuPHTk9z Sf9Cm3GtWUEF2j+PTkJT71mkrit9C/O3E3OVV1i/uVk7GGb14TM65qIuGcWx+uJeYEhQ uPhg== 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=uBwCTwK2AfPnwGmZ6k6v3aociIXvS2rFXFXRLlLCoYY=; b=FEgSUcpYTB0zcBVCeba7dV2vMexXSrxiKDumMG0MDNVICXxYVPflf7nAzKHBNRSDxm jxoYZgo8TUEXfcmoTo3EToMNfoPbHB6WIWMBvf4wMpjmRBL0bnlNvEYk7myCI+kgcB3D h8kb1poUvkavKHJMwSb7FrT6rSR9aOHJMBI/PIN5gFC4BEaRqD7QJ++ah1kUTHZDG+b3 MO27WTHU96XQWCpAAe1naN4ADDYRHvkCxXJwQmSnNgfaqFLOTqY2INVS1zjwyFHyR1Ce fDf2u+tEKEp7Refw5mrzseYo+5MawQ21OIOHVBfeqTIcb6eS/FD8GntF4ZAtHRLN7ska 7qPQ== X-Gm-Message-State: AOAM533Azld25IFv92T8OZHpg9YjgRYTT3MVpXpQGm0GWCS9cOZaNoyO bzbELOPZSUpWrUBuWCz67ENho3xoD0n1gg== X-Google-Smtp-Source: ABdhPJyok4xPJK4ZEI7Z2fNi2XNzQlaodif+7OX7Ht8iYx1CA2a4htVXWhM2U0SMsilsIOVFcEzSfA== X-Received: by 2002:a17:902:9a0b:: with SMTP id v11mr20990066plp.236.1599512256314; Mon, 07 Sep 2020 13:57:36 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id m21sm6101700pfo.13.2020.09.07.13.57.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Sep 2020 13:57:35 -0700 (PDT) To: Adam Roach , Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> From: Brian E Carpenter Message-ID: Date: Tue, 8 Sep 2020 08:57:31 +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] Primary complaint? [was: Posted my draft] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Sep 2020 20:57:38 -0000 Adam, On 08-Sep-20 07:27, Adam Roach wrote: ...> It seems to me that the primary complaint that initiated this current > effort is a belief that the community needs to be more directly involved > in determining whether the RSE is performing his or her duties to the > satisfaction of the community. I'm not at all sure about that. Who made that complaint? My complaint is that the mishmash consisting of the IAB's view of its job, the RSOC's idea of an "oversight" mechanism, the matrix management mess created by the LLC and the RSE both having contract management authority, and conflicting opinions about the breadth of purpose of the RFC series, combined to make the RSE's job impossible. Brian From nobody Mon Sep 7 14:24: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 109B33A11A3 for ; Mon, 7 Sep 2020 14:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBgXcdnetmpV for ; Mon, 7 Sep 2020 14:24:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC14D3A11A1 for ; Mon, 7 Sep 2020 14:24:21 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 087LOFOH018555 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Sep 2020 16:24:16 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599513859; bh=zfqgf1auNK5+QmYVGZykvPPOvxgwaLBeh/i/JdCeL4w=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=jHO1lsdve9ksmI2vlzLc4XckQw43hqjrFzPJjCB4L2uSuFmC2Pb5y8Vgo0icSzrkK Pw/547pBrTi42N79jJ9c/llvPsM2FS/5w1/zCLV14cQJyT+L/qRPYN48+BeyI8HjdA ogaZq00NFj62eUgF2VHf+acxH31oQP45tLo3CVHA= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Brian E Carpenter , Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> From: Adam Roach Message-ID: <0d041710-bc41-c760-143c-22e12d4573e2@nostrum.com> Date: Mon, 7 Sep 2020 16:24:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Primary complaint? [was: Posted my draft] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Sep 2020 21:24:26 -0000 On 9/7/2020 3:57 PM, Brian E Carpenter wrote: > Adam, > > On 08-Sep-20 07:27, Adam Roach wrote: > ...> It seems to me that the primary complaint that initiated this current >> effort is a belief that the community needs to be more directly involved >> in determining whether the RSE is performing his or her duties to the >> satisfaction of the community. > I'm not at all sure about that. Who made that complaint? There's been a lot said both on mailing lists and at plenaries that points in this direction: significant swaths of the conversation last June/July on ietf@ietf.org could be fairly summarized as "the community should have been looped into this process earlier." There's even a message on June 20, 2019 where you offered a position of "community input on how the RFC Series is working and what needs to be adjusted would be the obligatory first step," which is clearly asking for more direct involvement. Don't read more into my statement than I intend: I would never want to see some kind of management by consensus in plenary, and I don't think anyone has seriously proposed that. What I'm saying is that there's a clear signal that the community wants to be more involved rather than less involved, and that Mike's characterization in the message I was replying to was driving in the opposite direction. If you think I'm wrong in my evaluation of what the community expressed, I'd appreciate you being clear about whether you think the community wanted to be less involved than they were last June or exactly as involved as they were last June, since those are really the only two other options. /a From nobody Mon Sep 7 16:26:38 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A33A0E8C for ; Mon, 7 Sep 2020 16:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, 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 GfRcQxGN4ukp for ; Mon, 7 Sep 2020 16:26:35 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A9E3A0E8B for ; Mon, 7 Sep 2020 16:26:35 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id np15so7870965pjb.0 for ; Mon, 07 Sep 2020 16:26:35 -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=Fip9ooXRyvmCjsCD2Fi/l66gtLiM0DcywEWRN5h5YCg=; b=Pa7t1UxcPJ0t2Ae53XcoUdN7BCxu0dv5nX/UVpfo+j5rME8Qvn7LpTxT5ngDO/5m3F vSlIMs0+oGaplJPyFEi6IQyMovO+DPL/kCEwhVOzCbInXHNo8RpRR4bXsmPRtJ7sHP9Y QAsLIuIIiyyi7/m0nOjlRs8xY+A8eQJHbbyJOSG8aDw9ORYJDCPc6FtaXU1RcbfIYh/G rxAbrfe9HmkVaL9hbGHshmmDjt1juh359WP/6BvMgL37lXF3z9at1xaSvbOF283moSjq ySsVI3doe1oMv6PpRsrvxTxoNsheK+2yl+uqwC32EIh1/gHXlfjWXmqg5vU93+yoV/bA nErQ== 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=Fip9ooXRyvmCjsCD2Fi/l66gtLiM0DcywEWRN5h5YCg=; b=c8SCdd52AwcLOsKvuAFgSwnCQviCEIe3JnUfGr2Tdr8JOpCMyJUv49HSumP9fEEEM0 j5gEWKWU1Bk6/2CTwDTrYVPZXG+U+Y36/VDpIq6YN5Mhy7cFRuyj0Uq8J4DoTNPe4MdW hpuH5N/Yz0k+SzXEmWXSe+siJKGkhU3ALhM75hJke7s8tRtN9yNx7J0HWkj9GVtjdrEi nV0Aru1cgBox44JMwWma6AoEpMzk4UIYLbYMVWNQkddz3toPp8/4cb+I2/59bprDUoUG obAEJzdGYJS9dXdV1EaBzvswyTwQscl8UUWEKzOYv8kuSenQ13cBQXFXepp9fu0zBpwI S05Q== X-Gm-Message-State: AOAM5339Hzr3rlweCZtXhGBaI3K59PZp8Ed+QFL436XPBFKjUWGA1Y4L ENn/2NBqdCHpcuCP1zyskwSFs/1fk7ZgNw== X-Google-Smtp-Source: ABdhPJyxHxmN/Y20AyYQ2TGRZ39ahuG+YmVcjZNaEoR0/QE4yJ5V+8NKTJTu+EqZd74mYkgvtYQJ5g== X-Received: by 2002:a17:90b:1812:: with SMTP id lw18mr1260603pjb.133.1599521194484; Mon, 07 Sep 2020 16:26:34 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id o192sm12905391pfg.14.2020.09.07.16.26.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Sep 2020 16:26:33 -0700 (PDT) To: Adam Roach , Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> <0d041710-bc41-c760-143c-22e12d4573e2@nostrum.com> From: Brian E Carpenter Message-ID: <604da6d0-aefe-5383-e083-9d016a57602e@gmail.com> Date: Tue, 8 Sep 2020 11:26:30 +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: <0d041710-bc41-c760-143c-22e12d4573e2@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Primary complaint? [was: Posted my draft] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Sep 2020 23:26:36 -0000 On 08-Sep-20 09:24, Adam Roach wrote: > On 9/7/2020 3:57 PM, Brian E Carpenter wrote: >> Adam, >> >> On 08-Sep-20 07:27, Adam Roach wrote: >> ...> It seems to me that the primary complaint that initiated this current >>> effort is a belief that the community needs to be more directly involved >>> in determining whether the RSE is performing his or her duties to the >>> satisfaction of the community. >> I'm not at all sure about that. Who made that complaint? > > > There's been a lot said both on mailing lists and at plenaries that > points in this direction: significant swaths of the conversation last > June/July on ietf@ietf.org could be fairly summarized as "the community > should have been looped into this process earlier." There's even a > message on June 20, 2019 where you offered a position of "community > input on how the RFC Series is working and what needs to be adjusted > would be the obligatory first step," which is clearly asking for more > direct involvement. Ah, OK, I see what you mean. It seems to me that was largely directed at the way the RSOC seemed to be operating, prior to the RSE's resignation. > Don't read more into my statement than I intend: I would never want to > see some kind of management by consensus in plenary, and I don't think > anyone has seriously proposed that. What I'm saying is that there's a > clear signal that the community wants to be more involved rather than > less involved, and that Mike's characterization in the message I was > replying to was driving in the opposite direction. Yes, and I do of course support a more open body than Mike's Board. That's why my draft borrows very heavily from Martin's. > If you think I'm wrong in my evaluation of what the community expressed, > I'd appreciate you being clear about whether you think the community > wanted to be less involved than they were last June or exactly as > involved as they were last June, since those are really the only two > other options. No, not at all. It was mainly the word "primary" that triggered me. Brian From nobody Wed Sep 9 06:05:16 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35103A0B6D for ; Wed, 9 Sep 2020 06:05: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 QH8tbFV30gUM for ; Wed, 9 Sep 2020 06:05: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 E6B3D3A0B6B for ; Wed, 9 Sep 2020 06:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5003; q=dns/txt; s=iport; t=1599656714; x=1600866314; h=from:mime-version:subject:message-id:date:to; bh=tsI7cRn9xmNye6vygVhB72z3327+dtI1e5QaRUlXaQ4=; b=cBjsuSovJL3CV0ZeAT9SQvijNVhxj13KduUTEtMTSPZVL6gqBEKYjLht iISBEmI8qAvJLKsMQGVGr6axMSD5ZB19ND/PSdXhIwprOFPHwi6pYAEde MdFp8j1csLSc54ammy8GK23rqw043qQK4uRCavQP9wZ183w2wRONk+00/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAADz0Vhf/xbLJq1FFwMdAQEBAQk?= =?us-ascii?q?BEgEFBQGBewgBCwGDGVUBIBIshDiIImCIEpQphhyBHAVcCwEBAQwBASUKBAE?= =?us-ascii?q?BhEuCFCU0CQ4CAwEBCwEBBQEBAQIBBgRthVwMhhxkESwMBgIdg3sBgnwPO6M?= =?us-ascii?q?mjhB2gTKDToIFhFwdBgWBMwGGSYZ7ggCBEScMEIIfgXCBWAQXgWcmCIIdKzO?= =?us-ascii?q?CEhsEpW6QfIJvBIMJhVuGUIp6Ax6DCYlvhQuOU4Vglz+RMYNYAgQGBQIVgVQ?= =?us-ascii?q?6gVczGggbFTsqAYI/PRIZDY4rDAuDTopYPwMwAjUCBgEJAQEDCYwjgiABAQ?= X-IronPort-AV: E=Sophos; i="5.76,409,1592870400"; d="scan'208,217"; a="29455117" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Sep 2020 13:05:09 +0000 Received: from [10.61.235.105] ([10.61.235.105]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 089D59W1005515 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Sep 2020 13:05:09 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_219A20F0-ACA8-4CD4-833A-24A91AA8705E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <4C8194D1-787D-4479-924F-B8E874A47497@cisco.com> Date: Wed, 9 Sep 2020 15:05:09 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.235.105, [10.61.235.105] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Agenda for Interim Meeting - 15 Sep 2020 23.00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 13:05:16 -0000 --Apple-Mail=_219A20F0-ACA8-4CD4-833A-24A91AA8705E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings to all! Our next meeting will take place on September 15th at 23:00 GMT. WebEx = information can be found below. The chairs have been enjoying the group engaging in a good back and = forth about the various proposals for the evolution of the RFC Editor = function. Our goal is to narrow down to a starting point for adoption = as a WG draft. Note the words =E2=80=9Cstarting point=E2=80=9D, not = ending point. We observe that there are four proposals to discuss at our interim, and = this will form the basis of our agenda, which we propose to be as = follows: Note Well (Brian) Agenda Bashing (Brian) Brief overview by authors of their proposals (in order of submission) draft-brownlee-rfc-series-and-rse-changes-01 (Nevil =E2=80=93 5-10 = minutes) draft-thomson-rfced-model-01 (Martin =E2=80=93 5-10 minutes) draft-carpenter-rfced-model-00 (Brian =E2=80=93 5-10 minutes) draft-stjohns-rfced-rseb-00 (Mike =E2=80=93 5-10 minutes) A brief comparison of proposals (Eliot- 5 minutes) Discussion (remaining time minus 10 minutes) Humming (2 minutes) (Brian) Next steps (2-3 minutes) (Brian) AOB During Item 3 we would ask that there be only clarifying questions, as = we are devoting roughly half the time to discussion. Any hums will be verified on list. Please send any additions/changes you would like to see Real Soon Now. Brian and Eliot Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=3Dm1337e3af9b39bc2ce78932daea000cda= = Meeting number (access code): 171 361 7996=20 Meeting password: iabrfc=20 Join by phone: 1-650-479-3208 --Apple-Mail=_219A20F0-ACA8-4CD4-833A-24A91AA8705E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Greetings to all!

Our next meeting  will take place = on September 15th at 23:00 GMT.  WebEx information can be found = below.

The = chairs have been enjoying the group engaging in a good back and forth = about the various proposals for the evolution of the RFC Editor = function.  Our goal is to narrow down to a starting point for = adoption as a WG draft.  Note the words =E2=80=9Cstarting point=E2=80= =9D, not ending point.

We observe that there are four proposals to discuss at our = interim, and this will form the basis of our agenda, which we propose to = be as follows:

  1. Note Well = (Brian)
  2. Agenda Bashing (Brian)
  3. Brief= overview by authors of their proposals (in order of submission)
    1. draft-brownlee-rfc-series-and-rse-changes-01 (Nevil =E2=80= =93 5-10 minutes)
    2. draft-thomson-rfced-model-01 = (Martin =E2=80=93 5-10 minutes)
    3. draft-carpenter-rfced-model-00 (Brian =E2=80=93 5-10 = minutes)
    4. draft-stjohns-rfced-rseb-00 (Mike =E2=80=93 = 5-10 minutes)
  4. A brief comparison of proposals = (Eliot- 5 minutes)
  5. Discussion (remaining time minus = 10 minutes)
  6. Humming (2 minutes) (Brian)
  7. Next steps (2-3 minutes) (Brian)
  8. AOB

During Item 3 we would ask that there be only clarifying = questions, as we are devoting roughly half the time to = discussion.

Any = hums will be verified on list.

Please send any additions/changes you = would like to see Real Soon Now.

Brian and Eliot

Information about remote = participation:
https://ietf.webex.com/ietf/j.php?MTID=3Dm1337e3af9b39bc2ce7893= 2daea000cda

Meeting number (access = code): 171 361 7996 
Meeting password: = iabrfc 
Join by phone: 1-650-479-3208
= --Apple-Mail=_219A20F0-ACA8-4CD4-833A-24A91AA8705E-- From nobody Wed Sep 9 06:50:16 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB02B3A0C79 for ; Wed, 9 Sep 2020 06:50:14 -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 kAZFDOadhdqz for ; Wed, 9 Sep 2020 06:50:13 -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 3EC893A0C88 for ; Wed, 9 Sep 2020 06:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1026; q=dns/txt; s=iport; t=1599659413; x=1600869013; h=from:mime-version:subject:message-id:date:to; bh=/JbYVYKdC90fCVWiMLd/z8hpuNnq6PACm4JrtK+aVG8=; b=f8zczoYrQfz5uzjnx//xcl71NJxzAgdPEII3zh0C8I2C7VHCZnkOtNZT yxLhm/VfChDXbs+pZ3U4fcmsH5zdEEGe5JIAiKbVvvrLvlcGCVpB7nCXm YtJhpPYoEW7YWZ+4qncmhm7FS8AxTz9LfgjuZ1Dqyj9JPvEqCH/dmAnUl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAwCu3Fhf/xbLJq1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DbwEgEo1miBKUKYgZCwEBAQwBAS8EAQGGXyU4EwIDAQE?= =?us-ascii?q?LAQEFAQEBAgEGBG2FaIVpgScBAoRWgn2kDI4QdIE0hVOEdYE4jUWCAIE4DBC?= =?us-ascii?q?CIAGFdIJ9gi0Em0CbKoJvBIMJlyUDHpIDjlOuUINYAgQGBQIVgWsjgVczGgg?= =?us-ascii?q?bFWUBgj89EhkNnGg/A2cCBgoBAQMJjkMBAQ?= X-IronPort-AV: E=Sophos; i="5.76,409,1592870400"; d="scan'208,217"; a="29456255" 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; 09 Sep 2020 13:50:09 +0000 Received: from [10.61.235.105] ([10.61.235.105]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 089Do8nY002574 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Sep 2020 13:50:09 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_58AA21DF-5228-40E7-AAE0-CC29AA0A775F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Wed, 9 Sep 2020 15:50:08 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.235.105, [10.61.235.105] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] Minute taker needed X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 13:50:15 -0000 --Apple-Mail=_58AA21DF-5228-40E7-AAE0-CC29AA0A775F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If you are planning to attend the interim and are not planning to = present, would you kindly accept the usual remuneration, accolades, and = plaudits for agreeing to take minutes? Eliot --Apple-Mail=_58AA21DF-5228-40E7-AAE0-CC29AA0A775F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii If you are planning to attend the interim and are not planning to present, would you kindly accept the usual remuneration, accolades, and plaudits for agreeing to take minutes?

Eliot

--Apple-Mail=_58AA21DF-5228-40E7-AAE0-CC29AA0A775F-- From nobody Fri Sep 11 09:51:46 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 09F173A145C; Fri, 11 Sep 2020 09:51:40 -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: lear@cisco.com, rfcefdp-chairs@ietf.org, The IAB , rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159984309995.2307.5066458603718086703@ietfa.amsl.com> Date: Fri, 11 Sep 2020 09:51:39 -0700 Archived-At: Subject: [Rfced-future] rfcefdp - New Meeting Session Request for IETF 109 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 16:51:43 -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): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: rum dispatch stir sipcore emu opsawg anima Technology Overlap: gendispatch People who must be present: Brian E. Carpenter Eliot Lear John R. Levine Michael StJohns Brian Rosen Martin Thomson Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Sep 11 09:55:16 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82B13A0BFD for ; Fri, 11 Sep 2020 09:55:14 -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 hVylt_70V_8B for ; Fri, 11 Sep 2020 09:55:14 -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 926B03A0BED for ; Fri, 11 Sep 2020 09:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=448; q=dns/txt; s=iport; t=1599843313; x=1601052913; h=from:content-transfer-encoding:mime-version:subject: message-id:date:to; bh=zRwyg9yAgRyXwKrab96VJ24w2PUcvIDLTdcfbZrSGIs=; b=YADwA1U+1wPn2Rj2XAS4hvPPhUKoMmRiSP+SLZ307LmoboYeM8rgI/qh XZRftbDpAPxwB37bVzGYNzasPhhFyRG4df/4FqNYy6E3ePMPIHuuJUo9V ZF2wjhbqUfbyZUXItDS0T/kKJhOxRe+AeFgBO6fK7hOQnCOwy16M3XYrK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaBABSq1tf/xbLJq1fHgEBCxIMQIF?= =?us-ascii?q?EC4NvATKBWwEQgniJAo1XlQuBaQsBAQENAQEIDRoEAQEPhmIlNwYOAgMBAQs?= =?us-ascii?q?BAQUBAQECAQYEbYVohhyBCwIRFQKEGIJ9pWqOEHaBMoVThHyBDiqFTUuHL4I?= =?us-ascii?q?AgTgcg3YZAYJxgQYOgkozgi0EtwGCbwSDDZcnAx6CdwGPEY5arhNQg1kCBAY?= =?us-ascii?q?FAhWBaiSBVzMaCBsVZQGCPz0SGQ1YjV+OMT8DZwIGAQkBAQMJj2YBAQ?= X-IronPort-AV: E=Sophos;i="5.76,416,1592870400"; d="scan'208";a="29468816" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Sep 2020 16:55:09 +0000 Received: from [10.61.215.124] ([10.61.215.124]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 08BGt921004865 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2020 16:55:09 GMT From: Eliot Lear Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Fri, 11 Sep 2020 18:55:08 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.215.124, [10.61.215.124] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] Session request For IETF 109 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 16:55:15 -0000 Hello everyone, I have created a session request for IETF 109. My finger in the wind at = this point tells me that we=E2=80=99ll run for about 90 minutes, but the = slot requests are either 1 or 2 hours. We may revise this based on some = agenda bashing after the interim. We are generally trying to take into account the conflicts of authors, = but that may be too tough already. More on this after the interim next week. Eliot= From nobody Tue Sep 15 15:25: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 A525A3A0AD4 for ; Tue, 15 Sep 2020 15:25:36 -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 apHuHsWIRxvb for ; Tue, 15 Sep 2020 15:25:35 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D377C3A0E7B for ; Tue, 15 Sep 2020 15:25:34 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kIJOH-000FMp-Fy; Tue, 15 Sep 2020 18:25:33 -0400 Date: Tue, 15 Sep 2020 18:25:27 -0400 From: John C Klensin To: Martin Thomson , rfced-future@iab.org Message-ID: <12564DEF9AE2EFB41A087C69@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Rfced-future] Where is the expertise? (was: Re: My hard constraints) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 22:25:37 -0000 Martin, TL;DR summary: Openness, transparency, and broad involvement is important, but the IETF also needs to recognize when the community does not have knowledge and expertise and deal with that, not just assume the adequacy of IETF community wisdom. ---- Apologies for not getting back to the second part of my comments on this -- have been busy and have hoped that others would either make the point or clear up my confusion. I've also struggled to make it short. Given the interim meeting/call in an hour, time is obviously up. I am confused. I was confused and frustrated (your fault only to a very small degree) long before you posted the note excerpted below and those are major reasons why I've been so quiet on this list. --On Wednesday, August 26, 2020 12:22 +1000 Martin Thomson wrote: > On tricky problems we often do this little dance where no one > says what they really want. I think that it is important to > be clear on what aspects of proposals are important as opposed > to those that are either consequences of other decisions, > arbitrary, or soft preferences. So let me touch on three > points of contention: > > 1. where strategy happens > > For me, my overriding goal is to define a system whereby > substantive strategy decisions are both discussed and resolved > in a public forum. From this, I derive two hard objections to > the drafts that Mike has so helpfully published: > > * no body with closed membership > > * no tenured, employed, or contracted "leader" > > Requirements that meetings be public are not sufficient to > achieve this goal. IAB and IESG meetings are also routinely > public, but the only places where true engagement occurs is at > plenaries, which is inadequate. >... Openness and transparency and a greater degree of involvement in community involvement is great. A certain amount of skepticism about designated "leaders" or designated experts is too and I think we often have too little of it. However, this gets tied up with a problem I've observed occasionally in several engineering communities in a variety of fields including the IETF. That is an implicit assumption that, because the community and its members are expert in its particular area --and, in the case of the IETF, often quite dismissive of people who comment in that area but appear to lack expertise-- that the expertise extends to all areas. In those other areas, we need to understand what we don't know, seek outside expertise, and, to at least some degree, rely on it... just as we expect people from very different areas, to rely on us. While there may be exceptions, it generally is a bad idea to have network engineers doing brain surgery and an almost equally bad one to have brain surgeons designing network protocols. We can, and should, expect those outside experts to explain and educate, but that expectation is reasonable only if we are willing to listen and learn. In some areas, the IETF has recognized its collective limitations in other areas. The creation of the IASA (and now IASA2) is a reasonable example of such recognition because most of us are not expert in the sorts of financial and administrative areas IASA/IASA2 is suppose to provide expertise. Perhaps the observation that few of us want to be heavily involved with such things helps in that recognition. But, in other areas, ones that I suggest including publications strategy issues, determining whether documents are clear to a broad range of readers outside our narrow community, making sure documents are available and readable for _very_ long periods of time (presumably long after the IETF disappears because institutions like it usually do), we continue to prove quite poor at understanding and accepting the gaps in the community's knowledge. Those topics are not unique -- I'll avoid a list in the interest of space, but there are a few even more obvious examples that lie closer to our protocol work. So my confusion about your hard constraints and many of the other discussions on this list is that we want high quality and long-lived documents but, at the same time, we apparently want to rely on the expertise and authority of the community rather than finding actual experts and giving them authority. I don't see how those fit nicely together. Perhaps some of us really don't care about much of what I'm lumping together as quality and longevity. Others clearly do. If so, just as your note suggests, we should be having a clearer and more focused discussion of that specific issue. Similarly, the authority can subject to oversight of various sorts but having the collective wisdom of the community override expert judgment may be no more sensible than believing that a committee of brain surgeons would be good designers of network protocols even if one of them were not. We can insist that the expert(s) educate us, but only if we have the time and inclination to be educated -- something of which I've seen little evidence in this topic area or even in the discussions on this list. So, which is it? Because, until we get there, it seems to be that trying to pin down titles and exactly organizational relationships might be missing the point. thanks for listening, john (or maybe that is an unjustified assu From nobody Tue Sep 15 17:59:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA33D3A0A29 for ; Tue, 15 Sep 2020 17:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=feuXuShl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IBrW4JBb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrhEJBGuoxi4 for ; Tue, 15 Sep 2020 17:59:22 -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 769DC3A0A2C for ; Tue, 15 Sep 2020 17:59:22 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 3E3FCB1E; Tue, 15 Sep 2020 20:59:21 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Tue, 15 Sep 2020 20:59:21 -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=fm3; bh=A72gq3kSxGutNqbAwG6trVzifPjpkcs Q2OnK2z7w8hA=; b=feuXuShlWpurvsg3Zi+3+ZsENMllE5Rq4AM7x6tN+4V8mww AvnQ+O7UHR+eVX8grp3sMMFacwV7Jy80wGp0BWuCLb03rq6T3spNs733zhGoM8YK f802ADfCJ5hrEc9YLJdTCFh4/IxvFBPPjqgVkQrd2SfesT45pNG1NQnEK5ODyJ3h CAMY7Q3M04+fYe4TtsCzO8e93X0VIc/qK+XiOMti+VARubT8Y/T67bRbT03vU4LX iSofLMfrEgVK3eUgc5Qi22Zzbr1/X0tAn92R7LMbFKrSUPx867b0ANtzWdehkzLg 3C/ACeX5f3SNoLB38X5e1DdebeEDUAJiOUSmWtQ== 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=A72gq3 kSxGutNqbAwG6trVzifPjpkcsQ2OnK2z7w8hA=; b=IBrW4JBbaW3d/0XrLgjAGS 7J0py/4yS7VJmCUCBuQnLFeE6uvICwAbIU2bPUNCv3aKqlg+iCzy4HqSg9+mhp3D IiqRpcaZituC9COZGfqbbLwyzhHZsb78qSGJk2VgNf/b7YzHTngUy9ifgEN8tV3e uO7a6uCLjtcmA6AihfDacJ5yG/TZFUrZV0m0Qs7ZKk8oMWZZfUsmT6vLxELr8Vek xbX8ED6L217a/CCnUxsccQn3qscuuSdHDcKaUasmID6BRWrP/biJpN+x55RP96OQ wB7G6glqR6ybFVxr89To4izm9fDhDjIpLvuwKxQ2hlMg5g8UvFFIBcCZ0+mXMFuA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrtddugdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheefteduudduhedtkefhvd fhteelffdujeegjeffheffveekudeigfeuveekfeelnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 82E35200D4; Tue, 15 Sep 2020 20:59:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3 Mime-Version: 1.0 Message-Id: <50833a6b-6c77-4cf0-87a6-6908980631b9@www.fastmail.com> In-Reply-To: <12564DEF9AE2EFB41A087C69@PSB> References: <12564DEF9AE2EFB41A087C69@PSB> Date: Wed, 16 Sep 2020 10:58:40 +1000 From: "Martin Thomson" To: "John C Klensin" , rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Where_is_the_expertise=3F__=28was=3A_Re?= =?utf-8?q?=3A__My_hard_constraints=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 00:59:24 -0000 Hi John, I had a little trouble following the thread here, but to answer your most direct question... On Wed, Sep 16, 2020, at 08:25, John C Klensin wrote: > So my confusion about your hard constraints and many of the > other discussions on this list is that we want high quality and > long-lived documents but, at the same time, we apparently want > to rely on the expertise and authority of the community rather > than finding actual experts and giving them authority. I don't > see how those fit nicely together. Perhaps some of us really > don't care about much of what I'm lumping together as quality > and longevity. Others clearly do. If so, just as your note > suggests, we should be having a clearer and more focused > discussion of that specific issue. Similarly, the authority can > subject to oversight of various sorts but having the collective > wisdom of the community override expert judgment may be no more > sensible than believing that a committee of brain surgeons would > be good designers of network protocols even if one of them were > not. We can insist that the expert(s) educate us, but only if > we have the time and inclination to be educated -- something of > which I've seen little evidence in this topic area or even in > the discussions on this list. > > So, which is it? So I did put the question of vesting authority in an individual as a hard constraint. But only because one person is the ultimate closed board, where making internal communications open to public engagement or scrutiny is maximally difficult. If there is something we need then yes, we need to know that we need it. You and others have amply demonstrated that people are willing to agitate for contracting specialized expertise, so I'm not concerned about that aspect. We then need to then source that expertise. I have suggested this be ad-hoc, Brian suggests something like having someone on retainer (with some other duties that ensure they stay engaged). I don't see that latter distinction as being as important relative to the key distinction: expertise is sought as advice. Then finally we need to listen (and this seems to be your pivotal point). You assert that future incarnations of some open group might either not seek advice when necessary, or might ignore such advice if it does not have some authoritative impetus. Yes, we have numerous examples where individuals reject well-considered input from experts. That might be more acute when advise is outside of the expertise of the group (in a general sense, I'm constantly impressed by the diversity of expertise represented in this community). It's a threat we can acknowledge, but I don't think that the cost of the defense you propose is anywhere near worth paying. From nobody Wed Sep 16 02:35:33 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004E83A0F1D for ; Wed, 16 Sep 2020 02:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMkYskWCOGwh for ; Wed, 16 Sep 2020 02:35:31 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DC63A0F1B for ; Wed, 16 Sep 2020 02:35:30 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08G9ZSvO024756 for ; Wed, 16 Sep 2020 10:35:28 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C7B3D22042 for ; Wed, 16 Sep 2020 10:35:28 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id B280C22040 for ; Wed, 16 Sep 2020 10:35:28 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.40.230]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08G9ZRaf009188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2020 10:35:28 +0100 Reply-To: From: "Adrian Farrel" To: Date: Wed, 16 Sep 2020 10:35:27 +0100 Organization: Old Dog Consulting Message-ID: <00f401d68c0c$b6a3c290$23eb47b0$@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: AdaMC2o+OFtfqaBWQU64dLjm8u3Y+Q== Content-Language: en-gb X-Originating-IP: 87.112.40.230 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-25668.005 X-TM-AS-Result: No--15.825-10.0-31-10 X-imss-scan-details: No--15.825-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25668.005 X-TMASE-Result: 10--15.825400-10.000000 X-TMASE-MatchedRID: 2f54MF+YEvr37laQE543B2v2CEsM8dpJOViC3QIOASCy25qfhJxiCjDH xnr5pBtwKZYF+2pVLGZgNJdEFW3Am7kWDqm7WNaJxuvd33/I/WSbYck3o66U7P7spkgIRsSy8f4 StkBOa37mYgXqqYix1pMNmW27Ru2IPVvODhhNUCT0VCHd+VQiHm0TAJ1EuNBm7i61jx2QMPJIK7 BsVoaqr256HjsHQiTW7W9T1reG6wLImuJG/muc0bSlePUaQB97v8jdqvFOu+JHrX2E2MkfRHJS8 1mqB724X8szSis1XG4c3wTlX0NIpxlRDtRtOXIZ5nYykFx71TF9iuvWn3J8KjZVldK1+mhdCCBr HKRtXXGFYdcmVZBI0yCezYDg2QbmHEsuFokV5zdw34sVvTuXGBmyTBaqiJvcDIYQ+Gg8oZoeocb DCJ3SD2rpvdRbmCh2f4IcVBlzW26/o6FV0a/GMQPZZctd3P4B69aS+7/zbj+qvcIF1TcLYFl4xf TSs3QpcKB6McleZynEPkAYQVlJyN3U0Kg+MKUitvnlOJ61K3qz4D778GcgESk/C1BMsoqKl8IeB z+TMM2M7pkdeNTBZyivjKXQTfpLv7Q5vATVUMvFsChkXJd5oX3x9oKUU5NUkPjpBK48yksK0/BV YqipedkPEaeiDYOevAuwjNKWRTSFmMEVwi+q3YSSxX6w03puNViD8yHrgAlYXOxm7Wmd0Vs+KhM /P3RBGLSSpvoNQGKNl+W34q+tbYXASMJi7iGLutvHF25zoU9Lqa9X75MqaXsU9END0TV0wWahHS cmYz2e0SLddf/DjC8QxTNiP/mIzyFwutRiXkueAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg/cUt5lc1lLgtT4piLWpY7p+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfced-future] Trust versus accountability [Was: Where is the expertise? (was: Re: My hard constraints] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 09:35:33 -0000 I think this debate is evolving into a somewhat old conversation about trust versus accountability. On the one hand, an advisor's advice might be summarily ignored by our decision-makers. On the other hand, a person with delegated authority might not deliver what we want. I don't see how these two situations are markedly different. In the first case, the community replaces the decision-makers. In the second case, the contract of the person is terminated. Both risk us wasting some time, having to unpick decisions, and expending some angst to get back on track. Both situations can be properly managed through oversight from the community and through proper and respectful communication. On which side of the choice an individual falls seems (to me) to depend on where their paranoia is rooted: do you trust the I* to mainly follow expert advice, or do you trust an expert with well-defined directives to deliver? But there are other things that should influence this choice. The principal one that should concern us is the level of commitment to the IETF that we get from a consultant/employee/contractor in the different cases. How much control over their destiny does someone feel they have; how easy is it for them to throw up their hands and walk away; how strongly do they remain motivated to continue doing their absolute best? Those factors may also significantly influence the number and type of person who applies. Best, Adrian -----Original Message----- From: Rfced-future On Behalf Of Martin Thomson Sent: 16 September 2020 01:59 To: John C Klensin ; rfced-future@iab.org Subject: Re: [Rfced-future] Where is the expertise? (was: Re: My hard constraints) Hi John, I had a little trouble following the thread here, but to answer your most direct question... On Wed, Sep 16, 2020, at 08:25, John C Klensin wrote: > So my confusion about your hard constraints and many of the > other discussions on this list is that we want high quality and > long-lived documents but, at the same time, we apparently want > to rely on the expertise and authority of the community rather > than finding actual experts and giving them authority. I don't > see how those fit nicely together. Perhaps some of us really > don't care about much of what I'm lumping together as quality > and longevity. Others clearly do. If so, just as your note > suggests, we should be having a clearer and more focused > discussion of that specific issue. Similarly, the authority can > subject to oversight of various sorts but having the collective > wisdom of the community override expert judgment may be no more > sensible than believing that a committee of brain surgeons would > be good designers of network protocols even if one of them were > not. We can insist that the expert(s) educate us, but only if > we have the time and inclination to be educated -- something of > which I've seen little evidence in this topic area or even in > the discussions on this list. > > So, which is it? So I did put the question of vesting authority in an individual as a hard constraint. But only because one person is the ultimate closed board, where making internal communications open to public engagement or scrutiny is maximally difficult. If there is something we need then yes, we need to know that we need it. You and others have amply demonstrated that people are willing to agitate for contracting specialized expertise, so I'm not concerned about that aspect. We then need to then source that expertise. I have suggested this be ad-hoc, Brian suggests something like having someone on retainer (with some other duties that ensure they stay engaged). I don't see that latter distinction as being as important relative to the key distinction: expertise is sought as advice. Then finally we need to listen (and this seems to be your pivotal point). You assert that future incarnations of some open group might either not seek advice when necessary, or might ignore such advice if it does not have some authoritative impetus. Yes, we have numerous examples where individuals reject well-considered input from experts. That might be more acute when advise is outside of the expertise of the group (in a general sense, I'm constantly impressed by the diversity of expertise represented in this community). It's a threat we can acknowledge, but I don't think that the cost of the defense you propose is anywhere near worth paying. From nobody Wed Sep 16 03:09: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 EE3D33A0C4E for ; Wed, 16 Sep 2020 03:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1E_g9YkpS5I for ; Wed, 16 Sep 2020 03:09:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE0C3A0C06 for ; Wed, 16 Sep 2020 03:09:31 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08GA9SXm084036 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 16 Sep 2020 05:09:30 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600250970; bh=B2L133EU1AedNHdyhkhhBZciRgMKt8p4Sbm8gxqlQ/I=; h=Subject:To:References:From:Date:In-Reply-To; b=TsUwT11eRcZMDiy3y8xQw4ngsNBYQRXCWwUtccaK7Hgh32mCl56D5GyzScGDXZyUK /MA4U2WTVXYwYr/2scUUrk4Iyn4Hy2sqlNqMMVxJh+bEXJHt7bD69MbqiW/PTQitxf 7fOjk1ySBRkqPWEKdWno8w88Drb56ByZup1e8WZU= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: adrian@olddog.co.uk, rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> From: Adam Roach Message-ID: <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> Date: Wed, 16 Sep 2020 05:09:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? (was: Re: My hard constraints] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 10:09:34 -0000 On 9/16/2020 4:35 AM, Adrian Farrel wrote: > I don't see how these two situations are markedly different. In the first > case, the community replaces the decision-makers. In the second case, the > contract of the person is terminated. I think there is *absolutely* a marked difference: in a structure where continuous leadership change is part of the expected order of things, the former is business as usual, while the latter is clearly a traumatic event for the community. (This is assuming that the replacement happens on a normal nomcom cycle in the former case, and on a normal contract renewal cycle in the latter. If you're talking about out-of-cycle replacements: as John is fond of pointing out, mid-term recall process has never been successful; and mid-contract termination would be legally dicey except in the most egregious of violations.) /a From nobody Wed Sep 16 03:20: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 31E393A0E0A for ; Wed, 16 Sep 2020 03:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zffENs5meSz for ; Wed, 16 Sep 2020 03:20:28 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F2C3A0DED for ; Wed, 16 Sep 2020 03:20:27 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08GAKPeh027356; Wed, 16 Sep 2020 11:20:25 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F9CC2203B; Wed, 16 Sep 2020 11:20:25 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 7AA632203A; Wed, 16 Sep 2020 11:20:25 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.40.230]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08GAKOQj001166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Sep 2020 11:20:25 +0100 Reply-To: From: "Adrian Farrel" To: "'Adam Roach'" , References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> In-Reply-To: <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> Date: Wed, 16 Sep 2020 11:20:24 +0100 Organization: Old Dog Consulting Message-ID: <011101d68c12$fe03a500$fa0aef00$@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: AQFM+SDJYFvGamEgQmQGZWd2OZTRMwIyKQ4EqmygkUA= Content-Language: en-gb X-Originating-IP: 87.112.40.230 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-25668.006 X-TM-AS-Result: No--6.506-10.0-31-10 X-imss-scan-details: No--6.506-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25668.006 X-TMASE-Result: 10--6.505700-10.000000 X-TMASE-MatchedRID: WMT2WRIkHPPxIbpQ8BhdbEAvdL4TzpZNU5NTLQmjdYEUZ5IS2TgivZEx qXrBFaCArOOppPTYnng3oSTRsE1v8Wx1KzN44QPtzzuzg6dga4IZSo6PM4LsintTo0P1ssT+Las uly9+PUfT5iqMORYvGaw74EYTQ1pUKaT7un/IDBuA6qv+vR34LL/I3arxTrviRQgyInUyrWKJax P2QByNFg+5gZatHsyPRGTPpnQXilk4d+5S7Hm6+HDfixW9O5cYTIR/yqWMcruy25qfhJxiCvRkB 3dD7L2Z/ye/3Hc9K1rSWNwLl9G3n5qFPAiWakvIaiddnFknhU81wgjXWX56uCNGK7UC7ElMa4G7 autQDXxNLXH4ROxj5nfDrN+Nge5JcbgP9mi8yA7TI+uIed+/fGdtqI+Wek3u4WNDrZWE/xsPEGC lxngghK3WS3pROsBbX7bicKxRIU1UAAMyZMf0qCs3zPQeiEbe+gtHj7OwNO2FR9Hau8GO7vjk9M /Vd449KqBeMAVmfZuuQ7Nu/NeFiqcNYvcVU+xJdOXuGneHGe3AvpLE+mvX8g== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? (was: Re: My hard constraints] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 10:20:30 -0000 Hi Adam, Most contracts I sign with customers give them the ability to cancel = with 30 days' notice and no reason given. That is the nature of the = beast. (I believe in the US employment contracts are not typically = better than this.) I think it is absolutely the case that people retained in consultancy or = contracting roles also expect to be on a continuous re-hiring cycle, so = I can't see the difference you are making. That makes me reassert that = how one sees this problem depends on where you are coming from not where = you want to get to. Since you refer to the NomCom cycle, you seem to agree that replacing = wrong-doers up to two years after the event is acceptable. So a two-year = renewable contract would be of a similar form. But, of course, more = flexibility can be achieved using a one-year renewable contract. I* recall is roughly in the same bracket as contract termination for = contract violation. It rarely happens and is subject to all sorts of = checks and balances. Best, Adrian -----Original Message----- From: Adam Roach =20 Sent: 16 September 2020 11:09 To: adrian@olddog.co.uk; rfced-future@iab.org Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is = the expertise? (was: Re: My hard constraints] On 9/16/2020 4:35 AM, Adrian Farrel wrote: > I don't see how these two situations are markedly different. In the = first > case, the community replaces the decision-makers. In the second case, = the > contract of the person is terminated. I think there is *absolutely* a marked difference: in a structure where=20 continuous leadership change is part of the expected order of things,=20 the former is business as usual, while the latter is clearly a traumatic = event for the community. (This is assuming that the replacement happens on a normal nomcom cycle=20 in the former case, and on a normal contract renewal cycle in the=20 latter. If you're talking about out-of-cycle replacements: as John is=20 fond of pointing out, mid-term recall process has never been successful; = and mid-contract termination would be legally dicey except in the most=20 egregious of violations.) From nobody Wed Sep 16 05:33: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 255513A1229 for ; Wed, 16 Sep 2020 05:33:20 -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, RCVD_IN_DNSWL_BLOCKED=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 auFYQ2jMhMw4 for ; Wed, 16 Sep 2020 05:33:18 -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 9CDC73A1225 for ; Wed, 16 Sep 2020 05:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=92158; q=dns/txt; s=iport; t=1600259597; x=1601469197; h=from:mime-version:subject:message-id:date:to; bh=cXzB4M/7ZqNvLo7XNrfjk2DgutMMu/MBUqg0GLjlAvQ=; b=NuRjysNUS2OM+h3CidUZ5Z50AcbNNkKP3Lg33SsTXcKizxIBgkzsmkVs QY/CGJsXOh8gIWGFhxARGtn0tI2NN/DNPvZr+9u+LaHOUmAf+0SeJuAt+ FvZSf1Lqn6qU1AcBcEWqO0f5z1lH51Ve5blU77g6weHWPJEBraY83eqCZ k=; X-Files: rfced-compare-merge.pptx : 66755 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEBAAiBWJf/xbLJq1fHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFPg0YpASASjWekVQQHAQEBCgECAQEvBAEBhEYDgiclOBMCAwEBCwE?= =?us-ascii?q?BBQEBAQIBBgRthWiHVYQUAYJtD6YwjhB0gTSFU4RjEIE4gVOLdIIAgTgciBW?= =?us-ascii?q?CfYItBJtqjniMOIJvBIMNgTGWAgMegncBjxiOaa8Gg1oCBAYFAhWBayMqgS0?= =?us-ascii?q?zGggbFWUBgj88ARIZDY4rF44mPwNnAgYKAQEDCY5fAQE?= X-IronPort-AV: E=Sophos;i="5.76,432,1592870400"; d="xml'?pptx'72,48?scan'72,48,72,48,208,145?jpeg'72,48,72,48,208,145,145?rels'72,48,72,48,208,145,145"; a="29662712" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Sep 2020 12:33:13 +0000 Received: from [10.61.249.28] ([10.61.249.28]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 08GCXCmN002497 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2020 12:33:13 GMT From: Eliot Lear Content-Type: multipart/mixed; boundary="Apple-Mail=_64396FEE-3BF5-400F-BDAB-B58F31F6DA2D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <5E6BF445-C0E6-456B-818C-6F77ADD244D4@cisco.com> Date: Wed, 16 Sep 2020 14:33:12 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.249.28, [10.61.249.28] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Some slides based on yesterday's discussion X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 12:33:20 -0000 --Apple-Mail=_64396FEE-3BF5-400F-BDAB-B58F31F6DA2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, The chairs will have more to say about how things went yesterday, but I = wanted to share something based on the comparison I did. These are = slides you are free to use as you see fit, but when it came to = identifying issues, I thought these might prove helpful, to a point. Eliot --Apple-Mail=_64396FEE-3BF5-400F-BDAB-B58F31F6DA2D Content-Disposition: attachment; filename=rfced-compare-merge.pptx Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; x-unix-mode=0644; name="rfced-compare-merge.pptx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBpUnl8+AEAABYRAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM mM1u2zAMx+8F9g6GrkOspF0/EaeHrTutH0C7B9BsJtEmS4LEZM3bl5aT1i2SJq1txBcjssg/f7It ksrw8jFX0Rycl0YnbBD3WQQ6NZnUk4T9fvjZO2ORR6EzoYyGhC3As8vRl4Phw8KCj8hb+4RNEe0F 5z6dQi58bCxomhkblwukoZtwK9J/YgL8sN8/4anRCBp7WGiw0fAHjMVMYXT1SLdLkr8WJiz6XhoW sRIm80IgTPC1Pg6Uf+MjrFUyFUjzfK6zN2S9JVVMnsHGT6X1X8lgQ4RiZnOApd8tPU4nM4juhMMb kZMVtxa5deDJL9jG7yutQTXjsUwhM+ksJ5e4KparV8M4F1KvFrEJxiu6eS080quvDgZNk1W0d2Ja 0rTD8RGCw70THO2d4NteCLRB8KtvszJo/JuoaG9jKjzvnLG+jZ0bhLcRzCX8b4XgWXgbAVJ2h/Ja /1UEma0RxR8F97hQ0PiqK9I77YhfYmFmuNwX5aCdHFVqf5apnaxVj6mdPFaPqZ3MVo/puINMJx1k Ou0g01kHmc47yDTodxFqn5m8UlXrJ++dqmpoe+7LNu/ldzvdVZD+HFDjpawuUON1rC5Q40VsNyDy Dv0ineMdfBxhdeguvHuWhMChfL8Le45I0rXXDMV5PoNsTWwe/tUYPQEAAP//AwBQSwMEFAAGAAgA AAAhAGj4dKEDAQAA4gIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskttKAzEQhu8F3yHMfTfbKiLS bG9E6J3I+gBjMrsb3RxIptK+vaHgYWEtgr3MzD8f3yRZb/ZuFO+Usg1ewbKqQZDXwVjfK3huHxa3 IDKjNzgGTwoOlGHTXF6sn2hELkN5sDGLQvFZwcAc76TMeiCHuQqRfOl0ITnkcky9jKjfsCe5qusb mX4yoJkwxdYoSFtzBaI9RPofWzpiNMgodUi0iKlMJ7ZlF9Fi6okVmKAfSzkfE1Uhg5wXWp1XiIed e/FoxxmVr171Gqn/TWj5d6HQdVbTfdA7R57nvKaJb6cYWcZEuRSP6VM3dH1OIdozeUPm9KNhjJ9G cvIzmw8AAAD//wMAUEsDBBQABgAIAAAAIQD75ySm3AwAAOduAAAVAAAAcHB0L3NsaWRlcy9zbGlk ZTEueG1s7F1tb9tGEv5+wP2HhT71mmzFfSOXRpOCL2KQg9MYdop+psmVxQtF6kjKjlsU6N844O7P 9Zfc7JKU/CK5dmK7dCwjMZfkvs7MMzPLGdLf//BpnqNTVdVZWbwake+sEVJFUqZZcfJq9NOHCMsR qpu4SOO8LNSr0bmqRz+8/vvfvl/s1XmKoHVR78WvRrOmWeyNx3UyU/O4/q5cqALuTctqHjdwWp2M 0yo+g17n+Zhalj2ex1kx6tpXt2lfTqdZosIyWc5V0bSdVCqPG5h5PcsWdd/b4ja9LSpVQzem9aUp vYaVJUd5qo/14kOllC4Vp2+qxdHioDK3fzw9qFCWAr1GqIjnQJbRuLvRVTOnxakpjK80P+mL8d6n aTXXR1gb+vRqBMQ/17/H+pr61KCkvZisryaz9xvqJrPJhtrjfoDxhUH1qtrJXV8O7ZfzIWtyhcio m8d+3fQzWlbZq9GvUUR9MYk4jqCEueVz7E+4iyPK5IQ6UUCZ/ZtuTey9pFKGym9X0kLsaxyaZ0lV 1uW0+S4p5x2re4kB5hDeyYue5a9OyKnrOz4OhOtiybnE0nc9bAETPeIRS/oweksAmHN/NKsYd+vt Ft4zol7sl8nHGhUlMErzteXbqkbLTH1czFBzvgAaNZpGXb32pimsqbyRxZJJkDXDO0xcKiW9zG1i CSJsXUOzkTAqhM2uMrPte7HXfPLL9Fw3P4ajEbZ4L6+bo+Y8V+ZkoX+ZeVTA4zzWqFYF/ulohNKs atYS1Lx+p6oToDY6zdRZvYf0gC3p2uY394FUVXVk082Omn+Ws6K+Wx9d23EQV4DXRlWXmo/NYsbr RRs6tHiKF7MsiSoQ3R6r6ytXZZyvZDw+BhnnA5XxYGK7LApA//oCxrR4gF0aSexxERAKEsLZ5JYy fpUa8SWKbZP76zS8gIAs1aLaKr1+VFPqaAcA9agT+tgPGcHclwGWzCM4sieTIKKcM0o07RaE783L dEU2OL8d2RblmaoWZWYMAbE6yp3GOUxLUIu6RDLeLaYlz3qil/F6fZ1XEAts5oBSjVjHtol0LgOW E8oty23xKqjLmN0q33VHHbkvFMO4iVtS3dluNlpsjdA2x3l3ANGeZlXdHJZnxiYdg73uyqaGbmJ0 wtv09a8ioFRw7mFnMrExZ5xi39IqVPhh4EYhCZj3m4HexWbmgh6pG/JNlaXtgrI0KHOkB7MtVxJ7 K6DcUPoWs0JsT6SHOeEO9ojjYOaF1GI+J5EnVoAq83vBUisRUlDmEtCr2wCzWseVJVFBOHHZ8JbE iHRtV0pH3GJJLet6jjUVmkEHjiW51YqHkcxb2hJVpAdxFR9e1eL1L0Bnru3WRX3eKe2LvTdJ6xSt xr3L6GD30Dyu9o3JgcKhKeSnuTlmRQp2wxTj/ATc2Rxmo6ag6I9gdi7hZn5V09ZW8X7hVx8NYKZl 0XimSbxsSugRtHnR3YaqM1gpcOFgWSRND6q8OFqYqdeL5CBpOkmz9E+38os1fDXt6zZ1W7evdumu NzUStqVed/d4GeTVh0+GLMfLo19WxQiWsTr5Efz11qTGxyASpgjUOOzJ3/knm42yYadxVI4NgT6q Sm8PzJUVg81MyzxLoyw3yDGirGBy7czzprUnV2qp6VQlWkpbJmtSG5dqGidgll/MC5w3nY6Nr9xQ cefv1lduJHU3UtVpqNeAnGmDb+WB3GqxvYcz6EXXzb9u7Xc9fRY/N+5W00SluKrV8ZWF36iUnyKL 1wvqbchDmZ9NVt0K9RYyhK0lmYSYhz54SCF44Z4dMC4dGUrq9Va9Ks/u0VFxXOE4tsONj7nZqjet MHyREb8BKNdoqAXt8CBAU238YIuzaVN2lcDXRao6OV4JVGiFYuJdlynDk47jn+Eb3HVRXo2yy5ry gVczKFFjxBI2F4Lf4ED+JaJ2NEHRHUTts13J+xKXZ6GYOHW4cCRzB6aYjpoqbtRJlqBQJZl+hv2o iH5wJKAxOowCdKSqTNVokmZNWWVxjvwyrtJnq7uksASzQXcNSxjfmzDKyaxB5RQB98aHR96gVNj+ fjB+v9CaFUQogL1iFSfNEsrzstCSddfJDst3oq7tWIK77sBUlMqVsWZDlYojFVfJDAGJ51nTKAUT nPhjkJUnLQ6c2K5tM2LCK8ORhgCovASwnaNJcRKfKB3KHJQ0aOYj/RQazZWCPd1J/RJpy5BkjUpR ViyWoN4KlHZh2Bp9U5RGdtpVJWCBVVEva1Spfy+zSqX/eNJiRIkrbPjnDMzxWdmasZeeZnVZnaOT qlwuDAOaavl1bdWMUM7V/BgWPcsW6PgcwSJVPEcvUNxAL9WJerbeEJfSArtnD2wjF8zirEJ1b/2G puTQWdbM0FsoTOM8P46Tj09aTzHbtmwH9mf99nIgUuAtFirOa6SlofhhUEKg4yNoWlbaKfNfomKc 9Gcv0eHB0/Z+JHcFEVTIYUnDu6zI5ss5WsRVAx7FwuRMDM/96SzN01YI1LYpd9kNIW8tAW1ouAsX r1ITLp532WOXU2y2p5CxVXoNjOSXnxAdaIKNZ1uBkIxjz3MnWFAeYe3nYRJQlwRO5BBm3SGJDGm5 WCfFXEz9+5OMsAv5JTZlDmsf/l9MMLGl43QJYYIySi8n94FgVnXzRpWAKyi8GlVgcQ3R49M2PKNl t6uiLxel9mva2W3LJENnwPFXowJ0pImYB6WJRLexaW/ZQBddz239+0Hft0flXMHVOlnW+mGe3mnk Wd2g+LiEfcfZDJy9P37/b90/9fvj9/8BWOOND/0+dwrfwupmYAfSLC3++P0/DTopYdvTlChVTZzl KC5SNItrFKdp1j1KyVIVb9QWX5ysJp5GshoIMA8CAE9EWIBZxGH0wHFxSD3HDsG4hF5wf8lqt0hR G1xOmsO55UrK+wS7L8xJA40ghEW2JqUxxyGOa/c6w6awR3ieSWk9JYaXwSWJKyhl1udmcFEKfHXu 1Wn7ChJ+kj55+FkmhzyXxB/Qzyr/zGDs15EPs0tq+VJn01cweVWjw8nBLgtkYA8PVw+1+6wjBA74 4ZH38xvjfwPLXq5CEN31oI88PO2w1UATLS5kIax483NZfdQvDL3RgYddMsKwGLa/H6Bvbu8OXO7j yttcWT373J66Hv7x7bfPNXVqqHkJOwHZZSrcWeO/uV8mPQv+DjaFQCd5XIrEoBd9WL1S6/fjT0EC XmgnaxdhHxYD3x69D273mvafa3C//HCXd0qePCiHGi9/WJ7edTZdQBy2Vy+R9hf0aXkpy/V2e+fn Hiffvbb6mK+tbntTYKthQ3D4+Q1KdMbSs33Fw7Zd6nLH6j828lgJA3Yf4txX0wYfGs3iVbA0JAYa 7aRR6HjwH0vb8zCVnGKXUIJDHrqagpOJfZfMgbvmC3DblYRyE/vT356gtNP4q0/ISB3u6xIGGCi3 P0sYyIHyhvCG7jelDtz0XDxOEsBVG2nLl/N3ZdoJVq9bzGX99aLWqbqgclY9XXMM1xkKtVaprQY7 VNP2CyRtbsnGeXTRmlmcqvay2Dqe6VDXnsKYq767Djb33XbT1V8//V817qIINzVetTAjgwZcNZ5n RVlt6mAdeejqtwRqCbMhh2Odt4HiIpmV4BwkTdWxYqORau3PqtIWjbfWbhsSHLYjXW5FehvFHB7S pQzDKPR8DL8ltn3OsEttG09I4PuCgGmO2EMi3aGcC8cgnRLicPFXIf3iJi7gju/0aWU7rH6dWHW3 YlUOFKsTP/StMLDBFk8YBj9dYDcMPOxOIhYIXzLBH9QqO0QwIlusCtdhbarPzirvkD5spBNrK9Td wUKd+CLwbAw441jYPMIyDBgmludZXFCbSflIDjgjxOJsZ5Z3YH0csK4+OHsNrKQl2AC/1goDkICG OGRE4AnABXsWjbBwAiqIT2noRA9qmC0mdCqsxiKUCTEg2aF1h9YHR+vqe8rX0TrUbyuHIQ8d15ZY cgK+dAButBe4Aof6+aBPWeDa4pHcaM6Yqx+r7tC6Q+tjoHX16tp1tA71JbYA/N2I2D6ORBDC6Jxg P3IJDgGoAY18IgLySJ4wl5aU7s4T3qH1cdC6ejXuOlqH+pocdbyJ4LBl9aUDkHX4BHvStjFjRMeV uT+Rj2VbBXFkl5G/Q+sOrQ+O1u1RXjLUMO+EhfBDBSYyJDjweIAlbFix5XmAIhIGfvigwZ8LtlXo N8SZSVLZPVDeYX3gWHe2Y337e7h/LdaFxxiLYK8bhCLCk1C/eUzBmY48Rwo3tDw/eNhA79oy6689 2K1B3FnmHVrvA63m0P8ls02fRvB916aB9LFPeIR56DrYi2wBu0rGeeBLL9B/bKj9NMI18N3H9xGk o/92l8P7jxRs+DxC/zfZkrx6Fy/enxocwViNqgJzaaGB3VZdV9FLh3b/BwAA//8DAFBLAwQUAAYA CAAAACEA+3ny3zUKAAARRQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbOwc227bOPZ9gf0Hwk+d tqp1oW7BpIUk20EHSRPEHfSZlmhbW1nUUnQSTzFAf2OB3Z/rl+whJdmx42ScaZDIaYugoiRezv1C 8fjXd1ezDF1QXqYsP+wYb/QOonnMkjSfHHZ+/zjQvA4qBckTkrGcHnYWtOy8e/vPf/xaHJRZgmB0 Xh6Qw85UiOKg2y3jKZ2R8g0raA7vxozPiIBbPukmnFzCrLOsa+q6052RNO/U4/ku49l4nMa0x+L5 jOaimoTTjAiAvJymRdnMVuwyW8FpCdOo0WsgvQXM4mGWyGtZfOSUylZ+ccSLYXHG1esPF2ccpQnQ q4NyMgOydLr1i7qbus0vVKO7MXzSNMnB1ZjP5BVwQ1eHHSD+Qv7flc/olUBx9TBePY2np1v6xtP+ lt7dZoHutUUlVhVwN9ExG3Q+piKjyOjUcByXooFoztPDzpfBwAzt/gBrA2hpWA+xFvaxrw1My+ub 7iAyLedPOdpwDmJOFZXfL6XFcG5waJbGnJVsLN7EbFazupEYYI6Ba3mRUH5xe9j0QzfUItv3NQ9j T/NCP9B0YGJgBIbuhbB6RQCAubkqLLo1vjXiDSPK4pjFn0uUM2CU5GvFt2WPipnyWkyRWBRAIyFp VPerXqrGispbWexZHsia4p1m+KbnmevcNnTbsB3ZQ7LRsEzbdqxNZlZzFwfiKmTJQg4fwVUJGznI SjEUi4yqm0L+p+DgwOOMSK2mufb7sIOSlIuVBIm3J5RPgNroIqWX5QGSC1akq4bfPQeinNdkk8OG 4jc2zcv7zVGP7UaEg74KyteGdxUy3RXSig6VPpFimsYDDqLb6OrqyaaM46WMkxHIOG6pjEd9x7cG Edjf0IY1dRxpvjnwtADbkWGChGCrv6OMb1KDrFHsNrm/ScNrGpAmUlQro9esqlo17UBBA9PthVrY swwNh16keVZgaAOn348GJsaWaUjaFQY+mLFkSTa4341sBbukvGCpcgSGXlPugmSHHcswPEc3XNeu kanIswJ0XV9v4rmhscBm7BlKY13HMTx3U2FNMDi6USmsbfqW5VTWdzVTTe9rzR4RpKLVvR2nkHKr pFaMsvoCsj1OeSnO2aVySiNw2HVb9ZBDlFF4n7z9YkemaWMcaG6/72jYwqYW6tKG2mEv8gc9I7KC P5XuXR+mHsiV6iWPeJpUCKVJxDIkF3N923e9WzXK73mhbuk9zel7gYYN7GoB8Emzgp6pWyE2BoG9 1CiWPYgyKZEwPNu0fAMM620as8RjAyXT07GPb3eET4aSZXi+43teLeXPASVsuZ7j+6b/bDDyLNfH pmtUZvVujCr1arRKcDQFJru6h/VKhZX12NHh0zw5I5ycb7ra8g/QBSyDi+tOt/as12cXcRW5Lte9 z+oQnKAZ4ccqLoDGuWpkF5m6pnkCzl01STaBnCMDaOgYvPEQoPMNrODjoupNyXEe8s/KqI1ZLgI1 hMwFgxnB5eb1a+g6BUyBCWfzPBaN4cvyYaFAL4v4LBa1NdDlvxrz6z1COm76irLq23RbexuMlYDd 0q9+O5pHGf94pcgymg//WDYHgMby5gMkVVXcQ0YgEqoJ1DhvyF8HkdsjJ8VOFU2OFIE+Uy5zOPVk yWAFKcvSZJBmSnGUJFMAroI8E410rvWi4zGNpZRWTJakVnHvmMQQO72a5VomakdINl5QUicl5caL uKxX4rUXeQuKMxbaTmHiTsg2YWirkS7Fv3YOjvefxT8ad/k4ponGSzraQPxOo7yPLF4h1PiQVrif OwTsxtpN3ku3pZqPAdEzsN5xk67/kJr+o1hxyNJpdl8t2RaM6z25P9fzNc/o9zTcCyH77Nm+FjiR hT3X63lm0ATjnF0+YBII2anrOi5WCfz2aFxU6H5X8H1f+3N+FqGxDFpTlu9C4JtywiejpZT09J7d D24KiuJJbakfwagGJUrXI5x9xuaELEYUnoKqcZrHtESEs3meIEhEpoynYvHu2eAaUtAlwPC8f/aY OLXKVFiGbjvYtvEdmytPYiqGfTS4h6l4tBjqNnXfy4DwFMIZQKec7xQV3q0AEXZDt9l1fEJznFyk JeOLpaNBgqHzYfDpCBEwY6Drr1FSf1mtn0csL2lezney4q11+th0se16lt8ypz8UnAg6SWPUo3Eq P74/H28prRTqovNBhIaUp+BL+kkqwE2SDIWM8PWYeZ8xfYaW4hrXlkbjE+Of5ZfhIwh6ih82KPBs 3bYcCAraZUlO1eGdyVQgNgbT3e+C+W5VbHB8HHVPC+l0QP/Bq4Dli8Uc2jOWS7PQKmDPOBuRUbZA McnR7Cl3hm6jJXqx+5bD+hwbZzTScvp3Z6pn+OXly/3eETB9x9Vt7N/xxfFJggOa0SpKa6lKDynh 8RQBiWepEJQCgP2wC8L5U5d/6vITBfqG4zuOZajjdO1R5QhUZA5uboH6+YRMqEywWiWFUnORPHQE GkIFULZ8jWRMFqeCJijNizkEFvkyOSzRi5wpxa+wipssEXH673nKafJLq9C7M0L/njmTOm1DBWcx LUt1hhrIMJIJDnpB8gXLqbI8klgyrU5zRFMxpXwnCu1vsnD0iPtArTJBpuHbDvy5LdtrWGYI3SWT JjKTU8or+Px5fXlQBm1GZyNAepoWaLRAgCQlM/QKEQGz7BgH7M8GRG15HiiU+HB6Ep2evKpo9p1B xUPBNJvwexyX2Q7KK/R+eLpTgLo/nC8IF+CpC3X2HDCsBZ3TVXXLBdjmV3JL94fdt8Gep0OS57Ts W040JSlHZZPqtS0oRJcQq4DK9NGYZNmIxJ/3J67bz2BKmqeHMpgh+3if02d7H3pZjqM7ruW7DfQt UfKgKCjJSiSVPd/pjMCjaZA8eYzGjMsNpvA1yrtxc/canZ+1ayfnp7bfU9vvHR1VrA8+Hb1Gcl9K 3rK1Dwu7nQZprYHwsG8btml77bIPJ2mezuaz9UCufftDdTrVriMnIzYXSEwpKsnsAexC3+9HgyZG fDq7MLwjhEdw+XSEYhk57vexDEs3LF8esfqLLy9VUVRdKLUsnLx+Xxe3r1cA317hbi2rf2GlkF0h s6X1v4GjR7ZnYS0I/L5mm3igya0lzYhM34jcgWtY+j1q3JEUjFXN7vVfJviLgnVV/mqq8lfHtFyr Oj67qn/FhuO5bl2vbpuWaa7/9gBIJi/FEWVg5aBx2OGQ8Ciik4vq1LIU3rqLfJwzqXgVdLcVuqNL 4PhhJ4cYRtWKRUzVYFVVWcFcwBT1zFX/h9HNl0M2k8dAy3heqr1f+MvSUiCibNHllAj07et/y+Zs z7ev/wPTSbYe7fm7ILwM1JFTeJHk377+R6AJQ2kuGEqoIGmmjnNNSYlIkqT1N/c0oWSrubhRS68u zU9ebKvrDkPfMSMv1EIDBBL3fFcLBo6tDWwL4yj0gkhWpVd13Td04kGKux0MimK4ZuXItxZ3N7/e EWf8hBSnF4rGsJigPFKPCqlwVddVF4k7jPs/AAAA//8DAFBLAwQUAAYACAAAACEAusFQTz0MAACB bgAAFQAAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbOxd627bRhb+v8C+A6Ffu0mn4lw5NOoUvBoBksaw U+Q3TVEWEYokSMpJWhToayyw+3J9kj0zvMgXyZVb26FjBYFJkcO5nHO+c87MfKJ++PHzMjMukqpO i/xwgr83J0aSx8Uszc8PJz+/D5GcGHUT5bMoK/LkcPIlqSc/vvrnP34oD+psZsDTeX0QHU4WTVMe TKd1vEiWUf19USY53JsX1TJq4GN1Pp1V0SeodZlNiWmK6TJK80n3fLXL88V8nsaJX8SrZZI3bSVV kkUN9LxepGXd11buUltZJTVUo5++0qVXMLL4NJupY12+r5JEneUXR1V5Wh5X+vZPF8eVkc5AXhMj j5Yglsm0u9EV0x/zC30yvfb4eX8aHXyeV0t1hLEZnw8nIPwv6u9UXUs+N0bcXozXV+PFuw1l40Ww ofS0b2B6qVE1qrZzN4dD+uG8T5ssMfCk68ebuul7tKrSw8mvYUhcHoQMhXCGmOky5AbMRiGhMiBW 6BEqflNPY3EQV4mW8uvBWrC4oaFlGldFXcyb7+Ni2am6txhQDmadvahe/mr5jNiu5SKP2zaSjEkk XdtBJijRwQ42pQuttwKAPvdHPYppN95u4L0i6vJNEX+sjbwARSm9tnobSrTKVMdyYTRfSpBRo2TU lWtv6pO1lDeqWFIJtqZ1h7BNpCRXtY1NjrlQJZQaMSWcC3pdmW3d5UHz2S1mX9TjZ3DUxhYdZHVz 2nzJEv2hVH90PyrQcRYpVCc5+vl0YszSqllbUPPqbVKdg7SNizT5VB8YXlQBapqkmr5fFMu6yFUP Wlmqoeqqp+su6F611h2VizQOKzCkHjnrK9ctjg0WF52BxbGRWpwXCJuGHnhDl0ObJvOQTUKJHMY9 TEBfjAY7Wtx1aURXJLbNCm/K8JI9pjNlOK0L6lvVZ53sAC4OsXwXuT7FiLnSQ5I6GIUiCLyQMEYJ VrIrMTtYFrNBbPB5N7GVxaekKotUu2VsdpK7iDJwKZxhbFm23Q+mFc+6o1fRc3Oc1/ADamaAGYUf SwgsravwYVTajNotejjGJpOtK1xX1In70qkfNVErqjtHsUaZrTba5izrDmDa87Sqm5Pik44QZxA9 u3NdQj2iEfp69upX7hEQEXOQFQQCMcoIck3l0Ljre3boY486v2noXX5MX1AtdU0eVemsHVA684rM UI0J05ZYbAWU7UvXpKaPRCAdxDCzkAOKQtTxiUldhkOHD4AqsnvBkrYILDmhNgYvtw0wwziuDYmA HQlCxzckKrHNCaEm32FIrep6jTWVsYAKLFMyszUPbZk7evYknx1HVXRy3bfXv4CcmYoil71857Qv 197EbYoytHuX1jfHFd22jnFn2vw/JpXKLPWVoTc65hZZOgvTTKtZyz3xsqqVaNa0/uJaqWQ+T2Il 0rZH4OVzHY3nUQwx5OUyR1nTOYTo2o0k6lKl+tqNuO5aqjo4vQI1zxsU9wEQXYl8f2vYRlJVvR8Y 7fCreZzM7m/Mox4rgniXZJtSm9tQssn5mL7KO33IR3HgI+a74Mh9SBYc4VEmLelL4vTOpyo+3aM/ tWxuWcJiOhRudj5NO9y/5WtuMYEbnkaJ8+TYM+arPFaZ2C4Cvmkn1fnZYCW+6fPAuWkoWic6fbhv F7ZxUG4CGklq4yQ4fswxjcrgKMxRBOOc3RLtvorBnQZGeAeDe4i4t7FjzuwirYvqywAHoymMk1Pn w5EBqaGype+MWbeu0V33irxO8npVP2nXxIjFuCWpPTLXdNpUUZOcp7HhJ3Gqlr52kvOT8FAnoWec JlUKTmqwuw9F9VFN7Y+qYlU+W78lucmpAL81LmN8p1dfzxeNUcwB/cEUPMCo3NebN57xr93zwat1 9BlvV1daL/5qTV0N/37x4mmna8QWlsmZbY/MJyZZ0ganvRk+AzNkWNhCUKyXn8djhV6xXK7ytPli BPl5dJ6olGhUVrgxvB49aVMg2OYC/lsjy9KGwDgdJH2uEhgjhnytqVbf1szyXZnkRhlVTRqnpd6+ MF4aMMwkWhpVst6uvADLe6lmCc82j2NSmhBAxcimn94iSiuj7sPoqLzW69N3nnFPsdMt3l+r6d5X oce13CGEKSyYw/a9H4m9OWWZRFltKLvLf3xG5nbX3hjzomqXVb4zVBKpPhZXJl27LeaN1kIlsznm hMtxGejbNE+Xq+XVoDYqOz29JbwacPhwZMTKqz/tVTiKKReCwbzzdvtoNya7zcphY/zy545JdJXg sZ1ORAdyB7TkFp8NMlJ6hyNMj0vKkOPYAeKEhUjlwwh7xMaeFVqYmncgFBnKMNaUjMs0sD9hB11i NwhCLdru6VyiN2AhLasjB3FCCblK9ALLrOrmKCkAdXByOKkgGdFCjy7arTRlvF0RdTkvVMrX9m4b q8j4BBo/nORFnkyMqsm8Ihv29Upn1UAVXc1t+fvB5ovTYpnA1Tpe1WqF1oD/WVo3RnRWrBrj0yJq jD9+/2/dL+X+8fv/jGUSbVzJ/atdeAGjW0C0mKWz/I/f/9MY54WR5k1hzJImSjO9er+IaiOazVJl kVEG9pREG93F36ZK8adBlRJ2YAbCxIiCw0FcKhIGsTgyhSdMajKHOLtiaQeq1A4EqbExorC0ick4 yOJ+GFFCUptwvpUSRaiJCcZ7StQgidHxh0B9RCiq5y0rMA/CH1LBahlVb3TeDScn+iS70A4eXN0M kiJ9GmXn+eEkAx+ZzMH/nILPtDHTXhMiQpu2R29yt/qo9Tsv8sbRj0QQH6BGRd/obkPRBfhfkMOx 2g7tbSDLT0vd9bqMj+Omw4qp/nVCuVzCTeZ92aZuy/bFrtx15lrHW8p1d89WXla9/6zFcrY6/WU4 DWEYw4efIP61gSE662kpII2TPvPrIvq3TYp6ZlSoZgP1+RsmQ+2Jbnui257otueEfTucMD+5KLKL ZKYYV2u61fYp4re9lP1YfKx9WvmYaeVGw/9wtBM/YU/0ejxflE+j5+p4xkp6esYqGSkB6BK/JoDQ vdJEiOOqOK+i5XNV1WgJOjcoKw+soT2d5fGU+9pxn/au50hpGyDXjpCgvvax5yPsZxlPeJaxM4Hi aZOl1f6MKU1J/mRGce8MCtHv+b5J5g060Q7CqWBsBh/p9m9oE4873EfEsxgyTeYgW3KJHCk5lo7F mR/egUpxVwIFswRWO6BqMxRjSoTsiGTD+1UkUfG23Q2l4KP+jEGRgeS14LXcb+NS3Lb2G8UxwKN9 G0O2Wr4tZu110bsIfVm92qfNCS55jqGmG3nNmrJRK8/YOqKTZN6+EKQl22zsR7cuv4hmSXuZb21P V6hKz6HNoe6ugs11t9V05dcr3MPD3Ur5bQ8PT+iWwZENDy/TvKg2VbBeXe/KtwJqBbOB1LImshhR Hi+K6nASN1Wnio2xpg0jQ6EtGe06e93A+NiOdLkV6dZYSVO+jwMiXBQGgUQ+TO6Ri4MQ+b4XBpDO hkI4j4R0wgDHTDvnr4D0y3MQj1mu1fPs9lj9NrFqb8WqHGtUFqG0ACTIFA5FTsDgj+8GiIVEWp6L IcHxHxSrnNvSbrFq21yY1zhKe6zusfowWFXEty1gxa3AxodWP6QkEB5BPLAdxGFug2zTMpHJAyal 9CyfP2wOvUYr5Vx0YNzn0Husjxzrw/tLb2J9tO8y9TzpSJcjGVoOEoxxZGMTzkzLsQKIlCRkD5tF c0GFxjozuQkN7rG+x/oTwPrw5aKbWB/r14w8gblr2S4ipvQQE9Cw9BwXmZ5tEeIxQR96bWzAOmcE 4P61Zsx7rO+xfhesD2+Jvon17W+D/bpYp1R6NucE2VyayLfUl1iExxF3AOc2Z9x2HnbGbZk2a3N4 ZjMK7e1n3Hu0Pgpahy8q3kTrWL+0KIVLHeGEyBcehlRc7VoFboAc7kkf+yaT3mOtjzGAq21+rV2r PVqfG1q3bzHj0e4x+56gJnaRH9g2ChyIrZLJAEG7jkUtiYWkj7WabVLB6deKrfs8eo/1u2Dd2o71 7T8U8ZV3mTm1hGfBTFlwF1lM5dHUsREOfUIs27NDyR9pzoy5ZQKa95F5j9b7Qqs+9L8xtulFFa5r C+JJF7mYhYj5toWcUHAUcsqY50rHUz881L6o4gb47uVtFdSyiM1F+zWBjS+r6H8tLc6qt1H57kLj CNpqksrTl0oF7LbouogaOjz3fwAAAP//AwBQSwMEFAAGAAgAAAAhAMRG2VDXAAAAzgEAACAAAABw cHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc6yRQUvEMBCF74L/IczdpFtERDbdiwgLnnT9 ASGZtmHbmZDJiv33xoPQwh48eJw3b773YPaHr3lSn5glMlnY6QYUkucQabDwcXq5ewQlxVFwExNa WFDg0N3e7N9wcqUeyRiTqEohsTCWkp6MET/i7ERzQqqbnvPsSh3zYJLzZzegaZvmweQ1A7oNUx2D hXwMLajTkvAvbO776PGZ/WVGKlciDHFBeZ9iwEp1ecBiQeuVvLbc68oHc73W7j9ryU/cq1v4Uja9 VvrG1P42M5svdN8AAAD//wMAUEsDBBQABgAIAAAAIQCtOQRg1wAAAM4BAAAgAAAAcHB0L3NsaWRl cy9fcmVscy9zbGlkZTMueG1sLnJlbHOskUFLxDAQhe+C/yHM3aRbQUQ23YsIC550/QEhmbZh25mQ yYr998aD0MIePHicN2++92D2h695Up+YJTJZ2OkGFJLnEGmw8HF6uXsEJcVRcBMTWlhQ4NDd3uzf cHKlHskYk6hKIbEwlpKejBE/4uxEc0Kqm57z7Eod82CS82c3oGmb5sHkNQO6DVMdg4V8DC2o05Lw L2zu++jxmf1lRipXIgxxQXmfYsBKdXnAYkHrlby23OvKB3O91u4/a8lP3Ktb+FI2vVb6xtT+NjOb L3TfAAAA//8DAFBLAwQUAAYACAAAACEAI/NwpNYAAADOAQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGUyLnhtbC5yZWxzrJExa8QwDIX3Qv+D0V47l6GUcs4tpXDQqb3+AGEriWliGct3XP593aUk cEOHjnp6+t4D7Q/XeVIXyhI4WtjpBhRFxz7EwcLn6fXhCZQUjB4njmRhIYFDd3+3f6cJSz2SMSRR lRLFwlhKejZG3EgziuZEsW56zjOWOubBJHRfOJBpm+bR5DUDug1THb2FfPQtqNOS6C9s7vvg6IXd eaZYbkSYyIXkYwqeKhXzQMWC1it5bWl15YO5XWv3n7XkJ+4NFz6XTa+VvjH9NjObL3TfAAAA//8D AFBLAwQUAAYACAAAACEA8KqcM9YAAADOAQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnht bC5yZWxzrJFBS8QwEIXvgv8hzN2k7UFENt2LCAuedP0BQzJtg20SMrNi/73xILSwBw8e582b7z2Y w/FrmdUnFQ4pWmh1A4qiSz7E0cL7+fnuARQLRo9zimRhJYZjf3tzeKUZpR7xFDKrSolsYRLJj8aw m2hB1ilTrJshlQWljmU0Gd0HjmS6prk3ZcuAfsdUJ2+hnHwH6rxm+gs7DUNw9JTcZaEoVyJMTEL8 NgdPlYplJLGg9UbeWlpd+WCu12r/sxb/xL3gmi6y67XRd6but5nZfaH/BgAA//8DAFBLAwQUAAYA CAAAACEAsrwjNS4BAAD3BQAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHMgogQB KKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8lM9KxDAQxu+C7xByt2m76/qHTfciwh4E 0foAsZ22wTQJSVzt2xt2pbZlCR5Kj/Nl5psfM0O2u+9WoAMYy5WkOIlijEAWquSypvgtf7y6xcg6 JksmlASKO7B4l11ebF9AMOeLbMO1Rd5FWoob5/Q9IbZooGU2Uhqkf6mUaZnzoamJZsUHq4Gkcbwh ZuiBs5En2pcUm33p++edhv94q6riBTyo4rMF6c60IAcOX89G+WYoZ6YGR3EvRd4Nk/MQqzkhrOAl /AEcw181DUHczAmhDdjJJHopBJEuNIkkBJHMDvHErAMzQTmJo4wg1mZOLKkc2CnWQBxlBLGuF1rZ OriyeE4Kx94FvLpOwOB+B2KIZL3QOFYhiLtZp+FrBxDH8CT2d0FG33X2AwAA//8DAFBLAwQUAAYA CAAAACEAPw/7ey0JAAAZRQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbOwc227bOPZ9gf0Hwk+7 7agWJeoWTFpIshUUSNsgzqDPjETbQiVRoGgnmWKA/sYCuz/XL9lDSnISx+k4nUzrpjYMk6J4O/fD y/Gvry7LAi2ZaHJeHQ7wC3OAWJXyLK9mh4PfzhLDH6BG0iqjBa/Y4eCKNYNXL//5j1/rg6bIELSu mgN6OJhLWR8Mh006ZyVtXvCaVfBuykVJJTyK2TAT9AJ6LYuhZZrusKR5Nejai23a8+k0T9mIp4uS VbLtRLCCSph5M8/rpu+t3qa3WrAGutGtb03pJUCWTopMpU19JhhTuWp5JOpJfSL067fLE4HyDPA1 QBUtAS2DYfeiq6Yfq6XODNeaz/osPbicilKlABu6PBwA8q/U71CVsUuJ0rYwvS5N5+821E3n4w21 h/0AwxuDKqjayd0Fx+rBOctlwRAedPM4bmQ/o4XIDwcfk8SKnHFCjARyBjEjYkRjEhiJZftjy0ti y3b/UK2xe5AKprH8esUt2L1DoTJPBW/4VL5IedmRuucYIA4mHb+oWX70RsQKIi8yYicIDJ8Q3/Cj IDRMIGKIQ2z6EYzeIgDm3KcaimEHbwd4T4imPubphwZVHAil6NrSbVWjJaZK6zmSVzXgSCocdfXa lzpzjeWNJPZtH3hN087AgeX71m1qY9PBjqtqKDJi23Ic114nZtt3fSAvI55dqebnkGpmowdFIyfy qmD6oVY/eh4CaFxQJdWsMn6bDFCWC3nNQfLlGyZmgG20zNlFc4BiKkBqJBPDszkvG16pGbS4VKDq rofXU9Czarmb1vM8TQQwUi851yXrHEdWHEfPgePIjnJcPHYDO4lBG0YOjGmS2AisxDdC4sTYAnoR e7wlx61jg97C2H1ceBeHN/gxzxTjtCqoH1XnOtyBuISWN4qMaGRjg0R+bPh2iI3EHY/jxCLEtrDC XY3JQcmzFdrgeTu01fyCiZrnWi1js8PckhaHAy8gJHBIq4/0pPq0R84N2bkL5f3S43u2566pSmya GGPTa4XHgSzx+5H7njps38iOqKQtph5sxKTiWs2z8rzoEuDsaS4aecovtIE4B+PZ5XUN1UQL6Ovs 5UcntiyHkNDwxmPXIDaxjMhU+syJRnGQjHBsh39oybvZTBeokbohj0SetQDlWcwLpAZzcRBg5155 CkZ+ZNrmyHDHfmgQTDwjxJ5n2OHIMu2I4CR0VvLEi0cRJc0Q2HcsO8Cg5O6TlxUcayBZXuCZ7v0q 4ruBZPs4cCzLNp0nA5KFA9e1MQmCpwOS43sEB6a/DeO1AtbLlRRoDmT2TB8UmS7Q+mNL88uq7IQK erpugJvfQRqIUmc3TXFnWW/2LtPWj1yN+5DRNxt/PbZWpedaSX1gQrn/umQ1G+0Y8SLPkrzQZNZ4 Z3EhWowWsrVQa7XYdMpShdJ2RmCKK+0yTWkKhv55WRmF7PQ2XXvBaOfPNmsv0qYbSXRK7yWQeSqN tPdSjFvuyV8CGzEhem29s+CLacqyx4N5p2E1wClhxSb/cy8lf4I65dSzvxVzsBRBJRXHWnIgc6oz xbLQaV5lIJ46S4sZIK8AzLEpePsTwG2AidZ/Qra1GT2uIvFB43rKKxnqJnQhOfSoMNS9hqpzoBNo +ZNFlcpeWItqUuupN3V6ksrO3zDVp8PLzRoRm/Z1ZdPW7avdehtOtQW7p1739nwB9D671Gg5X0x+ X2UTAGP18JZXLebAm+spD9g47dHfLRmftsr+yRS13LB6fsKqem+G92b4ljHZtAYwR2qPbhQYPh6P DDKKYNU7cgIjdGOb+J4/8q2wXwMIfvGIi08vcDzP9Yh3/xpAtuD+JZf/Cyxwx+FX6Dw9idFUmbJ8 8z7bOoLv8omYna+4ZGSOnHF4l1E0TfRmy2P7SBuBihhQhDXodHzyZGCa0HIrd2pPoPth2imNYGPT cYnjkC/s3XwXjTAZo+QBGuHvWPlsnFiYLfOGi6uVvkKSo9NJ+P4I0SpTvPQLyrpDuq485lXDqmbR 7BQg72pWoddNs3gEgY6JF3n9vtL3E+gRW/JiyTJFkmt6/NAWm1gecTzfDnbMYk+koJLN8hSNWJqr 0/OtuPuHsAunSYwmTORgGlbS/p6LD+p08EjwRb03598CmP3OyrfcWdnIH++Pnv20npHvmI7tgme0 W4r3nb6sNJtLxKfgX4yH4GPslF9xfByjf22/JXC7j37To+srb+Zf21PXw7+fbcXBe6/r60GqhvTH 3hSxAtcznS+e9X4XF4sVrF1h7CV9L+l7SX+ExRR29bUOfedwdwQ95mW5qHJ5hcbVjM6Y2jrYKVbe uCA62qkpbruS+R44Gy95sdCK/ETwmaDlDy1EFg4cF77eju1IrBzj4YpHZ2qxjlJeNVIsntbhgrYu NRUyT/Na3/ZFzxGAyWiJBLu+3b8E/nuu9iH3exY/Bhl/2vU28X0TvHB3xw4i4jnNBWp6X3ynbMzr ybsYPZIDHvGztZ529t7mz+Juvw6jH9pTsF3XdD078HoG2RGRDuua0aJBSrSrVz+RRD90NmjKRXuG +QtSi331yG/tPz78dG2vBB6sBDoyqJPlx6LCbu20k8DBjuX4u6Um3uRVXi7Kh7tn327R+wV/H0Hy /gilyn3ZrYsHb/kFah7FiR8H4zjp/cX9weMTOnjcmrMfvOe7Wx6S59ug+ODzZdXXhmN1IVqroM2b z12Q++3Y4/sj3e1V3DGMFPFLZO1o5HHomrHj28QIw2BsOBZJDLX3ZODYCnDsJR62zQfEuiPFGNfR wjf/oeBPAtcBSuJbOvTWtWzPbq/QXsfeEuz6ntfFrTuWbVm3/4MAOFM08ohxMCiQORwIWFBqpNNl KziKebsqqrjiSpm1s7sv4B1dAMUPBxUIoVY5Mdei3Ap3CEomybue2/qPo8CfTXjJoLRJF426+YPg W+SNRPScLyS6mFOJPn/6b9NfEfr86X+oZHTjDaGvncIzgG4OjlCWZ9XnT/+RaMZBM0sOqljSvNB3 v+a0QTTLcsWRtAB+YnSjJbwTxa+T/q8vNkWUR1HgWrEfGREGhiSjwDPCxHWMxLEJiSM/jFU8fBtR fkcmHiOsHJjN9olnd5uwGwPL+3/xSAvxhtbvlhrHMJhkItZFtRK4tup1FQU7tPs/AAAA//8DAFBL AwQUAAYACAAAACEAzJqnQ7sCAADxDQAAFAAAAHBwdC9wcmVzZW50YXRpb24ueG1s7JfdbtowFMfv J+0dIt9ONOSTgAhVaZdtUieh0j2Am5gS1bEj26HQau++Y2NIgGrqA+QK2/9zjo9/2I7P9HpbUWdD hCw5S5F3NUQOYTkvSvacoj+P2SBBjlSYFZhyRlK0IxJdz75+mdaTWhBJmMIKXB0Iw+QEp2itVD1x XZmvSYXlFa8JA23FRYUVdMWzWwj8CuEr6vrDYexWuGTI+ovP+PPVqszJHc+bCqbfBxGEmjzkuqzl IVr9mWjdVZymJPGGLJsnSVTGmZJABzm4UfyWV9pJLspcNdBI0RDNgIekxW8sFRG/inupzkacskiR 74WjMAniEKCKiR4BxUPubOp+5M64IvJ/Y22Q2Ab5yAUCn7b3uUTdJHztfyLHXkcOLmW/I4eX8rAj R+0Ku4ks35x8C1R9bwzUwSHfpShOokR3TECzGmt2EIzV2AvDo1VBVrih6pFs1VLtKJlNsR5bLIRt PSyEQ7He0IQNbn+abLomdEO9GmwqLO71n+lg+gyHgSIHbB7x0/LtMCMsSlFjQvA9m4sXsyn01mO2 C9IapoL9vWhYrrTeyUJCJC/RcV6I0OcNFm50yWlZZCWlpqN3K7mlwtlgmE1t91vkzMrM6qhdDcvP 4WR+q9iAKm2JJwSfCQTvhVyeCblscTxoHO6Rh0Xjt2jCaKQT7vkYKJZP0PI5QOj5aCiWT9jy8YKR F/eADlQsoKgDKPETk30PSFOxgOIWkO8nsfkK9IA0FQto1AE0CoP+jj5SsYCSFpCm01/SRyoW0LgD KI5G/SV9pGJerpdPzHoCbfuWhZbTiDJF79+zm2zuB8FgGAfZIPTn0SCBj95gfJcFWeTNb7zhzV9d LHiRfgH/aMqCQJBDveJFFxVLVeaCS75SVzmvbOnj1vyViJqXpvrx/H29sn9jQy6HX5Ode1qnzf4B AAD//wMAUEsDBBQABgAIAAAAIQDZ2OxtTQQAAE0PAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDIueG1szFfbbtw2EH0v0H8Q1GdGN+q2iB1IlFQUcGKj63wALXG9aiRRpbib3QYB8lvt 5+RLOqQkb2K7yaZYA34RLxoOZ+acIYcvX+3axtgyMdS8OzOdF7ZpsK7kVd3dnplvrwsUmcYgaVfR hnfszNyzwXx1/vNPL/vF0FQXdM830gAd3bCgZ+Zayn5hWUO5Zi0dXvCedfBvxUVLJQzFrVUJ+h50 t43l2nZgtbTuzGm9OGY9X63qkmW83LSsk6MSwRoqwf5hXffDrK0/Rlsv2ABq9OqvTZL7HrzlN3+Y hhYSWxg65jn4XS6byuhoCxPXtWyYAdExCO8kaNICQ38tGFO9bvur6Jf9ldDr3myvhFFXSs+03rSm H5OYHnZb3bHuLb+du3SxW4lWtRAMY3dmAmZ79bXUHNtJoxwny8Nsub58RLZc549IW/MG1hebKq9G 4x66487ujOFQUdJ2XAxytmgj6jPzQ1G4qZ8XGBXQQ9hOMUpzHKPC9aLcDQviesFHtdoJFqVgGpbf qpleTvAA0rYuBR/4Sr4oeTtxY6YYoOngCU1l5YcsDWIfYw+5ESbIs3GIkjBKUWAnaYK9Is2T/OMU ALB5brUX1uTv5PgMxNBf8PLdYHQcgFK4jrjdSYxgqrZfT5SSKkaT3PhTdw5Rnlggdymv9mqTG2j1 JF00g1zKfcP0oFcfbYYAIBqqMpZ16O1yBFeek6Yu3xmSG6yqpfGaDpIJQ+8PKQ1alIOjm8oKrdA6 bGzNkP838N4M/MR+46qhJVvzpoKN3GdKAz+O7Jw4BcpxFiPPxQlKcJgi13Zd37EjnOXkKWlQV7uD yAkY0Cvwt81dUv84IxQymhDDI4y4v4u2/Nu7LFnJ4Uhs2JY1R2h0v6/xel2L4xV631dY8I2Q66M1 4iM01qtvKPyxvMJzXmVUsq+SynuuSUWI7Xm+j8LCDlEUY4yiNE5RlEd2FmZJTJ42qcaztZJQrPwF ntBmpQxTiTZeaSfJtBXc+9pbEic4IrGPfDvByPNxgNKgCFAe2qRIY9/B6iaZjQIMZd2yor7dCHa5 UTXCQxYZQytJw2h3l8fyPLacACJ9oBMYoEHvqisq6O8Pifh/yObPZCs4V8fBl3TDz5RubpolueNF iERwhkchtlHk4AylSRLafpQT7NtPT7eVFCPf/txQAaGbKXfCw/20UAcz1MumrpjxZtPe3APcf661 WxHmhOQRirFbwJ4YHiaOmyCo2kjmOqmN0+zpAYcXD8TsUcz1JXbiY8YpIptEPtA6A6dDG6rWNHVc ZPsQ6yKP/CQ7HDODgrQD6449XT5/+vuXz5/+OcHpopv5yTNHXfcm7qRpHLgESu3UAeCg7ILKuwh8 VPgexiSNEuLliju9gx9yByaP407P3zPR81o/Cx17os+WqoogdqHQs+P5MhgpcjBW4b5U7kPbiNe0 v9xqjrS6QiJ6qle8HEUPIsr1+Rl8/i8AAAD//wMAUEsDBBQABgAIAAAAIQC2wsUJMwUAAD8VAAAh AAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1szFjbjts2EH0v0H8Q1GdGokRduIg3 kGSxLbBJFvXmAxSJXgvRrRTt7DYIkN9qPydf0iElrbyXpE6TXfjFoqgZ8sycQ3Lo5y+u6srYcdGX bbMw8TPbNHiTt0XZXC7MNxcMhabRy6wpsqpt+MK85r354vTnn553J31VnGXX7VYaMEbTn2QLcyNl d2JZfb7hddY/azvewLd1K+pMwqu4tAqRvYex68pybNu36qxszNFfHOLfrtdlzpdtvq15I4dBBK8y Cfj7Tdn102jdIaN1gvcwjPa+DUledxBtz/PfeFaYhjYUO+jC5inEnq+qwmiyGjpWPFfuhjLkQn/t uwvBuWo1u19Ft+rOhXZ6tTsXRlmoQUZn0xo/jGb6tdnphnXH/XJqZidXa1GrJ2TDuFqYQNq1+rVU H7+SRj505nNvvnn9gG2+SR+wtqYJrL1JVVQDuPvhOFM4F6WsuKFSpHGc9XJCtBXlwvzAmBN7KSOI QQsROyYoTglFzHHD1AlY4rj+R+WN/ZNccM3L78WkL+zf47Quc9H27Vo+y9t6FMekMaATk5FOhfKD 7zo+jlyGAmpHiIVkiUJmAwRqezRY+nHE0o9jAgDz9NRRWGO8Y+ATEX131ubveqNpgSjF68DbjcVA pnp2m1FTUuVotBs+6sac5QcpDl0cegN3OLBp4Ia32ca2hz3fHml0Qs8J3OAumcPY3Ym8itviWrm/ hSeQmDX5poX193YYtOrlSl5XXLd3FR4hFXz9Bxj3fy1MmGmSyo2Bau85dupH+wlwqjK1ofAGvVkN c8jTpCrzd4ZsDV6U0niZ9ZILQ2cHdhwYRA04kDAM3ukYJuw6nK/L0r2RpcrSeZXlfNNWsEgN51gV GsRJ4MCcLHJShAlJEF2mAUpp4EfLBGMn8B9foUoUCpCS1fcIlXghJb77NaFiz7ZxeLBQv6ROo87E md7EyqaADV01tdf2FZxa2mtPvA6xh899W5UFK6tKvyjCeFIJY5dVsEyvhm1Mlo0cegJvFv2N8fA2 j2NNM91eG7rpzEiJFzgqBwfBVdM+FVyFcYTrznApSPFQuDh8QrgK4wiXzHCxG2AtsYPwKsunwqtA jni9PbyhE6qsHR9eBXLE6894HSfUB8Dx4VUgR7zBHt6AuAcvtyfFq0COeMMZrwJ7+Hp7SrwK5IiX 7uH1veA415sC+XBlotCDwU0p/O2VijrRdKHSf3elQqZKZZlJfqtScY+0UmG+52Ia2YgS7CA3JTA7 S2MUh2FE4zQm5Clq6UKaWlObrFpPFcsgki+WLPqG9dW6Qr9ojazhkqejTWhEwoR6yLMjglyP+Cj2 mY/SwE5YTD1MIoh2AgUcyrLmrLzcCv56KzWFd6Vl9LVMKp41NwqUp9TCPmR6lhMA0KQ3xXkmMrWC 7qjz/4jNm8TG2lYJeV9u5EjlltDUDlPqoiCyAwSXNhtubcCH7/osxkmIfUYeX25rKQa9/bnNBKRu ktx/VMnfIrkfS7U/Ub2CLZIbr7b12zuEe0dKuE0wpss4AsI9H2EPJo7DOECJTync4TGjS/r4hPdV ATl7kHPnEbYZzEI7Cb0lipcOQ4EN1784hu3V9iDXLA29aDlvM72itAF0h+4unz/9/cvnT//8gN1F P6a/uKas69aonTimvpOEcBxgwhBZ0gBFcGIg5rlwp43DKHFTpZ0Ok/vagc7DtNO177no2lL/D4jt UT66WsCUqiuA60wsDxqZ0SriVyp+eFbiZda93mmR1PpwT3RXp4Q5mM4mKvbpj8/TfwEAAP//AwBQ SwMEFAAGAAgAAAAhAFXucSWuBAAAbBMAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 NC54bWzsWF1u3DYQfi/QOwjqMy1RoijKiB3oj0UBJza6zgFkietVI4kqxV2vGxjItdrj5CQluZI3 /om9Tu3CD3kRKWo4nJnvG3KoN2/XbWOtmBhq3h3YcM+1LdaVvKq78wP7wykFxLYGWXRV0fCOHdiX bLDfHv7805t+f2iqo+KSL6WldHTDfnFgL6Ts9x1nKBesLYY93rNOfZtz0RZSvYpzpxLFhdLdNo7n uthpi7qzx/lil/l8Pq9LlvFy2bJObpQI1hRS2T8s6n6YtPW7aOsFG5QaM/umSfKyV97KC3589odt GTmxUiPQPlSul7OmsrqiVQOnF9xKeSeVGvNp6E8FY7rXrX4V/aw/EWbG+9WJsOpKaxhn2s74YRQz r93KdJxb08+nbrG/notWtyoS1vrAVoBd6qejx9haWuVmsNyOlovje2TLRX6PtDMt4Hy1qPZqY9xd d7zJndNaNszS8TF2HA1ysmgp6gP7E6VeEuQUAap6ALkJAkmOIkA9n+ReSFPPx1d6NsT7pWAGk9+q iVsQ38GzrUvBBz6XeyVvR2JM/FJQQjRCqa38hLwshAgHAKcwBDFFEBCPpCDKSZbmUUpcGlyNAVA2 T63xwhn9HR2fgBj6I15+HKyOK6A0rhvcriU2YOq2X0x80jEa5TYfTWcb5ZEFcp3w6lIvcqZaM1js N4OcycuGmZdeP4wZQgHRFDpdWQc+zDbgysO0qcuPluQWq2ppvSsGyYRl1lf5rLRoBzduaiuMQme7 sDNB/m3g/Qn4kf3WSVOUbMGbSi3kvVIahJjGfpJp3PMEuC5yAclgDlIY+zh0CcoS/JI0GP5S9hfN XJuz3gp/gwv3pDvxidqlTB5D4gXYC25mfgAJxFpAZzTyA+j75HZeb1TvzLJeE2zVXG8cT2edNs6Q briHdbdXMTF5eJUZK3lXWQ1bsWYHjd7jGk8Xtdhdof+4QsqXQi521oh20FjPH1D4tNxFD+Wu/0pz F8dpGuVqYRrkEUgSREGEYAxInOcxxjAIY/Q/5q5h1ZNyF8PQ+5G8P5L3PyZvMCVvVkh2I3PRaz11 Mw/nuTp189ALgTplE5BkYQoIdaOQZnFAYPbyxVcl7Tvn76bmfZZibK6uBMbbNIoRSaMABG6MgB8g DBJMsXLeTWkSBRDF+dV0w6gUhrJuGa3Pl4IdL/Ul4i6LrKGVacOK7jqP5WHkQKwivaWTMsCA3lUn hSh+v0vE7yEbnshGOdfbwdd0C14p3SKKIU1CH4S+KvLSDHkgzrMcYBJ4Xkxz5ML05ek2l2LDtz+X hVChmyj3SM33FMo9L9ThBPWsqStmvV+2Z7cAx68U8DwIXTeIQ+D5UQpcpAAnhGQgicI497CXuTF5 ecCHplIxuxfzR2qF79pmICVuSgLlZeZRELooVTUR9IAbqFjTnARxtt1mBg1pp6zbdXf58vnvX758 /ucZdhfTTP9Epqib3sidJImwlxJ1JkBV0qEs0vdzdVOngY9QmpA49XPNnR6iu9xRg7txp+cXTPS8 Nj+NoDvSZ1XoEiNCbkR8F5lyzDG2Te01R2baf9U24l3RH68MSVpTIqVmqNfE3IhuRbTv01+yw38B AAD//wMAUEsDBBQABgAIAAAAIQDCwGunBwYAAP8eAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDUueG1s7Fnrbts2FP4/YO8geL9Zi1dRRpNC12FA2gRz+gCKRMfadJskO8mKAn2t7XH6 JCMpKXYSJ1WSpjCw/LEoivx4Dr/vHB7Jb99d5pmxFnWTlsXBBL4xJ4Yo4jJJi/ODycfTEPCJ0bRR kURZWYiDyZVoJu8Of/7pbTVrsuQouipXrSEximYWHUyWbVvNptMmXoo8at6UlSjks0VZ51Erb+vz aVJHFxI7z6bINNk0j9Ji0s+vx8wvF4s0Fn4Zr3JRtB1ILbKolfY3y7RqBrRqDFpVi0bC6Nk3TWqv Kulte1GeXp5elMdnf0wMPbhey244OZT+x/MsMYoolx1emVdRnTZloZ801WkthGoV61/ral6d1HrC h/VJbaSJAugnTqb9g36Yvi3WujG9Nf18aEazy0Wdq6vcDePyYCJJu1K/U9UnLlsj7jrjTW+8PN4x Nl4GO0ZPhwWmW4sqrzrj7rqDBndO0zYThtoebcdR0w4Wrer0YPIpDJFLg5CAULYAMV0C3IDYIESY B8gKPYTZZzUbsllcC83Lb8mgL8jucJqncV025aJ9E5d5L45BY5JOSHo6lZWfQuIEJg8wwAH3gcOI BxzHC0HAfJN4xCLQtD/3GyBtHq7ai2nvb+/4QERTHZXxn41RlJIoxWvH2/WIjkx1rZaDptQe9eO6 h7qx2eWdFHNsW5xr7jCjENGbZEOTQsrMnkWIEaUM3+ayg65m7aVbJldq+pm8aq1Fs6xp5+1VJvRN pX60GbWkOItUMhAF+DjvVm0PvSyN/zTa0hBJ2hrvo6YVtaE9k9lCoqh1uw1U/mnA6WZhbcvDksLX klIunmRRLJZllshV0J6qi1sUOzYNACckAAgTC3DX8oHpWJhgC4XQDl5eXYpRZZDSxHNEBhmHsJPQ RmVSY5bFrU5kHGEborEaM6IiXpYyxZ91kIPcdHudQTnNyKP6SGeitEhkVlZNDbD6II8ePSsRi9/l wOZvmXOIUvvZ4OY1Sg+INoCEWkiNHYVq3kVVUD0q3qDakGgLxqBCfhdVQfWoZIMKsQV1GI+C1SNv wiqsHpZuwXLEtQ1PhVVYPSzbwCLEmd6wp8IqrB7W2oK1CB7N2C5YhdXD8g2swhxP2Q5YhdXD2luw jFrPokxhde2tmNAZWC0iB1wf14/PyCpydUJunp2RyZCRvbJopaM3kjLe06Tsm9SEAQ6BT10fMEQI kKty4Hu2ZzlQnvgOfMmkrDhfRtmiT8ldunxiSkZUOmPdOvhvpGTMOKFy9PPO/RdW3e1V9AY+vMpc xGWRGJlYi2wEot7lhxFPl2k9HrA/Bh8CDMtV3S5HI5IRiOniAcDHxS69t5oi+1qrU4QQVeUTch1g clmr257vAEhd2wmCEHOX/ahqSgXxX6uoltru47grrR8TxwxaSJ9p99dWHEMV6a+11Wtt9Vpb/b9q K/ZQbUX3tbYKnADaCAPomDbALgkBRwEFhLkoDDjlQfiiL7x307I+VZ+clu+pr7bS8mt99Vpf7Yxf a4hfP2rFjeBlexq8JmeMuGYAmM9s4FGCgcNsExDqYhiGxHbMH/C1Kmm76mrrFQl2n6DvDWL9hXxk pC2ypPPWsx3CPZsCajoEYEoYcFnIQGCZXujaFBJHejsYJTls01yE6fmqFserVlN4W0VGk7deJqLi Oo7bQ3sKmdzpjZykAZr0IjmJ6kgdVLeE+BSx8UFsYVmqdLAtN2tP5SaXsnwi5Sbzp6rkCQSOhXwQ +oRRBhEzsfvyclu09a5qHn7jS+ljJPd9qbYHqudZmgjjwyo/u0U431PC5bubHQaBBWSeQcBBKuI8 ZAPOfdOBCCLX9V6e8CZL5J7t5Pwbn2KelGZgyE2PUx+4PgqBZcqXVteFCJhU7rUqiRx/k2YaRWkh rRubXb5++eeXr1/+/Q7ZRV+GvyiHXdetXjuuazPkcRe4UFZ1xLct4ISMgpBiQjyXOx4OlHYqSO5q R3aO005VXoi6KlP9Py40e/msI1W0MGjLyh9ZA02dRjbWKuLnyn95zer3UXW81iLJdYnk6a5KCbMb uhmifB/+uD78DwAA//8DAFBLAwQUAAYACAAAACEAM/skxtQDAAD0CwAAIQAAAHBwdC9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQ2LnhtbMxW227bOBB9X2D/QdA+M7qRsmTULkRJXCyQNkGdfgAr0bFQ 3Zai3XiLAP2t3c/pl+yQkuo0yQLBIgHyYlLkzHDOnMMx37y9aWrrIORQde3K9s5c2xJt0ZVVe72y P14xFNnWoHhb8rprxco+isF+u/71lzf9cqjLc37s9sqCGO2w5Ct7p1S/dJyh2ImGD2ddL1rY23ay 4Qo+5bVTSv4FYje147tu6DS8au3JXz7Fv9tuq0JkXbFvRKvGIFLUXEH+w67qhzla/5RovRQDhDHe P6ekjj2gVZWqxUVbH23LmMoDLHr2GtAXm7q0Wt7AwpW2soyZ3hn6KymEnrWH32W/6S+lcXh/uJRW VeoAk6PtTBuTmflsD2bi3HO/nqd8ebOVjR6hFtbNygbKjvrX0WviRlnFuFicVovdxSO2xS5/xNqZ D3DuHKpRjck9hOPPcMY66PKYPM4HNWe0l9XK/sqYT0nOMGIwQ9ilGNEcx4j5QZT7C5b6QXirvb1w WUhhWPmjnNXlhQ8YbapCdkO3VWdF10zSmBUGZHp4IlNn+ZUQQpOARSjwiIdgM0c09hPEgsUioCRi IcG3UwEg53k0KJwJ7wR8JmLoz7vi82C1HRCleR15+2ExkqnHfndXUZPduGkmpypPKlA3tCuP+pBP MJpFvqwHtVHHWpiPXv+YNCQQUXN9YUWLPm5GctU6ravis6U6S5SVst7xQQlpmfPhRkMUDXCEqbMw AZ3Twc5M+X8TH8zEZ1wJ67Lmhdh1dQmn+K9UAx5lJA1iH7lplqI0xSGizE1QRiI3zfMFYUny8hoo FfTUvwAJr7c6MbiA3nj1nkUTW2hMBm0aJzhKY4KIm2AUEI02ZCHKF27KaEw8nOS3c6srgUNVNYJV 13spLvbKUHhfWtbQqLQWvP3RRNQ6drwQKn2SEyRgSG/LSy75h4fq/D9iw7PYWNdpId+VW/Ba5Ral bpAFBC1oQFEYYh9R34+QG2EvC6MAJwF9ebltlRz19ueeSyjdLLnZ9xkk97xUk5nqTV2Vwnq/bz7d Ixy/UsJdL8oJy1O0iBK4ZzFOUZT5kEeSBUmQZnlI4pcnHB5mULNHOfdfoM14DJpnRDJEM5+hhQug KfWgxxKoNcsjkmSnNjNoSlvI7qnd5fu3v3/7/u2fZ+guZpifZnPVzWzSDqVx6KcRRdTDDOEsXqAE XgWIkQDjlEZJGuRaO72HH2oHFp+mnb77ImTfVeb16rmTfA68BuHHvreI3Gj+MxglckpW877R8GGs 5TveXxyMRhrz356apV7rcjQ9mWjo82t9/S8AAAD//wMAUEsDBBQABgAIAAAAIQDKr0x4ggMAAPMJ AAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1szJbbbtw2EIbvC/QdBPWa1ok6 LbIOREksCrix0U0egJa4XiE6leJudhsYyGu1j5Mn6ZASs6ntAr6wgdyI1OwMNTPfvyO9eXvsWuvA xdQM/dr2Llzb4n011E1/t7Y/vKcosa1Jsr5m7dDztX3ik/328uef3oyrqa2v2GnYSwvO6KcVW9s7 KceV40zVjndsuhhG3sNv20F0TMKtuHNqwT7B2V3r+K4bOR1renuJF8+JH7bbpuLFUO073sv5EMFb JiH/adeMkzltfM5po+ATHKOj/5uSPI1Q7W3L+o+2pd3EAQyefQmVV5u2tnrWgYFoD2WcxveCc7Xr D7+KcTPeCO377nAjrKZWsUuM7Sw/LG76tj/ojfMg/M5s2eq4FZ1aoQXWcW0DqZO6OsrGj9KqZmN1 tla76yd8q135hLdjHuB891BV1Zzc43J8U07BJLduWlbx3dDWXFiqSTqlq0ma5PaiWdufKfVJWFKM KOwQdglGpMQpon6QlH5Mcz+I7lW0F60qwTWX32qjLy96xLRrKjFMw1ZeVEO3iMNoDHB6eMGpEv5c eHGRFqWL3DBNUBziEKVh5KPMx8QnxM+jKLtfegE5m1VX4SylLz0wTKbxaqg+TlY/ADOFeEb4zWPm qtZxt2iqlvCP+gsqYe1WJQYcvJmAcdabM4BFIPJIhvqkHnoLqzayVTvJjTy1XN+M6rIFaepq8zTD SZ6GKHQzjIIQR4hENEJl7OaUpKGHs/LeCL0GhrLpOG3u9oJf76VGKAA16BsmAe/Rhw3k3cm85az/ piV5mTpeBJ1WvZo7Bglo6H19wwT748ERc3dHXaSpyDEy+3+xBUZsdBgkSOx7ufk/qNzcKA7DyI0B QEARDXCC0iQEueWxH9I4wSTIX19uWylmvf25ZwJaZyRnYl9Aci+LGhvUm7apufVu390+AB78oMCD jJRh5gJmHJQoDnChRkuBChKEhGS0LILy9YHDaxl69iRz/xXGjEcTN0/CApHCpyh2cY4I8XyYsdBr WiZhVpzHzKSQ9pDdc6fL1y9///L1yz8vMF30Yt7Qput6t2iHkDTy84Qg4mGKcJHGKKNRiGgYYJyT JMsVPYjx8GPtgPF52hmHT1yMQ6O/XTx3kc+BtTDjUs/1UxzF6YJp1sg5WwV+o+qHtRW/s/H6oEUC DwPIuTaNSpiz69lF1W4+1i7/BQAA//8DAFBLAwQUAAYACAAAACEANio2IqgFAAA8FwAAIQAAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbMxY627bNhj9P2DvIGi/WYsUqUvQpNCNw4C0 Deb0ARSJjrXpNol2nQ0F+lrb4/RJRlJi7DhurKTNlj/WZ/nw8HKODim/frOpSmPNur5o6lMTvrJM g9VZkxf19an54ZICzzR6ntZ5WjY1OzVvWG++Ofvxh9ftSV/m5+lNs+KG4Kj7k/TUXHLensxmfbZk Vdq/alpWi98WTVelXHztrmd5l34U3FU5Q5blzKq0qM2xfTelfbNYFBmLm2xVsZoPJB0rUy7G3y+L ttds7RS2tmO9oFGt7w6J37Rits3Vb5cb01Cwbi1uQPNMzDybl7lRp5W4ETU1FwzGx4IvjShtJZPC 9O1lx5is6vXPXTtvLzrV9N36ojOKXFKNFOZs/GGEqa/1WhWzvebXukxPNouuklexIsbm1BTC3cjP mbzHNtzIhpvZ9m62fH8Amy2TA+iZ7mC206mc1TC4+9NBejqXBS+ZIRdKjeO853pEq644Nf+iFIUk oRhQUQFshRiECfYBRbaXIJdGyHY+ydbQOck6prT5Jdceg849Xasi65q+WfBXWVONBtE+E5JCPEoq Ryl6d62Y+hHwUGQBy8YJCKGTAD/BNEhsHKvehwUQY9ZXNYvZON9x4lqIvj1vst97o26EUFLXQbdb xCCmvLbL0VdcrtGIG35UxXaVD0rs2b7reUo7TFxh1rti276NkO0OIkLHskbErpQDc3vCN2GT38jW V+IqJEzrbNmIJ/Bq4Cx7Puc3JVP1uoTjgHK2+FWA+z9Fb1v2W4Csdxq28kO160SjMpWRwmrwYT70 wc+issh+N3hjsLzgxtu056wz1NqIzBEkknCQYCBv1Rz02NV0HjalrU2pH9OLMs3Ysilz0RF6oRZN kjgkUUwBIaELIogt4Ak1gSgSLyShbwf+c1q0yDdbyHR3EujZcLSn77kYkbv2dKCLpGeUPbHn2s6A mGLPb/CkKtF9LPJ2sRogSvsAFu9iNUCU+ADW2sVqgCjJMawGiNI5htUAUbrHsBogSu8YVgNE6R/D DoBDz3wrH/d1ebvFPD4DpGlUBPQHMmC/F+XVh3uZs6ypc6Nka1ZOYETHGS+XRTed0D5OSJtVJ84Q UxnxBMZi8QDh45IU327vUprdGLVfaIziEJLAjyCwIxIB4uMYeDCOgBs44gAAA+Qg/Pw7vcwvUz08 y7RcyKFtRns9detHFnHHPPrK3m97EBKB/sZwNaq0O1enwqLOxeYpS9Vq9U68CqhWO9kgDxxfzd6R ajy1TOO7k7l7+Tzy+RBL1DS+O3vDXoaPfNB21TSmET4U9JrQQ57cZ55AuLcbjIQIyaPAkwj3tgxN 6GK1az6BcG9fGQkl23RRHtp8NKFD3CeK8r/tUI/LVqKzNU45u5Ot+IVmK/QgDcIQgchJfJmtIfAh hEAcqpBrU+oHifX82Zrze8kKB/W/Gq3q3frBAFRflEcW4iVfzTbyA+xFPgHECjCwCXZA6FAHJK4V 0dAnEAfJJ/2XQS405EXFaHG96tj7FVcS7lvL6CselSytbx3Iz/wZdMRKb+0kBqBEr/OLtEulxffc +RSzOdpstGmkkXftRl6o3TyPUmL5VKw4soAvQh/4CMYgwZC6yA8sOyTPb7cF7wa//bFKO7F02nJH XpUeY7nvK7WrpZ6XRc6Md6vqak9w56XmS4ITD1kIEOragGIcgABCD/g0xq5FA5SQ/+Ds1pe5WLOD mh85wT0pZiD1rMgjMQhjRIFr4QiEIUTAImKtaeKRIN7GTC8lrcXopqbLl89///Tl8z/fIV3URf+5 qVddVaN3wtB3UOSFIISYAhz7LgioQwAlNsZR6AWRnUjvtBDf9464Oc07bfORdW1TqH+BoTXaZ53K F0Ib2z7BWL0jzdTQ9PXWInM5fXEtu7dp+36tPFKpvT1St1rpywG6hcip63+9z/4FAAD//wMAUEsD BBQABgAIAAAAIQAeMTRSfQUAAAgXAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDku eG1szFjtbts2FP0/YO8gaL9ZixQpUUGTQl8cBqRtsKQPoEhyLFRfk2jXWVGgr7U9Tp9kl5QU2/lo 3NQZ8sei6Muje3kOj0i9frOuSmOVd33R1McmfmWZRl6nTVbUV8fmhwuBuGn0MqmzpGzq/Ni8znvz zcmvv7xuj/oyO02um6U0AKPuj5JjcyFlezSb9ekir5L+VdPmNfw3b7oqkXDbXc2yLvkE2FU5I5bl zKqkqM1xfLfP+GY+L9I8atJllddyAOnyMpGQf78o2n5Ca/dBa7u8Bxg9ejcled1CtW2RXqxNQ4d1 K+jA5glUnp6XmVEnFXScFalcdrnxqZALI0xahaRj+vaiy3PVqle/d+15e9bpoe9WZ51RZApqhDBn 4x9jmL6tV7oxuzX8amomR+t5V6krzIixPjaBuGv1O1N9+Voa6dCZbnrTxft7YtNFfE/0bHrAbOuh qqohubvlkKmci0KWuaEmSudx2sspo2VXHJufhSABiwVFAlqIWgFFQUw9JIjNY+KKkNjOFzUaO0dp l2tu/sgmjWHnDq9VkXZN38zlq7SpRoFMOgNKMR0pVVl+5iEVAQ4xsrmwEPapi7iwQ7jFxBNWZLEQ nj5MAOQ8XXUVs7HesfCJiL49bdKPvVE3QJTideDtJmIgU13bxagrqeZojBv+1I3NLN9LMbc9l3PN HWUuiHWXbNuzCbHdgUTsWNYYsU3lgNweyXXQZNdq9CVcgcKkThcNrMDLAbPs5bm8LnPdXpV4TCjL 539CcP83PG2DfhOg2lsDW/Wjx3UwqEyUpeQ1+nA+PEOehGWRfjRkY+RZIY23SS/zztBzA54DIApw oGAAb3UNU+66nO+L0p5EOS3TszJJ80VTZvAg8kIlygLLp8TBiLquQMyiNgoiHCAQqBMzCjnY4vkl Ctan8llvovcXKsPcxqNSPe5SwnaV6mCXKPlopVLu2s4QsY9SH5KnUSXdqfawos7A01VTj1q+gxeX HvWIenWTbKDGNbYXHuHbeApkxLM3eB6mdG88FXmDp0BGPLrBw7arVvmegNY2oEIZAdkWICdc1fEE QIUyAjobQEK4o8KeAKhQRkB3C9ClmrknACqUEZBvABXa/qTsACqUEdDbAnSY+0RSFMr9HprX2VnS JWrYLRd9iinSmze1Wo/bjmi/UEeEGaUxDznCti1QRGkEjihCFHPiUYFFTLzg+R1R+Y+peVsk5Xw0 R/Izb3FiMXdc6A+8xmFbghlE/6/mqF3lgOaId8zs580R75j3AcwRH9ocdwEPYI67gAcwx13AA5jj LuABzHEX8GFzVPAQcHOe+fENp1p5er/Z//SGk03eGiVyd7dJX6i3UgYmartwDHIjH1EMB6IgFhGy hCP8CLzI5/bze2sm7zgrHth/0Fr1Mfm7BqhvtEbmcF7X1YaeT3noMdhW+xTZjDoocISDYtcKReAx TP34y3T6z4BDWVS5KK7g7PB+KTWFt6Vl9JUMyzypbxQoT7wZdmCmN3KCBA7/IncmsYmmUULelht7 qXKLocfHEYoJ5sgJaIgC33GQF4SWG8LrnLPo+eU2l92gt7+WSQdTN0nukaPOj0jusFS7E9XnZZHl xrtldXmLcOeFEi4Ytx2Pucj2fYJsi/rIY8xHEQtcEviR49n0+Qnvywzm7F7OH9nBPclmsOBWCEqG bSoRyLWUygNMkMVgrkXMmR9tbKZXlNaQ3b7u8u3rP799+/rvAdxFX6bvlNOs69aonSDwHBLyAAWY CkQjz0W+cBgSzKY0DLgf2rHSTovpXe1A537aaZtPedc2hf6gi61RPqukVNsuh1nMs4g30jRoZJOt Iv5c1Q/XsnubtO9XWiSVfrmHuqtVwhxCNyGq9ukL9sl/AAAA//8DAFBLAwQUAAYACAAAACEAujA7 AWgEAACFDwAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWzMV1tv2zYUfh+w /yBoz4xEiboZdQpdhwFpE8zu3lmJjoXqNop27RUB+re2n9NfskNKips4bZ0iAfIiUtThuX3fOaRe vd7VlbZlvC/bZq7jM1PXWJO3Rdlcz/V3ywz5utYL2hS0ahs21/es11+f//rLq27WV8UF3bcboYGO pp/Rub4WopsZRp+vWU37s7ZjDXxbtbymAl75tVFw+hF015VhmaZr1LRs9HE/P2V/u1qVOUvafFOz RgxKOKuoAP/7ddn1k7buFG0dZz2oUbvvuiT2HUQLiRHLna4pOb6FFayfQ+j5oiq0htawsCxFxTRI kPYXCJc5rbQl2wkl1ndLzpicNdvfebforrja/XZ7xbWykNpGLboxfhjF1GuzVRPj3vbraUpnuxWv 5QhZ0XZzHcDby6ch18AJLR8W88Nqvr58QDZfpw9IG5MB4yujMqrBueNwrCmcISkyV8qPi15MHm14 Odc/ZZkVOWlGUAYzRMyIoCglAcos208tL4st272Ru7E7yzlT+PxRTDzD7hG2dZnztm9X4ixv65Ek E9cAVkxGWKWXn1w7su3AC1CSODFKfeKgKDRDmFk2TgPXTR3nZkwA+DyNKgpjjHcMfAKi7y7a/EOv NS0AJXEdcLuVGMCUY7ceuSVkjka54aOaHLI8skDsorbYSyPvYVSLdFb1YiH2FVMvnXwoNzgAUVFZ uqxB7xYDuOI8rsr8gyZajRWl0N7QXjCuKftQ26BFBjiEKb1QCo2DYWOC/NvA2xPwd2pAu6poztZt VYA564WSAXtuFno4QJbjB4hgEqEoJi644AUxwdj0CXl+Mkhoda3lJXSjoe1I93aHzY9hiOznoIVR icbAgWO+dJIq2+q2BTyePxJBRZ/+Af7ct6Li+L6VBctbaKMV27LqBI3WjzUu1yU/XaH9Y4VZu+Fi fbJGcoLGcvUdhY+rQjJVYUIFu1N89gstvtQ1SUR8D8z5JnJcYqMgISby3DRxiIUx8YLnL74Ciq3/ ByKh1Woqu+EAfJLOvIK7goo2DkLix4GDHDMkyHZkl3EzF6WeGWdR4GASpjfT1aMADEVZs6y83nB2 uZE3imMWaX0t4orR5raOxXlgYBcyfaATOKBAb4oryumfx0T8GbI5E9mytpXt4Gu6kRdKt8xNSZKZ KfLTzEGuDUwLggyjIPKCMHYd24uy56fbSvCBb39vKIfUTZT7mVb/Dco9LdTuBPWiKgumvd3U7+8B 7rzUw91OQ+xZLpzrIUZ2QsC656UIh74bErjnpRF+fsDhRwly9iDm6hB74jaDM9+MfSdBUWJlyDNJ jKIIW8h0INdZ6jthcmgzvYS0Ae9O7S5fPv/725fP/z1Bd1HD9IM0ZV3NRu5EUeBasQ8XMkwyRJLA Q2HmOihzbELiyA9jO5Xc6TA55g4snsadrv3IeNeW6m8SmyN9tlTeCGzfJQ7G1nQaDBw5eCuBX8j4 Yaz4G9pdbhVJanVFitVSJ4k5iB5EZOzT7/P5/wAAAP//AwBQSwMEFAAGAAgAAAAhAPhO/JabBAAA ZRAAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1szFjbbts4EH1fYP9B0D6z kijqZtQpdONigbQJ1u6+qxIdC9VtKdq1WxTob+1+Tr9kh5QUN06aOIsEyItJUcPhmTlnSMqv3+zq Stsy3pdtM9etV6ausSZvi7K5muvvlxT5utaLrCmyqm3YXN+zXn9z9usvr7tZXxXn2b7dCA18NP0s m+trIbqZYfT5mtVZ/6rtWAPvVi2vMwGP/MooePYJfNeVgU3TNeqsbPRxPj9lfrtalTlL2nxTs0YM TjirMgH4+3XZ9ZO37hRvHWc9uFGzb0IS+w6ihcSIZSkqFjbFcqdryp5v4Y2ln0EK8kVVaE1Ww8Bf YFrmWaUpew0ypi3ZTiizvltyxmSv2f7Ou0V3ydXsd9tLrpWF9DZ60Y3xxWimHput6hhH06+mbjbb rXgtW8iOtpvrQOJe/hpyDEBo+TCYH0bz9cUdtvk6vcPamBYwflhURjWAux0OnsI5SopMmgJ03osJ 2oaXc/0LpThyUkoQhR4iZkRQlJIAUWz7KfZojG33q5xtubOcM0XYH8UkPMu9RXZd5rzt25V4lbf1 qJpJfMCzRUaeJdwvZhKnJPUTFGJiI5wSFwV+aqMkCX0Pmzbx7ejrmAnAPLUqCmMMfMzAxEjfnbf5 x15rWmBMEjwQeG0xsCrbbj2KTcgc6VrLS5DkoL1x1mCqOofk38k8wCWBOXBqu46FnZsiwC721XtJ ruNblm/7xxQPrruZ2EVtsZezP0AL1EpEc51lktXBbdWLhdhXTD108keB4mBcZXIHYQ16vxhsxVlc lflHTbQaK0qhvc16wbimooYtBrxIFENyZbTKoXGAoZDdrzv7tu5k4JdVlrN1WxWwHH6hEnTCKMRm GqDANTFKAuKhwKMh4CCx57ihH4fh80tQEn2kQIC3O0x+hBJtH98jRM+zif2cQuykBrfV9db2eGFK qEqX/R3CPF5FJej+VRYsb+FUqNiWVSd4xA97XK5LfrpD+2GHtN1wsT7ZIznBY7m6x+HjyptM5Z1k gt2oavuFVjWs4KXUMVEcmBaCg4SgkDoJinzq+zZN/JCmz1/VBVRx/xkiyarVVM/Dwf7Tglb3juO6 +0mlreAOpKKNg5D4ceAgxwwJsh04RiOXuij1zJhGgWOREKKdQAGHoqwZLa82nF1s5E3ptoq0vhZx xbLmuo7FWWBYLmT6ICcAoEhvisuMZ3/eFuL/EZsziY22rdwOfpQbeaFyc03PdGlKUei5ATI9kFsU YwCThFYYuY5nkfj55bYSfNDb35uMQ+omyT1whjxGck9LtTtRvajKgmnvNvWHI8KdF0p4TMI4cCMf halrIpoSEwh3PGRbUZBiOFax6T8/4fAhCDm7k3N1iD3xNmNR34x9uYsmmCIPLkgoiiyMTAdyTVPf CZPDNtNLShtAd+ru8v3bP799//bvE+wuqpk+/Kasq96onSgKXBz7EYosQhFJAg9OB9dB1IGDIo78 MLZTqZ3OIre1A4OnaadrPzHetaX6WrbMUT7bTJ7fFnE9jMn1aTBo5IBWEr+Q8UNb8bdZd7FVIqnV FSlWQ50U5mB6MJGxT38PnP0HAAD//wMAUEsDBBQABgAIAAAAIQAavQP1owIAAGYGAAAfAAAAcHB0 L25vdGVzU2xpZGVzL25vdGVzU2xpZGU0LnhtbKxUy07jMBTdjzT/YHkf8mwJES0iLR0hMVBR+ADj OE00ju2x3dLOiH8f20na8hpYsIlvrn0f51z7nJ5tGgrWRKqasxEMjwIICMO8qNlyBO/vZl4KgdKI FYhyRkZwSxQ8G3//dioyxjVRwMQzlaERrLQWme8rXJEGqSMuCDN7JZcN0uZXLv1CokeTt6F+FARD v0E1g128/Ew8L8sakynHq4Yw3SaRhCJteldVLVSfTXwmm5BEmTQu+llLY4MNL2hhVyXuJCHWYusf UizEXLrt6/VcgrowjEHAUGOIgX630R1zv2ztDP9F+LI3UbYpZWNXgw1sRtDQv7Vf3/rIRgPcOvHe i6ubN87i6uKN035fwD8oalG1zb2GE/VwFrQuCLhs0JKAOUWYVJwWRIJwh7NHoMQVx78UYNwgbAnh t1x31qRCbEnOlSDYuVo2duEtRXYVFdBbYSorWlw2y+5gu+uMffM9py2M98HEPZhrd1MPYUQfw/i4 0wdebKGptNkff79fkelNbgJsLRvonCijSi/0lhL3I9zUWTFHEt0aEBTZV0iYd7+AoKilPpircGX6 nJ9gI3k+2utV82CIOCQl/gpSzPhMaiMaf0bw9wpJTWTH0eDrOCpp4TD9zcM8mMbx0Bse57EXxUng 5UE69SZhNMgHaRxFF4MnuGvNAGemOZtCvuRXNXpCCWK7J6XHiSVaO7pLqwfvDuc/I3FLLyLmRV8p 3VlgJWsLIT8ZRpM09/IwmXnJ9OTYO58NB95sECfJJE/PJ/HFkxWlMMmwJE6vLote6cLkldY1NZZc 8VIfYd50oukL/kik4LXTzTDoxHeNqJlLkIbH6UnQ3izXWr+6Zu3AOznEVP5E4mbtLoepZYY7cS5h dL27G/sjdsT25Y3/AQAA//8DAFBLAwQUAAYACAAAACEAAwxY5KQCAABnBgAAHwAAAHBwdC9ub3Rl c1NsaWRlcy9ub3Rlc1NsaWRlMS54bWysVMtO4zAU3Y80/2B5H/JsKREtIikdITFQUfgA4zhNNI7t sd3Szoh/H9tJ2vIaWLCJ7ev7OufG5/Rs01CwJlLVnI1heBRAQBjmRc2WY3h/N/NGECiNWIEoZ2QM t0TBs8n3b6ciZVwTBUw8Uykaw0prkfq+whVpkDrigjBzV3LZIG2OcukXEj2avA31oyAY+g2qGezi 5WfieVnWmEw5XjWE6TaJJBRp07uqaqH6bOIz2YQkyqRx0c9amhhseEELuypxJwmxO7b+IcVCzKW7 vl7PJagLwxgEDDWGGOh3F52bO7K12/gvwpf9FqWbUjZ2NdjAZgwN/Vv79a2NbDTArRHvrbi6ecMX VxdvePt9Af+gqEXVNvcaTtTDWdC6IOCyQUsC5hRhUnFaEAnCHc4egRJXHP9SgHGDsCWE33Ld7fIK sSU5V4JgZ2rZ2IW3FNlVVEBvhamsaHHZLDvH9tZt9s33nLYw3gcT92Cu3Z96CCP6GMbHnT7wYgtN pc3e/f1+Rao3mQmwtWygM6KUKr3QW0rcQbips2KOJLo1ICiyr5Aw734BQVFLfTBX4cr0OT/BRvJ8 tNer5sEQcUhK/BWkmPGZ1EY0/ozh7xWSmsiOo8HXcVTSwmH6m4VZMI3joTc8zmIvipPAy4LR1MvD aJANRnEUXQye4K41A5yZ5mwK+ZJf1eicEsR2T0pPQku0dnSXVg/eHc5/RuKWXkTMi75SutuBlawt hOxkGOWjzMvCZOYl05Nj73w2HHizQZwkeTY6z+OLJytKYZJiSZxeXRa90oXJK61raiy54qU+wrzp RNMX/JFIwWunm2HQie8aUTPV4zBIBnEcnXQDMr31q+vWTrzTQ0zlTyRu1u7vMMXMdHNnEkbYu59j 72JnbJ/e5B8AAAD//wMAUEsDBBQABgAIAAAAIQAm/YsgowIAAGcGAAAfAAAAcHB0L25vdGVzU2xp ZGVzL25vdGVzU2xpZGUyLnhtbKxUy07jMBTdjzT/YHkf8mwpES0iKR0hMVBR+ADjOE00ju2x3dLO iH8f20na8hpYsInt6/s658bn9GzTULAmUtWcjWF4FEBAGOZFzZZjeH8380YQKI1YgShnZAy3RMGz yfdvpyJlXBMFTDxTKRrDSmuR+r7CFWmQOuKCMHNXctkgbY5y6RcSPZq8DfWjIBj6DaoZ7OLlZ+J5 WdaYTDleNYTpNokkFGnTu6pqofps4jPZhCTKpHHRz1qaGGx4QQu7KnEnCbE7tv4hxULMpbu+Xs8l qAvDGAQMNYYY6HcXnZs7srXb+C/Cl/0WpZtSNnY12MBmDA39W/v1rY1sNMCtEe+tuLp5wxdXF294 +30B/6CoRdU29xpO1MNZ0Log4LJBSwLmFGFScVoQCcIdzh6BElcc/1KAcYOwJYTfct3t8gqxJTlX gmBnatnYhbcU2VVUQG+FqaxocdksO8f21m32zfectjDeBxP3YK7dn3oII/oYxsedPvBiC02lzd79 /X5FqjeZCbC1bKAzopQqvdBbStxBuKmzYo4kujUgKLKvkDDvfgFBUUt9MFfhyvQ5P8FG8ny016vm wRBxSEr8FaSY8ZnURjT+jOHvFZKayI6jwddxVNLCYfqbhVkwjeOhNzzOYi+Kk8DLgtHUy8NokA1G cRRdDJ7grjUDnJnmbAr5kl/V6JwSxHZPSk8iS7R2dJdWD94dzn9G4pZeRMyLvlK624GVrC2E7GQY 5aPMy8Jk5iXTk2PvfDYceLNBnCR5NjrP44snK0phkmJJnF5dFr3ShckrrWtqLLnipT7CvOlE0xf8 kUjBa6ebYdCJ7xpR80yG0TCI4iB28/ddb/3qurUT7/QQU/kTiZu1+ztMMTPd3JmEEfbu59i72Bnb pzf5BwAA//8DAFBLAwQUAAYACAAAACEAD+54YqQCAABmBgAAHwAAAHBwdC9ub3Rlc1NsaWRlcy9u b3Rlc1NsaWRlMy54bWysVMtO4zAU3Y80/2B5H9I8WkJEi0hKR0gMVBQ+wDhOE41je2y3tDPi38d2 kra8BhZsYvv6vs658Tk92zQUrIlUNWdjGBwNICAM86JmyzG8v5t5CQRKI1YgyhkZwy1R8Gzy/dup SBnXRAETz1SKxrDSWqS+r3BFGqSOuCDM3JVcNkibo1z6hUSPJm9D/XAwGPkNqhns4uVn4nlZ1phM OV41hOk2iSQUadO7qmqh+mziM9mEJMqkcdHPWpoYbHhBC7sqcScJsTu2/iHFQsylu75ezyWoC8MY BAw1hhjodxedmzuytdv4L8KX/Ralm1I2djXYwGYMDf1b+/WtjWw0wK0R7624unnDF1cXb3j7fQH/ oKhF1Tb3Gk7Yw1nQuiDgskFLAuYUYVJxWhAJgh3OHoESVxz/UoBxg7AlhN9y3e3yCrElOVeCYGdq 2diFtxTZVVRAb4WprGhx2Sw7x/bWbfbN95y2MN4HE/Vgrt2feggj/BjGx50+8GILTaXN3v39fkWq N5kJsLVsoDOilCq90FtK3EG4qbNijiS6NSAosq+QMO9+AUFRS30wV+HK9Dk/wUb8fLTXq+bBEHFI SvQVpJjxmdRGNP6M4e8VkprIjqPh13FU0sJh+psF2WAaRSNvdJxFXhjFAy8bJFMvD8JhNkyiMLwY PsFdawY4M83ZFPIlv6rROSWI7Z6UnkSWaO3oLq0evDuc/4zELb2ImBd9pXS3AytZWwjZySjMk8zL gnjmxdOTY+98Nhp6s2EUx3mWnOfRxZMVpSBOsSROry6LXumC+JXWNTWWXPFSH2HedKLpC/5IpOC1 081g0InvGlHz5qP4JImTOO7mY1rrV9esHXgnh5jKn0jcrN3PYWqZ4ebOJIyud//G3sWO2L68yT8A AAD//wMAUEsDBBQABgAIAAAAIQCwsQ6XAAUAAEMSAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDEueG1szFjbbtw2EH0v0H8Q1GdmRYqkJCPrQNSlKOAkRjf5AFnieoXoVom7sRMEyG+1 n5Mv6ZCSsutLUjt2Cr8sKWp4ODPnaDTa5y8u6srayX4o22Zp42eObckmb4uyOV/ab9+kyLetQWVN kVVtI5f2pRzsF8e//vK8Oxqq4iS7bLfKAoxmOMqW9kap7mixGPKNrLPhWdvJBu6t277OFFz254ui z94Ddl0tiOPwRZ2VjT3t7++yv12vy1zGbb6tZaNGkF5WmQL/h03ZDTNadxe0rpcDwJjdV11Slx1E q0pVSdsyZv0OFrB9DJHnq6qwmqyGhTfawlpVZSHNraF700upZ83u975bdae92fFqd9pbZaERpp32 YroxmZnLZmcmi2vbz+dpdnSx7ms9QiKsi6UNfF3q34VekxfKysfFfL+ab17fYptvklusF/MBi4ND dVSjczfDIXM4YyJ0fowfJ4OaPdr25dL+mKZEsCSlKIUZoo6gSCQ0QClx/YR4aURc/knvxvwo76Wh 5I9ilhbmN+isy7xvh3atnuVtPelilhcwienEpPbyY+BG3A08itzQDZEXUDjdcSPkeUlMPRI7Ho0+ TQkAn+fRRLGY4p0Cn4kYupM2fzdYTQtEaV5H3r5ajGTqsdtMcspVb9I0mY73zWSf6FtZxoxQxxn5 w5hAqtyrjAeYjgaaSciox50bfI7Y3ZG6EG1xqXefwQg8Zk2+aeHpOxsxq0Gt1GUlzXxX4U6bVOeN 8d/wW8j1n7A4fFjaXJ86HjTZjvMDjE7/mKh62FRlurLIBr1djcep46gq83eWai1ZlMp6mQ1K9pZ5 9KD0AIgGHCkZwTsTzhyGiez7InVnka62ZyMueaI6TVMWRj6jiOEgQklIY+QLESCceCHnYSISzH6+ Toft2ahTcEqr70F6dblDHNf/jl4xZ8zj5K56/aZI66w/MeWsbAqo6mZ6Vbhn21fwFjMABxrWvl7X sJmSPSplHtH+3hf6yuOh8SZodw895uLe0Ng/hNZ4EzTdQ2PXw7oS3Bt7Xz4mwAmbHWD7xNcuPAxb A07YfI9NiG8Ky8OwNeCE7R1ge9T9ESqvYmvACdvfY2vgH+LyCrYGnLCDA2zOTFV/GLYGfKQKPczF 9HGKNJ2LdJwpaZ1WWS43bVXAQe4TLdYUE+b6sY+I5wtEBDQVfuxxxH3KwsT1YhEGP79YF8o2PG+y aj0X7JHwb1Zs02p+t6yaCyOLNbS6JtooCKkfBQwxJ4Q+ilGOBE85SjwnSkXAMA2TT3PjXACHqqxl Wp5ve/l6qwyF19VlDbWKKpk1X7tSdRwsMIdM7+UEDhjSm+I06zOt6msC/RGxsVlsadtqLR/KjT5R uQkngsYu9ZAgUYwYhYMDrvngInbCIPZFJH6+3NZQbIze/tpmPaRultx/NAn3kdzjUs2/Nn/6I816 ta3PrhHOnirhDEdCMIZSlzAEnygCBVEawCyEhiri2MHkf2gGqwJydivnY8v2uGUGp74DHXCMRExS 5Dk0QkJgghwGuU4Tn4XxvswMmtIGvLtrdfny+e/fvnz+5xGqixnmb/0562Y2aQfadk4ieDEITFNE 48BDYcqBTOZSGgk/jNxEa6fD9KZ2YPFu2una97Lv2tL8F4KdST67rIJGB3uMQzvizm+DUSN7bzXx Kx0/jFX/Mute74xIavN+j8xSp4U5mu5NdOzznz/H/wIAAP//AwBQSwMEFAAGAAgAAAAhAH5DMFrT AAAAvwEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTQueG1sLnJlbHOskMFq wzAMhu+DvYPRfXZSyhijTi+j0EMvpXsAYyuJWSIbSx3r29ewDRroYYcd9Uv69KHN9mue1CcWjoks tLoBheRTiDRYeD/tnl5AsTgKbkqEFi7IsO0eHzZHnJzUJR5jZlUpxBZGkfxqDPsRZ8c6ZaTa6VOZ ndSyDCY7/+EGNKumeTbllgHdgqn2wULZhxWo0yXjX9ip76PHt+TPM5LcOWF4igEr0JUBxYLW38lP Y60rEMx9j/Y/PSgJ8sGxYFnY3OSLofbXzCze3l0BAAD//wMAUEsDBBQABgAIAAAAIQAXPO1q0wAA AL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGUzLnhtbC5yZWxzrJDBasMw DIbvg72D0X120sIYo04vo9BDL6V7AGMriVkiG0sd69vXsA0a6GGHHfVL+vShzfZrntQnFo6JLLS6 AYXkU4g0WHg/7Z5eQLE4Cm5KhBYuyLDtHh82R5yc1CUeY2ZVKcQWRpH8agz7EWfHOmWk2ulTmZ3U sgwmO//hBjSrpnk25ZYB3YKp9sFC2YcVqNMl41/Yqe+jx7fkzzOS3DlheIoBK9CVAcWC1t/JT2Ot KxDMfY/2Pz0oCfLBsWBZ2Nzki6H218ws3t5dAQAA//8DAFBLAwQUAAYACAAAACEAmfaZrtMAAAC/ AQAAKgAAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlMi54bWwucmVsc6yQwWrDMAyG 74O9g9F9dpLDGKNOL2PQQy+lewBhK4lpYhtLG+3b17ANGuhhhx31S/r0oc32vMzqiwqHFC20ugFF 0SUf4mjh4/j+9AKKBaPHOUWycCGGbf/4sDnQjFKXeAqZVaVEtjCJ5Fdj2E20IOuUKdbOkMqCUssy mozuhCOZrmmeTbllQL9iqp23UHa+A3W8ZPoLOw1DcPSW3OdCUe6cMDwHTxWIZSSxoPV38tPodAWC ue/R/qdHTEK8RxYqK5ubfDXU/pqZ1dv7KwAAAP//AwBQSwMEFAAGAAgAAAAhAEqvdTnSAAAAvwEA ACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTEueG1sLnJlbHOskLFqAzEMhvdC 38Foj32XIZQSX5ZSyJClpA9gbN2dyZ1sLCUkb19DS8lBhg4d9Uv69KHt7jpP6oKFYyILrW5AIfkU Ig0WPo/vqxdQLI6CmxKhhRsy7Lrnp+0HTk7qEo8xs6oUYgujSH41hv2Is2OdMlLt9KnMTmpZBpOd P7kBzbppNqbcM6BbMNU+WCj7sAZ1vGX8Czv1ffT4lvx5RpIHJwxPMWAFujKgWND6O/lptLoCwTz2 aP/Tg5IgHxwLloXNXb4Y+jUzi7d3XwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAAC0A AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHOMz70KwjAQB/Bd 8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H 1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66ra qPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32 AwAA//8DAFBLAwQUAAYACAAAACEAaaJfIRUBAADHBwAALAAAAHBwdC9zbGlkZU1hc3RlcnMvX3Jl bHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzxNVNasMwEAXgfaF3MLOPJTuJk5TI2YRCoKuSHkBY4x9q S0ZSSn37ipZCDGFoIaCNwJL15uNttD98Dn3ygdZ1RgvIUg4J6sqoTjcC3s7Piy0kzkutZG80CpjQ waF8fNi/Yi99uOTabnRJSNFOQOv9+MSYq1ocpEvNiDqc1MYO0odP27BRVu+yQZZzXjB7nQHlLDM5 KQH2pML88zTiX7JNXXcVHk11GVD7GyOY6zuFL3IyFx9ipW3QC0jT6/3ZT9s0jAB2W7aMKVtSsk1M 2YaSZfk9aT7cxRnqe+dnzSjHXRn/bSgnG4opIzsrYsoKsrO4pZGtrWPS1mRrPGprnLKtYtJWlGwX U7b7lbHZ81t+AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALQAAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHB RfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj2 7XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uD uL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQA BgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDkueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyz f02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0 IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNn SoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALAAA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzjM+9CsIwEAfwXfAd wu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UW BGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0 bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMA AP//AwBQSwMEFAAGAAgAAAAhAFNtX6QUCAAAMTYAACEAAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRl TWFzdGVyMS54bWzsWv9u47gR/r9A30FQ/yy0FiVSP4x1DpZs3S2Q2wsuuQegJTpWI0sqRfuSPSyw z9K3aB9nn6RDirLlJPYm103hBEaAiB6NRsP55hsOab//4XZZGGvGm7wqRyZ6Z5sGK9Mqy8vrkfnb VWIFptEIWma0qEo2Mu9YY/5w9te/vK+HTZH9TBvBuAE2ymZIR+ZCiHo4GDTpgi1p866qWQn35hVf UgEf+fUg4/R3sL0sBo5te4MlzUtTP8+f8nw1n+cpm1TpaslK0RrhrKAC/G8Wed101uqnWKs5a8CM enrHpTOYX3pZZPI6u27//8rmRp7dQpRsG4EGHSrLLC64sabFyJxdI3Nw9n6glfVIPtzUV5wxOSrX P/L6sr7g6g0f1xccbIJJ0yjpEuIrDagbWk19LNdqMLj3+HU3pMPbOV/KK4THAA8BxTv5fyBl7FYY aStMt9J08csjuuli+oj2oHvBoPdSOavWuYfTcbrpXOWiYMZFQVO2qIoMcqWNHPh03ojOuxXPR+Yf SeJEZJpgK4GRhe0IW9EUh1biuMHU8ZPYcb3P8mnkDVPOFGgfsi75kPcA8GWe8qqp5uJdWi115nQJ CFgjrNNPevwH8tDUCx3XwkEQWJ6NA2uMpraFEw/5SWSD1P6sgwE+d1c1i4Geuw5CB0pTn1fpTWOU FYAmMW4x3Gi0wMprvTDEXQ3xEjJeWq+9qQbbiD8Kd+AGkLoKR9cjyCG7wCObIOJJBYkoch1CPHcH VzqseSN+ZNXSkIORyVkqFFB0DTNsVTsV5VPrST0Ut1GV3UnNGVwBfqgl8Pyi4p9Mo/hQNiMzRBjD u4X6gInvwAfevzPbuSOKuCpU/tEyBTsjMxVc+VICc8crUc1z7VH7SnmraMSluCuYmnct/ykxB4cK KksZK63fLtuwiLO4yNMbQ1QGy3Jh6CKmQg+1DqxI2y3CEgBlcLCdqpr94fx3N/kvMeinv3Ok6Z8k nhtHvmf5U+xYEx9HVuQ6kRVM4hB44Ya+j18+/SWg0iGZtP8LC1DgEO8wDbBLkOsGx0+DZ2d+LZN+ rZ5VwuczQUZMEaF5hAn336KAOvyWS5ZWZWYUbM2KJ1h0vm3xapHzpxtUxe6wwaRacbF4skX8BIv5 /IDB59UT3NWTCRW7y6l7pPUkjCbBZALrp28nsUUC7FshwbaVoGQ8dgKcEOf/UE8yAd3rJ5gJLea6 rqjk+rN1xXNh5ST3+irHx65SkGVlu/6+osVVTacrJGq8LpDMdVpcw66gUM5mbP4riGQ4kZyugqQq 8izJi+KRbljctq2eyEvRSnxi210/uVFuP23tDLo3qaF2pB33HFRsnBdZm2xxOMZBHBKL2GNsuQR7 VuQlnjX17TiJQoLwePrZ7HICKCTyJUvy6xVnv6xaKO6T2GiWIi4YLTdlVJyFA+RBom/ZPJcbBEiE MrugnMro3KsDf4brpON6UlWyGvfZjo+U7dNgGsd+hCwcAdsnU+xaoYewNYU2GkPrnEyi5OXZPodU Vvn5zxXlEDrN+LbVfQ7jse0GqlHYR3mMEA7eMuW7lvv4SP99yeZ1ZLsEX5jxcbWc3aMcOVLKQYfr k4D4VjydxFYYwH41cJ3EimLfTaCJH08xennKNUUGMXuMdapDet466yH7IOve/EJ7rJzbLLQoCew4 IBMrmkCq+TaOrShCjmUTyPVkGpDxZLvQNpJSJWTHU9fXr1/+/bevX/7zHdZXdemO3LqsVyPN3SgK PScOYJOLcGLhSehb48QjVkJcjOMoGMfuVHK3Rvghd0H4NO7W1e+M11WuDiqRremrIHIw9jyEPOJp nrQc3XoriacPINOC/0xrY3aNoBcTCOJ7C6PsBkaza0fKHClzpAxGNE1ZKUBDDzqJ00k2Om4ncTsJ 7iS4k5BOQjqJ10mgeC6KvLyBYMiLacyr4qdW0I3a40yoEuf0rlqJD5lGoidpDwwR9nHgejgE7gyl hH/IVAHar0skzzpd1dYf0EU9XdUQHNB1erqqjB3QdXu6qhod0MU9XQX7AV3S0/W/oev1dNWBxgFd v6cbfkM36GOhWHpAeQe4bul4CLy4VaWlUWN54rZ3z2FAdbqis8tPusK2VVWVVEbPy4jfqGNzefRf 6o9wawEFApbLi1WZCnlfWS4v67Rd4NKLVNfI0N7WyL5CJA/ud1U3pXRzd7b6WJXtkUuvWrdO3jAu v0l5auXWpvtaakqqiM6hDxmZf1/+wyqEXgvpvRuM6pP75t6NtNG2H63yu9Gv1br3AIol5ecAsdM2 w3kJ5RyCanWC40FKNK0q6q17PbCSClbGbXTGPKfgdU3LqoGPtmNH0HhguHZ/wNQ6F+kiocu8kM0G CNIF5Q0Tm/VqtopBosQj8+uXf7XSXjo4aofwEulQ7kuHcl86lIfTQQ2dLeReQJTzrwByckyIv1gB +I6IS5g14u4WcdjQujLmJ8ifCbkK2pFDLnHWkOMe5ACv2k6dIH8W5Og11HWJs4ac9JZym/gKxhPk bw9yibOG3OtBThB+Le3bCfJnQi5x1pD7PchDv/X+BPnbg1zirCEPtpC72JFBP0H+FiGXOGvIwx7k QeCd2rc3CrnEuf396PZcph5WYsH45pQGnrhoE0PPbnM4Hv+0NapVdo90XiRJXluMHz/6UF/gnOKz 96CgC8IpPnt21a4vN9anAO3bg6LACZT3pwDt2bGpZfwUoP37m+53AKcA7dkNgLunIn2od/aIfyrS u51mv7lUv6jovqhtv8dtfxt+9l8AAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAA cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHOMz70KwjAQB/Bd8B3C 7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYE Z/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRt QDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA //8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMv c2xpZGVMYXlvdXQxLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujb m9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVR PGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm 8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8 AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc4zP vQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDI m2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlX Ec0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTL EgGqbdTs3fYDAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0 AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y 0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+ I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYA CAAAACEA1dGS8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0 LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39N o3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHL EMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qF xdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4zPvQrCMBAH8F3wHcLt Jq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn 9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1A OzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD/ /wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDYueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub 0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8 axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby +UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEAtM9YGbkA AAAkAQAALAAAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxzjM/B CsIwDAbgu+A7lNxttx1EZO0uIuwq8wFKl3XFrS1tFff2FnZx4MFLIAn/F1I373kiLwzROMuhpAUQ tMr1xmoO9+56OAGJSdpeTs4ihwUjNGK/q284yZRDcTQ+kqzYyGFMyZ8Zi2rEWUbqPNq8GVyYZcpt 0MxL9ZAaWVUURxa+DRAbk7Q9h9D2JZBu8fiP7YbBKLw49ZzRph8nWMpZzKAMGhMHStfJWiuaPWCi ZpvfxAcAAP//AwBQSwMEFAAGAAgAAAAhANnXVIC0BQAAbh0AACEAAABwcHQvbm90ZXNNYXN0ZXJz L25vdGVzTWFzdGVyMS54bWzsWO9u2zYQ/z5g7yBoHwdV/2XZqFPETtwGSNugTh+AlmhbMEVqJO0m HQr0tbbH6ZPsSJH+lyx1s2xYUX+xTqfjkffj745nPn9xUxNnhbmoGO274bPAdTAtWFnRWd99fz3y ctcREtESEUZx373Fwn1x8vNPz5seZRKL10hIzB3wQkUP9d25lE3P90UxxzUSz1iDKXybMl4jCa98 5pccfQDvNfGjIMj8GlXUNeP5IePZdFoV+IwVyxpT2TrhmCAJEYh51QjrrTnEW8OxADd69M6STiDC YkxK9ZzM2t93eOpU5Q3gFAQhWKCe9oyHhDsrRPruZBa6/slz3xgbSQ0WzTXHWEl09ZI34+aK6xne rK44+ASXrkNRDQgrB/qDMdOvdKUFf2/4zIqodzPltXoCPA6sEPbxVv36SodvpFO0ymKjLeZv77Et 5uf3WPt2An9rUhVVu7i74UQ2nFcYlUCQK4IKPGdEyRojbWwXL5pLViyEQxkEp7BoY11btACoZzN3 5G0DfuclB2Z+7Lu/LREHCpohrZ0WNos8HKGo2wnzwESepHknz3fCR72GC/kSs9pRQt/luJCaCWh1 KWRrak30OtrZm568GbDyVllO4AkoQdLB+DnjH12HXFDRd7thksDUUr8kaSeCF779ZbLzRZIhI+sI iJBjeUuwllckhGkdRGaQ1ESvr8TTd6BSiIXAchOVsWzlLQ+NBoWWV4gjNYwgVQ8w9d6PzchGR2ej 0oE+zIjYMuIMSbzDh+gp+FBK1+TmNzMhzvMkC+MfhQ/8sXyYklLv5O9Jno/i7iD0wtO8652GySn8 jAIvj0bnYdbNz4dJ55NrNwa2W1Y1HlWzJcdvly08fI9UjqjlkGBE1wHIk64fZlCR1VqkXtFUleOn 5mVieTkmVYmdixrNdukZf52eIL1j0kjDOSwKn4oGqHAYdwUpL+qZ4a/Ohm/ib5anmqNA0TBM4qDd zQ2J0yTPEkviOMizcL3fj2IxgqN/VBHS8ow6HxSFOuBTY8MARvXVut0cjoDpwsy7ZaWYRv+r1HAQ LcBP3y2kPjE2LNcv/0LZSy293qh2aYdYyVPUPQXR7kHY0kiz9rE0AgiDNH2QRlkQJK3Fd1QMN5us yiEUu7WFBmS/KJk6NCRVsXAkc3BZScd0vFLBIpRTsSlQbeFsJ9iZRe/kw7OMccFo6RC8wuQAj7pM POzxel7xwx1qwjzscMSWXM4P9qj5/RWP1fQBh9+WaZnNtBFjaoe2Uy19ilSbyr2Ws800HeYjWs8c Ei4KDex/33B0/v85tq6qk++kF+3snvlvlvVkjzDZUxAGznVwfR9nNB8f3aT+iMz5513rIBwEZ3Gc eVlnEHtRnATeIMjPvGEYpYM0j6PoPF13rUIRg8LmHdqsfvn8xy9fPv/5BM2qftjbAthd2BwjOUte qUAG3Swa5gNvECYjLznrdrzTUZZ6ozROkuEgPx3G55/UBUaY9AqO9d3GRWlvRcLkzr1IXRWcCTaV zwpWmwsWv2EfMG9Ype9YwsBc1OhOLoY9jbMsimyvCmuzT71alRfm7qQg/DVqnMkshOyX0CDLG5DK BUiTWaR0kdJFSgcSKgpMJVgYwWoiq1nbxFYTW01iNYnVpFaTWk1mNXBazElFFwCGerjOlJFXrcJK bQnQ11x3SFkjftkS2NQ1B6h5jSbjj4byLc21CUaXdMAX+u+Buqei5hU+qb8KFZ1dLWn7X+E+jjsL zNXdnJLvdNh7F1AA7t0OG1atZtXMnkKJ67u/1tQj0tQPtPcBI3MTJPY+FML4ble4m3pajDbQ6FQ/ 4mNAMfjEG3wsCEd8FCgGn2SDTxh3wuwIkEXFAJRuAZRHuT7vjwApVAxA2QagKMozdRdyBEijYgDq bAHUSeJjjV6jYgDKNwApdI5Feo2KAai7BVCWdo5Feo1K+09uq1+0r+2d0clfAAAA//8DAFBLAwQU AAYACAAAACEAe0O8XcQGAADPIAAAFAAAAHBwdC90aGVtZS90aGVtZTIueG1s7FnNixs3FL8X+j8M c3f8NeOPECfYYzubZDdZspuUHLW2PKNYMzKSvBsTAiU59VIopKWXQm89lNJAAw299I8JJLTpH9En je0Z2ZrmaxMCXS/Ykub3nn567+nprebCpXsxdY4xF4QlHbd6ruI6OBmxMUnCjnvrcFhquY6QKBkj yhLccRdYuJcufv7ZBXReRjjGDsgn4jzquJGUs/PlshjBMBLn2Awn8GzCeIwkdHlYHnN0AnpjWq5V Ko1yjEjiOgmKQe2NyYSMsHOoVLoXV8oHFL4SKdTAiPIDpRobEho7nlbVj1iIgHLnGNGOC/OM2ckh viddhyIh4UHHreiPW754obwWorJANic31J+l3FJgPK1pOR4erQU9z/ca3bV+DaByGzdoDhqDxlqf BqDRCFaacjF1NmuBt8TmQGnTorvf7NerBj6nv76F7/rqz8BrUNr0tvDDYZDZMAdKm/4W3u+1e31T vwalzcYWvlnp9r2mgdegiJJkuoWu+I16sFrtGjJhdMcKb/vesFlbwjNUORddqXwii2ItRncZHwJA OxdJkjhyMcMTNAJcgCg54sTZJWEEgTdDCRMwXKlVhpU6fKs/T7e0R9F5jHLS6dBIbA0pPo4YcTKT HfcqaHVzkBfPnj1/+PT5w9+fP3r0/OGvy7m35XZQEublXv30zT8/fOn8/duPrx5/a8eLPP7lL1+9 /OPP/1IvDVrfPXn59MmL77/+6+fHFniXo6M8/JDEWDjX8Ylzk8WwQMsE+Ii/ncRhhEheopuEAiVI yVjQAxkZ6OsLRJEF18OmHW9zSBc24OX5XYPwQcTnkliA16LYAO4xRnuMW9d0Tc2Vt8I8Ce2T83ke dxOhY9vcwYaXB/MZxD2xqQwibNDcp+ByFOIES0c9Y1OMLWJ3CDHsukdGnAk2kc4d4vQQsZrkkBwZ 0ZQJ7ZAY/LKwEQR/G7bZu+30GLWp7+NjEwl7A1GbSkwNM15Gc4liK2MU0zxyF8nIRvJgwUeGwYUE T4eYMmcwxkLYZG7whUH3GqQZu9v36CI2kVySqQ25ixjLI/tsGkQonlk5kyTKY6+IKYQocvaZtJJg 5g5RffADSgrdfZtgw92v39u3IA3ZA0Q9mXPblsDM3I8LOkHYprzLYyPFdjmxRkdvHhqhvYsxRSdo jLFz64oNz2aGzTPSVyPIKjvYZpuryIxV1U+wgFpJFTcWxxJhhOwBDlkBn73FRuJZoCRGvEjz9akZ MgM46mJrvNLR1EilhKtNaydxQ8TG+gq17kfICCvVF/Z4XXDDf2+yx0Dm7jvI4LeWgcT+xrY5RNSY IAuYQwRVhi3dgojh/kxEbSctNrfKTcxNm7mhvFH0xCR5bQW0Ufv4H6f2+WBVz+nXO0UpZbPKKcJt 1jYB42Py6Zc2fTRP9jGcJmeVzVll83+sbIr281k9c1bPnNUzH62eyUoYfRG0uu7RWuLCu58JofRA LijeFbr4EbD3x0MY1B0ttL5qmkXQXE5n4EKOdNvhTH5BZHQQoRlMU9UzhGKpOhTOjAkon/SwVbcu v+bxHhuno9Xq6nYTBJDMxqH8Wo1DsSbT0UYzu8Zbq9e9UF+3rggo2bchkZvMJFG3kGiuBl9DQq/s VFi0LSxaSn0hC/2z9AocTg5SF+O+lzKCcIOQHis/pfIr7566p4uMaS67ZlleW3E9HU8bJHLhZpLI hWEEh8fm8Cn7up251KCnTLFNo9n6EL5WSWQjN9DE7DknsOfqPqgZoVnHncA/TtCMZ6BPqEyFaJh0 3JFcGvpdMsuMC9lHIkph+lG6/phIzB1KYoj1vBtoknGr1ppqjZ8ouXbl07Oc/sk7GU8meCQLRrIu PEuVWJ++J1h12BxIH0TjE+eIzvlNBIbym1VlwDERcm3NMeG54M6suJGullvReOuSbVFEZxFanij5 ZJ7CdXtNJ7cOzXRzVWZ/uZijUDnpvU/d1wttJM2CA0Sdmvb88eEO+RyrLO8brNLUvZnr2qtcV3RK vP+BkKOWTWZQU4wt1IrOjlMsCHLTrUOz6Iw47dNgM2rVAbGqK3Vv6/U2O7oLkd+HanVOpUgvyO5B +R2sXkymmUCPrrLLPenMOem49yt+1wtqflCqtPxByat7lVLL79ZLXd+vVwd+tdLv1R6AUWQUV/10 7iH8s08Xy7f3enzrDX68KrXPjVhcZroOLmth/Qa/Wit+g+8QsMz9Rm3Yrrd7jVK73h2WvH6vVWoH jV6p3wia/WE/8Fvt4QPXOdZgr1sPvMagVWpUg6DkNSqKfqtdanq1WtdrdlsDr/tgaWtY+ep3ZV7N 6+K/AAAA//8DAFBLAwQKAAAAAAAAACEAOHQscG44AABuOAAAFwAAAGRvY1Byb3BzL3RodW1ibmFp bC5qcGVn/9j/4AAQSkZJRgABAQAAYABgAAD/4QCARXhpZgAATU0AKgAAAAgABAEaAAUAAAABAAAA PgEbAAUAAAABAAAARgEoAAMAAAABAAIAAIdpAAQAAAABAAAATgAAAAAAAABgAAAAAQAAAGAAAAAB AAOgAQADAAAAAQABAACgAgAEAAAAAQAAAQCgAwAEAAAAAQAAAJAAAAAA/+0AOFBob3Rvc2hvcCAz LjAAOEJJTQQEAAAAAAAAOEJJTQQlAAAAAAAQ1B2M2Y8AsgTpgAmY7PhCfv/AABEIAJABAAMBIgAC EQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAA AX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4 OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQAD AQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEG EkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpT VFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4 ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2wBDAAICAgICAgMCAgMFAwMD BQYFBQUFBggGBgYGBggKCAgICAgICgoKCgoKCgoMDAwMDAwODg4ODg8PDw8PDw8PDw//2wBDAQIC AgQEBAcEBAcQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBD/3QAEABD/2gAMAwEAAhEDEQA/AP38ooooA4rxX8RPB3gfUvDukeKdRWwuvFd+NM01WR2E 920bSLFuVSqFlQ4LkAnCg7iAVi+IXg+fx/cfC+HUVfxNaacmqzWgRyY7OSUwrIz7dgJcY27t2OcY INeXfHn4San8WpPDdhZSLbQWD6hI91uxJaXEllIlncRL1Z4bny5BjptzXz9rH7P3xk8T6Fquv6ub O18ZeLdFvP7ZNtcjyTdy31hImnxSPG+YPsNobbeyMuSWZSGIoA+/ReWhiScToYpMbW3Da2TgYPQ8 nFZ97r2m2UkETM873FwtsBBG05SR84MnlhvLUY5dsKO55FfGHhz9n9rC80PXtX8Mytp2iS69qZ0+ /NhO1ve3NvZx2zWtrpsUdsmTBI6pGpKyMZM7348Q/Zk8Eapq8ujTQaVbDXLBvC95qd7ZRpDbfZrB LtXhuHEaSNqW+UvchyWYbCcFeQD9UBc2zCRllQiL75DD5eM8+nHPPaiK5tp4xLDKkiMcBlYEEntk V+ZvjX4I+IPhX8ItN/sbR7GwZ9B8PabrOweZbT6jBq9pNNLfBVbzYBH54llkDDy2ZW+U8ex/C/wL F4p/Zo1Lwx4TsF0bVYtSv9QsZ0jjgs5NXhvjfwXNp5SIPsf2gKseF4iXZ8wGSAfYTaxZrq39jESe eIGuC/lP5IRWCkGbHlh8nOwtuxzjHNXkuIJUEkcisjAMCGBBU9Dn0NfA3iD9n34q614YkndbdNb1 vTvtesRRXEe2a/udat9Tu7BHmjkjaI28bWsbyRmNkVVddhIrK1n9lrxfrnh/TfD3h9Lnw/pniOS/ s/EKXV1arcWti80d/bPapp0cdsm26hZRFGAFW5kbJ5FAH6HvcQRsqSSKrO20AkAlsZwPfHOKwPFn i3QvBOiS+IPEUzw2kckMIEUUk8sk1xIsMMUUUStJJJJI6oiqpJJHFfGWmfB34r/aPBHjXXtCtLvx 5JqMupa1PJNbXWlWpu7q2M0YinTzvMhtbaNbae2KuroA3yMa+gfEHhNL74TT+GW8BpeRS3Du2ixa gsDj/TGmFxDd5XZMGxcIQ6FHwA6sAaAO/wBD8e+F9fmsbK1unttQ1C2lu4rK8hltLzyYZBDIzW86 pKu1yFO5R1BGQQa0PDnirQPFeh6Z4i0K7W4sNYiE9o5BjMsbDIIRwrdOcEZFfJPhn4b/ABN8NeKP C3xH8TeFovGWt6bpesaeJJbq0fU7OKW9SfT0lvJljE0iWoaF5UOS5OSwZpDwg/Z2+IsGhafoF54f sdT1ObQtAsbLWTdIG8NXenSPJcvDuAkOGYSo0HMrjZJtQK1AH3Z4Z8XaL4ss7m90mUlLS7vLOQSD YwksbmS1lOM/d8yJtrdxzW8bu0WJp2mQRIdrPuG0MDjBPTOePrXwz4j/AGbNfl0nXLnw5pFla674 gfx4t7cpKI5bmDXvtJ09JZQNzLloCVJxGVyOQcv8d/s96vaWniHT/Anha2fT5rzTL7SbGBrNbJL2 20+e1llurO7VoJonLIsq48w8SIfMRTQB9ReMfiv4N8B6rHpfia5a2H2CfUppgu+OC3hlhgXeFy5e aWdY4URWaRgQoyK2PC3jrQfF1nLeaet3ZmCcW7xajZXGnTiUqHVfKuo4nO5WBBUEHscggfM9z8PP HvjnTfEXjk2UMHiW11nRf7NsrgvbWs9p4VuUlMKsys8cd1dfanhcqfleFyCBWH8e/Bvxr+M/hhbK 28DWenMbPVLeBZrrT7m/t7uaOEWs/nzRSx28W4SFzbFpwUiKsuW2gH2+bm3VzE0qBwMlSwzj1x6U hurURxymZNkxUI24Yct90Ke+e2OtfB/xO+D0umaR4l8R3nhK08Q614o8caBOELKZb3TY5NPjNvLM Vby4i8MhKN+7J5fhia5jX/2bfHerWtg17obDQZ28RBPD+nXGm79IGrXMUtu0L30E1ujLGj7nt9rw O+ISy5oA/RG61GwsYppry4jhS3jeWQswG2NOWY+gHc1X0vXdG1rTbHV9KvYrqy1ONJbaWNwVmR13 qUPfK88dq+Qbr9nG8u9YvtZl0qyn1DUvEs8899csk1xNo02hNp5jmcrl1aYgvD91j8+3NeZJ+zd4 yu4vB0GpeGpbDT9N8P6bpH2XSrnSon0zULG5eS4vYpJ7eUoLrMcnm2zLPmMB1zjaAfo4s0Lu0SSK zpgsoIJGcgZH4GpK8c+D/wANbTwDb+I9QudMtbXWvEOu6xqFzdRBWmuILnUJ5rXzJPvHbC6gIThO QB1z7HQAUUUUAFFFFABRRRQAUUUUAf/Q/Uz9s/UNQ0z4KTXWm3UtnN/aFmPMhkaN8FjkblIODX5H f8Jj4w/6D+o/+Bk3/wAXX7g/HTw9ofiX4eXlj4g0xtYtoXW4W1SR4mlkiBZFVoypyTwOcZNfAFj4 A+H91az3N18Jr+zaJI3WJ766aSUNIqSbQrYBjBZiGILAAqCCSv6vwZxNhMJg/ZV4Nvmb0Sfbuz4z Psmr4iv7SlJJWXV/5Hx7/wAJj4w/6D+o/wDgZN/8XR/wmPjD/oP6j/4GTf8AxdfYj+DPhIArxfCr W2Qnks90p2ckMF88nnHQ4IyM13nh/wCC3wd13T/t8vgq60tt5Xybu5uUlwACGwJmGDn19QelfWrj nLn/AMupfdH/ADPF/wBWcZ/Ovvf+R8JaN4w8Xtqlura9qBBY8G7mI+6f9uu3tvifoS6ZHFdxa/cX otViMp1qYJ55U75Qo6fNgqOmOCDX21Z/AH4OQ3UcsXhza6ng/a7r095a8vPw7+Ekc19DJ8M9VAsr gRKyy3bLPEXKCaP97yONxHXB79K563GGXTfvU5L0svyka0+HsZFaSj87v9DwA/E3wkkEYig8RmXZ tYnW5VwQR8wPOScegABIxkZqnD8SvDwNwlzH4hlSR1aN/wC25RKihcFfu7cE85IJ6V9pn9nz4MA4 /wCEb/8AJy6/+O0n/DPvwY/6Fv8A8nLr/wCO1kuKct/kn9//ANsX/YWN/mj/AF8j40t/iZ4VW5ll ubfxE8RY+Wi63KAEPGG4ySBz16+3FeYHxj4vyduvaiBnjN5MTj/vuv0a/wCGffgx/wBC3/5OXX/x 2j/hn34Mf9C3/wCTl1/8drejxhl0L2pz+dn+cjOpw9jJbyj+K/Q/OT/hMfGH/Qf1H/wMm/8Ai6/S 39g7VtW1bwx4sk1W+nvmjvoApnleUqDFnALk4FZv/DPvwY/6Fv8A8nLr/wCO19I/AvwL4R8C6Zqt r4S0/wDs+K6nR5V82WXcypgHMrMRx6V4PFvFGDxOBnRowak7bpd12Z6OSZJiKOIjUqSTWvV9vQ91 orx74j/ELV/CWp6fY6fZbo5MSPJJ92YDIMUZGcMOCxxkDGBzkcl/wvHV/wDoBJ/39f8A+N1+JVcx owk4Seq8n/kfWzx1KMnGT1R9HUV84/8AC8dX/wCgEn/f1/8A43R/wvHV/wDoBJ/39f8A+N1n/a2H /m/B/wCRP9o0e/4M+jqK+ZL3436+whNvpcVttlUtud38xe8YygwW7Ecj0PSvpCwuXvbK3u5IHtmm jVzFIAHQsM7WAzyOhrow+Lp1b+zd7eTX5mtHFQqNqHQ/EST4j6Rp2qX8Oux63qF5BfXpdotXmghd TMRGmxeQqqMHBB9/TPtfiL4VEeL0eJWky5ymtOBj+EDK8e5OeOxPNfWnifwtoFn4x1Kzh+EFpq9g ZVZL6J1Xe0mWlLozZyrHHA559gcZPD2hkoZPgfAqOTyJoiVAB5K7gRnsPfnaeK/eI8W4C2tOf3/8 E+IeQYq/xx+7/gHzBdfEfw29uUtI/EUcwdcM2uSEFM/NkbfvY4GOKnuPiZ4ZlR2htvEEMrsnA1uU xooZS4XILZIDDJJ+96jNfUWk+CdNvPEbabqHwk0iy01Lh1N2zls26l9sigE5ZgE+TtuOTxXpn/Cp PhT/ANCdpn/fpv8A4qqXFmAf/Lqf3/8ABF/YGK/nj93/AAD4Rf4l+FxaTpBB4h+0up8tn1uVkR8M BkAAlckEjOTgc9c+YDxj4xxzr+o/+Bk3/wAXX6e/8Kk+FP8A0J2mf9+m/wDiqP8AhUnwp/6E7TP+ /Tf/ABVb0eMsDC9qUnfvZ/mzOpw5iZb1F8rr9D8w/wDhMfGH/Qf1H/wMm/8Ai6P+Ex8Yf9B/Uf8A wMm/+Lr9PP8AhUnwp/6E7TP+/Tf/ABVH/CpPhT/0J2mf9+m/+Krf/XrBf8+X9yM/9V8T/wA/F+J+ Yf8AwmPjD/oP6j/4GTf/ABdd18L/ABZ4rn+JfhKCfXL+WOTVrFWR7qZlZTOgIILYIPcGv0C/4VJ8 Kf8AoTtM/wC/Tf8AxVbPh34XfDKx1/TL2y8J6dBcQXMMkciRMGR1cFWB3dQeRWGJ42wcqcoqi9U+ iLpcM4hTTdRfifZlFFFfg5+ihRRRQB//0f3Q8bgjw3dzJam+lgRpY4Fba0siKSqA9ix4H1r5l0nx R4nv4Lh7z4eXlnLb/Zz5bTsS/mMRLsYqqsYlGTz8xOBx8x+n/F+pWek6JLqGoSCG3hIZ3OAqqASS SeAABkntXk8fxC8HSokkeqQMsnCkSx8kZyB83UYOfoa9LCqfJ7pjUtc89l8Z34G+D4c6yyZB+bCs UOeQoJ545VtpGR16V6B4aW317TTf32hXOiyeYyCC7b94VABD/IxGDn1zkGnTfEHwfbrvn1OGNfMW LJkQDzH+6ud3U9hUp8d+FQ2w6hFuwDjenQjI/i9BXRap5kaG5HommBwRDyP9pv8AGvLm8RXcc+oQ v4G1MrZXPlRup3LcQFygmj59BuKnkA16JZ+KtFu2BtZ/OAOCUwwB98E1iW/xK8EXd+dKtdWgmvRI 0RhSRGkEi7soVByGG1sj2PpTtU8w0OlOh6WCR5Of+BN/jR/Yel/88P8Ax5v8a5SX4peAYJzaza1b RzAZKNKgfGSM7Sc8kED1q+vj/wAJOCy6lEQHaP76ffQlWXr1BUg+hB9DRap5i0Nz+w9L/wCeH/jz f40f2Hpf/PD/AMeb/GucufiR4KsmKXmrQQFQrHfIi4Dlgp5PQ7Wx9D6GrDePPCinadQiyccb0J5O 0d+54otU8w0Nv+w9L/54f+PN/jXa+FLO2s4LhbZNgZgTyT2968stviD4QvIBdWmpwzQsSA6yIVyC VPO7sQR9RXpXgjWNP1uwkvtMlE9vJsZJFwVZWXIKkcEEdDWGJ5+R3Lha5xHxa+LvhT4b3OkWetWj aheXEyTKiqCYIVO15gW43AEhQCCT1IFcb/w1p8L/APn31L/vxH/8drtvjJrXwt0qz0gfEiGK6b7Z E9rEV3upDgPIV/55Kv8ArAQQw4wTgVxf/Cb/ALLH9zR//Bcf/jNeHVlJPSSXr/w6PpsFh6EqSlKh OT7p6f8ApLG/8NafC/8A599S/wC/Ef8A8do/4a0+F/8Az76l/wB+I/8A47Tv+E3/AGWP7mj/APgu P/xmj/hN/wBlj+5o/wD4Lj/8ZrPnn/Ovu/8Atjq+qYf/AKBqn3//AGpj6x+1b8NpreF7XS7y+mhn ikVJoY1CgMAzqd7YdVJK8cnjI6j6g0TWdO8RaRZ65pMnnWd9Es0T4K5RxkcHBH418s+I/Gf7LMmm gC0sLoLNAxjtLIxSkLKpJz5a5UDl1z8ygjnOD9V6Xe6dqOnW19pEsc9lPGrQvEQY2jI+XbjjGK3p Sb3kn6f8OzzcyoUoRi6dKUN/i67baI+Z/FOq+NtN8R3FnoXgeLV9NDoVuftcULvlWaYbHOQQ20IS MHDZ7VRs9f8AGzTwRaj8PVt42eNJZBfRMAHkEbOqqpJVA3mNnGFB6naDwvjuD4I6x491CPxDqN5D r9y0MVxbW87q8gCgQoFRSwDAKcKRuON2cVladYfATQ3uoodfmilcSwTrc38bOCsuWLrMDhRIhPI8 tiTkMCK93kqHgNo9JGtfElICj/DqKS4RMGRb6NYmlwW+VcM2zoMk5yemBmrSax4+NncTyfDxElgC bIzfRZm+dVfbgELhSWGSc4I9M+Z3dv8ABi3uIIbnxfqUMs3lSpjWColSaUrGRtIXYXjYfLgcHPXN bGg3vwk0rVLLUdO8W3crQyeZDBNqySRMxUrgo5yRjPBNPkqBdHQX+s/FWHUXisPAFpPaN5Zic3aB lUpG0nmEsBlSZFUKDuIU8Ak0/Ttc+Jptbm51j4dwpKkStDbwXkTF3MqoVaVn2rhCz42ngdcnFbTf HL4YobtZNdtkaxJE6tKitGV6gqSDkdwOatn4x/D7ZK66vbyGEbnWOVHkA3Kmdikv951HTqR60ckx XRzN1rPxSMXm2fgC0jKzmNkkvEkbyggPmqVKBsucBeDtHPNWZNa+Idvb6e3/AAgMN7PIsxu1hu0i WJg+IlQyfeymCzcjOQDgZro4/i54BmGYtYtGG5U4uIfvMcKv3+pPQV1H/CS2g4MUn5D/ABp+zqBd HmsviDx+AXt/hqJFUhcNqMCMTkAsBtPy455Ib/Zr0XwWNR1BEuvEWhRaLeR3IVIUlFxmMbSr7wFH JJGMdql/4SW0/wCeUn6f41b0/wAQ2s1/bRLE4LyoBnHdh70pU6lgUkeyUUUV4x0hRRRQB//S/cnx /Z2194YuoL2RIrbBMzSHagjAO8kjGBtzk54r5JHwo+Bd3bwSEaK8RVxFunx8pYBhtZwfvKAQRkEY 9q+vfG8U0/hfUIba2jvZpIZFSCXiOZijBY3/ANljwfY18Up4Q8XyQ3Uknws0JNTeNFV2YGObepW4 DyiUvyoVVZuWJYn39HDVWoWMpxVzZ0X4XfBSxs5/DemXelyxkeZPC12XZlQO2ZAX5VVdgc8bSQ3H FbGm/A34Watp8N3pOnWN1ZFXjieIyGParFWCENjAZTyO+T3zU3w1+HNhFaala+JvAljocZaQQmOX zzMlySbgH947IpYAqu7GCOAwwPc7DT7HSrKHTdMgS1tbddkcUY2oi+igdBXQq0jPlR5/4b+GGi+F fMi8O29vp8c7KzpErBWKLtXjOBgccVw58F/CzRdZbxCLjT7PUoXuJmnV3Vlc5E7kA4BJbDkjkkZ5 xX0PH98V876noevDWLua2+Gdndh55XS4/tNUEy+Z5gMkZX+NgGKYK5xnpw3XkCiiGLwZ8H7y5t7y K90h7sRJDHL54WdUtioX5t4dShUYY4YHvknNe9+GXwYvLm8ur3+yLmfUiDcOZPNaUyNkZIY9Tzxj gegrQ8IfD2w1C9uo/Fvw307SY3DSPcC5FyZZsqoCryQCoySW656lia9Kg+GXw9tRci18PWcP2wqZ vLj2b9gIXOMcAEjHQgkHgml7eTDlR5NL8MvgveGKylm0aX7Oiqkf2oEKjF2UbfM6Eu+Pr7DElr8L fg6slpd2X9ktIt2GgeObexugwQYw5LMDgAc4r02T4T/DOWFraTwzYtE4UMphGGCtvGfX5uee/WrE Pwy+H1vqVtrMPh+0W+s3EkM2wl43BJDKSTzk9etP20g5Ueer+zv8OFkEo0Oy3BmcZEhG5wQTgtjJ yea+hPhx4ft/DWkNpVmFS2gEccSJnCIi7VXnngCq1dV4d/1U3+8P5VhiKjcGmVBanH/E34beCfH0 GnnxUFgmtriJYZw2yRt7jMGeCVl6YByDyMEVz3/DN3wd/wCgG3/gVcf/ABytr4leAdS8YTafc6fe bPs7hHhk5jVWb5pVAx86jtnkDAIPXi/+FFah/wBBxP8AwHb/AOO185XnU53y0eZd7r9ToWbYyn+7 pOXKu0rG1/wzd8Hf+gG3/gVcf/HKP+Gbvg7/ANANv/Aq4/8AjlYv/CitQ/6Dif8AgO3/AMdo/wCF Fah/0HE/8B2/+O1l7Sr/ANA/4xK/t3MO8v8AwMdrn7OHwcFiB9kbSt80K+eLmUnmRRsHmOVzJ9wH GRnjnFe+aVpWnaHp1vpGkW6WlnaII4ooxhUUdAB/nPevnS/+BmsrAPsupw3Tl0BR4mRQpYBmzvb7 oycY5xjjrX0TpFg+laXa6c9xJdtbRqhllOXfaOpNdWFlNt81Pl+a1+4l5jia3u127La7ufMet6J8 PZfEc1nqbW02rXMywlTaebMz/JIoyASdqlGznCgZOADjhp2+AztdzSXGnXE9ypnnRLHzp5RuzlkV Wd2JwQMFjxgdK+gLzRvDF1qbandWNlNeq4PnPFE0oZCNp3kbsrtGOeMD0qpbeG/B9lJFLZ6dYwSQ Mjo6Rxq6tHnadwGcrk454zX0vtZnK0jz/T/ht8PPEdml/baZaTwxtNApm08RsCjski7ZVVtpYHth uoyCCdH/AIU/4KDO66ZZo8pVnZbVFZijK65IweGVT+Ar083Nuesyf99D/Gk+02//AD2T/vof40e1 mLlR5rJ8JPBs1xLdy6ZZPPOXMjmziLOZc7yx7lsnOeuTnqaq/wDCl/Av2pr0aXaCV7c2jYt1CtAX EmxlB2kbwGGQSD0r1T7Tb/8APZP++h/jR9pt/wDnsn/fQ/xo9rMfKjy2X4NeBppYp5NJsjJAyujC 0jBVkxtwR6YHHTiuu/4RhTybk/8AfH/166T7Tb/89k/76H+NH2m3/wCeyf8AfQ/xp+2mLlRzf/CL r/z8n/vj/wCvVzTvDiw6hay/aCdkqNjZ1ww962PtNv8A89k/76H+NWbO4tzdwASoSXX+Iev1pSrT sNRR6TRRRXinSFFFFAH/0/2z+LUq2/gTUp3uTZLHGzGdesIVGJkGAeV69D0r884PG14uny6k/wAV BJaxRxiZxpRG0T7hC43BmHCk55LAbmJBBr9JvHSwHwzeyXFo98kKNJ9njGXm2KTsUdy3QDuTXyku qeDYpmkh+GupyzLlWkt7BPLZj2VpDEzKezMg45IGa9bB1lGFmc9WF2cJ4TvPEfiiDU49C+IMWoy2 ojjONPRWtmkYOpcPhixRWXB6ZORkcex6TaXGn6XaWF3dPez28SRyTyffldVAZ292PNc9B4s8LaPC X0r4f61axbgJzHYiAIMkuThhu25LEjg5OCTxXs1hpek39jbX6W0sK3MSShJCVkUOoYBlzwwzyOxr tjioGLpM5CAnzk+v9K8ln8K/Exr64ksvGgt7Kad5EiaxjmeKNi52CR2OcblAOMAKAB1J+l4tB0wS KRGeP9o14VqnxCn0y81CzHw/1if7E9wqOm4rOsG/ayEKR+92jYCcnd7Gm8VDzBUmYjeGPiOliltb +MQs/mSu0sllHIcSFSqgHAwmGAz2OOwxSuPB3xOmiMaePZEORhhYW6tgcnkAcnp0xjtnmu6vfiBo lnqMmljwf4guJ49ufJtCyYY4B3F1GM5GTjp71Y1LxvpemS7JPBniGdSiOHhtRIpLReYV/wBbkFfu nI+9wM9aX1mHmHspHms/gn4o3kbQXPjxkUOskb29nHC6lGJ2HafnRlJDZPUAjvVe28BfE2CZHl8d STx7SGVoTywYOjD5yeqhW6blLdCa7qb4o6DZSWkOqeDtftJL2Ro4gbbcCUQyNyH6gDoM5PC5IONv V/Gmk6bqjada+FNa1CONhuuILZzCYygcOjZ+YHIGOMc5xjFL6zT8x+zkZvhnS9f0uO5Gv6p/aksz IUYKyBFVQpUKWYckbiRjJPPavoH4b/8AHpff9dF/9Brw/RPGNlrOr2mjN4P1qxe5lMbTXEJS3jUK 7bzJuOQdoAGBywGcgivo3wnY21lBcLbKVDMCcknt71hjMRGVNpF0qbUrs8X+OXj34oeEtb0Cz8E6 Sbi0upMmQIZvtE4DYtiq4ZRtG/rlscHAYHgP+Fw/tKf9CGP/AABuv/jlfWfiDxN4c8NizPiG9hs/ ts6wweawG6U88Z6Y6k9B3NM/4TLwh/0HLH/wJi/+Kr5+dGTd1Jr7v8j6LD4+nCmoyw8Zeb5tfuaP k/8A4XD+0p/0IY/8Abr/AOOUf8Lh/aU/6EMf+AN1/wDHK+sP+Ey8If8AQcsf/AmL/wCKo/4TLwh/ 0HLH/wACYv8A4qo+ry/nf4f5G39p0v8AoGj/AOTf/JHxrrXxl/aLiWyNz4UOm7rqFUK2c6+e7HAg O92GJOnHPcEV9w6bNe3On21xqNuLS6kjRpYQ4kEbkZZN44bB4yOtcxqPxB8B6dHDNfa5ZBXljiUi ZHw8h2r90nAycE9B3IFdoDnkVrCm47tv1t+iOHHYqNRR5aShvtfX72z4s1rwnqN74pk1dNcnhtVu RKbMKfLOzaNpIdTglN2MfeJzkZB46H4W6oWVdQ8XaldW7BY5IBI0KmPJLhXjYOrNnhw2V5x1r1zx BfeNrTxXdWOl+D4LvRleIrfGf52D7fNPkggkoWPGeQprKuPEPjeC4vYY/hxJdR2skgjlS8jRbiMO VQxq2WBK4Ylsd8Kfl3fS/WYdmeE6bLGl6XbaRafYrRpXj3ySZmleZ8yuXb55CzYyTtGcKMAYAArR wKx7/wAReNbee2+xfDaW5gmjRpD9shV43DuJUwWGT5YQxsQAWYgkY5dD4l8W+Zsu/htcRqjIrut5 EwO9gmUAySBuyc4wAx7DdX12PYXsWa2BRgVU0bUvGt34pOla14ISw0gTTRi+W5WUOkYbZJsBBVXI GMgnkcDnHqX9kaZ/z7L+tP65HsL2TPOMCjAr0f8AsjTP+fZf1o/sjTP+fZf1o+uR7B7JnnGBWjo4 H9rWX/XeP/0IV239kaZ/z7L+tWrHS9OS9t3S3UMsiEHnggipni42eg1Sdz1OiiivnDuCiiigD//U /dXxjZyah4dvNPiuHtJLqN4lmj+/E0ilQ6/7Sk5HuK+YNU+GfxUkmm/sP4mXdnb+QqwxyWqSbJQW DZYnOwqRjOWBGc9a+jviJfahpvha6vNJiE95HzFGSAJHAJVMngbjgZ7V8pp8TfjAo8uXwS7sqOxk F3AiuVGVCoQzKWGBhjw2QTgbq9LC0XKFzGpKzO3T4ceNwEL/ABI1ZnDZf9zbgMvPAG35evUc8V6N 4d0q80XSIdNv9Sm1eeIyFrq4x5sm92YbscfKDtGOMAcCvnGz+LPxlv4pJU8EPbAtJFH50yBvMjOM um1cI/JVw2MY5Pe1B8UfjLsZrvwK6lCoKpeW5J+UBsZ/28kHptx3rp+rv+rkc6PqKP74r5S17xRp 9r4huraP4oalZIslz5ltHpzziI+YVIDiMhUjwQCe+CDjIPonhPxv401i5mi1/Rn0TyljZC0kcwk3 7wVBVRgrtBbr95ec5A891H4j/HC1u76Kx8H29xEjT/ZpBKn75E3mItyMGT5c8Hbk5xxkeGkCmiO5 8d+HhFcsnxI1b57PyVt1sJPMiIiWMzFWQPvZvnUswySQpJyaiPiDT7Owsopfizqrx3abo3TTy0zo rNFhSEJB8yNgflJJyOm0Dorv4jfFW3umhg8F+ehyFl+2wIDgZ+YGMkZJ4xnjvnAOXa/Er4tLE8Z8 BeQ0JfZtu7cKRvbbtATrjBOdoOTyOcL6tL+rhzozbDxp4fS7gu2+LOq3KwTgsJLBlgYEhhG5WJV+ 6dvJ9eMjjoNC8e+F/C01trOsfEC91XTriO4VIHs5Gg3oSS3mLGzDaEOAx56g4PNT/haHxYjtbh5P BDGe0eINGlxCRMjK5cxMV52kLjPXdggGr158RfiYlw9vB4LN1Z7YeTcwKW81R5o2MmDs3EEd8N2o +rS/q4c6Oxm+PfwvhSST+1ZJEQEho7ad1YhN+0MEIDYGMMRzxXu3gHWLPxBocWt6fu+z3irIm8bW A5GCMnkEepr5q0Dx38QtQSNdU8KjSYy8KhWuYJCkbg+YxVUxmPgbQTuB6jGK+ivh7cy3FldK+0LE 6qoVQoAx0AAArHE0ZKDbKhJXOP8Ai18D9J+Kd/pep3F7LZT2REUpU7hJbE5ZVVsqrg8hsc9GB4I8 /wD+GP8A4f8A/QV1L/vqD/41Xf8Axg+Ndl8KZ9Ls3sJb2e/cO+BtRLdGAkKscK0nZVzx1bjAPmv/ AA2L4L/6Al//AN9Qf/HK+frew5vftfzPr8vWbOjH6tzcnS22/wDmW/8Ahj/4f/8AQV1L/vqD/wCN Uf8ADH/w/wD+grqX/fUH/wAaqp/w2L4L/wCgJf8A/fUH/wAco/4bF8F/9AS//wC+oP8A45Wf+y/3 fwO3lzz++Mv/ANj3wkYoxpes3kchkTzDN5Tjys/vAAsa/MVyFJOAeSCOD9X6RpVpoelWmjWAYW1l EkMYdi7bEG0ZZsknA6mvkXUP2xfD3kA6VoV004dMiZ4lQx7h5mCrkhtudvGM4zxX1roOs2niLRrL XbBZFt7+JJoxKhjcK4yNynkH/I4rooey19lb5Hj5wsfaP129tbX+VzjJP9Y/+8f50yvmnxf45+Km meKbux8O2+n39nuIjW4vFt5E+Tdl/mLctkY2dNuCcsVbceMfjcht4rfQ7KWRk3TMb4rGjGQgBSV3 NhACeOvQ9q+k+rs+Y5j6Yor5al8Y/Hy3Cquh2F25Zlyl55aEBchvmJK/MCuOeoOeTt0tI8VfGyS9 hi1nTLCG2Zh5kkd2xKqeyrg5IPc9R7nCn1dhzo+k6K+bL7xV8bI7kLYaXp80IihLFrxhmVgPNCna DtUkhSVG4DnFNt/Fnxvks7mWfSNPiuAmYIvtrMCwPIdguBkdCOh65o+rsOdH0rRXy5D40+PckSyv 4e09Cd/7s6gQwIYBcnaRhhk+vHIycBJfF3x/+RY9H00FwuT9sZhH13dcbieAMDA5JJ6UfV2HMj6k qxaf8fUP++v86+bNM8VfGSeadNV0mxtYwFMTJfNJuO9AwbEeR8hcjA6qATg5r1TStU1B9Us0a4cq 00YIPcFhQ8M7MFNH0HRRRXhnUFFFFAH/1f2++JunRar4K1OyuL9tLikhkD3anDQJsYNIp7FB8wPb FfG1p8Mfh7dWsGnW3xGv0uJGW3YHUDHLJLEwV1aKT5kZm4IwCCQB1wftnxzeWFh4cubjVUV7MAiY OAUMZB37geNu3Oc9q+WbHx1+z4l3ZazZNo0d3tQ282YFmAfDptLYYE5Bx1z9DXp4Tn5NDGpa+pzV /wCB/hdeahdS3HxElSZyZmRNWCKgcl/lAbB4zwckL7HJm074S/DrXfJ0nSvGt1eHywyW0eoh2Kxs GMgTluMLzjAHTAJzrr4l/Z6itY9Sg07SzbmRlE0VvGyowaNWZnRTsXLx/MxAO5TnkGtzQPGfwYtt VjPhaDTxqEziFWs0jaTcwYAFowSAQGGTxnIJya6v3hn7p0HhP4V23hN5vsmq3d4bkqWN5M85GzON u44Xrzgc8V5G/gv4X6xq2o6VH45uzqU99JLMI7p0khmt/NMkSNtxHGi7wwBwAvXufo+LxLatIoEL 8/T/ABrx7/hPPgL/AGtdXkn9lQ6lbTTwTvIIopVlbckysXwfm5D9mHJyOab9qC5TD8EaF8PfB9zq MFr4/wD7YuZkkndbm8+0LFBGWm/dqGIARX5IySoz2NdoPFHgH7LHenxPaLBKZQjsGVWMKo7gbsZK iROBz8wA54rCs/GHwC04T2unWulWwtYCzJDFCo8gweeSiqPmQwsWJUEbSfpVPTvG/wCz5rT2Hh7T 7GwuftNwHtYDajYbiVSQyhkADuIic8E4B9KSlV2C0TsbfX/At1bxXMHirT3jnZET96oYs7+Wo2lt wy/y8gc12n/CLyf8/I/75P8AjXjx1/8AZ6tHuL1NN0kNCInlljhibAafy0JZQek2P904JxgGurv/ AI9/DLTjEbvV48TxPOjITKrRRuUZgyBhgMpU89eOtPmqitE7b/hF5P8An5H/AHz/APXr0PwTprab bXSNIJN7qeBjHFeGap8cfh7ouqpoWp35g1CRYnWDY7SMJwTHgKp5fBAHUnjGSK928GalFqdtcSxI yBWX73XkZrDFObg+Yuna+hzXxN8W/DHQ5dH074gtDI81yk1uki7zC0WT5zd1QEbSf4s7cEZrD/4W n+z/AP8AQU0r/vwP/iK5r4+aX8Hm1LQdR+IUrQXzTLEBASJJbXJD+bs+YRRk7gw5B4XOSK82/sv9 jz/n+P8A39vv8K8GpVmnZNfefVYPA0J0oylGo3/dimt+h7d/wtP9n/8A6Cmlf9+B/wDEUf8AC0/2 f/8AoKaV/wB+B/8AEV4j/Zf7Hn/P8f8Av7ff4Uf2X+x5/wA/x/7+33+FR7efeP3s6f7Mw38lX/wF f5nqeu/E39na5t7e2vJ9PvoZbmDKxQD5Crhlkf5R8isAW68dQRmvoyGWGeJJrd1kikUMjKQVZTyC COCCOlfAmvab+ybHbW82nX85aO5hMqQNdO7xFwHB83gLg5Yj5toO3nFfdeiHSG0eyOgGI6b5KC28 jHleUB8mzHG3HTFa0qkpfE18jy8zwtOmo+zU1v8AErdtv1Phz4j+G/gIni/U7jxvcyR6qwWS6Krc KGjjQMpYxEBljQqxA4HylhnbXcXPjb4d2WoTaPdazImpW8cErWrW8nnlbhQ6FVxljtOWx071T8Z/ Gj4c+G/EV3pviLTPMvbX52f7OspIUB8qxXcxVSDhcnkAAniqEnxt+GVnqraV/ZIGpwQ27pFHbxs7 RzRhkEcigxkKh5+cADgZr6JOov6R883E9m/4ReIcG4YH/dFH/CMQ/wDPw3/fIry2f9ofwTbwajM8 dyZNKcpcxLDIZExOIN2Nm0guwI5yV5xwaxP+Gp/hsWEYF0zsSoVYXb5lUMwyAR8udrc4DAqeQafN U7/kLQ9t/wCEYh/5+G/75FH/AAjEP/Pw3/fIrzm4+PHg63itJWJY30UM0Kq6Ess7MiDJIUHcpDfN gY5OKjT4/wDghm1KOVpYZNJL/aVeKXMYSUQg/LGQQzkbcEkg5x1w71f6sK8T0r/hGIf+fhv++RR/ wjEP/Pw3/fIryOX9pj4Xw28l22ofuIfvyeVOEHy7/vGID7vPXkA4zUsf7R3gGXTZtTj+0MkTrEE8 iUSSSSB2RUUoMlghIPTkZIzS5qnf8h6Hq/8AwjEP/Pw3/fIq5p3hyKHULaUXDEpKjY2jswryTS/j /wCFNY8QnwxY2V698ly9qwMLBFeMuCxbHCfuz8+Mcj1r1jTvEgm1C1i+z43youd/TLAelD9q0/8A gBeNz2uiiivBOsKKKKAP/9b9x/iFHp7+FL6TVnCWMCNLOSnmDyo1LPlOdw2g8YOemDXx/az/ALNk pl1CC+0cF3dWdrRRuJYliNy8gk9Rwe2RX2h4uj1GXw7erpNst5eiJzDC/wBySQKdiv8A7LNgH2r5 ri8MfGkqkj+G/DMAR1/dJFIxZcLltxACkfMAoHp8wGTXfh6zjGyZlOCbKOk2PwY1S+tdC0W+0m5u ZsyQQQwREnamCVAGAQi+xwPau60/4beG9J2HSrW2svLzt8i2jj25GDjbjGRXG2Wg/Hm3lM9t4a8N 2TIzNuRZBJK2Su4lVAXcoByDk5wdvOPYfDll4zfTQfFlpbpqG9siyEhh2cbeZPmyOQfXrxnA6Vip dzN00ZkXhiNZFP2k8f7H/wBevBdS1/4DWt9qP9pXNobq0e4ju2bTSzbrfcJwW2Hft2EMRnsO4z9W JYXoYfuHH4Viz+DdLupXmudCt5pHzuZ7aNmbOc5JUk5yc0PEy7h7NdjwebUvgfp946XGt6Vb3cUf ksGiQSCMJgp0yVCcEDgDj2rOsbn9n6+uE+w6po/2kzLsCwRpL5iuURhwGHzAhW6EdDivo5/CtlJI JZNHhZ1zhjboSM9cHbUKeDdLjLGPQrdS5y2LaMZOc5OF555+tH1mXcPZrscQPhh4YRpiLO2BnyJP 9Gj+fO3Ib1HyLx7CmzfC7wpcwRWtxY2ksMC7I0a0iZUXJbCg8AZJOB3Oa9S+wX3/ADwf8qPsF9/z 7v8AlT+sy7h7PyPMD8M/DJTy2tLdgYzEd1ujExnqhJySvt0r1rwTpaaXa3MUb7wzLjjbgAYxVT7B ff8APu/5V0mhQTQRyiZChLDGRjtWGIrtwabLhCzOG+Jfw98AeN5NJbxgqx3EVwiW7htkkozuaAkY JRwDnnK9QRWB/wAM9/BP/oCJ/wCBc/8A8dra+IXw2n8Y6lZahbXvlbMRSpIC6LHknfGvA3ZxkZAI xzkc8n/woK3/AOgwP/AUf/HK+drzqcztRTXe6/yNlmuMp+5Tb5VtaVjS/wCGe/gn/wBARP8AwLn/ APjtH/DPfwT/AOgIn/gXP/8AHazf+FBW/wD0GB/4Cj/45R/woK3/AOgwP/AUf/HKy56v/Phfev8A If8AbWP7y/8AA2Qa5+z/APBBbeCJrUaY09xCiyJdSlmO4HyxvdgPMAK5xnnjBxX0Fp+n2Ok2MGma ZAlraWqCOKKMbURFGAABXz1dfAWVPK+xapHJukCyb4Nm2M/eZcMcsOw6Hua+hrC0WwsrexSR5Vt0 WMPK292CjGWY9Se5rqwrm781NR+ad/uSF9fxNbSu3ZbXdz5R8TeMvAPh3xJqGja219Hc2aid3jtT OhRhvypjVm4z3A5B/HPs/H/wvvLe5u7K5vXhsk3u62M2NquIjsPlfNtJ5C5wOelfSL6VqBdyITgk 9x/jTf7K1H/nkfzH+NfRfWpfzHO6a7HzJF8UvhJLGJ01C98uRyhf7DPt3LwwY+VwR3z0qKT4qfCi BIwLjUMSKhiX7DKm8OCcKGjXgBSWPAHc819Opo19GoWO32gEnA2gZJyTx6nmnf2TqP8AzxP5ij61 L+YPZrsfOmmeMvhbqks9pp8100lpG0rp9gmBChlDhR5XzEM43BcnqexNR2XjvwHfeJ/+ES8rUYb6 S8ayBltgI2dGdd+4ZxFuQAOwAJdMdePpD+ytRznyjn6j/Gj+ytR/55Hn3H+NH1qX8wezXY+aPE/j b4daM8en6ta6jdLfwyuB9hzG6Ru8MgfzQoUfIx+fAKDdnbS33j/4XaI5s7mW7hWBIgmy0YxksDtj TahG5R24GDkZGa+lv7K1Lp5R/Mf40f2VqP8AzyP5j/Gj61L+YPZrseXeH7fw74lsBrGkSzGIu8RM kflSBoztZWV1DDB9a6jT/DtpFf20qySEpKjDJHZh7V1H9k6j/wA8T+Yqa20u/S4idoiArKTyOgNK WJlb4gVPyO1oooryToCiiigD/9f99bqSaG1mmtoTcSojMkYYKXYDIXceBk8ZPArxxfjHcQPNaal4 L15Lu2YrKltai5jG3qVlDKsn/AN2egyQQPY7q3W7tprV2dFmRkLRsUcBhjKsuCpHYjkGvI9Q+F/i AThvDXjjVdLtmhMLxTOb7O7rIsk7F1fAAUg4XnjJJoAjn+M0MFxbo3hPXjBcW0Nx5gsSSjT9I3UN wyj7/OF79CQS/GrT45GSPwv4glCZLMumvjA4OOeTu45x6jIxl9t8N/GtvaXtm3xA1GVZ7ZoYC8MW +B3x+83/AH3IG4LlgRu6kqpBo/wz8Wafctcah481LUVWS3kjjdVRF8loyQdpywkRWRgTg7y2N3NA GmvxQSWe1tY/DGtiW7h8757PakXLqFlbcQrEr0G7gg9M4w5PjSsWjS6q/g/XvMjkihEAsiZGd1kZ iOfuJ5eC5wMso7nCab8OviQdFFnrnxDu5L8yB2nt7aGMABXUoAQeCWVvbbgdSaW8+GXj27s7K2X4 j6jbva+aJJIreENMJCuAc5GVAIB5OTkY6UAXbb4xWl0sjx+FvECiGCa4cPp7K+2FdwVVJy7vghUX JyCCAcZNH+LUuuXtvplv4R1u1ursTvGbu1+zwBY1ZozJKxIQy7QApG5SfmAxUEPw48eR2ssUnxDv muJp43aYW0QKwJ5mYY1Ysq7t65fBb5B+Ecvwz8eGBPs3xF1CK73uZJTbxOroz7goib5FIA2grjjP HPAAyb41rbRlp/BviFnWZYSIrLzATgl2BDjKLhvmx83GM7hVrwt8YrfxnfS2OheHdUj+zSFJ5LyE W6R+WQJRnLZkTcMIOW9hgmrrPwy8e6vqEl0vxGv7O3cjbBBbxoqLiPIDBgTkoTk5xuIHykgt/wCF ZfEJLdoYPiVqCERhEZrWByD3Ylslj6c8E9xgAAm/4XXbCZLZ/BviVJZCoCnTsjLBiPmEhUfd5OcD IBOenqWgazH4g0i31eG2uLNLgMRFdRmKZdrFfmQ9OmR6jBryu++Gfj2XUGvNM+I2oWUPkLCsP2eK ZAQu3ed+SWz82euTgkjAHrGiWV9puk2tjqV82pXUCBZLl0CNKw/iKrwCfagDUooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooA//2VBLAwQUAAYACAAAACEAe0O8XcQGAADPIAAA FAAAAHBwdC90aGVtZS90aGVtZTEueG1s7FnNixs3FL8X+j8Mc3f8NeOPECfYYzubZDdZspuUHLW2 PKNYMzKSvBsTAiU59VIopKWXQm89lNJAAw299I8JJLTpH9Enje0Z2ZrmaxMCXS/Ykub3nn567+np rebCpXsxdY4xF4QlHbd6ruI6OBmxMUnCjnvrcFhquY6QKBkjyhLccRdYuJcufv7ZBXReRjjGDsgn 4jzquJGUs/PlshjBMBLn2Awn8GzCeIwkdHlYHnN0AnpjWq5VKo1yjEjiOgmKQe2NyYSMsHOoVLoX V8oHFL4SKdTAiPIDpRobEho7nlbVj1iIgHLnGNGOC/OM2ckhviddhyIh4UHHreiPW754obwWorJA Nic31J+l3FJgPK1pOR4erQU9z/ca3bV+DaByGzdoDhqDxlqfBqDRCFaacjF1NmuBt8TmQGnTorvf 7NerBj6nv76F7/rqz8BrUNr0tvDDYZDZMAdKm/4W3u+1e31TvwalzcYWvlnp9r2mgdegiJJkuoWu +I16sFrtGjJhdMcKb/vesFlbwjNUORddqXwii2ItRncZHwJAOxdJkjhyMcMTNAJcgCg54sTZJWEE gTdDCRMwXKlVhpU6fKs/T7e0R9F5jHLS6dBIbA0pPo4YcTKTHfcqaHVzkBfPnj1/+PT5w9+fP3r0 /OGvy7m35XZQEublXv30zT8/fOn8/duPrx5/a8eLPP7lL1+9/OPP/1IvDVrfPXn59MmL77/+6+fH FniXo6M8/JDEWDjX8Ylzk8WwQMsE+Ii/ncRhhEheopuEAiVIyVjQAxkZ6OsLRJEF18OmHW9zSBc2 4OX5XYPwQcTnkliA16LYAO4xRnuMW9d0Tc2Vt8I8Ce2T83kedxOhY9vcwYaXB/MZxD2xqQwibNDc p+ByFOIES0c9Y1OMLWJ3CDHsukdGnAk2kc4d4vQQsZrkkBwZ0ZQJ7ZAY/LKwEQR/G7bZu+30GLWp 7+NjEwl7A1GbSkwNM15Gc4liK2MU0zxyF8nIRvJgwUeGwYUET4eYMmcwxkLYZG7whUH3GqQZu9v3 6CI2kVySqQ25ixjLI/tsGkQonlk5kyTKY6+IKYQocvaZtJJg5g5RffADSgrdfZtgw92v39u3IA3Z A0Q9mXPblsDM3I8LOkHYprzLYyPFdjmxRkdvHhqhvYsxRSdojLFz64oNz2aGzTPSVyPIKjvYZpur yIxV1U+wgFpJFTcWxxJhhOwBDlkBn73FRuJZoCRGvEjz9akZMgM46mJrvNLR1EilhKtNaydxQ8TG +gq17kfICCvVF/Z4XXDDf2+yx0Dm7jvI4LeWgcT+xrY5RNSYIAuYQwRVhi3dgojh/kxEbSctNrfK TcxNm7mhvFH0xCR5bQW0Ufv4H6f2+WBVz+nXO0UpZbPKKcJt1jYB42Py6Zc2fTRP9jGcJmeVzVll 83+sbIr281k9c1bPnNUzH62eyUoYfRG0uu7RWuLCu58JofRALijeFbr4EbD3x0MY1B0ttL5qmkXQ XE5n4EKOdNvhTH5BZHQQoRlMU9UzhGKpOhTOjAkon/SwVbcuv+bxHhuno9Xq6nYTBJDMxqH8Wo1D sSbT0UYzu8Zbq9e9UF+3rggo2bchkZvMJFG3kGiuBl9DQq/sVFi0LSxaSn0hC/2z9AocTg5SF+O+ lzKCcIOQHis/pfIr7566p4uMaS67ZlleW3E9HU8bJHLhZpLIhWEEh8fm8Cn7up251KCnTLFNo9n6 EL5WSWQjN9DE7DknsOfqPqgZoVnHncA/TtCMZ6BPqEyFaJh03JFcGvpdMsuMC9lHIkph+lG6/phI zB1KYoj1vBtoknGr1ppqjZ8ouXbl07Oc/sk7GU8meCQLRrIuPEuVWJ++J1h12BxIH0TjE+eIzvlN BIbym1VlwDERcm3NMeG54M6suJGullvReOuSbVFEZxFanij5ZJ7CdXtNJ7cOzXRzVWZ/uZijUDnp vU/d1wttJM2CA0Sdmvb88eEO+RyrLO8brNLUvZnr2qtcV3RKvP+BkKOWTWZQU4wt1IrOjlMsCHLT rUOz6Iw47dNgM2rVAbGqK3Vv6/U2O7oLkd+HanVOpUgvyO5B+R2sXkymmUCPrrLLPenMOem49yt+ 1wtqflCqtPxByat7lVLL79ZLXd+vVwd+tdLv1R6AUWQUV/107iH8s08Xy7f3enzrDX68KrXPjVhc ZroOLmth/Qa/Wit+g+8QsMz9Rm3Yrrd7jVK73h2WvH6vVWoHjV6p3wia/WE/8Fvt4QPXOdZgr1sP vMagVWpUg6DkNSqKfqtdanq1WtdrdlsDr/tgaWtY+ep3ZV7N6+K/AAAA//8DAFBLAwQUAAYACAAA ACEAP4W4cSICAAAoCwAAEwAAAHBwdC90YWJsZVN0eWxlcy54bWzkVt9v2jAQfp+0/8Hye+okhJYh QgW0aJO2PXSs707sgFX/iGKvUE373+c4AQJLq3UlEtJeiE3u7vvu8905o+uN4OCRFpopGcPgwoeA ylQRJpcx/L6YewMItMGSYK4kjeET1fB6/P7dCA9Nwr+ZJ04/awNsFKmHOIYrY/IhQjpdUYH1hcqp tO8yVQhs7LZYIlLgtY0uOAp9/xIJzCQEhGYx/NmfhWE/iibe1e3tpRf1otCb+tHAG/SnN7MP85tg 1pv8guMGtuVmfz+Rv3auHL5iYXP5Qgn7IUAVKAQemKQplQYEDmK9UpwuEu7g0sXGmZWbTElzRzPA yCaGgklVOPu80GbGC/CIeQwTjtMHiMYjtLMvbZwsdGdFHoLa5gDApI3llBTlgtPMuKcEa3tO4ZVv TyoVuc1cy6UjoBVnZM64Y3yExM0WqWGFynDVo45esOWqQ5hdeKPy7lDq4IkyRonuYPbxmdSM0I/d QTUAquV911j3dVXW1ZdtQ70QF7vmqXrHMNtG7l/b45Zejbd1aEGvEBxmXfzosAUTO4MCJ8Fxe6C3 MYzewnDPqlyFz/Fr8apsnb87zbPLyrFyTJ/j15ZVVZnYjkJ1ODlBEkMlHcvTDdB9Lb84QF+tZVt/ tCrVyDRjJf//IutmqqUCd2p9Nln/cb30BsHpr5d/HY6vKqxaVqf2uUl8fLueWuVt/M6F3qtbvqg/ Kw829vt2/BsAAP//AwBQSwMEFAAGAAgAAAAhAM1ADN94AQAAFwMAABEAAABwcHQvdmlld1Byb3Bz LnhtbIxSTW/CMAy9T9p/iHLfWj4Go6LlMm0XpE2C7Z6lbsnUJlEcoOzXz/3ga3Dglmc/Pz/bmc6q smAbcKiMjnnvMeQMtDSp0nnMP5evD8+coRc6FYXREPMdIJ8l93dTG20UbD8cIwGNkYj5ynsbBQHK FZQCH40FTbnMuFJ4gi4PUie2JFwWQT8MR0EplOZdvbul3mSZkvBi5LoE7VsRB4XwZB5XyuJezd6i Zh0gyTTVZ5YSGk7XxOKrGbHGxPXGQTqHzDP8pVVNBuMBD05zS2Ob1GQ4mgzrVHCpg4VK4Qjlokhb xFALuzRvTqUxpyu08P37B6RHate4kh13I9xCigL2caxBMhURVqw+Y7/HGcn0wrC2QeHdlXBwqLOR cSpXmlUxfwqHnO2INB51pK5pTcvX5H6OvksczLdi56Np4wGXUPmTaU/28M9xa+zM7TF03WnY+NyP ctBuln7ROqe9LqyQ9P2YpOIxnZu+ttztn61K+6eTPwAAAP//AwBQSwMEFAAGAAgAAAAhAKpaAi+2 AQAAkgMAABEAAABwcHQvcHJlc1Byb3BzLnhtbKyT0WrbMBSG7wd7B6N7xZIty7GJU2xLgcEGY3QP oMlyImZbRlLajrF3n5q4XdquUMauJPFzfn3/OdLm6m4cohtlnTZTBfAKgUhN0nR62lfg6/UOrkHk vJg6MZhJVeCHcuBq+/7dZi5nq5yavPCh9LONgtHkSlGBg/dzGcdOHtQo3MrMagpab+wofDjafdxZ cRsuGIc4QYjGo9ATWOrtW+pN32upmJHHMQCcTawaTiTuoGf34Da/xe0yxxOkbQgpB/vJHrcbUTq7 /9YONroRQwV4wdtdBuIXAkMs4/VfhJbkTU7vhfiP61yqO//R+WUXHa2uwE+e05YXpIYUpS0kmCSw KXgDKcNpjhBGdZL/uqfDpOy0k8J2H0axV7zTngkvHsJj8iL+qKU1zvR+Jc249DGeza2ys9GnVmK0 zONEjRbgAPeUkaW4RjSpYV6sa0jSpIB1wxhsmnqdUZqgDKNHRtWL4+BPjGzW/xEvTXKav4a4C5PY 1TWDiLcckizlsFinGBLaJGnDw5KSM2JWyoOw/toK+T28yy+qb4RT3SNo9i+gySUovoQ8r6exx8+/ 0fY3AAAA//8DAFBLAwQUAAYACAAAACEAnl37TTMCAADFBQAAEAAIAWRvY1Byb3BzL2FwcC54bWwg ogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0VFFv2jAQfp+0/2DlvRhaRBEyqapU CE1lRSK0z25ySaw5duTz0rJfv0tSUlhRJTaNp+/uPn++fIdP3LyWmtXgUFkzD0aDYcDAJDZVJp8H 23hxMQ0YemlSqa2BebADDG7Cr1/E2tkKnFeAjCQMzoPC+2rGOSYFlBIHVDZUyawrpafQ5dxmmUrg ziY/SzCeXw6HEw6vHkwK6UXVCwad4qz2fyua2qTpDx/jXUV6oYitlzpWJYSXo/GV4O+xeLIuxfB6 NBW8g+K2qrRKpCdLwpVKnEWbebaSiTLeYsHW9gXc2lIk+CGXPAGkHtpo0bYYPqkUMHEARvATZbGW TuZOVgWGo8k1cd5jsdHN4XAs+BsS363vEh0QS5WmYN6qQ8GPYrFaRVpVbWEPxSaRGiLyJsykRiDp PiGWIJu5r6VyxKz9rIbEW8dQ/aLJTwL2LBEaR+dBLZ2SxgcdrQtarCv0LlxY45FtEVLB+2QLD7mH WI3Dq5ZA4FNipxXT3wHO0B6dod3ax2LlNeAZV4xPX9EGrY+Ejx3urnjIaOb+hOHTQ8PbHjq7u3Zu SV8fttejSGr17NRnNXav8sKfZDy0z4l9MLhHK3A5fQOrFbzgjG38N1sY5JF09DY9uP92qCfzuLAl WvPPh45m88c0IltW0uyo0KN7ZX7gtortnfSwfz/HSbEppIOUtlH/vvqEWNIknW74USFNDume87HQ 7KDHbivTXhgM6dfumn2uWSb7dRn+BgAA//8DAFBLAwQUAAYACAAAACEAMA8kGH8BAADzAgAAEQAI AWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJN TwIxEIbvJv6Hpic9LO0uoNAsayLqCRMSMRpuTTtg4/YjbQX59+4u7AqRg8dmnnky807zu29dog34 oKyZ4LRHMQIjrFRmPcGvi6dkhFGI3EheWgMTvIOA74rLi1w4JqyHubcOfFQQUGUygQk3wR8xOkZI EB+geehVhKmKK+s1j9XTr4nj4pOvgWSU3hANkUseOamFieuM+KCUolO6L182AikIlKDBxEDSXkp+ 2Qheh7MNTeWI1CruHJxF22JHfwfVgdvttrftN2g1f0ren2cvzaqJMnVWAnCRS8GiiiUUU6sd9ypY g+wK1XnZwMuQk46oWeGBR+uLx1LZiGbAPbqqFuT+ugHbch17yUN8ri60UiDvd2c7/lJ1o4eNqu9c DGiDdO/WOvfKRJBFRjOa0HGSDhZ0zPpDNhwvO2kL5Yeo97OBRFVEbB9oW3nrTx8WT7jz0VHjG7D0 dlmvddL/K9SHsf9hTG8Wacb6GRtmR8ZWUDRDn37T4gcAAP//AwBQSwECLQAUAAYACAAAACEAaVJ5 fPgBAAAWEQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAI AAAAIQBo+HShAwEAAOICAAALAAAAAAAAAAAAAAAAADEEAABfcmVscy8ucmVsc1BLAQItABQABgAI AAAAIQD75ySm3AwAAOduAAAVAAAAAAAAAAAAAAAAAGUHAABwcHQvc2xpZGVzL3NsaWRlMS54bWxQ SwECLQAUAAYACAAAACEA+3ny3zUKAAARRQAAFQAAAAAAAAAAAAAAAAB0FAAAcHB0L3NsaWRlcy9z bGlkZTIueG1sUEsBAi0AFAAGAAgAAAAhALrBUE89DAAAgW4AABUAAAAAAAAAAAAAAAAA3B4AAHBw dC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQABgAIAAAAIQDERtlQ1wAAAM4BAAAgAAAAAAAAAAAA AAAAAEwrAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc1BLAQItABQABgAIAAAAIQCt OQRg1wAAAM4BAAAgAAAAAAAAAAAAAAAAAGEsAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwu cmVsc1BLAQItABQABgAIAAAAIQAj83Ck1gAAAM4BAAAgAAAAAAAAAAAAAAAAAHYtAABwcHQvc2xp ZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc1BLAQItABQABgAIAAAAIQDwqpwz1gAAAM4BAAAgAAAA AAAAAAAAAAAAAIouAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc1BLAQItABQABgAI AAAAIQCyvCM1LgEAAPcFAAAfAAAAAAAAAAAAAAAAAJ4vAABwcHQvX3JlbHMvcHJlc2VudGF0aW9u LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAD8P+3stCQAAGUUAABUAAAAAAAAAAAAAAAAAETIAAHBw dC9zbGlkZXMvc2xpZGU0LnhtbFBLAQItABQABgAIAAAAIQDMmqdDuwIAAPENAAAUAAAAAAAAAAAA AAAAAHE7AABwcHQvcHJlc2VudGF0aW9uLnhtbFBLAQItABQABgAIAAAAIQDZ2OxtTQQAAE0PAAAh AAAAAAAAAAAAAAAAAF4+AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWxQSwECLQAU AAYACAAAACEAtsLFCTMFAAA/FQAAIQAAAAAAAAAAAAAAAADqQgAAcHB0L3NsaWRlTGF5b3V0cy9z bGlkZUxheW91dDMueG1sUEsBAi0AFAAGAAgAAAAhAFXucSWuBAAAbBMAACEAAAAAAAAAAAAAAAAA XEgAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ0LnhtbFBLAQItABQABgAIAAAAIQDCwGun BwYAAP8eAAAhAAAAAAAAAAAAAAAAAElNAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54 bWxQSwECLQAUAAYACAAAACEAM/skxtQDAAD0CwAAIQAAAAAAAAAAAAAAAACPUwAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDYueG1sUEsBAi0AFAAGAAgAAAAhAMqvTHiCAwAA8wkAACEAAAAA AAAAAAAAAAAAolcAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3LnhtbFBLAQItABQABgAI AAAAIQA2KjYiqAUAADwXAAAhAAAAAAAAAAAAAAAAAGNbAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0OC54bWxQSwECLQAUAAYACAAAACEAHjE0Un0FAAAIFwAAIQAAAAAAAAAAAAAAAABKYQAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1sUEsBAi0AFAAGAAgAAAAhALowOwFoBAAA hQ8AACIAAAAAAAAAAAAAAAAABmcAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQ SwECLQAUAAYACAAAACEA+E78lpsEAABlEAAAIgAAAAAAAAAAAAAAAACuawAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDExLnhtbFBLAQItABQABgAIAAAAIQAavQP1owIAAGYGAAAfAAAAAAAA AAAAAAAAAIlwAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAh AAMMWOSkAgAAZwYAAB8AAAAAAAAAAAAAAAAAaXMAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRl MS54bWxQSwECLQAUAAYACAAAACEAJv2LIKMCAABnBgAAHwAAAAAAAAAAAAAAAABKdgAAcHB0L25v dGVzU2xpZGVzL25vdGVzU2xpZGUyLnhtbFBLAQItABQABgAIAAAAIQAP7nhipAIAAGYGAAAfAAAA AAAAAAAAAAAAACp5AABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTMueG1sUEsBAi0AFAAGAAgA AAAhALCxDpcABQAAQxIAACEAAAAAAAAAAAAAAAAAC3wAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQxLnhtbFBLAQItABQABgAIAAAAIQB+QzBa0wAAAL8BAAAqAAAAAAAAAAAAAAAAAEqBAABw cHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA FzztatMAAAC/AQAAKgAAAAAAAAAAAAAAAABlggAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVz U2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAJn2ma7TAAAAvwEAACoAAAAAAAAAAAAAAAAA gIMAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlMi54bWwucmVsc1BLAQItABQABgAI AAAAIQBKr3U50gAAAL8BAAAqAAAAAAAAAAAAAAAAAJuEAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMv bm90ZXNTbGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALQAAAAAAAAAA AAAAAAC1hQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhAGmiXyEVAQAAxwcAACwAAAAAAAAAAAAAAAAAvIYAAHBwdC9zbGlkZU1hc3Rl cnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEA AC0AAAAAAAAAAAAAAAAAG4gAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54 bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAACKJAABwcHQv c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV 0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAACiKAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0OC54bWwucmVsc1BLAQItABQABgAIAAAAIQBTbV+kFAgAADE2AAAhAAAAAAAAAAAAAAAA AC6LAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA1dGS 8bwAAAA3AQAALAAAAAAAAAAAAAAAAACBkwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDcueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAACH lAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHNQSwECLQAUAAYA CAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAACNlQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDIueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAA AAAAAAAAAACTlgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHNQ SwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAACZlwAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3 AQAALAAAAAAAAAAAAAAAAACfmAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUu eG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAAClmQAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYueG1sLnJlbHNQSwECLQAUAAYACAAAACEA tM9YGbkAAAAkAQAALAAAAAAAAAAAAAAAAACrmgAAcHB0L25vdGVzTWFzdGVycy9fcmVscy9ub3Rl c01hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA2ddUgLQFAABuHQAAIQAAAAAAAAAAAAAA AACumwAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhAHtD vF3EBgAAzyAAABQAAAAAAAAAAAAAAAAAoaEAAHBwdC90aGVtZS90aGVtZTIueG1sUEsBAi0ACgAA AAAAAAAhADh0LHBuOAAAbjgAABcAAAAAAAAAAAAAAAAAl6gAAGRvY1Byb3BzL3RodW1ibmFpbC5q cGVnUEsBAi0AFAAGAAgAAAAhAHtDvF3EBgAAzyAAABQAAAAAAAAAAAAAAAAAOuEAAHBwdC90aGVt ZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAD+FuHEiAgAAKAsAABMAAAAAAAAAAAAAAAAAMOgA AHBwdC90YWJsZVN0eWxlcy54bWxQSwECLQAUAAYACAAAACEAzUAM33gBAAAXAwAAEQAAAAAAAAAA AAAAAACD6gAAcHB0L3ZpZXdQcm9wcy54bWxQSwECLQAUAAYACAAAACEAqloCL7YBAACSAwAAEQAA AAAAAAAAAAAAAAAq7AAAcHB0L3ByZXNQcm9wcy54bWxQSwECLQAUAAYACAAAACEAnl37TTMCAADF BQAAEAAAAAAAAAAAAAAAAAAP7gAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQAwDyQY fwEAAPMCAAARAAAAAAAAAAAAAAAAAHjxAABkb2NQcm9wcy9jb3JlLnhtbFBLBQYAAAAANgA2AH8Q AAAu9AAAAAA= --Apple-Mail=_64396FEE-3BF5-400F-BDAB-B58F31F6DA2D-- From nobody Wed Sep 16 12:27: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 2DE513A0B66 for ; Wed, 16 Sep 2020 12:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wLPO3XfmnXX for ; Wed, 16 Sep 2020 12:27:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958423A0B65 for ; Wed, 16 Sep 2020 12:27:51 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08GJRnE6067312 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 16 Sep 2020 14:27:50 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600284470; bh=tWuhjgFVq+hok5R+JR2nnhYecSSJAXASlGPtpI9gUeQ=; h=Subject:To:References:From:Date:In-Reply-To; b=WobPtpf0MgYizOh5s1LmtjK1BEmYPIVN9OlZo3vsTEflbsloiSOCHK43E4FZGBW7Q CzFKlma5XaORbj9Okq5rMUUMF67KzwOkka+RAzvCGmaeaaboo4B74A+8fS+3ogrrTV P5R2Vk6QBYARgxiw2xroExfxX2c/UrdwNaEoBfLo= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: adrian@olddog.co.uk, rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> From: Adam Roach Message-ID: Date: Wed, 16 Sep 2020 14:27:42 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? (was: Re: My hard constraints] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 19:27:54 -0000 On 9/16/2020 5:20 AM, Adrian Farrel wrote: > I think it is absolutely the case that people retained in consultancy or contracting roles also expect to be on a continuous re-hiring cycle, so I can't see the difference you are making. I'd like to enter into evidence that Spencer (to pick a random person) is no longer on the IESG, and no one felt the need to spin up an IAB program in response to his departure. There are very different presumptions in the community about the likelihood of renewal between the two arrangements. If this distinction isn't obvious to you at this point, I'm not sure there's much more I can say on the topic to help you understand the point I'm making. I'm going to stop responding now under the assumption that other participants can. /a From nobody Wed Sep 16 13:07:24 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D413A0DE3 for ; Wed, 16 Sep 2020 13:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_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 XOcBNRv1_nxg for ; Wed, 16 Sep 2020 13:07:20 -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 BA2AA3A0DE8 for ; Wed, 16 Sep 2020 13:07:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BsB2w3j5fz6GJDM; Wed, 16 Sep 2020 13:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1600286840; bh=dUJGwKRUL9dviubBhbN3Naq23npC5+2OZgkVX/1XdOU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cVx82JmI0usvqppneltS8ppLWRrmSTXzURYANTXiJRIEqklDvIugNgXuPvzw0/EJW 0pMc5iMhvLtSXgI/adQmoOpjYV0HeFvKBmhXQ+1G5F0l9iljouFhH3l0dpE2dtUJvg NfjMeU9FN7tVkZ+uFb7nefuHR+EERg0SbW62YhS4= 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 4BsB2t126nz6GHfL; Wed, 16 Sep 2020 13:07:18 -0700 (PDT) To: Adam Roach , adrian@olddog.co.uk, rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Wed, 16 Sep 2020 16:07:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.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] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 20:07:23 -0000 Yes, I have a very different expectation about persistence and retention. The RSE (or whatever we rename such a person if we keep the role) provides skills that this community does not have. They provide skills that we are demonstrably not good at recruiting. Based on the learning curve for outsiders to learn the job, it is also a job with a significant amount of context. Replacing that person every 4 years would be a bad thing for the community (if you assume we agree that we should have such a person). I have been trying to figure out what compromises in approach I can live with, and what points from various proposals seem to make sense to me, and if there is any way to put them together. I am quite sympathetic to the view that the community needs a stronger voice in the long term strategic direction of the RFC series. I am very concerned by the proposals which remove the role of a publication expert in providing guidance to the RPC (AMS provides direct line management. They do not provide publication expertise in the sense we mean it. Heck, although they provide the web publication service, that is not their primary expertise.) I am wondering if there is some middle ground on this. Keep the RSE as a person in charge of the tactical and hybrid (between tactical and strategic) direction, with an explicit role of providing advise on the strategic direction. And somehow craft a community body to own the true strategic direction (roughly, things where if it takes 2 years to work out an agreement, that's okay. But not looking at the quesiton is a bad idea.) I am not sure how to set up the chairing and reporting of this body. Yours, Joel On 9/16/2020 3:27 PM, Adam Roach wrote: > On 9/16/2020 5:20 AM, Adrian Farrel wrote: >> I think it is absolutely the case that people retained in consultancy >> or contracting roles also expect to be on a continuous re-hiring >> cycle, so I can't see the difference you are making. > > > I'd like to enter into evidence that Spencer (to pick a random person) > is no longer on the IESG, and no one felt the need to spin up an IAB > program in response to his departure. There are very different > presumptions in the community about the likelihood of renewal between > the two arrangements. > > If this distinction isn't obvious to you at this point, I'm not sure > there's much more I can say on the topic to help you understand the > point I'm making. I'm going to stop responding now under the assumption > that other participants can. > > /a > From nobody Wed Sep 16 14:19: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 08B7A3A11E1 for ; Wed, 16 Sep 2020 14:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-LqsKqcO19l for ; Wed, 16 Sep 2020 14:19:24 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 4931C3A0C5A for ; Wed, 16 Sep 2020 14:19:24 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id d9so4743412pfd.3 for ; Wed, 16 Sep 2020 14:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=65UJhZllG055g2XwKo183zfaG9vmdi2CLDUl0SGIznI=; b=oiKJz+XhJ3SYK0gmom+pHmUmSXLtfmclIV2gHknPC11ppnrVuqxt725BaG1fFfld1s 8z3u0kZVhnqUZJsQg3Db0dyA9Bqa8gz++H1K08HYzYdluqkAmQvLCNImUgzFLVG1WT5R Bi3tnfxhWY07dzOZvO+W36hwto3UVv660xrxap5Wig5O2P/h2KVkSkE9Q8/aHKhqhGqD xkeyIsKuFOknWKZl5r/9pgv0pSbFJFomKRe4Rg5aawAxUcvuJ+65I9+txZW7jXxULYEH 8hpPhAge+zWeT40HKPMDvOSRBkCUMlpIAvmKbzGxP+TvfZNbyhYgpqe3VIMtg29g0XOx c3Xw== 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=65UJhZllG055g2XwKo183zfaG9vmdi2CLDUl0SGIznI=; b=dg++uJkP/pW3zQlgEKq36LFlUQe1JsPSq91ta932GXvJncy8QPqyxvPqvqXZJ9Zs6z YoYHXr2U7lj04JM7KfiF1mNWN23jnkDJKT3AqjUsAseqKkth5wbwdeYJ3HevKki1Lg0y MgfU/c4XZ78BM+gOlNTFtRrLOs9IAwGfcoUk/Ts7EWXV2n7N6/onfjbEBVMBfcIp2tUm s/QNvA08XbXINe+7w0eYv8IImCITnEdYKrQt51eDe0LBX0deuU2Jx9K9cMyzFx3zLgPn hTHJxq4VehD/PRAySNEvpT0zxxjljJO+NQaRxlcX+4x3NfbDqA1xiM3XK/N76ZT7l8uu 4cMQ== X-Gm-Message-State: AOAM533UNwhBTJzXaj4qDVQWI8LET8B8P1IwuGWtHBRDiDI6o17cBxus p7Gmqms2ogQnyuysMez/RvsL+Y0HkCE= X-Google-Smtp-Source: ABdhPJxR0jXMCKv0MHOjnXAq1AynphbULBmG4hgQUbkVK5bE8OxSE0+ybTgOGEp8z3lLrIX5RMpmSQ== X-Received: by 2002:a63:c551:: with SMTP id g17mr19498003pgd.399.1600291163286; Wed, 16 Sep 2020 14:19:23 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id d17sm17275364pgn.56.2020.09.16.14.19.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2020 14:19:22 -0700 (PDT) To: "Joel M. Halpern" , Adam Roach , adrian@olddog.co.uk, rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> From: Brian E Carpenter Message-ID: <27aaf010-714e-fa52-41fa-8670fb547b18@gmail.com> Date: Thu, 17 Sep 2020 09:19:19 +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] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 21:19:26 -0000 On 17-Sep-20 08:07, Joel M. Halpern wrote: > Yes, I have a very different expectation about persistence and retention. > > The RSE (or whatever we rename such a person if we keep the role) > provides skills that this community does not have. They provide skills > that we are demonstrably not good at recruiting. Based on the learning > curve for outsiders to learn the job, it is also a job with a > significant amount of context. Replacing that person every 4 years > would be a bad thing for the community (if you assume we agree that we > should have such a person). Yes. The analogy with our pro bono counsel is a good one (except that I have no expectation of finding a pro bono RFC Series Advisor). Our previous pro bono counsel was with the IETF for at least 18 years. He got to know us fairly well. Brian > > I have been trying to figure out what compromises in approach I can live > with, and what points from various proposals seem to make sense to me, > and if there is any way to put them together. I am quite sympathetic > to the view that the community needs a stronger voice in the long term > strategic direction of the RFC series. I am very concerned by the > proposals which remove the role of a publication expert in providing > guidance to the RPC (AMS provides direct line management. They do not > provide publication expertise in the sense we mean it. Heck, although > they provide the web publication service, that is not their primary > expertise.) > > I am wondering if there is some middle ground on this. Keep the RSE as > a person in charge of the tactical and hybrid (between tactical and > strategic) direction, with an explicit role of providing advise on the > strategic direction. And somehow craft a community body to own the true > strategic direction (roughly, things where if it takes 2 years to work > out an agreement, that's okay. But not looking at the quesiton is a bad > idea.) > > I am not sure how to set up the chairing and reporting of this body. > > Yours, > Joel > > > On 9/16/2020 3:27 PM, Adam Roach wrote: >> On 9/16/2020 5:20 AM, Adrian Farrel wrote: >>> I think it is absolutely the case that people retained in consultancy >>> or contracting roles also expect to be on a continuous re-hiring >>> cycle, so I can't see the difference you are making. >> >> >> I'd like to enter into evidence that Spencer (to pick a random person) >> is no longer on the IESG, and no one felt the need to spin up an IAB >> program in response to his departure. There are very different >> presumptions in the community about the likelihood of renewal between >> the two arrangements. >> >> If this distinction isn't obvious to you at this point, I'm not sure >> there's much more I can say on the topic to help you understand the >> point I'm making. I'm going to stop responding now under the assumption >> that other participants can. >> >> /a >> > From nobody Wed Sep 16 14:31: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 65F0A3A0CDA for ; Wed, 16 Sep 2020 14:31:34 -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 tgyRj7caY0Kp for ; Wed, 16 Sep 2020 14:31:33 -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 56BF03A0CD8 for ; Wed, 16 Sep 2020 14:31:33 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id e4so3899181pln.10 for ; Wed, 16 Sep 2020 14:31:33 -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=gLwAyHn4LP20ND7k5XdMsxZFx8TpOq7aebg930QznqM=; b=CZ/snR3SWnmRoAncWo4vyTqXylt6NnDlUw5frVWJ1FCFYZfMN1XWIQVxkI4s6O69w/ cUTmA/CwhKZA3R4U0kgxGdnAGXMR1al8CJLmSK4FI1TEq8fxHmfFrICcUdQ/5DXwigai Ls2bZVWER5XwOFzL7HcmNASp8vwrW3JVyHJd/jrsvFi5CtlIF7f9F2fU5q0p0HqpcgMe cXQuapVdduKFjM1cveP9qy913uGQNHdQ0+LCyavvYqUTfDuZ8XZ7SMvg+CKcsopUL4Ek 2xGsOC5vUXddnzXiMnSyooAkm80CMG3RXxQNSDzFxkP/xa/kqVgtZGP0uZkNouoBoikg vB4A== 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=gLwAyHn4LP20ND7k5XdMsxZFx8TpOq7aebg930QznqM=; b=YtVn6fewVFyPyg7w2cr77r18Mfd2RNUL/jy6VHU0WByktfRUX/08k5PUA8rg9oJGLP Jf7hfqjuWoKLiEVIg8E2B/F2u/PiWfo/uNCyFP1qDIKt+hb+bxoPaEgX5hcljOGP2NS6 m7Jn2XqrKk8HdU7ZKI5j61I5qkC27SEC4BDbyfVEIcBH8XdTL9TmYkw6/rKW7ZEBokzZ 99Bo9vWcskqJSaWiEjtTpDbig+sQ/jrDz7nwkqvDVCvN9YroSn/IhioTdOMjWD2C3IFX CoydjvpXv73FunpYSs6aA0uSzQg8PhgWymObBDzSMbJtH8NzcZ3YqAHuU27OdNBWUBXY gcAQ== X-Gm-Message-State: AOAM531LzZZiI06GqqsXHazr/k4S7qXqcnUVC6cWk9fSmFocU+5BisiX E/2mliaXjqnw2u7DnQnRW+ZyLLjY9yY= X-Google-Smtp-Source: ABdhPJxEehLtrjwdZ1OXsFAbn2dsE6RRh5m8HLONHDKSiR8FHpRA/SjPAbxXV1vHX1PyDVgBLgundQ== X-Received: by 2002:a17:902:a585:b029:d0:afd3:d851 with SMTP id az5-20020a170902a585b02900d0afd3d851mr26350970plb.2.1600291892490; Wed, 16 Sep 2020 14:31:32 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id g23sm18088401pfh.133.2020.09.16.14.31.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2020 14:31:31 -0700 (PDT) To: adrian@olddog.co.uk, rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> From: Brian E Carpenter Message-ID: <01ee9d26-f463-f4b9-f3a5-dfda2343b05c@gmail.com> Date: Thu, 17 Sep 2020 09:31:29 +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: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] an advisor's advice [Was: Trust versus accountability] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 21:31:34 -0000 On 16-Sep-20 21:35, Adrian Farrel wrote: > I think this debate is evolving into a somewhat old conversation about trust > versus accountability. > > On the one hand, an advisor's advice might be summarily ignored by our > decision-makers. I want to focus on that. At least in my mind, the decision maker is an open WG operating by rough consensus. Yes, that could lead to explicitly ignoring expert advice. Isn't that exactly how the IETF works? Why is it more broken in this case than it is in the IETF? In any case it makes it clear that the WG is accountable for its own mistakes, and that's a WG that is open to the entire community. So any mistakes are made by (the interested parties in) the community itself. And people who didn't participate have only themselves to blame. Regards Brian From nobody Wed Sep 16 14:41: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 5399A3A1204 for ; Wed, 16 Sep 2020 14:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AZvsk0TS-Tcb for ; Wed, 16 Sep 2020 14:41:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32F63A0D38 for ; Wed, 16 Sep 2020 14:41:14 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kIfAs-000JpL-MK; Wed, 16 Sep 2020 17:41:10 -0400 Date: Wed, 16 Sep 2020 17:41:04 -0400 From: John C Klensin To: Adam Roach , adrian@olddog.co.uk cc: rfced-future@iab.org Message-ID: <26D176CA4BDAD514DA7D9B79@PSB> In-Reply-To: References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? (was: Re: My hard constraints] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 21:41:17 -0000 --On Wednesday, September 16, 2020 14:27 -0500 Adam Roach wrote: > On 9/16/2020 5:20 AM, Adrian Farrel wrote: >> I think it is absolutely the case that people retained in >> consultancy or contracting roles also expect to be on a >> continuous re-hiring cycle, so I can't see the difference you >> are making. > > > I'd like to enter into evidence that Spencer (to pick a random > person) is no longer on the IESG, and no one felt the need to > spin up an IAB program in response to his departure. There are > very different presumptions in the community about the > likelihood of renewal between the two arrangements. Yes, but one of the problems with that analogy is that Spencer, IIR, stepped down voluntarily (at least as far as the IETF is concerned). Better analogies would be someone who was willing to serve again but was not given another term by the Nomcom. Even then, we don't spin up IAB programs (and the community would almost certainly consider it the height of arrogance for the IAB to even consider doing so). I suggest that a significant fraction of the community believes that turnover on the IESG is actually helpful and that people serving more than, say, six or eight years would be a problem (I haven't looked at the statistics lately, but suspect the mode is still four years). Now, by contrast, if we are trying to obtain and retain a professional-type expert (see Joel's (I think) comment about finding lawyers only when one needs advice and then finding another one the next time), there had better be an expectation of both long tenure (even if on nominally short-term contract with routine renewals) and that the community will mostly respect that person's expertise rather than, e.g., regularly second-guessing them because we assume we (or the IESG, or the IAB, or the LLC, or even some committee drawn from our community are smarter and/or more knowledgeable than said expert. Should "we" end up behaving that way --regardless of the organizational structure-- whether the individual leaves in frustration or the contract is terminated (whether at renewal time or before that) is just a matter of time (and probably not long). And, since every professional community has its own informal "grapevine" communications, it will likely get harder to find and successfully recruit the next such person we would go looking for as a replacement. > If this distinction isn't obvious to you at this point, I'm > not sure there's much more I can say on the topic to help you > understand the point I'm making. I'm going to stop responding > now under the assumption that other participants can. I don't know whether the above helps or not, because I'm not sure we are asking the same question. Response to Martin's note soon. best, john From nobody Wed Sep 16 14:44: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 AC6293A1219 for ; Wed, 16 Sep 2020 14:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=K4CF5Dw6; dkim=pass (2048-bit key) header.d=taugh.com header.b=tdznF72S Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C20nbQsE7vBg for ; Wed, 16 Sep 2020 14:44:13 -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 B28C63A1218 for ; Wed, 16 Sep 2020 14:44:13 -0700 (PDT) Received: (qmail 80060 invoked from network); 16 Sep 2020 21:44:12 -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=138b7.5f62872c.k2009; bh=qC/CwO+3kqRdiiG+uQ6BxnjdBTOe3sA6QOQK1Lch/oo=; b=K4CF5Dw6Kymh8GcDUf79ioYDCTjnGPcjybviKcccCS9HF/DHLc0m/okOMMLntUxlBrI3MQNRh7DY/vlJ3Tva6KkNQLFliG8obSQmawvGYiOGQIKzyht+uAkx/jR5fMu4mSnLzGlOq40xnJ3IoHTVdfsf/xrTjjMN6CXSH+Z/zYXX/NbqNS192RtTE8ByliOeHuTVzh3hCeHdJ7JQRckV0GNScd8qfKv0QKWooCo3y+ZrYXLmb0fcP6DVZ8+Z7jUKH/Qa/t+1NwpjSWKkNzqgOFcR8sU1wOvj4SJtKNYa4dA6Cc41cvj4pq5fUyhjQQ4vQ5NR1iArnuzgdZNqGwoqsw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=138b7.5f62872c.k2009; bh=qC/CwO+3kqRdiiG+uQ6BxnjdBTOe3sA6QOQK1Lch/oo=; b=tdznF72SDvxa9l7kRxJ+uTB+frDVZPJy2XpJ4YHbOJTu9tRBRxPqoaPvyqPNCIn5pdiCKBidCpm5W/lB0LTey8C1QgVO/YPCW4qbI7E/rwv0y8HUjnDKynMd8LC6BpjLth55mhAeP6jiPrePBAHpKr4amRt7cuMY4Hem1o9NMyyafwZROMbz8xo0B7Pu/Qks4Jm919AAcyCBSYLxt93IpfyOrob6ZWR6DDweWM03fK6Nxr8aY3rX94STp4jQjI4r0suJOdU9JXQ8zozSesw6BXOdurDu1K1DGG99HXeUwDcss/flmV1FJx3m/FWTjnDQvro7kY5VS4JcXDMjqvcz8g== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 16 Sep 2020 21:44:11 -0000 Received: by ary.qy (Postfix, from userid 501) id 35135212AA34; Wed, 16 Sep 2020 17:44:11 -0400 (EDT) Date: 16 Sep 2020 17:44:11 -0400 Message-Id: <20200916214411.35135212AA34@ary.qy> From: "John Levine" To: rfced-future@iab.org In-Reply-To: <27aaf010-714e-fa52-41fa-8670fb547b18@gmail.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] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 21:44:16 -0000 In article <27aaf010-714e-fa52-41fa-8670fb547b18@gmail.com> you write: >Yes. The analogy with our pro bono counsel is a good one (except that >I have no expectation of finding a pro bono RFC Series Advisor). Our >previous pro bono counsel was with the IETF for at least 18 years. He >got to know us fairly well. FYI, our lawyers are not pro bono, they're on retainer as was our prior lawyer. I agree with you that it is a good thing in these specialized jobs to have people stay long enough to learn what we do and how we work. FWIW, I've been around for quite a while but in my new role as tRSE I'm still learning all sorts of stuff about the process, the history, and the stuff we have yet to do. R's, John From nobody Wed Sep 16 14:49: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 71FCA3A121A for ; Wed, 16 Sep 2020 14:49:06 -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 pShpNeBF-ZEJ for ; Wed, 16 Sep 2020 14:49:05 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE1C3A1219 for ; Wed, 16 Sep 2020 14:49:05 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kIfIR-000Jqh-NG; Wed, 16 Sep 2020 17:48:59 -0400 Date: Wed, 16 Sep 2020 17:48:53 -0400 From: John C Klensin To: Brian E Carpenter , "Joel M. Halpern" , Adam Roach , adrian@olddog.co.uk cc: rfced-future@iab.org Message-ID: <2C62E748F26D9156D92E1745@PSB> In-Reply-To: <27aaf010-714e-fa52-41fa-8670fb547b18@gmail.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <27aaf010-714e-fa52-41fa-8670fb547b18@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 21:49:06 -0000 --On Thursday, September 17, 2020 09:19 +1200 Brian E Carpenter wrote: > Yes. The analogy with our pro bono counsel is a good one > (except that I have no expectation of finding a pro bono RFC > Series Advisor). And my expectation is that, if we found such a person to do the work for free and he or she were not named, e.g., "Postel", the community would behave as is free advise is worth what one pays for it that the expert/advisor would soon get frustrated and resign. john From nobody Wed Sep 16 14:51: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 76FD93A1224 for ; Wed, 16 Sep 2020 14:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.794 X-Spam-Level: X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGTRfpSlrC7e for ; Wed, 16 Sep 2020 14:51:49 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC133A1225 for ; Wed, 16 Sep 2020 14:51:48 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 08GLkqaS020750; Wed, 16 Sep 2020 22:51:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=MBXh2WshyGcBTG5Ez6PywMcdhDoKNmihvPjvHcxrgLc=; b=UtV2vVPJSbaRnjvEoov1t3bo2WYugwTJfFtuFKt5x/PMBJnVVnZqKHi19sUJm8y7nBdv 30OyZnTh47GDfXeNXbtzKH8d//OZYEineE9pSE83X4MTZbT/0gynhdn/IChRjvIyPDT7 CldCCzVVjh3x0bhG4bHGVZcB8lf+wluf1x/x/wfFrMXBwsg3Y5bH7Yj7JZ7nXsrWQS4s F0W263P988ySCeK1BCpqsgUn6Gcn6Q/odHfMCozYCx42amgwf66/PG8jepnCSLhGiToi TE8LDDG0oQNyKrBJN8kABthz9vqh5Ub5Q4nISsj98GkhOkj2+p/AwOWkM6iyzzec2rVS Kg== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 33k5q22hq7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Sep 2020 22:51:47 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 08GLYPw9031030; Wed, 16 Sep 2020 17:51:47 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint7.akamai.com with ESMTP id 33k5ne63qe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 16 Sep 2020 17:51:47 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Sep 2020 17:51:46 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Sep 2020 17:51:45 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Wed, 16 Sep 2020 17:51:45 -0400 From: "Salz, Rich" To: Brian E Carpenter , "adrian@olddog.co.uk" , "rfced-future@iab.org" Thread-Topic: [Rfced-future] an advisor's advice [Was: Trust versus accountability] Thread-Index: AQHWjHDEi4WzDtxJY0uhCy3P29se6alrzkKA Date: Wed, 16 Sep 2020 21:51:45 +0000 Message-ID: <1A801D70-082F-4551-B2BD-4B544D98A60E@akamai.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <01ee9d26-f463-f4b9-f3a5-dfda2343b05c@gmail.com> In-Reply-To: <01ee9d26-f463-f4b9-f3a5-dfda2343b05c@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: text/plain; charset="utf-8" Content-ID: <55CB457D4C9F3E44AD169BE5D82F650E@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-16_13:2020-09-16, 2020-09-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=528 spamscore=0 malwarescore=0 adultscore=0 mlxscore=0 suspectscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009160156 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-16_13:2020-09-16, 2020-09-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 clxscore=1011 lowpriorityscore=0 priorityscore=1501 spamscore=0 mlxlogscore=489 bulkscore=0 mlxscore=0 adultscore=0 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009160157 Archived-At: Subject: Re: [Rfced-future] an advisor's advice [Was: Trust versus accountability] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 21:51:50 -0000 PiAgIEkgd2FudCB0byBmb2N1cyBvbiB0aGF0LiBBdCBsZWFzdCBpbiBteSBtaW5kLCB0aGUgZGVj aXNpb24gbWFrZXIgaXMgYW4gb3BlbiBXRyBvcGVyYXRpbmcgYnkgcm91Z2ggY29uc2Vuc3VzLiBZ ZXMsIHRoYXQgY291bGQgbGVhZCB0byBleHBsaWNpdGx5IGlnbm9yaW5nIGV4cGVydCBhZHZpY2Uu IElzbid0IHRoYXQgZXhhY3RseSBob3cgdGhlIElFVEYgd29ya3M/IFdoeSBpcyBpdCBtb3JlIGJy b2tlbiBpbiB0aGlzIGNhc2UgdGhhbiBpdCBpcyBpbiB0aGUgSUVURj8NCg0KSSBiZWxpZXZlIHRo YXQsIHVubGlrZSBJbnRlcm5ldCBwcm90b2NvbCBkZXNpZ24sIG1hbnkgcGVvcGxlIGhlcmUgcmVj b2duaXplIHRoYXQgd2UgYXJlIG5vdCBleHBlcnRzIGluIHRoZSBmaWVsZCwgYW5kIHRoZXJlIGlz IGNvbmNlcm4gYWJvdXQgd2VsbC1tZWFuaW5nIGFtYXRldXJzIGdldHRpbmcgaXQgaG9ycmlibHkg d3JvbmcNCg0K From nobody Wed Sep 16 15:08: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 D86583A0D84 for ; Wed, 16 Sep 2020 15:08:17 -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 kxNlt1yIR3uc for ; Wed, 16 Sep 2020 15:08:16 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05703A0A9B for ; Wed, 16 Sep 2020 15:08:16 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kIfb4-000JuG-Nd; Wed, 16 Sep 2020 18:08:14 -0400 Date: Wed, 16 Sep 2020 18:08:08 -0400 From: John C Klensin To: Brian E Carpenter , adrian@olddog.co.uk, rfced-future@iab.org Message-ID: In-Reply-To: <01ee9d26-f463-f4b9-f3a5-dfda2343b05c@gmail.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <01ee9d26-f463-f4b9-f3a5-dfda2343b05c@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] an advisor's advice [Was: Trust versus accountability] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 22:08:18 -0000 --On Thursday, September 17, 2020 09:31 +1200 Brian E Carpenter wrote: > On 16-Sep-20 21:35, Adrian Farrel wrote: >> I think this debate is evolving into a somewhat old >> conversation about trust versus accountability. >> >> On the one hand, an advisor's advice might be summarily >> ignored by our decision-makers. > > I want to focus on that. At least in my mind, the decision > maker is an open WG operating by rough consensus. Yes, that > could lead to explicitly ignoring expert advice. Isn't that > exactly how the IETF works? Why is it more broken in this case > than it is in the IETF? Because, in the case of the IETF, there is a strong assumption, almost always justified, that a significant fraction of the people in the WG are expert in the subject matter the WG is considering. I am not yet convinced that, if we put together something WG-like, we will be able to populate it sufficiently that we can have a reasonable expectation of expertise in that group or, to put it differently, that any consensus reached (rough or otherwise), will actually be informed consensus. > In any case it makes it clear that the WG is accountable for > its own mistakes, and that's a WG that is open to the entire > community. So any mistakes are made by (the interested parties > in) the community itself. And people who didn't participate > have only themselves to blame. Sure, but the damage is to the series and its users and that is much more important than blame. And, were the word to get around the professional technical publications community that whomever takes the position (no matter how we characterize it) will be reporting to, and subject to the whims of, a collection of ignorant fools, then the intersection between the set of people one would want to recruit and the set willing to take the position will rapidly trend toward zero. best, john From nobody Wed Sep 16 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 8A8383A0DFF for ; Wed, 16 Sep 2020 15:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npb-EsFnVxl3 for ; Wed, 16 Sep 2020 15:37:01 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 138AF3A0DFE for ; Wed, 16 Sep 2020 15:37:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 2659F4195116; Wed, 16 Sep 2020 18:36:56 -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 1v33z-TS9WH1; Wed, 16 Sep 2020 18:36:51 -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 F388041950FE; Wed, 16 Sep 2020 18:36:49 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\)) From: "Scott O. Bradner" In-Reply-To: <20200916214411.35135212AA34@ary.qy> Date: Wed, 16 Sep 2020 18:36:40 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <47D3D168-2CA1-4084-A6FB-F4B783958D34@sobco.com> References: <20200916214411.35135212AA34@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3445.9.6) Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 22:37:04 -0000 fwiw - our =E2=80=9Cprior lawyer=E2=80=9D was pro bono (other than = expenses) for more than a decade before he left the law firm that=20 was supporting his pro bono work and the IETF started to pay him Scott > On Sep 16, 2020, at 5:44 PM, John Levine wrote: >=20 > In article <27aaf010-714e-fa52-41fa-8670fb547b18@gmail.com> you write: >> Yes. The analogy with our pro bono counsel is a good one (except that >> I have no expectation of finding a pro bono RFC Series Advisor). Our=20= >> previous pro bono counsel was with the IETF for at least 18 years. He >> got to know us fairly well. >=20 > FYI, our lawyers are not pro bono, they're on retainer as was our > prior lawyer. I agree with you that it is a good thing in these > specialized jobs to have people stay long enough to learn what we do > and how we work. >=20 > FWIW, I've been around for quite a while but in my new role as tRSE > I'm still learning all sorts of stuff about the process, the history, > and the stuff we have yet to do. >=20 > R's, > John >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Sep 16 16:22: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 67BE03A1223 for ; Wed, 16 Sep 2020 16:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gctVMZqO66Bt for ; Wed, 16 Sep 2020 16:22:14 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20563A121F for ; Wed, 16 Sep 2020 16:22:14 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id f1so68828plo.13 for ; Wed, 16 Sep 2020 16:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Igfzi24w5leCX/SJsXh/Yb7NlB3/ABpsiBeNrgDqFYI=; b=uYC3JoUJwlLX5tpzDousaIjNHUO6Fc2jNOddijm7GPb3Qu6tW4bamoQzaITNm6oasW YQOHqzWKI4TMJblzrGji7B5Sk36N8jq8Jy6DheOEs5uL6fa7EUgGVcvWY/oHx+5vcj+S L0qnQzcMbmOVlGVP3kNzLKf1W/FIsnzvSo0E3aenvAWBx1CBYB36cCKZ7Q7Td43FoH+k WugKmlf9j0AaHkFphlrw63kB30ipXc4D6Isd1wkYfm+7DvkbGOetMyMSs7OVgo9KRYQ6 uYRcnGgGMROu8Jc26pXssS2smHwc4NbtAuv8F+r9N5jm7iuBE3v5RAydQluUeTqzsesO zJXA== 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=Igfzi24w5leCX/SJsXh/Yb7NlB3/ABpsiBeNrgDqFYI=; b=ondwkX8Wqmga6tdrBCwmEFTak9eKTm3MH2HC3qPFs4y21nW2gWDfLpzUgmR3jAFvFV n8kffHF7xb65e+qq+WBQ4GS5l0G0iKU2RjXU1GUkixmecp8nleteJTdBMLQDotGhE++e oFqJOKN1npGZln12+IAX57mIfe83D7eqHsNz9/VpZKWHJfUvznFv/JVxP9gfVzf3Ir22 hvdohjsr7+QEoIZuPaNAbe54HQWWauAo4i59tf/TDbQ6B/+S6mPwbNG0p0P2YdCYiMR7 Aqhd7t/rIonWUWSqH4DB9eDx0M3W6znz2g80vZexEKdM/2XHLZAUQ6WTA0SHqbenHzWa Ulwg== X-Gm-Message-State: AOAM531G0SQ6p8u9ITUkTCBAezAaV1avjDkhG+5H4M7MHm7yT0IufKc7 75KRuh2pZAJ/WBm5qVZ9PxpbXIZJDAM= X-Google-Smtp-Source: ABdhPJzWegCiOQnEIFV8POsp2QjvzkmUUsUxoElVz31tdwSLyAiCbuh4QAOmyER6N1mliOvhAhG9og== X-Received: by 2002:a17:902:ba90:b029:d1:e5e7:bdfe with SMTP id k16-20020a170902ba90b02900d1e5e7bdfemr8387205pls.49.1600298533738; Wed, 16 Sep 2020 16:22:13 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id m14sm17997422pfo.202.2020.09.16.16.22.11 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2020 16:22:12 -0700 (PDT) To: rfced-future@iab.org References: <20200916214411.35135212AA34@ary.qy> <47D3D168-2CA1-4084-A6FB-F4B783958D34@sobco.com> From: Brian E Carpenter Message-ID: <0940b9bb-5610-f59b-e5b3-3989f511cc28@gmail.com> Date: Thu, 17 Sep 2020 11:22:11 +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: <47D3D168-2CA1-4084-A6FB-F4B783958D34@sobco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 23:22:16 -0000 On 17-Sep-20 10:36, Scott O. Bradner wrote: > fwiw - our =E2=80=9Cprior lawyer=E2=80=9D was pro bono (other than expe= nses) for more than a decade before he left the law firm that=20 > was supporting his pro bono work and the IETF started to pay him Yes, I knew that he switched to a retainer at some point, but that actually corresponds better to what we are discussing here. Either way, we had one expert advisor for the best part of two decades. Brian >=20 > Scott >=20 >> On Sep 16, 2020, at 5:44 PM, John Levine wrote: >> >> In article <27aaf010-714e-fa52-41fa-8670fb547b18@gmail.com> you write:= >>> Yes. The analogy with our pro bono counsel is a good one (except that= >>> I have no expectation of finding a pro bono RFC Series Advisor). Our = >>> previous pro bono counsel was with the IETF for at least 18 years. He= >>> got to know us fairly well. >> >> FYI, our lawyers are not pro bono, they're on retainer as was our >> prior lawyer. I agree with you that it is a good thing in these >> specialized jobs to have people stay long enough to learn what we do >> and how we work. >> >> FWIW, I've been around for quite a while but in my new role as tRSE >> I'm still learning all sorts of stuff about the process, the history, >> and the stuff we have yet to do. >> >> R's, >> John >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Wed Sep 16 16:24: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 9F9323A1223 for ; Wed, 16 Sep 2020 16:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNZnwacXOqhl for ; Wed, 16 Sep 2020 16:24:15 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995283A121F for ; Wed, 16 Sep 2020 16:24:15 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id k13so96884plk.3 for ; Wed, 16 Sep 2020 16:24:15 -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=mgCgeL1ZlrBZflTK1YIZAuLLJzpKGfLiocPiQari5vY=; b=dORH0h4SBOh6GhRrYVRORu+CD57ZAQomKkQL4vqTz5KOJHYQ638soAB/mOYBuDlVtY 2l7M4hKMaBdAtGJYG9S14q9eAQjzukf/7ozGzRapxnbcwQx9gxeWynoKLAp7nxbhwoxF q+ELH9WCfqpigqu32uHOm3UxA94gZa9LW7egIWYis1StD3Q+sf3bQMhuspAEU6waWUBf FD2Rd7PBWAyBRNhsN9rAzkULy3AQmbFRnGb7luzNvPO/BVs0JlTdqQFzhALCH6g6hteI 9IDpTp3pF6/2NfKeJAIAuk9qOXzyuGPz9VOUj2PVP373uWqMQ9Nxnbm81XhTVpVsuGQM UXUQ== 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=mgCgeL1ZlrBZflTK1YIZAuLLJzpKGfLiocPiQari5vY=; b=E+A5+tTvgsqjlMs2O5WC331az2nCU21EAw/GbMuOHAFsJyB6q3gcmNSeW0Uety9hu/ idvY4scLuka75Xw9eJwptm3UWi3M2Q7n5C4pA0XkXg8DwmdIP4yZwznUBdtaECQI22Je U2hoVx4QdZNPXP3k2F6LCrv1II3Vgf0OSKNEcgC0liCCnNp2ismzP7YvCT2u0aMtdPp/ SyMA6vWRoxZ0oK8ES9gnvgSG0ZeLxe9rmnGID7BYbSHVFJ0JYR51qhd/KunXqdZl5Vgs 1HW+rwGd4faGp/zXO4JytEx+XT735ghga/4PYn6XOqe/xhkp5cHDFIl//6umWtI9uMOQ +fQg== X-Gm-Message-State: AOAM533LIzooGtTg/zhx2lhxalOtms0jhhgsC64+LyeSmF9cKMkfk9XM Wtuy6Dg2GN41s6nzJzHDJe0I8o32UAE= X-Google-Smtp-Source: ABdhPJxtSEFpLomftRrwuxvBtXxRQ7noazl5kKrcZWgMz/UcD6IvZdD90re7WGAIetuSsbQxt2nMDQ== X-Received: by 2002:a17:90a:a016:: with SMTP id q22mr5574040pjp.99.1600298654729; Wed, 16 Sep 2020 16:24:14 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id a3sm18323027pfl.213.2020.09.16.16.24.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2020 16:24:14 -0700 (PDT) To: Eliot Lear , rfced-future@iab.org References: <5E6BF445-C0E6-456B-818C-6F77ADD244D4@cisco.com> From: Brian E Carpenter Message-ID: Date: Thu, 17 Sep 2020 11:24:12 +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: <5E6BF445-C0E6-456B-818C-6F77ADD244D4@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Some slides based on yesterday's discussion X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 23:24:17 -0000 Thanks Eliot, good slides. As one of the document authors involved, I'm going to do exactly nothing until we've had some review of those slides from non-authors. Regards Brian Carpenter On 17-Sep-20 00:33, Eliot Lear wrote: > Hi, > > The chairs will have more to say about how things went yesterday, but I wanted to share something based on the comparison I did. These are slides you are free to use as you see fit, but when it came to identifying issues, I thought these might prove helpful, to a point. > > Eliot > > From nobody Wed Sep 16 22:30: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 37D233A02BB for ; Wed, 16 Sep 2020 22:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=mwv4NJcx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lZ56bR3r Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc2dJ4GqS_Mt for ; Wed, 16 Sep 2020 22:30:25 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883C33A0140 for ; Wed, 16 Sep 2020 22:30:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2E28498B; Thu, 17 Sep 2020 01:30:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 17 Sep 2020 01:30: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=j ZvbEwsNZal9Jk9Yn19qfsM5mqZRAqDaRZ2Q0K0u2nk=; b=mwv4NJcxs9BAmBghA yZUWK9wVzn8dDarC0kiLc6+7/5VtyPo8MX2V3ROqKaooOGU4jHigwC3WuEN9Mi8C J3B2mcPwzd8pTVu+Z4GiTNxKBCQ77pjmTn7nnrS+3nFHWfVCz45B753DpcA+7YF9 ClFB0WEZSGq+Y08X3gZAGtDQnd5jfqh2cSIe4/jtxCjyKPKbIP29K/5UbuvitpOd 2LGpB/TActTyvXITM/6ZvP9SVVdUgo3dAXcHqMKdicSdKLR9+3OCbRVjRlcHWXQu 9YMnzfCpLE0AX4DkEXUdLkThGFsJva+6gF7sxPkxrNAfIa4dXFarKTiH1HNucm3a tTXdQ== 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=jZvbEwsNZal9Jk9Yn19qfsM5mqZRAqDaRZ2Q0K0u2 nk=; b=lZ56bR3rz3JfHCw+1LnDYkqMblQjbp8oLLgWJTYogd/hFtgkdl/7WpMoF Jf5sDbQtxc6eNaR0aTn0+Svm87OesaMfE24Qlm8oPKNH5vujAuVh6CFwtGTg9Zz1 GDkO3BxpawZRZ31B0EI4tZzpVRP/j5WMOvgVuPuVPYa4R5/DKfGmS9VBQUNkXLTp 2phf1b3FVlIAMSMVARvn4PX0gQ+idvp3qm47h3SRR5Tv43tcsXyCa5g/W7MmQ2Dz 7At45CQKW2iNP0oMWOKcODrXisJrl1ybu1t+Mg8rOB+LdANg/CwxQXI/7ST6ecvl 2a7f+bgcHOBwJ0tdWhk1bQgH1ghCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrtdefgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhe dunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 3C1E13064680; Thu, 17 Sep 2020 01:30:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Mark Nottingham In-Reply-To: Date: Thu, 17 Sep 2020 15:30:16 +1000 Cc: Adam Roach , adrian@olddog.co.uk, rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 05:30:27 -0000 Hi Joel, > On 17 Sep 2020, at 6:07 am, Joel M. Halpern = wrote: >=20 > I am very concerned by the proposals which remove the role of a = publication expert in providing guidance to the RPC (AMS provides direct = line management. They do not provide publication expertise in the sense = we mean it. Heck, although they provide the web publication service, = that is not their primary expertise.) This statement made me wonder why we assume it's necessary to separate = the function of the RSE and the RPC -- in other words, why can't AMS = provide publication expertise, as an expansion of their contract? After = all, they go through a process to hire people with specialised skills = (editors) to meet the terms of the contract; what makes providing advice = about publication different? That may or may not be a good thing for us to actually do, but if we = could articulate the reason(s) for that separation (or determine that = isn't not necessary), it might shed more light on our options. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Sep 16 22:35:36 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721363A044E for ; Wed, 16 Sep 2020 22:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqd3jPAhmK-q; Wed, 16 Sep 2020 22:35:32 -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 86CE33A044A; Wed, 16 Sep 2020 22:35:31 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3B9D99A5-8A37-4928-8D10-5CFBB7141161" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 17 Sep 2020 17:35:29 +1200 In-Reply-To: <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> Cc: "Joel M. Halpern" , rfced-future@iab.org, adrian@olddog.co.uk, Adam Roach To: Mark Nottingham References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 05:35:34 -0000 --Apple-Mail=_3B9D99A5-8A37-4928-8D10-5CFBB7141161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 17/09/2020, at 5:30 PM, Mark Nottingham wrote: >=20 > Hi Joel, >=20 >> On 17 Sep 2020, at 6:07 am, Joel M. Halpern = wrote: >>=20 >> I am very concerned by the proposals which remove the role of a = publication expert in providing guidance to the RPC (AMS provides direct = line management. They do not provide publication expertise in the sense = we mean it. Heck, although they provide the web publication service, = that is not their primary expertise.) >=20 > This statement made me wonder why we assume it's necessary to separate = the function of the RSE and the RPC -- in other words, why can't AMS = provide publication expertise, as an expansion of their contract? After = all, they go through a process to hire people with specialised skills = (editors) to meet the terms of the contract; what makes providing advice = about publication different? >=20 > That may or may not be a good thing for us to actually do, but if we = could articulate the reason(s) for that separation (or determine that = isn't not necessary), it might shed more light on our options. I can ask. Jay >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=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=_3B9D99A5-8A37-4928-8D10-5CFBB7141161 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 17/09/2020, at 5:30 PM, Mark Nottingham <mnot@mnot.net> = wrote:

Hi Joel,

On 17 Sep 2020, at 6:07 am, Joel M. Halpern <jmh@joelhalpern.com>= wrote:

I am very concerned by the = proposals which remove the role of a publication expert in providing = guidance to the RPC (AMS provides direct line management.  They do = not provide publication expertise in the sense we mean it.  Heck, = although they provide the web publication service, that is not their = primary expertise.)

This = statement made me wonder why we assume it's necessary to separate the = function of the RSE and the RPC -- in other words, why can't AMS provide = publication expertise, as an expansion of their contract? After all, = they go through a process to hire people with specialised skills = (editors) to meet the terms of the contract; what makes providing advice = about publication different?

That may or = may not be a good thing for us to actually do, but if we could = articulate the reason(s) for that separation (or determine that isn't = not necessary), it might shed more light on our options.

I can = ask.

Jay


Cheers,

--
Mark Nottingham   https://www.mnot.net/

--
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=_3B9D99A5-8A37-4928-8D10-5CFBB7141161-- From nobody Thu Sep 17 00:38: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 4AB9B3A0D93 for ; Thu, 17 Sep 2020 00:38:32 -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 H33IYGEhp5pW for ; Thu, 17 Sep 2020 00:38:31 -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 7F9D73A0D91 for ; Thu, 17 Sep 2020 00:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1437; q=dns/txt; s=iport; t=1600328310; x=1601537910; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=o6icYQ1CFN1b/JttsbpoWZvBLA7zhXJX5++lC+/U+Cs=; b=Yv5TRG5nmkEN6VUpqPnTayLRRrdkZI9AiQJ2l8GjdFhgtSpYNT8vj++A c4SIMxMa9yr/aHtRNLs0n4V1CboTav155Pl7LmEU0Fh8poOVifnvs3JuH JuE+chdj+5HhCOWF6X/t8dDT1CA9WOTM3U93mChg7J3qUYjP6V81qp0BV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAwB2EWNf/xbLJq1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DbwEgEiyEOYkCiBEmnB4LAQEBDQEBLwQBAYRLAoIkJTg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQYEbYVohXIBAQEBAgEjSA4FCwsOCgICJgICVwYTgya?= =?us-ascii?q?CXSC0CnaBMoVThQaBDiqNR4IAgTgMEIJNPoQ9gxczgi0EtyKCcYMRlzYDHpI?= =?us-ascii?q?RjmmvDINbAgQGBQIVgWsjgVczGggbFWUBgj4+EhkNnGg/AzA3AgYBCQEBAwm?= =?us-ascii?q?OXwEB?= X-IronPort-AV: E=Sophos;i="5.76,436,1592870400"; d="scan'208";a="29689787" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Sep 2020 07:38:26 +0000 Received: from [10.61.166.186] ([10.61.166.186]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 08H7cPkE013346 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Sep 2020 07:38:26 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Eliot Lear In-Reply-To: <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> Date: Thu, 17 Sep 2020 09:38:25 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.166.186, [10.61.166.186] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 07:38:32 -0000 Hi Mark, > On 17 Sep 2020, at 07:30, Mark Nottingham wrote: >=20 > This statement made me wonder why we assume it's necessary to separate = the function of the RSE and the RPC -- in other words, why can't AMS = provide publication expertise, as an expansion of their contract? After = all, they go through a process to hire people with specialised skills = (editors) to meet the terms of the contract; what makes providing advice = about publication different? I would take some care when considering things in this light to = distinguish what one views as strategic to the organization versus = operational. Joel=E2=80=99s point as I understand it is that one should = be wary of short term contracts for strategic aspects, lest all of that = context walks out the door. However, you also are highlighting that the IETF=E2=80=99s split of = responsibilities is unique. That is, most organizations house both = strategic/planning and operational functions vertically and integrally. = None of the current proposals recombine these aspects, although = Martin=E2=80=99s sort-of angles in that direction. =20 Where organizations vary is whether the strategic function is = represented at executive levels. That is the case with the IEEE and = SMTPE, for instance, but not so with ISO, ETSI or the ITU. And you know = more than I do about how this works at the W3C or WHATWG. =20 Eliot From nobody Thu Sep 17 04:10: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 134EF3A0544; Thu, 17 Sep 2020 04:10:16 -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 4mEmS2Bvu0vs; Thu, 17 Sep 2020 04:10:14 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6357C3A0522; Thu, 17 Sep 2020 04:10:14 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kIrno-0002Np-PH; Thu, 17 Sep 2020 07:10:12 -0400 Date: Thu, 17 Sep 2020 07:10:07 -0400 From: John C Klensin To: Eliot Lear , Mark Nottingham cc: rfced-future@iab.org Message-ID: <59DFCD3455C7604CC733BF8E@PSB> In-Reply-To: <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 11:10:16 -0000 TL;DR summary: if we are going to make comparisons to other organizations that might influence our decisions, those comparisons should be accurate and sometimes are not. --On Thursday, September 17, 2020 09:38 +0200 Eliot Lear wrote: >> On 17 Sep 2020, at 07:30, Mark Nottingham >> wrote: >> >> This statement made me wonder why we assume it's necessary to >> separate the function of the RSE and the RPC -- in other >> words, why can't AMS provide publication expertise, as an >> expansion of their contract? After all, they go through a >> process to hire people with specialised skills (editors) to >> meet the terms of the contract; what makes providing advice >> about publication different? > > I would take some care when considering things in this light > to distinguish what one views as strategic to the organization > versus operational. Joel's point as I understand it is that > one should be wary of short term contracts for strategic > aspects, lest all of that context walks out the door. FWIW, while we start from different places, my concern about respecting expertise and understanding that having rough consensus in some IETF body may not constitute informed consensus lead to nearly the same conclusions. > However, you also are highlighting that the IETF's split of > responsibilities is unique. That is, most organizations house > both strategic/planning and operational functions vertically > and integrally. None of the current proposals recombine these > aspects, although Martin's sort-of angles in that direction. > Where organizations vary is whether the strategic function is > represented at executive levels. That is the case with the > IEEE and SMTPE, for instance, but not so with ISO, ETSI or the > ITU. I don't know much about ETSI, but the situation with ISO (outside the special circumstances of ISO/IEC JTC1 which, btw, are becoming less special) and ITU are different enough that the dichotomy you suggest is not quite right. Those two differ but, to oversimplify, the "volunteer" groups that determine policy are official representatives of National Member Bodies and governments respectively, not the technical experts (and, btw, there are qualifications and vetting for those experts unlike the IETF's "all welcome as long as you don't behave really badly" policies). In addition, they both operate on "strong secretariat" and "edit first, vote later" models. Again oversimplifying, the secretariats have subject matter and publications expertise [1] and can, in practice, kill a proposal for standardization or a document. And, as discussed earlier on this list, having only final-form documents go through the final public review and approval processes changes this discussion enough that comparisons are difficult. > And you know more than I do about how this works at the > W3C or WHATWG. I will mostly defer to Mark on that, but again note that W3C has a professional staff with considerable technical subject matter expertise and ability to overrule the volunteers on standardization matters _and_ that they tend more toward living and incremental documents with snapshot than the more fixed (and hence potential of being archival) approach used by the IETF [2]. thanks, john [1] Ours have more than we often recognize, but "we" discourage them from even expressing those views in substantive discussions, much less making decisions that can override participant community consensus. [2] I think which is better and what we should be doing is another of the issues about which there are very fundamental differences of opinion on this list and probably in the IETf community, differences that, along with the questions of expertise and ones of whether it is actually important to get publications right from an editorial and technical clarity standpoint, probably go on any list of areas in which there are fundamental enough differences of opinion to make reaching consensus difficult. From nobody Thu Sep 17 05: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 819B53A0969 for ; Thu, 17 Sep 2020 05:22:30 -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 sgWcdM06p8eH for ; Thu, 17 Sep 2020 05:22:28 -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 95A7B3A09DA for ; Thu, 17 Sep 2020 05:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4814; q=dns/txt; s=iport; t=1600345347; x=1601554947; h=from:mime-version:subject:message-id:date:to; bh=N6jdKr1fAtcNFTGBkLCHKE9XaLQkN8l8k04zfvx01EA=; b=MQSuvJt4ru+KJ0Bj+Zhj5Tf93lpYVBa0ADL4aTUi7G7KCirhqBhQDXCB gKtrE/Qw7ITPNNIVQ+RnTkn1oNv+2nGiBwsyKI0AAs5THOEDScOhmlHR4 sr7U7lXQfmFLL0SxTpUHWdzKMwPv3SDg9Y3Y7/rqQlORyyVdK++EhOWNF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBgCsVGNf/xbLJq1fHgEBCxIMhAq?= =?us-ascii?q?BdAEgEoRliQKIE5QriBkLAQEBDQEBLwQBAYZ0JTgTAgMBAQsBAQUBAQECAQY?= =?us-ascii?q?EbYVohhx1PgKEGIJ9piWOEHaBMoVThH+BOI1HggCBOAwQgiABiD4zgi0Etye?= =?us-ascii?q?CcYMRlzgDHoMJiXqFD45rrxKDWwIEBgUCFYFrI4FXMxoIGxU7KgGCPz0SGQ2?= =?us-ascii?q?OKxeBAgEIAY0aPwNnAgYBCQEBAwmOXwEB?= X-IronPort-AV: E=Sophos; i="5.76,436,1592870400"; d="scan'208,217"; a="29699983" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Sep 2020 12:22:01 +0000 Received: from [10.61.166.186] ([10.61.166.186]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 08HCM0FQ024441 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2020 12:22:01 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_03AC0887-B794-4352-BC83-6345E8FBBC59" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <7FFAF791-6432-4994-AFC3-AEAEE5C46EFB@cisco.com> Date: Thu, 17 Sep 2020 14:22:00 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.166.186, [10.61.166.186] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Summary of our last interim X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 12:22:31 -0000 --Apple-Mail=_03AC0887-B794-4352-BC83-6345E8FBBC59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The chairs would like to thank all who participated in the Interim, = with a special tip of the hat to those who helped take notes (Rich, Martin, and others). Summary The meeting convened at 11:00pm GMT on Tuesday, September 15th. After a = very quick view of the Note Well and Agenda, each author presented each = of the four proposals that the group had before us. Eliot then = presented a comparison that highlighted similarities and differences, = and then some discussion followed. There was some discussion about = which proposals were most similar, and Nevil indicated that he could = withdraw his in support of Mike=E2=80=99s. Nobody raised any objections = to this. The chairs had hoped to find a single draft that could be viewed as a = starting point. However, during the hum it became clear that a good = number of people were not yet ready to take such a decision. In the = jabber chat there were some concerns that by doing so, the inertia to = make changes from what was adopted would be too high. One person raised a particular issue, that even an advisor function = would not be sufficient to continue the existing RPC functions. Others = (in jabber) felt that this did not give the RPC enough credit. It was also suggested that a neutral editor try to capture things we = agree on. Unless a large number of people want to adopt one of the drafts, this is = how things will stand for now. Next Steps Eliot asked the authors to see how they might combine efforts.=20 Those people who said they were not ready should discuss, please, on = list, what will make them ready. We discussed the possibility of another interim, and in particular to = have that interim at a different time slot so as to share the pain. If = that meeting should come to pass we will have to put it on the calendar = very quickly. That requires progress in terms of convergence. = Otherwise our next scheduled meeting will be at IETF109. Eliot & Brian= --Apple-Mail=_03AC0887-B794-4352-BC83-6345E8FBBC59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
 The =
chairs would like to thank all who participated in the Interim, with a =
special tip of the hat to those who helped take notes (Rich,
Martin, and others).

Summary

The meeting convened at 11:00pm GMT on Tuesday, September 15th.  After a =
very quick view of the Note Well and Agenda, each author presented each =
of the four proposals that the group had before us.  Eliot then =
presented a comparison that highlighted similarities and differences, =
and then some discussion followed.  There was some discussion about =
which proposals were most similar, and Nevil indicated that he could =
withdraw his in support of Mike=E2=80=99s.  Nobody raised any objections =
to this.

The chairs had hoped to find a single draft that could be viewed as a =
starting point.  However, during the hum it became clear that a good =
number of people were not yet ready to take such a decision.  In the =
jabber chat there were some concerns that by doing so, the inertia to =
make changes from what was adopted would be too high.

One person raised a particular issue, that even an advisor function =
would not be sufficient to continue the existing RPC functions. Others =
(in jabber) felt that this did not give the RPC enough =
credit.
It=
 was also suggested that a neutral editor try to capture things we agree =
on.

Unless a large number of people want to adopt one of the drafts, this is =
how things will stand for now.

Next Steps

Eliot asked the authors to see how they might combine efforts.=20

Those people who said they were not ready should discuss, =
please, on list, what will make them ready.

We discussed the possibility of another interim, and in particular to =
have that interim at a different time slot so as to share the pain. If =
that meeting should come to pass we will have to put it on the calendar =
very quickly.  That requires progress in terms of convergence.  =
Otherwise our next scheduled meeting will be at =
IETF109.
Eliot & = Brian
= --Apple-Mail=_03AC0887-B794-4352-BC83-6345E8FBBC59-- From nobody Thu Sep 17 05:32: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 517433A09BA for ; Thu, 17 Sep 2020 05:32:36 -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 k3of1H_IsfV4 for ; Thu, 17 Sep 2020 05:32:35 -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 B557E3A0983 for ; Thu, 17 Sep 2020 05:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=474; q=dns/txt; s=iport; t=1600345954; x=1601555554; h=from:content-transfer-encoding:mime-version:subject: message-id:date:to; bh=5AhjYt7HhfjSqU1xfdwfeMsAuGl4a9cngkaPTl6UmP4=; b=dz57Xhc4fCTh7Zhbqarbny0YRiv8sZiHxKkzQL2ZCqZODM63d0pniKTp dQptoSKPE7Ri/q4pQ6o99L1l5qkO+h7ZX0bF6f9YSlErglRTHqUF/HAzj /x9NlRR4V1Mnt2Uoh4GaKgOg85qmQmzwLmON0ohU3ej9/lhioZSGU5aSY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBgDnVmNf/xbLJq1fHgEBCxIMQIU?= =?us-ascii?q?+ASAShGWJAogTnEQLAQEBDQEBLwQBAYZ0JTgTAgMBAQsBAQUBAQECAQYEbYV?= =?us-ascii?q?ohhyBCwImAoQYgn2mNI4QdoEyhVOEfIEOKo1HggCBOAwQgh8BAYV0gkozgi0?= =?us-ascii?q?EtyeCcQSDDZc4Ax6CdwGPGo5rrxKDWwIEBgUCFYFrI4FXMxoIGxVlAYI/PRI?= =?us-ascii?q?ZDZxoPwNnAgYBCQEBAwmOXwEB?= X-IronPort-AV: E=Sophos;i="5.76,436,1592870400"; d="scan'208";a="29638373" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Sep 2020 12:32:30 +0000 Received: from [10.61.166.186] ([10.61.166.186]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 08HCWTbU026583 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2020 12:32:29 GMT From: Eliot Lear Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <4932B312-8422-4C35-A385-F04FBA6AFFDB@cisco.com> Date: Thu, 17 Sep 2020 14:32:28 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.166.186, [10.61.166.186] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Just to follow up on participation X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 12:32:36 -0000 I had mentioned in the interim that initially I was concerned that we = would not have good participation in an open program to advise/oversee = RFC Editor. That=E2=80=99s why I put that minimum participation item in = the table. This is based on the activity I tracked on rfc-interest. On = the other hand, this program has been fairly active. We=E2=80=99ve had = some 30 or so people contribute to one extent or another over the last = several months. Eliot From nobody Thu Sep 17 06:30: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 2AD243A0B30 for ; Thu, 17 Sep 2020 06:30:43 -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, 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=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 nZYI0xy11S9H for ; Thu, 17 Sep 2020 06:30:41 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 40E6B3A0B35 for ; Thu, 17 Sep 2020 06:30:39 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id z18so942730qvp.6 for ; Thu, 17 Sep 2020 06:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QFV768/816NthYRjwezkjYDo09t+7RzlK67ifJ/ft6g=; b=LIfR/DaFiyx6Q9kyNt1vJd6zClf8X7b2AxLpEfsgMsx3JpCWGqcewHc+1/kBaEECuf 6f5396/0ySkG1taQYMtdLJeDhMmYCguM1VcEw5NH3Qjy3u+AP55Q+cpmUh2UF0Jpu5ow FONRK8wTxVL0D5wPlLila65lpuAevHxnFjQ/GL0J+R23YezE1fYX2DspAmDW7V/G2bXj jFHHdhjHyuL16e4Ef5OVp17u9/viJ0vbRrWyhi/lBYTKqPDRZFT15u7TZ9mVHxwEZFg6 Nn4zie0uJCcAFsbOsS7us7J8vf4d6MRrttfkc5tWyNQHjsjo7rzJUL2acDOfO/YU06f8 WSWw== 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=QFV768/816NthYRjwezkjYDo09t+7RzlK67ifJ/ft6g=; b=OmWM3gDoZDlbOKDFaHxidW6C4J33hxyqjGDYti6E6JbQX6bQnkqi5gspO6DZWN1bbb mDt2A+Fj/V+Yy142tLMcIRtKsF7u97MFsL6xDTsLvgz/t+TPwbfDVcXIe3zwAj1OuxNZ EO2zH9Wx17xfqaoZXcHcS0w5436H5XnTgAr65ZkR9U2HBwCKUb73lH1x0S2AYGktvbsT vrISMiU+shgTELXKtWCm2vVgtbeWeXQCYbnQNhUHSTk8/DmHmc7ebe+GES0ejN8+3b8c 8y3NPzVu69Mrrqlv5KW4+GbPILeslJIRkUB66PGxluqW+XgkOI9QK0XBD+gsScijd/2J D+pA== X-Gm-Message-State: AOAM5328F6O6H+N6DQGyZ68MdHD3JvNl0H8vElfxdFoPtulsSJD85lSz e8JNoyXJneHJjAOC7Zu4ek9OoGfTSkBbuw== X-Google-Smtp-Source: ABdhPJx9bj9JR38SZmztvW5RBbgnJA6tPqYqUXYuoUhd8OTr3bjIFRtVvvy+nW01ZzQ90urEF3ZRbg== X-Received: by 2002:a0c:a085:: with SMTP id c5mr29415423qva.30.1600349438093; Thu, 17 Sep 2020 06:30:38 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:d4f6:3f9c:c314:1894? ([2601:18b:300:36ee:d4f6:3f9c:c314:1894]) by smtp.gmail.com with ESMTPSA id v56sm22079867qtc.49.2020.09.17.06.30.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Sep 2020 06:30:37 -0700 (PDT) From: Ted Lemon Message-Id: <9A0A122B-3E4A-40DB-AB7D-5D1FB697C91A@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_07725019-DB09-4876-989E-51F27D919E28" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 17 Sep 2020 09:30:35 -0400 In-Reply-To: <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> Cc: rfced-future@iab.org To: Mark Nottingham References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 13:30:43 -0000 --Apple-Mail=_07725019-DB09-4876-989E-51F27D919E28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 17, 2020, at 1:30 AM, Mark Nottingham wrote: > This statement made me wonder why we assume it's necessary to separate = the function of the RSE and the RPC -- in other words, why can't AMS = provide publication expertise, as an expansion of their contract? After = all, they go through a process to hire people with specialised skills = (editors) to meet the terms of the contract; what makes providing advice = about publication different? Another thing to say about this, which perhaps has been considered = already, is that the existing RPC staff, whether AMS should hire the RSE = or not, are definitely qualified to help think about the problem of = hiring a good RSE, and should be able to spend time on the steering = committee. That is, if finding a qualified set of people to help oversee = or search for RSEs is challenging for the IETF, here is a pool which = contains perhaps not the exact experience set we need, but definitely a = more related experience set than would be typical of an IETF standards = geek. --Apple-Mail=_07725019-DB09-4876-989E-51F27D919E28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Sep 17, 2020, at 1:30 AM, Mark Nottingham <mnot@mnot.net> = wrote:
This = statement made me wonder why we assume it's necessary to separate the = function of the RSE and the RPC -- in other words, why can't AMS provide = publication expertise, as an expansion of their contract? After all, = they go through a process to hire people with specialised skills = (editors) to meet the terms of the contract; what makes providing advice = about publication different?

Another thing to say about this, which = perhaps has been considered already, is that the existing RPC staff, = whether AMS should hire the RSE or not, are definitely qualified to help = think about the problem of hiring a good RSE, and should be able to = spend time on the steering committee. That is, if finding a qualified = set of people to help oversee or search for RSEs is challenging for the = IETF, here is a pool which contains perhaps not the exact experience set = we need, but definitely a more related experience set than would be = typical of an IETF standards geek.

= --Apple-Mail=_07725019-DB09-4876-989E-51F27D919E28-- From nobody Thu Sep 17 06:47: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 56CA23A0B48; Thu, 17 Sep 2020 06:47:37 -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 69Uj5fkcMsYW; Thu, 17 Sep 2020 06:47:35 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35AF3A0B34; Thu, 17 Sep 2020 06:47:34 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kIuG5-0002oL-Li; Thu, 17 Sep 2020 09:47:33 -0400 Date: Thu, 17 Sep 2020 09:47:28 -0400 From: John C Klensin To: Eliot Lear cc: rfced-future@iab.org Message-ID: <2C4DAA97D8015E8B19974BE7@PSB> In-Reply-To: <4932B312-8422-4C35-A385-F04FBA6AFFDB@cisco.com> References: <4932B312-8422-4C35-A385-F04FBA6AFFDB@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Just to follow up on participation X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 13:47:37 -0000 --On Thursday, September 17, 2020 14:32 +0200 Eliot Lear wrote: > I had mentioned in the interim that initially I was concerned > that we would not have good participation in an open program > to advise/oversee RFC Editor. That's why I put that minimum > participation item in the table. This is based on the > activity I tracked on rfc-interest. On the other hand, this > program has been fairly active. We've had some 30 or so > people contribute to one extent or another over the last > several months. Eliot, Observation from anecdotal data: This list/program appears to me to have drawn people who are concerned about the organizational structure of the RFC Editor function and the future of the Series. The rfc-interest list has tended to include topics associated with similar (and other) strategic issues and a lot of fairly low-level but intense discussions of, e.g., rather specific v3 issues. Those was are interested in one but not the other may either drop off or stop reading the message flow for an extended period. I don't think one can infer from either how much participation there would be in a long-term maintenance/ advice/ oversight effort, much less whether people with relevant expertise would participate. So I think some form of your minimum participation question -- if intended to extend past the immediate effort -- should remain on the table. john From nobody Thu Sep 17 07:58: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 C8DDF3A005C for ; Thu, 17 Sep 2020 07:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_V3-r3rNIfC for ; Thu, 17 Sep 2020 07:58:16 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A717E3A0039 for ; Thu, 17 Sep 2020 07:58:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Bsg7r2kC8z1ny9b; Thu, 17 Sep 2020 07:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1600354696; bh=N2WPX6VmrNe2edSIKwDa8hDoNoNSWdli+UVNF8dg6Yw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BlK5FX+c9hbh/C6NcfrtMCEp0YMwNEzdsAoXZBDelD83E2KB4OoBd11xIupASvnzK 0V2hxvyrhi+y96WweA78V7E4h+x9hz5q6TcJ0uHLE9TsEVSD6ov6ZoAwD+BRkIqtZ5 Tja7aXhEh4+AVvT8n1/VcsLzfr+vCP+hyGr4F+cM= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4Bsg7q0qR1z1ntfW; Thu, 17 Sep 2020 07:58:14 -0700 (PDT) To: Mark Nottingham Cc: Adam Roach , adrian@olddog.co.uk, rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> From: "Joel M. Halpern" Message-ID: Date: Thu, 17 Sep 2020 10:58:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 14:58:18 -0000 We could have tasked AMS with hiring the person. While way outside their wheelhouse, I presume they would do so if asked. But this person is making day-to-day judgment calls tied closely to community agreements. More so even than Jay as far as I can tell. Even if we remove the long term strategic component from the job, I would think we would want them closely tied to the community. Adding an extra level of indirection (Community->Jay->AMS->RPC Lead) seems like making things more complicated. For little or no benefit. Yours, Joel On 9/17/2020 1:30 AM, Mark Nottingham wrote: > Hi Joel, > >> On 17 Sep 2020, at 6:07 am, Joel M. Halpern wrote: >> >> I am very concerned by the proposals which remove the role of a publication expert in providing guidance to the RPC (AMS provides direct line management. They do not provide publication expertise in the sense we mean it. Heck, although they provide the web publication service, that is not their primary expertise.) > > This statement made me wonder why we assume it's necessary to separate the function of the RSE and the RPC -- in other words, why can't AMS provide publication expertise, as an expansion of their contract? After all, they go through a process to hire people with specialised skills (editors) to meet the terms of the contract; what makes providing advice about publication different? > > That may or may not be a good thing for us to actually do, but if we could articulate the reason(s) for that separation (or determine that isn't not necessary), it might shed more light on our options. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Thu Sep 17 09:33: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 840FD3A0DE0 for ; Thu, 17 Sep 2020 09:33: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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pnrvl8_PpaM for ; Thu, 17 Sep 2020 09:33:20 -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 1B49B3A0D89 for ; Thu, 17 Sep 2020 09:33:19 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id g3so2337792qtq.10 for ; Thu, 17 Sep 2020 09:33:19 -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=Xi5wQanFrHD8gHe5IDytOIyVGU4dGxKxZHq1jJnag7A=; b=WrlZQNyd0HDCyalb6S6W8yrWnS76TgJhKJHvrCXLP2O/W/yvUuzm26nM4v8/Cb18ww mVg3Kc2TG8rZSMVuCVakvB8WZ36ouc6pt8imX090ha0pbO+3eqMR5u+7echGTz55JSoH 2Hjf2PKHgp4XFI658Fg9s90fqqJUQDU3Br91rwIlMGFEbxwBnyeTBzHg2uyHZfjsNfRW zMIaL2wk0yzCLbSTCEBbWOfwkTTKuANSFxLKaVFokP8KxaHERpG03z0uacw1gJIV7EV8 ZIy41x1VilSZ6KpxcnRkbg5YZF/2dAqEAJJJySH5VwQbrjWf8cdPzSZREx8vhf6EJDun XuGA== 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=Xi5wQanFrHD8gHe5IDytOIyVGU4dGxKxZHq1jJnag7A=; b=hSx2YNm8uJxBm5iCtuDe8MtbRHMgy2sgx56ZhcHEHammo3m/O46w1N2PnyOjIvu1ck cs5ZfhAqSnk/tEI1y0q/NV++OxkEjTzIhnqDlIZuHsicrs/dvNc9vO7FQcVYCTRcPazB mlBG7ldDBfwEewczvuIc8Y4VLepHJ1Ort5DKm+HWr0c9i9nVzlmUO8xqq2aoudQVR0me HQkH6tQwbDvamgX21RaXm+OSjAEKjXA/gTpPo/jotNhWGlf5d0+PzSLtLR69ufviFTPl OLNJNVmWmdFf6YQchv+M25mb5jgcO/p+TVHaPLbLK8ntLZC0GpUcZ7sXmnxm/g7nAXUN srNA== X-Gm-Message-State: AOAM531fYsBC+E1waf2oPyN7g1TDCc3Wp6Z5rpJOvJdTbCeP+zyNqEjs tuYcHrhTOY2/eIbvuxP1V/pFQw6AncYPLFD/X+Y= X-Google-Smtp-Source: ABdhPJw1657IHTf/ibDX6HyzDhbX70pLNTyfyFQIoXI0tq5N8VKEZIdwXXQAZympednLeNTbRSp1MQ== X-Received: by 2002:ac8:4d05:: with SMTP id w5mr28584663qtv.339.1600360398433; Thu, 17 Sep 2020 09:33:18 -0700 (PDT) Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id e24sm177197qka.76.2020.09.17.09.33.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2020 09:33:17 -0700 (PDT) To: rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> From: Michael StJohns Message-ID: Date: Thu, 17 Sep 2020 12:33:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 16:33:22 -0000 +1.  There's also the problem of having all of our eggs in one basket.  If for example AMS decided to get out of the IETF business, or the IETF behaved badly enough that AMS felt the relationship was no longer viable, we'd lose ALL of our publication expertise and especially the hard earned IETF specific parts of that.  I would suggest that a small bit of redundancy in this space is warranted. Mike On 9/17/2020 10:58 AM, Joel M. Halpern wrote: > We could have tasked AMS with hiring the person. > While way outside their wheelhouse, I presume they would do so if asked. > > But this person is making day-to-day judgment calls tied closely to > community agreements.  More so even than Jay as far as I can tell.  > Even if we remove the long term strategic component from the job, I > would think we would want them closely tied to the community.  Adding > an extra level of indirection (Community->Jay->AMS->RPC Lead) seems > like making things more complicated.  For little or no benefit. > > Yours, > Joel > > On 9/17/2020 1:30 AM, Mark Nottingham wrote: >> Hi Joel, >> >>> On 17 Sep 2020, at 6:07 am, Joel M. Halpern >>> wrote: >>> >>> I am very concerned by the proposals which remove the role of a >>> publication expert in providing guidance to the RPC (AMS provides >>> direct line management.  They do not provide publication expertise >>> in the sense we mean it.  Heck, although they provide the web >>> publication service, that is not their primary expertise.) >> >> This statement made me wonder why we assume it's necessary to >> separate the function of the RSE and the RPC -- in other words, why >> can't AMS provide publication expertise, as an expansion of their >> contract? After all, they go through a process to hire people with >> specialised skills (editors) to meet the terms of the contract; what >> makes providing advice about publication different? >> >> That may or may not be a good thing for us to actually do, but if we >> could articulate the reason(s) for that separation (or determine that >> isn't not necessary), it might shed more light on our options. >> >> Cheers, >> >> -- >> Mark Nottingham   https://www.mnot.net/ >> > From nobody Thu Sep 17 14:05:38 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAA13A0BC1 for ; Thu, 17 Sep 2020 14:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgsEuoACEh-N for ; Thu, 17 Sep 2020 14:05:36 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2076D3A0BB3 for ; Thu, 17 Sep 2020 14:05:36 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id w7so2008910pfi.4 for ; Thu, 17 Sep 2020 14:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MJxoeZ5dujMqAbufcdN+0oxRrLf8ll03MsWPckBGcko=; b=CyNrIIpDmWWyVVJiHpT6w+pXdsI5P6ohe+5mZlNpym8oWxNKWkP8HFGLot4ASmT3tE O/tM1y8RB9QLWqmOppHaGGIt+zpcMukoBdxnGDUWt0UUJa5PpiysXSnf3FxqAnL5ppnS njiicN4LfsTSumwh2ds9pF8b6FhRmB6HVq+XFY8jo2y56JxYDhv5+KpyQhqagwB8TtMC +W3PYu3fsNfFoAHbqlaTQYG44r1WEVjy1sejMgQEGzpBBzpf/40PL7c31IWMrFmPnNjj 4tBQPKzrgvjplmmE0lx1OJFFmkoMCkL8FrBXl40lrZz2h7ySHA3bHeidgIKWlzrviWnT 8gng== 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=MJxoeZ5dujMqAbufcdN+0oxRrLf8ll03MsWPckBGcko=; b=NEMgMoHK4qdD5vhX01fNwFI45+UfxR2GnYVt9zVROcklFIEI/r7Ou+83JZ30wwF6lh Ofs9Cgjeg+MgspAbr+exLFlqSV+2QkAbNAKsXWF8Lc55WkDh4yktFteMf2oYM/PleYkh K/Q7d1T6z19FeuiFG1cf1qRh7ESHjevm6boZZpGQmw7ljWB8ifC8tS6lg1amLL4cD3S7 CdgjalsZY+68DgmqnhNgc60USsSfPajxPfvpBsslmxl4GcwWdrFBW/TZTMSDdP+BcQ4/ iBXmrRmQory/dAsZ27dE7QKLxSBgWiQWQBmXCPUw/kLhG4qaTqk1qeDmtjhCH9H8M2Kl SjAw== X-Gm-Message-State: AOAM531L2EPSaAqI3NsFd6AnP3+rlkf3mZXhSNlcWXWjFE7Meanh5XU9 uA8pbA3ofO8uHO6SDy985h44G84X5J8= X-Google-Smtp-Source: ABdhPJy+dEYTHuYabbDoCSxC6EiaZflqY9KiTn2Smdcz3C8s3YGW5GgenKF9FMCzT6Im1Xl+iwtd7w== X-Received: by 2002:a63:4f66:: with SMTP id p38mr23920701pgl.284.1600376735050; Thu, 17 Sep 2020 14:05:35 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id 197sm528765pgg.22.2020.09.17.14.05.32 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Sep 2020 14:05:34 -0700 (PDT) To: rfced-future@iab.org References: <4932B312-8422-4C35-A385-F04FBA6AFFDB@cisco.com> From: Brian E Carpenter Message-ID: Date: Fri, 18 Sep 2020 09:05:30 +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: <4932B312-8422-4C35-A385-F04FBA6AFFDB@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Just to follow up on participation X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 21:05:38 -0000 On 18-Sep-20 00:32, Eliot Lear wrote: > I had mentioned in the interim that initially I was concerned that we w= ould not have good participation in an open program to advise/oversee RFC= Editor. That=E2=80=99s why I put that minimum participation item in the= table. This is based on the activity I tracked on rfc-interest. On the= other hand, this program has been fairly active. We=E2=80=99ve had some= 30 or so people contribute to one extent or another over the last severa= l months. I don't know if it's encouraging or discouraging, but the fact is that th= e large majority of IETF participants just don't care about "admin stuff"= and that includes our topic here. You only hear from them when you've do= ne something wrong. Over on eligibility-discuss we have a similar situati= on (49 subscribers, and about 40 unique email senders). So I don't see how we can do better than making the discussion forum open= , announcing it, and accepting that most people will not show up unless w= e goof. Brian From nobody Thu Sep 17 14:33: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 0A3C23A0C7C for ; Thu, 17 Sep 2020 14:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 5805TF9d5ost for ; Thu, 17 Sep 2020 14:32:58 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E363A0C73 for ; Thu, 17 Sep 2020 14:32:57 -0700 (PDT) Received: from [192.168.217.118] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Bsqv95v7rzyfn; Thu, 17 Sep 2020 23:32:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 17 Sep 2020 23:32:53 +0200 Cc: rfced-future@iab.org X-Mao-Original-Outgoing-Id: 622071173.221976-fd4b01e57703f5de32ee7a9fb66330a4 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4932B312-8422-4C35-A385-F04FBA6AFFDB@cisco.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Just to follow up on participation X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 21:33:00 -0000 On 2020-09-17, at 23:05, Brian E Carpenter = wrote: >=20 > So I don't see how we can do better than making the discussion forum = open, announcing it, and accepting that most people will not show up = unless we goof. (The obvious answer is: goof.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Sep 17 15:18:24 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687243A0E00 for ; Thu, 17 Sep 2020 15:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=N5RhqOyQ; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=ZaLdxEec Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb_O8pFw95V1 for ; Thu, 17 Sep 2020 15:18:15 -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 B48333A0E24 for ; Thu, 17 Sep 2020 15:18:14 -0700 (PDT) Received: (qmail 2958 invoked by uid 100); 17 Sep 2020 22:18:13 -0000 Date: 17 Sep 2020 22:18:12 -0000 Message-ID: From: "John Levine" To: rfced-future@iab.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=b87.5f63e0a5.k2009; i=news@user.iecc.com; bh=XuxN0DSiG4r+5qNpIQvAY/mBxhfhEHQh1m9nKteUJR8=; b=N5RhqOyQFBnNwCE0vvWXFUKxG+VutIO0UBXWy31Bkzbvxaar/0MeZkPN6usPTESyJB8nFP2nkMj2op0YYDe+sMJMFmEwSmoNmbXVn3Clgqs5ssNkgaoovErO1487fpH4P5VEeBAGl8E6C4a0yxJ+C53prU+gxfyDnUXtBibTdewztLN+WJm9tedP7p7yWkfFvb0TT7mmpOLd72fffGZTP/nEnNb6NwTPHMRT+ezLLDKEvUqpNVUWPVH7vSOcjTKGhrCwI/vArD2HOSu7ODTpHcSidvFVmN/rsAomtxwmUPXbsuiBjy+cqFD0bEZlta3o/MjCaDRfO+kMHMG7bcF9Tw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=b87.5f63e0a5.k2009; olt=news@user.iecc.com; bh=XuxN0DSiG4r+5qNpIQvAY/mBxhfhEHQh1m9nKteUJR8=; b=ZaLdxEecWypmhiTJhzf5BGdEcfFJRRynyXiGZSkRZ1Z8jVs75dvX/lTh5u/MFCxJ9XpEskZgO7LTmsfaAEiT737Nhkeu6d1q89p4HYyDif81GGU+a2FIHv8um902zXb7s2phGlKWcTMeR68QfQdX0LHnr5zyA4Dsz25I1M/RpBrpTPXX0u3mziEAVRSqt+9Ue+/pkC6kZ1Rk+KFaTTx4vlas6Ty4aAcjog2EY8GVYgcAY29+2M6cv9dVZstxkwAFD+rN0xs05G1shdVSDfJsYpxj7UM7WLFG/XYE7/KoEM1sCvxwYGZtsKXGi1pH6/UNlu3XfdDXdtrqTrY5iTcSFA== Organization: Taughannock Networks References: <4932B312-8422-4C35-A385-F04FBA6AFFDB@cisco.com> In-Reply-To: <4932B312-8422-4C35-A385-F04FBA6AFFDB@cisco.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [Rfced-future] Just to follow up on participation X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 22:18:22 -0000 In article , Brian E Carpenter wrote: >I don't know if it's encouraging or discouraging, but the fact is that the large majority of IETF participants just don't care about "admin >stuff" and that includes our topic here. You only hear from them when you've done something wrong. Over on eligibility-discuss we have a similar >situation (49 subscribers, and about 40 unique email senders). For the most part, I take that as a vote of confidence. The IETF works well enough that it's not worth their time to worry about admin stuff. Before we pat ourselves on the back too much, I'd also note that the amount of progress per megabyte read and written in IETF admin discussions is very low, so things have to be pretty bad to make it worth getting involved. R's, John -- 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 Thu Sep 17 16:46:33 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7503A0F56 for ; Thu, 17 Sep 2020 16:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=r3xmgzbh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RTWrR9VM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OBvl51_ND4H for ; Thu, 17 Sep 2020 16:46:30 -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 21F483A0F0F for ; Thu, 17 Sep 2020 16:46:29 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 418D45C0236 for ; Thu, 17 Sep 2020 19:46:29 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Thu, 17 Sep 2020 19:46:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=SYD4U HW3zcyrNuuHx3XALCNffTwdYBVZemTGNKXPh1Q=; b=r3xmgzbhh1qA3Y1IDc2Sz spTV3Ah3gXxzdfjQvukjn/3JXeHreTttFVz+XWpIHByH06WOOd7B/jUeiOQHlNkE FP/BoQDbcaJZd3Sun/zK9QljWF7YmChQOj0Fa1TzWcZs6G4vKOb8GrOfZ0bwP9re zVRdRs3tqqr61unex9SMnGVKDhV5nL8+kwXL8vHjQPBXr0ygNm99QxfZwQoOt/Lj YTe2Ku1zZsx3qRXuhGTGia74nOhI0Mz6YjO4O1My7BYNoDu9lpsCR/NhXpTrWVj+ EYbmMypKkt35/QB277SqmaQ3gEvrSoskT1H9WobgyS51WE7Xcn8H9I1NvgVCxTXz w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=SYD4UHW3zcyrNuuHx3XALCNffTwdYBVZemTGNKXPh 1Q=; b=RTWrR9VMO4lj/OoohWPeeOLdA5oSOdznZybd0A2LJecQhg/AgczxOcKMy /tOFJEWU8wAqfk/oEx5Mr2EENiBtnd+4iGyylPz2cD9Y7UlXYrOYMDWbfR1GxNVF JG8zO8eg09U9JuqRcKUEraRzlK1CvYiMkR+0A2vnQ0O8jC7t3ET2SrbIyzHerIuV i0Ae54RDduBpVkUSXDufK2ZijRcpjaeoOPeul3O3qVQiONUMoa3RnDNZqe7svmf6 3FfSYvGd46K7fHyMs0t6p9HetoCw3N40C57VCnzywumw9QhaXC60DG+SjZg6zy+W P+eKIY2uL1ImgUxEOgbm6z/CCDlJg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrtdehgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgjeeuudeiffeltdegle ehjedvtedtjeduudehgfegfefgkefgueeiteegffdttdenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E4FAF20066; Thu, 17 Sep 2020 19:46:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-324-g0f99587-fm-20200916.004-g0f995879 Mime-Version: 1.0 Message-Id: <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> In-Reply-To: <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> Date: Fri, 18 Sep 2020 09:46:10 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Trust_versus_accountability_=5BWas=3A_W?= =?utf-8?q?here_is_the_expertise=3F?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 23:46:32 -0000 On Thu, Sep 17, 2020, at 17:38, Eliot Lear wrote: > However, you also are highlighting that the IETF=E2=80=99s split of=20= > responsibilities is unique. That is, most organizations house both=20= > strategic/planning and operational functions vertically and integrally= .=20 > None of the current proposals recombine these aspects, although=20 > Martin=E2=80=99s sort-of angles in that direction. =20 I want to understand your point better here, because I don't think that = I was suggesting the sort of integration you suggested. What aspects do= you believe that I am proposing be recombined? I did envisage that the short-term, tactical decisions would be made by = the editing/publishing house. But only to the extent that they are nece= ssary to ensure operational continuity. That is, if you need a decision= to finalize a document, then it is tactical and a decision can be made.= (I've seen this many times in AUTH48 recently and for the most part, s= ensible proposals are made by RPC staff and those are what gets enacted,= other times I or another editor have made suggestions, a few cases have= involved John.) But strategic direction needs to be set outside of tha= t process[*]. [*] My expectation is that we will need processes to ensure that a patte= rn of tactical decisions don't turn into decisions about strategic direc= tion. That process is not something I've developed more, because it's a= relatively unimportant detail, but I have some ideas. From nobody Thu Sep 17 19:08: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 51F503A1081 for ; Thu, 17 Sep 2020 19:08: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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVCtvSnBZP1r for ; Thu, 17 Sep 2020 19:08:53 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9AF3A0A9F for ; Thu, 17 Sep 2020 19:08:53 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kJ5pT-00059q-H0; Thu, 17 Sep 2020 22:08:51 -0400 Date: Thu, 17 Sep 2020 22:08:45 -0400 From: John C Klensin To: Michael StJohns , rfced-future@iab.org Message-ID: <100FCD5499178A7D13417D40@PSB> In-Reply-To: References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 02:08:55 -0000 +1 to both this and Joel's comment. =20 It again seems to me that this is another symptom of one of those fundamental differences in perspective, preferences, and assumptions. I don't know if I can state this in a way that is fair to both sides but it seems to me that, at the extremes: One set of assumptions is that most of our documents are close to ok when they get through the IESG (or equivalent for other streams); that only light copy editing is needed (if that); that if authors are not comfortable in American English, implications of that should be sorted out long before their document leaves the Stream and enters production; that some stylistic inconsistencies are ok (especially if it saves time) and that we really should not be insisting on stylistic and layout issues that go much beyond those required for consistency with RFC 7841 and assorted IPR documents; and that, if some issues in the language used in a specification are later identified as ambiguous or otherwise problematic, it will be fine to issue errata, assume everyone will find them, and treat them as authoritative changes. One consequence of those assumptions is that we don't need anything equivalent to an RSE at all except maybe as a source of occasional advice (and probably not that) and that the RPC can do anything that is needed and that the RPC staff may actually be overqualified and intervening in documents too much. At the other extreme, the assumptions are that we want a highly professional series (a series, not just a collection of documents we found a way to number), a consistent and professional style, an editorial team that is expected to have enough subject matter to work with the terminology and issues of technical clarity (not just pure copy-editing), and documents that are archival not only in the physical preservation sense but also of providing a record of the evolution of thinking about the technical properties and protocols of the Internet. IT seems to me that, unless we can figure out how to discuss the differences among those points of view (and points in between) and decide, meetings that end in "not ready yet" may be inevitable because the issues we are discussing may be largely just symptoms. john --On Thursday, September 17, 2020 12:33 -0400 Michael StJohns wrote: > +1.=C2=A0 There's also the problem of having all of our eggs = in > one basket.=C2=A0 If for example AMS decided to get out of the > IETF business, or the IETF behaved badly enough that AMS felt > the relationship was no longer viable, we'd lose ALL of our > publication expertise and especially the hard earned IETF > specific parts of that.=C2=A0 I would suggest that a small bit = of > redundancy in this space is warranted. >=20 > Mike >=20 > On 9/17/2020 10:58 AM, Joel M. Halpern wrote: >> We could have tasked AMS with hiring the person. >> While way outside their wheelhouse, I presume they would do >> so if asked. >>=20 >> But this person is making day-to-day judgment calls tied >> closely to community agreements.=C2=A0 More so even than Jay = as >> far as I can tell.=C2=A0 Even if we remove the long term >> strategic component from the job, I would think we would >> want them closely tied to the community.=C2=A0 Adding an = extra >> level of indirection (Community->Jay->AMS->RPC Lead) seems=20 >> like making things more complicated.=C2=A0 For little or no >> benefit. >>=20 >> Yours, >> Joel >>=20 >> On 9/17/2020 1:30 AM, Mark Nottingham wrote: >>> Hi Joel, >>>=20 >>>> On 17 Sep 2020, at 6:07 am, Joel M. Halpern >>>> wrote: >>>>=20 >>>> I am very concerned by the proposals which remove the role >>>> of a publication expert in providing guidance to the RPC >>>> (AMS provides direct line management.=C2=A0 They do not >>>> provide publication expertise in the sense we mean = it.=C2=A0 >>>> Heck, although they provide the web publication service, >>>> that is not their primary expertise.) >>>=20 >>> This statement made me wonder why we assume it's necessary >>> to separate the function of the RSE and the RPC -- in other >>> words, why can't AMS provide publication expertise, as an >>> expansion of their contract? After all, they go through a >>> process to hire people with specialised skills (editors) to >>> meet the terms of the contract; what makes providing advice >>> about publication different? >>>=20 >>> That may or may not be a good thing for us to actually do, >>> but if we could articulate the reason(s) for that >>> separation (or determine that isn't not necessary), it >>> might shed more light on our options. >>>=20 >>> Cheers, >>>=20 >>> --=20 >>> Mark Nottingham=C2=A0=C2=A0 https://www.mnot.net/ >>>=20 From nobody Thu Sep 17 20:52: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 ADF613A08B8 for ; Thu, 17 Sep 2020 20:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.398, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSavfF6p4FSQ for ; Thu, 17 Sep 2020 20:52:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F7F3A08B1 for ; Thu, 17 Sep 2020 20:52:23 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08I3qH1K067048 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 17 Sep 2020 22:52:19 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600401141; bh=lBG5FK6K1Bbm2jcSFMpztzL3suQzps7YsZWdrlJVQjQ=; h=Subject:To:References:From:Date:In-Reply-To; b=EJZeRa4YyfwithQLM6tOs+34imdXCprwOBlX0nhgQm2nsCs7i4D4QEdsAf9bUl31M UOKuu84WjlkeRRvbsP3gT4PLJgeF/1Qp6pdRfOkx6K/52Pdf5l2IQrvsVCbWT7Nrvd f43nqDtfvVLH06yTZYuXBEui8KSSN0etV7pryhJA= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: John C Klensin , Michael StJohns , rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> From: Adam Roach Message-ID: <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> Date: Thu, 17 Sep 2020 22:52:11 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <100FCD5499178A7D13417D40@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 03:52:25 -0000 On 9/17/2020 9:08 PM, John C Klensin wrote: > One set of assumptions is that most of our documents are close > to ok when they get through the IESG (or equivalent for other > streams); that only light copy editing is needed (if that); that > if authors are not comfortable in American English, implications > of that should be sorted out long before their document leaves > the Stream and enters production; that some stylistic > inconsistencies are ok (especially if it saves time) and that we > really should not be insisting on stylistic and layout issues > that go much beyond those required for consistency with RFC 7841 > and assorted IPR documents; and that, if some issues in the > language used in a specification are later identified as > ambiguous or otherwise problematic, it will be fine to issue > errata, assume everyone will find them, and treat them as > authoritative changes. I think this misrepresents the position of the folks who want a consultative RSE instead of an executive RSE. Nearly all of the functions you describe above are, and have for a long time been, in the remit of the RPC, not the RSE. I'm not even sure whether it would be within the charter of this effort to change them. For example, I think that publication strategy would be better off with a community-led process and a consultative RSE; while, at the same time, I disagree with almost everything about your foregoing characterization. What I would support (although I'd be probably be happy with alternatives) is a model that devolves the non-strategic aspects of the historic RSE role to an employee of the RPC (either selected from their current staff or hired, as they see fit), with the expectation that the RPC would continue to leverage their domain knowledge to ensure consistent, clearly-written, professional documents. /a From nobody Fri Sep 18 02:46: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 68C7D3A0B95 for ; Fri, 18 Sep 2020 02:46: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 XSjwtrCYxHVM for ; Fri, 18 Sep 2020 02:46:47 -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 B3EBC3A0B7E for ; Fri, 18 Sep 2020 02:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2383; q=dns/txt; s=iport; t=1600422406; x=1601632006; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mDRFe0uDAaGNorXz2RgPbMmvEg/qbrvrJ+JY+qlcX7Q=; b=WtA/tiP52aCrxIQEWPUzzpQrVylRK2Fftah25PInzQFg6TgJRZGiCpDt DqhLHY4uHgQNUbu7JGgALPoHIT6Wk7GanDqA9Y+Dix2BY6v+kqyyviQBE 8QuZa7MAGscOPyvk6M2o9l4O8LlFtpIgF1wmrHy5RbhciHbyHvJwrKSOL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAADGgWRf/xbLJq1fGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBT4F1NUl8ASASLIQ5iQKIOpwfCwEBAQ0BAS8EAQG?= =?us-ascii?q?ESwKCKyU4EwIDAQELAQEFAQEBAgEGBG2FaIVyAQECAgEjVgULGQoCAiYCAlc?= =?us-ascii?q?GE4Mmgl0gtHd2gTKFU4UBgQ4qjUeCAIE4HIpfM4ItBLcsgnEEgw2XOwMeoQK?= =?us-ascii?q?vGoNcAgQGBQIVgWsjgVczGggbFWUBgj4+EhkNjisXjiY/AzA3AgYBCQEBAwm?= =?us-ascii?q?OXwEB?= X-IronPort-AV: E=Sophos;i="5.77,274,1596499200"; d="scan'208";a="29730637" 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; 18 Sep 2020 09:46:25 +0000 Received: from dhcp-10-61-106-92.cisco.com (dhcp-10-61-106-92.cisco.com [10.61.106.92]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 08I9kO65032583 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 09:46:25 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Eliot Lear In-Reply-To: <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> Date: Fri, 18 Sep 2020 11:46:24 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <1144E853-B51A-4FAB-B90C-471CDCD7E677@cisco.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.106.92, dhcp-10-61-106-92.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] What is strategic? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 09:46:48 -0000 Hi Martin, > On 18 Sep 2020, at 01:46, Martin Thomson wrote: >=20 > On Thu, Sep 17, 2020, at 17:38, Eliot Lear wrote: >> However, you also are highlighting that the IETF=E2=80=99s split of=20= >> responsibilities is unique. That is, most organizations house both=20= >> strategic/planning and operational functions vertically and = integrally.=20 >> None of the current proposals recombine these aspects, although=20 >> Martin=E2=80=99s sort-of angles in that direction. =20 >=20 > I want to understand your point better here, because I don't think = that I was suggesting the sort of integration you suggested. What = aspects do you believe that I am proposing be recombined? The angling I was thinking of was as you described below. I believe you = intended either through your comments or the proposal itself to expand = the authority of the RPC, but by what degree I could not surmise. mm? = km? Somewhere in between? >=20 > I did envisage that the short-term, tactical decisions would be made = by the editing/publishing house. But only to the extent that they are = necessary to ensure operational continuity. That is, if you need a = decision to finalize a document, then it is tactical and a decision can = be made. (I've seen this many times in AUTH48 recently and for the most = part, sensible proposals are made by RPC staff and those are what gets = enacted, other times I or another editor have made suggestions, a few = cases have involved John.) But strategic direction needs to be set = outside of that process[*]. >=20 > [*] My expectation is that we will need processes to ensure that a = pattern of tactical decisions don't turn into decisions about strategic = direction. That process is not something I've developed more, because = it's a relatively unimportant detail, but I have some ideas. I would encourage that discussion now, so that everyone understands what = you and the others are proposing, and agrees on what is and is not = strategic. That might be something upon which we can find more common = ground across the proposals. I would hope that John Levine and perhaps = others like Nevil could help a little by discussing what is being done = by the RSE and what has been done in the past, and whether you would see = those tasks as strategic or tactical. Eliot= From nobody Fri Sep 18 05:34: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 E86113A083A for ; Fri, 18 Sep 2020 05:34:07 -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 kf5n8kPRPFtI for ; Fri, 18 Sep 2020 05:34:06 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C66C3A0838 for ; Fri, 18 Sep 2020 05:34:06 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kJFaW-0007TK-1n; Fri, 18 Sep 2020 08:34:04 -0400 Date: Fri, 18 Sep 2020 08:33:58 -0400 From: John C Klensin To: Adam Roach , Michael StJohns , rfced-future@iab.org Message-ID: <22961974432A8DE0994D3A6C@PSB> In-Reply-To: <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 12:34:08 -0000 --On Thursday, September 17, 2020 22:52 -0500 Adam Roach wrote: > On 9/17/2020 9:08 PM, John C Klensin wrote: >> One set of assumptions is that most of our documents are close >> to ok when they get through the IESG (or equivalent for other >> streams); that only light copy editing is needed (if that); >> that if authors are not comfortable in American English, >> implications of that should be sorted out long before their >> document leaves the Stream and enters production; that some >> stylistic inconsistencies are ok (especially if it saves >> time) and that we really should not be insisting on stylistic >> and layout issues that go much beyond those required for >> consistency with RFC 7841 and assorted IPR documents; and >> that, if some issues in the language used in a specification >> are later identified as ambiguous or otherwise problematic, >> it will be fine to issue errata, assume everyone will find >> them, and treat them as authoritative changes. > > > I think this misrepresents the position of the folks who want > a consultative RSE instead of an executive RSE. Nearly all of > the functions you describe above are, and have for a long time > been, in the remit of the RPC, not the RSE. I'm not even sure > whether it would be within the charter of this effort to > change them. > > For example, I think that publication strategy would be better > off with a community-led process and a consultative RSE; > while, at the same time, I disagree with almost everything > about your foregoing characterization. What I would support > (although I'd be probably be happy with alternatives) is a > model that devolves the non-strategic aspects of the historic > RSE role to an employee of the RPC (either selected from their > current staff or hired, as they see fit), with the expectation > that the RPC would continue to leverage their domain knowledge > to ensure consistent, clearly-written, professional documents. Adam, As I said, those were deliberately stated as extremes. At the same time, I continue to be concerned about two things that were a large fraction of what caused me to write that note: (1) community-driven process is a fine idea except that we have problems defining, and then capturing the wishes of, the relevant community for the RFC Series (or Collection). If it really means "IETF WG", "IAB Program", or even, "The IETF LLC ExecDir" then that isn't the community for the RFC Series and, more important, assumes types of knowledge that are not among the criteria for which those people are selected or self-select. (2) From my point of view, this whole problem [1] started because of a transition of the RSE from "respected senior colleague" to "just another contractor". While I have the highest confidence in AMS, making that role an employee of a contractor could make that problem even worse, discouraging the individual from speaking out on important issues. Part of the concern is that I don't think there is nearly as clear a line between "strategic" and "operational" as many people have assumed [2]. best, john [1] Or maybe it isn't a problem, just an opportunity to fix a system that, despite three major adjustments, had been working well for about 48 years: (i) replacing a staff that was highly skilled in the substantive technical content of Internet protocols with an editorial staff whose skill level is such that referring to them a "copy editors" is demeaning (and might even be considered oppressive or exclusionary language), (ii) switching to an explicit "streams" model and making the ISE a separate role, and (iii) separating the RSE role from direct production management and leadership. [2] part of the problem is that we have a long history of "you let them do that, therefore, not only do I get to do so too, but it is now policy" in this area. From nobody Fri Sep 18 08:55:38 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636D93A0F03 for ; Fri, 18 Sep 2020 08:55: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 sgBrs-LH9siR for ; Fri, 18 Sep 2020 08:55: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 0B4C53A0CD0 for ; Fri, 18 Sep 2020 08:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6620; q=dns/txt; s=iport; t=1600444527; x=1601654127; h=from:mime-version:subject:message-id:date:to; bh=BMu7j7jsJ0utUo/RWZIajbgSTFZiVbmXvoxDssaVPa4=; b=mfah8+FKd+i0yd8Fcr1oxXtKwIuY2dO47b5C37rrbhipQYQxuIsVOM7w 4DXCN8pkwf08r/MX5dsfN6W/dXfS0UeheFap06Pq1QCWpaZKgskt0KziA +U/EYueIbfDNUveI3bwq6MGbEbFAo6H8JYTVHe1485/1pdXNmB7JW0rut A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOBwBd12Rf/xbLJq1fHgEBCxIMghG?= =?us-ascii?q?DbQEgEoQlQIkCiBWULIgZCwEBAQ0BAS8EAQGGeSU4EwIDAQELAQEFAQEBAgE?= =?us-ascii?q?GBG2FaEMBEAGFMBdPIEQCgQaDEoJ9mgqMdY4QdoEyhVOEcoE4AYVMS4cvggC?= =?us-ascii?q?BOAwQghhzh1Qzgi0Ej2enRYJxBIMNjDeLBAMegwyJeoUPjm2uSlCDXAIEBgU?= =?us-ascii?q?CFYFrI4FXMxoIGxU7KgGCPz0SGQ1XnBE/A2cCBgEJAQEDCYUmiTkBAQ?= X-IronPort-AV: E=Sophos; i="5.77,274,1596499200"; d="scan'208,217"; a="29676170" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Sep 2020 15:55:23 +0000 Received: from [10.61.199.38] ([10.61.199.38]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 08IFtMU6031451 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 18 Sep 2020 15:55:22 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_6100CA67-6572-4F50-8B0E-BD962012B07F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> Date: Fri, 18 Sep 2020 17:55:22 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.199.38, [10.61.199.38] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 15:55:37 -0000 --Apple-Mail=_6100CA67-6572-4F50-8B0E-BD962012B07F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello everyone, =E2=80=9CWhen you come to a fork in the road, take it.=E2=80=9D =E2=80=94 Yogi Bera The chairs have had an opportunity to discuss the last interim. We note = that some people liked the comparison chart, as a means to highlight = both similarities and differences. We know that some people would very = much like to have seen a draft adopted, while others were not ready to = move forward. Several people would instead like to go issue by issue = and resolve those issues before adopting a draft. The chairs will leave = this choice to the group as to which way to proceed at the moment. You are invited to specify your preference on list by September 25th, = 2:00pm GMT. Option A or Option B. Please be explicit. We can pursue one of two approaches: Option A: Pursue adopting a draft The approach would be that we would adopt a draft by IETF 109 =E2=80=93 = as a starting point. To avoid further deadlocks, there would be no = =E2=80=9CI=E2=80=99m not ready=E2=80=9D option in the hum. Authors are = invited to merge and indicate open issues in drafts. Others are = invited, if they really feel the need, to create new drafts within 2-3 = weeks. If there are more than two options, the chairs will find ways to = wheedle things down to get to a draft to adopt, while being sensitive to = the concerns EKR and others raised about inertia of what is in a draft. = If the group would like an interim to facilitate this option, the chairs = will accommodate. Option B: Pursue open issues one by one Pursue issues one by one to resolve on list, starting with =E2=80=9CDo = people believe that the RSE position should continue in some form?=E2=80=9D= We would pursue from the nature of the role if we get an affirmative = answer. Other questions would follow, such as aspects of oversight and = relationship to RPC. If after the poll the group is evenly divided between these choices, in = order to take the fork, the chairs will spin a spinner and make a = decision. You are encouraged to discuss these options, and may change = your minds right up to the deadline. A Plea This program consists nearly exclusively of senior members of the = community- you are all past or current leaders of this organization = with deep experience and knowledge. We therefore hope that you will = seek to find common ground with one another when you see a deadlock in = view. Brian and Eliot --Apple-Mail=_6100CA67-6572-4F50-8B0E-BD962012B07F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello everyone,


=E2=80=9CW= hen you come to a fork in the road, take it.=E2=80=9D
=E2=80=94 Yogi Bera

The chairs have had an opportunity to = discuss the last interim.  We note that some people liked the = comparison chart, as a means to highlight both similarities and = differences.   We know that some people would very much like to = have seen a draft adopted, while others were not ready to move forward. =  Several people would instead like to go issue by issue and resolve = those issues before adopting a draft.  The chairs will leave this = choice to the group as to which way to proceed at the moment.

You are invited to = specify your preference on list by = September 25th, 2:00pm GMT.  Option A or Option B.  Please be = explicit.

We= can pursue one of two approaches:

Option A:  Pursue = adopting a draft

The approach would be that we would adopt a draft by IETF 109 =E2=80=93 as a starting point.  To avoid further deadlocks, = there would be no =E2=80=9CI=E2=80=99m not = ready=E2=80=9D option in the hum.  Authors are invited to merge and = indicate open issues in drafts.  Others are invited, if they really = feel the need, to create new drafts within 2-3 weeks.  If there are = more than two options, the chairs will find ways to wheedle things down = to get to a draft to adopt, while being sensitive to the concerns EKR = and others raised about inertia of what is in a draft.  If the = group would like an interim to facilitate this option, the chairs will = accommodate.

Option B: Pursue open issues one by one

Pursue issues one by one = to resolve on list, starting with =E2=80=9CDo people believe that the = RSE position should continue in some form?=E2=80=9D  We would = pursue from the nature of the role if we get an affirmative answer. =  Other questions would follow, such as aspects of oversight and = relationship to RPC.

If after the poll the group is evenly divided between these = choices, in order to take the fork, the chairs will spin a spinner and = make a decision.  You are encouraged to discuss these options, and = may change your minds right up to the deadline.

A Plea

This program consists = nearly exclusively of senior members of the community-  you are all = past or current leaders of this organization with deep experience and = knowledge.  We therefore hope that you will seek to find common = ground with one another when you see a deadlock in view.

Brian and = Eliot

= --Apple-Mail=_6100CA67-6572-4F50-8B0E-BD962012B07F-- From nobody Fri Sep 18 08:58: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 2CF553A0F79 for ; Fri, 18 Sep 2020 08:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.398, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz5kqWHcicS6 for ; Fri, 18 Sep 2020 08:57:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47DF3A126C for ; Fri, 18 Sep 2020 08:57:17 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08IFvEhT020676 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 10:57:15 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600444637; bh=pmiLSZFjlOX7DmgAqbnlAB2xONFOrl9qznZrhfdLssY=; h=Subject:To:References:From:Date:In-Reply-To; b=rQmUEw2JJXh37RtBOBgP4B0tNmsO0VR6GsKKJA6rp5zwA3aykFpzdUSm024ahO3pC kB22gLff5Hx3Hn3hi1ZDnSkolFUXFiKuKjeAgnRwpOsCmBWSsKWXn8zeyaNxleVtsJ K50s9nnYYuyiB1GEhdYsgOQw7FhCfhyp9uIhhDyg= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: John C Klensin , Michael StJohns , rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> From: Adam Roach Message-ID: <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> Date: Fri, 18 Sep 2020 10:57:07 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <22961974432A8DE0994D3A6C@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 15:58:00 -0000 On 9/18/2020 7:33 AM, John C Klensin wrote: > community-driven process is a fine idea except that we have > problems defining, and then capturing the wishes of, the > relevant community for the RFC Series (or Collection). I understand and admire the problem of not being able to clearly delineate the relevant community of interest. However, if the concern is that we might define a process that excludes their participation because they don't know about it, then moving instead to a model where they can't participate even if they do must be a step in the wrong direction. /a From nobody Fri Sep 18 09:12: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 9C26D3A102E for ; Fri, 18 Sep 2020 09:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9dQDpGwWNa7 for ; Fri, 18 Sep 2020 09:12:33 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014DE3A1039 for ; Fri, 18 Sep 2020 09:11:09 -0700 (PDT) Received: from [172.16.42.104] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BtJjS0vDwz1047; Fri, 18 Sep 2020 18:11:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> Date: Fri, 18 Sep 2020 18:11:07 +0200 Cc: rfced-future@iab.org X-Mao-Original-Outgoing-Id: 622138267.504244-4148060c7f4455aa09a2ae0c8ebcb239 Content-Transfer-Encoding: quoted-printable Message-Id: <824B3581-60AB-4EC8-8400-420B385567D1@tzi.org> References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 16:12:39 -0000 > On 2020-09-18, at 17:55, Eliot Lear = wrote: >=20 > Option A: Pursue adopting a draft > [=E2=80=A6] > Option B: Pursue open issues one by one >=20 > Pursue issues one by one to resolve on list, starting with =E2=80=9CDo = people believe that the RSE position should continue in some form?=E2=80=9D= =20 Now, what=E2=80=99s the difference? Adopting a draft essentially means = making at least this decision (unless we plan to adopt one draft and = then incrementally turn it into the other). I know that I can make a decision at this point, based on the = information I have from both my IETF experiences and general life = experience. Other people have different experiences, hence a different = perspective, and may therefore come up with a different decision. Not = sure that there is a way to somehow equalize those experiences. What we = maybe can do is discuss specific scenarios, and try to avoid process = confabulation (e.g., as in =E2=80=9Call humans SHOULD be good and wise, = and therefore=E2=80=A6=E2=80=9D). Choosing scenarios that have = different outcomes in the different models, but aren=E2=80=99t realistic = enough that we can discuss them with a view towards what would really = happen in practice, does not help. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Sep 18 09:12: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 5CD1C3A107F for ; Fri, 18 Sep 2020 09:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVqhpik8RyV3 for ; Fri, 18 Sep 2020 09:12:40 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DDB3A0FAC for ; Fri, 18 Sep 2020 09:12:38 -0700 (PDT) Received: from [172.16.42.104] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BtJl84wfvz103j; Fri, 18 Sep 2020 18:12:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> Date: Fri, 18 Sep 2020 18:12:36 +0200 Cc: John C Klensin , Michael StJohns , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 622138355.980516-8deac2df081593f6033725fcde880bc5 Content-Transfer-Encoding: quoted-printable Message-Id: <465EFD68-B661-4742-A9F1-29F1B078C3A1@tzi.org> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 16:12:43 -0000 On 2020-09-18, at 17:57, Adam Roach wrote: >=20 > can't participate Is that a property of one of the two drafts we are discussing? If yes, we should fix that. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Sep 18 09: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 DA9773A1053 for ; Fri, 18 Sep 2020 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4QhfjdhysBa for ; Fri, 18 Sep 2020 09:17:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668FC3A1058 for ; Fri, 18 Sep 2020 09:17:39 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08IGHboB027873 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 11:17:38 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600445858; bh=HKn5U6ePpQrZZY8ttwenbHieIQB9NgwQX7mtmR36Ntk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=WOQU52dJe9wELU1RPYvRjZ9qPvHKMtsfIeYOLOwqHjw1p96eVjr/2dMNp79K0544Q wn44Y04VhPIld0cQtjHm1NTytclSb+T4y3BFNQlbjVJZJIN0waQMew031WP4mLMj/g T4GGzTcrkhoyIoV4/NO9BXTHGLXw9cGi6XjaceYc= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Carsten Bormann Cc: John C Klensin , rfced-future@iab.org, Michael StJohns References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <465EFD68-B661-4742-A9F1-29F1B078C3A1@tzi.org> From: Adam Roach Message-ID: <51f2260d-3519-bf2a-f377-986af59c9db0@nostrum.com> Date: Fri, 18 Sep 2020 11:17:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <465EFD68-B661-4742-A9F1-29F1B078C3A1@tzi.org> Content-Type: multipart/alternative; boundary="------------8A777DAC1E7A7203FF2DEA33" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 16:17:44 -0000 This is a multi-part message in MIME format. --------------8A777DAC1E7A7203FF2DEA33 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 9/18/2020 11:12 AM, Carsten Bormann wrote: > On 2020-09-18, at 17:57, Adam Roach wrote: >> can't participate > Is that a property of one of the two drafts we are discussing? > If yes, we should fix that. You've left off the context here ("participating in what?"). John and I are discussing: * Participating in a community-driven process, or * Not participating in a community-driven process Any model that opts for an executive RSE instead of a community-driven process necessarily excludes participation in a community-driven process. /a --------------8A777DAC1E7A7203FF2DEA33 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 9/18/2020 11:12 AM, Carsten Bormann wrote:
On 2020-09-18, at 17:57, Adam Roach <adam@nostrum.com> wrote:

can't participate

Is that a property of one of the two drafts we are discussing?
If yes, we should fix that.


You've left off the context here ("participating in what?"). John and I are discussing:

  • Participating in a community-driven process, or
  • Not participating in a community-driven process


Any model that opts for an executive RSE instead of a community-driven process necessarily excludes participation in a community-driven process.

/a

--------------8A777DAC1E7A7203FF2DEA33-- From nobody Fri Sep 18 09:22: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 187293A10B6 for ; Fri, 18 Sep 2020 09:22:07 -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 qASOrHXttKlU for ; Fri, 18 Sep 2020 09:22:05 -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 70BAF3A10B5 for ; Fri, 18 Sep 2020 09:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1614; q=dns/txt; s=iport; t=1600446125; x=1601655725; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aaTYFV4Uo8YpS1NSV7+4okHcPO/fVaYmR2dtLDZjC4k=; b=YXifml9QPoWFIzSXKFznr3VgzOGXKYet9OFiEMkkLH0BEX8mfPpS1k7Z CPXa8n8VYBsuBgbvtrCNBTPeyv2JXA7GV1jPMtjJxBdvXRBsWFzuOIDsd 6HEGslPlFGlpKpCcQWZROjnq7YHxIq2emG8uRw8aLDbJFYVta8YpLzBYf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAAB83WRf/xbLJq1fGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIE+AgEBAQELAYNuASASLIQ5iQKIFSacHws?= =?us-ascii?q?BAQENAQEvBAEBhEsCgiwlNwYOAgMBAQsBAQUBAQECAQYEbYVohXIBAQEDASN?= =?us-ascii?q?WBQsLDgoCAiYCAlcGExmDDYJdILUQdoEyhVOEcoEOKgGNRoIAgTgMEIJNPoJ?= =?us-ascii?q?cBIFdgxczgi0EtyyCcYMRlzsDHoMMiXqFD45trxqDXAIEBgUCFYFqJIFXMxo?= =?us-ascii?q?IGxU7KgGCPj4SGQ2caD8DMAI1AgYBCQEBAwmOXwEB?= X-IronPort-AV: E=Sophos;i="5.77,274,1596499200"; d="scan'208";a="29738531" 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; 18 Sep 2020 16:22:01 +0000 Received: from [10.61.199.38] ([10.61.199.38]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 08IGM0L7005348 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 16:22:01 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Eliot Lear In-Reply-To: <824B3581-60AB-4EC8-8400-420B385567D1@tzi.org> Date: Fri, 18 Sep 2020 18:22:00 +0200 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <06CF1AB3-2709-44DF-AE5F-23576F90F520@cisco.com> References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <824B3581-60AB-4EC8-8400-420B385567D1@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.199.38, [10.61.199.38] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 16:22:07 -0000 > On 18 Sep 2020, at 18:11, Carsten Bormann wrote: >=20 >=20 >=20 >> On 2020-09-18, at 17:55, Eliot Lear = wrote: >>=20 >> Option A: Pursue adopting a draft >> [=E2=80=A6] >> Option B: Pursue open issues one by one >>=20 >> Pursue issues one by one to resolve on list, starting with =E2=80=9CDo = people believe that the RSE position should continue in some form?=E2=80=9D= =20 >=20 > Now, what=E2=80=99s the difference? =20 You may not have a preference and that is fine. But others expressed a = preference in our interim. If we adopt a draft there will certainly be = open issues to resolve. There is no getting around resolving our = differences. It is a matter of which method the group wants to pursue. > Adopting a draft essentially means making at least this decision = (unless we plan to adopt one draft and then incrementally turn it into = the other). I think from the chairs' point of view, we could indeed do exactly what = your parenthetical states. Some people are uncomfortable with that = approach. We are therefore offering an alternative based on a = suggestion made in the interim. >=20 > I know that I can make a decision at this point, based on the = information I have from both my IETF experiences and general life = experience. Other people have different experiences, hence a different = perspective, and may therefore come up with a different decision. =20 It is precisely because a large number of people were not ready to make = a decision that we are at this point. Eliot= From nobody Fri Sep 18 09:26: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 4A0D83A1123 for ; Fri, 18 Sep 2020 09:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_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 KqiiLkz91bCK for ; Fri, 18 Sep 2020 09:26:44 -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 52A363A1121 for ; Fri, 18 Sep 2020 09:26:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BtK3S1jzKz6G87s; Fri, 18 Sep 2020 09:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1600446404; bh=jUVfrmGcacTtqF0JOaKhtj/ST4chUYW+Fm5kZNT7lPQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dVQbEAs5iaZ72vlDRCpprAheYGaasBcKmlAPWUGXyGCUMoFNEnxPlOFRlv2lLcpWF 4m8qUwpujZB+8/ZMu6AaJaCSefTc/oRDkLZGMs/lCWXkgY9Js6Un4SXIUu9A+mc5Qq ZKTaELkU0CXvVXFKTa+fmscZxuZUNwR7sEAMVFI4= 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 4BtK3R4H9Bz6GJD1; Fri, 18 Sep 2020 09:26:43 -0700 (PDT) To: Adam Roach Cc: rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <465EFD68-B661-4742-A9F1-29F1B078C3A1@tzi.org> <51f2260d-3519-bf2a-f377-986af59c9db0@nostrum.com> From: "Joel M. Halpern" Message-ID: <4a4c1aaf-e182-ec0c-ae01-e5bfe1cae00b@joelhalpern.com> Date: Fri, 18 Sep 2020 12:26:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <51f2260d-3519-bf2a-f377-986af59c9db0@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 16:26:45 -0000 I hope that is not as strict a dichotomy as you describe. While the approach I described may not work, it seems like there ought to be some approach that allows for an effective leader of the series and effective and respected community input. Yours, Joel On 9/18/2020 12:17 PM, Adam Roach wrote: > On 9/18/2020 11:12 AM, Carsten Bormann wrote: >> On 2020-09-18, at 17:57, Adam Roach wrote: >>> can't participate >> Is that a property of one of the two drafts we are discussing? >> If yes, we should fix that. > > > You've left off the context here ("participating in what?"). John and I > are discussing: > > * Participating in a community-driven process, or > * Not participating in a community-driven process > > > Any model that opts for an executive RSE instead of a community-driven > process necessarily excludes participation in a community-driven process. > > /a > > From nobody Fri Sep 18 09:29:38 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49433A1128; Fri, 18 Sep 2020 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFKbNWQpIY-W; Fri, 18 Sep 2020 09:29:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA1F3A10E6; Fri, 18 Sep 2020 09:29:34 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08IGTVWY032165 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 11:29:33 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600446573; bh=ZZFDo+hkLjdl+fOKTm3hcSWSn02rbHyPOnbWhYMPhT8=; h=Subject:To:References:From:Date:In-Reply-To; b=cX7Txo0/Zhu44px7tuwr0t/0AM8MCLCPvjxPveeH4uFg8Jg/jPfl/hMYCATzJirFE t0pkY28ly3MRhhl6zwm9Kmy+vqkWC7GXpBE7yOILeVG4vnvh1k2r1AtX1Obf9BfvYc FQ43vvJWI9U6jJ4l8bL3/nh/jaRtCcVN8AsbW4/Y= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Eliot Lear , rfced-future@iab.org References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> From: Adam Roach Message-ID: Date: Fri, 18 Sep 2020 11:29:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> Content-Type: multipart/alternative; boundary="------------F59EDD38FCA271D4B458FDA5" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 16:29:37 -0000 This is a multi-part message in MIME format. --------------F59EDD38FCA271D4B458FDA5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have a strong preference for Option A. Our community doesn't have a good, established process in general for recording the result of point-by-point discussions an an accessible form other than recording them in an internet draft. (I don't consider trolling through voluminous email archives and meeting minutes to be "accessible.") We need a vehicle for tracking these decisions before we get too far down the path of making a long string of them. Unless we can agree on using some kind of issue-tracking system to record these decisions (which would be its own controversial bag of worms for the current set of participants), the conventional vehicle is an internet-draft. Let's get that in place and then start working on sanding down the rough edges. /a On 9/18/2020 10:55 AM, Eliot Lear wrote: > Hello everyone, > > > “When you come to a fork in the road, take it.” > — Yogi Bera > > The chairs have had an opportunity to discuss the last interim.  We > note that some people liked the comparison chart, as a means to > highlight both similarities and differences.   We know that some > people would very much like to have seen a draft adopted, while others > were not ready to move forward.  Several people would instead like to > go issue by issue and resolve those issues before adopting a draft. >  The chairs will leave this choice to the group as to which way to > proceed at the moment. > > You are invited to specify your preference *on list* *by September > 25th, 2:00pm GMT.  Option A or Option B.  Please be explicit.* > > We can pursue one of two approaches: > > *Option A:  Pursue adopting a draft* > > The approach would be that we *would* adopt a draft by IETF 109 – *as > a starting point*.  To avoid further deadlocks, there would be > *no* “I’m not ready” option in the hum.  Authors are invited to merge > and indicate open issues in drafts.  Others are invited, if they > really feel the need, to create new drafts within 2-3 weeks.  If there > are more than two options, the chairs will find ways to wheedle things > down to get to a draft to adopt, while being sensitive to the concerns > EKR and others raised about inertia of what is in a draft.  If the > group would like an interim to facilitate this option, the chairs will > accommodate. > > *Option B: Pursue open issues one by one* > > Pursue issues one by one to resolve on list, starting with “Do people > believe that the RSE position should continue in some form?”  We would > pursue from the nature of the role if we get an affirmative answer. >  Other questions would follow, such as aspects of oversight and > relationship to RPC. > > If after the poll the group is evenly divided between these choices, > in order to take the fork, the chairs will spin a spinner and make a > decision.  You are encouraged to discuss these options, and may change > your minds right up to the deadline. > > *A Plea* > > This program consists nearly exclusively of senior members of the > community-  you are all past or current leaders of this organization > with deep experience and knowledge.  We therefore hope that you will > seek to find common ground with one another when you see a deadlock in > view. > > Brian and Eliot > > --------------F59EDD38FCA271D4B458FDA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I have a strong preference for Option A.

Our community doesn't have a good, established process in general for recording the result of point-by-point discussions an an accessible form other than recording them in an internet draft. (I don't consider trolling through voluminous email archives and meeting minutes to be "accessible.")

We need a vehicle for tracking these decisions before we get too far down the path of making a long string of them. Unless we can agree on using some kind of issue-tracking system to record these decisions (which would be its own controversial bag of worms for the current set of participants), the conventional vehicle is an internet-draft. Let's get that in place and then start working on sanding down the rough edges.

/a

On 9/18/2020 10:55 AM, Eliot Lear wrote:
Hello everyone,


“When you come to a fork in the road, take it.”
— Yogi Bera

The chairs have had an opportunity to discuss the last interim.  We note that some people liked the comparison chart, as a means to highlight both similarities and differences.   We know that some people would very much like to have seen a draft adopted, while others were not ready to move forward.  Several people would instead like to go issue by issue and resolve those issues before adopting a draft.  The chairs will leave this choice to the group as to which way to proceed at the moment.

You are invited to specify your preference on list by September 25th, 2:00pm GMT.  Option A or Option B.  Please be explicit.

We can pursue one of two approaches:

Option A:  Pursue adopting a draft

The approach would be that we would adopt a draft by IETF 109 – as a starting point.  To avoid further deadlocks, there would be no “I’m not ready” option in the hum.  Authors are invited to merge and indicate open issues in drafts.  Others are invited, if they really feel the need, to create new drafts within 2-3 weeks.  If there are more than two options, the chairs will find ways to wheedle things down to get to a draft to adopt, while being sensitive to the concerns EKR and others raised about inertia of what is in a draft.  If the group would like an interim to facilitate this option, the chairs will accommodate.

Option B: Pursue open issues one by one

Pursue issues one by one to resolve on list, starting with “Do people believe that the RSE position should continue in some form?”  We would pursue from the nature of the role if we get an affirmative answer.  Other questions would follow, such as aspects of oversight and relationship to RPC.

If after the poll the group is evenly divided between these choices, in order to take the fork, the chairs will spin a spinner and make a decision.  You are encouraged to discuss these options, and may change your minds right up to the deadline.

A Plea

This program consists nearly exclusively of senior members of the community-  you are all past or current leaders of this organization with deep experience and knowledge.  We therefore hope that you will seek to find common ground with one another when you see a deadlock in view.

Brian and Eliot



--------------F59EDD38FCA271D4B458FDA5-- From nobody Fri Sep 18 09:35: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 120073A1024 for ; Fri, 18 Sep 2020 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcSZnHGSHVy3 for ; Fri, 18 Sep 2020 09:35:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17AE23A0CE7 for ; Fri, 18 Sep 2020 09:35:25 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08IGZMOD034255 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 11:35:24 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600446924; bh=EAJdAAIZtI/lQ1u3AdKOH+8hn5F3jaby0WBk9PEUYtw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=A7CkcInGr25Hoyzr99abaPu9I+72Qv9XItnIyIqi3g1Pc1EvFASDg8VeKVl/fcO3X WuRAIRm3F8vg5I7rF4yWRlJ8FzBBoPIBVMpqPrYdkdiz3nNFtDG3yY9rHeZjxCSrGG UNysOa+t5CoGIt+UneaL064PVgmlWBI/VlrX7qSc= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: "Joel M. Halpern" Cc: rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <465EFD68-B661-4742-A9F1-29F1B078C3A1@tzi.org> <51f2260d-3519-bf2a-f377-986af59c9db0@nostrum.com> <4a4c1aaf-e182-ec0c-ae01-e5bfe1cae00b@joelhalpern.com> From: Adam Roach Message-ID: <8bbaf52e-b9a8-e79a-c231-3cd26de1298c@nostrum.com> Date: Fri, 18 Sep 2020 11:35:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <4a4c1aaf-e182-ec0c-ae01-e5bfe1cae00b@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 16:35:26 -0000 On 9/18/2020 11:26 AM, Joel M. Halpern wrote: > I hope that is not as strict a dichotomy as you describe.  While the > approach I described may not work, it seems like there ought to be > some approach that allows for an effective leader of the series and > effective and respected community input. > Again,  you're losing the context here. I was specifically responding to John's assertion: > community-driven process is a fine idea except that we have > problems defining, and then capturing the wishes of, the > relevant community for the RFC Series (or Collection). ...which implicitly dismisses the notion of a community-driven process under the premise that some people might be excluded. My point -- and I'm trying to make a very narrowly-focused point here -- is that this specific line of argumentation is flawed inasmuch as you can't fix unintentional disenfranchisement by replacing it with intentional disenfranchisement. That's it. That's the point. That's the whole point. /a From nobody Fri Sep 18 09:37: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 19E483A1178 for ; Fri, 18 Sep 2020 09:37:11 -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=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 bd9QB1EX92rq for ; Fri, 18 Sep 2020 09:37:09 -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 9B1223A1179 for ; Fri, 18 Sep 2020 09:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1199; q=dns/txt; s=iport; t=1600447028; x=1601656628; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MsJNmN1pczI2WmHLWdMiSGg7u01aieSewdQB/3hJOls=; b=NZIrxv1VAexmB/dX1HZYusr1M7HZWHKvelYTcjlXBgptvmA63aLsPb3n Ds7my9XRcBXj5zbj2eE5UBX+TaZ6krb26RYVyaKAG2b2z+PHH/15EiQ3u TC0a7kpiaTWfyOLhF3jojjAZhoeXR/KrXZkWBSYHRVGd/mFZa0fyDCeCa o=; X-IPAS-Result: =?us-ascii?q?A0D7AgDX4WRf/xbLJq1fHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DbwEgEiyEOYkCiBYmmjaBaQsBAQENAQEvBAEBhEsCgiwlOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBG2FaIVyAQEBAwEjVgULCxgCAiYCAlcGExSDEoJdILUkd?= =?us-ascii?q?oEyhVOEf4EOKo1HggCBOAwQgTiBFT6ECAESASGDFzOCLQS3LIJxgxGXOwMeg?= =?us-ascii?q?wyJeoUPjm2vGoNcAgQGBQIVgWsjZ3AzGggbFWUBgj4+EhkNnGg/AzA3AgYBC?= =?us-ascii?q?QEBAwmOXwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,274,1596499200"; d="scan'208";a="27301014" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Sep 2020 16:37:04 +0000 Received: from [10.61.199.38] ([10.61.199.38]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 08IGb3ZR023885 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 16:37:04 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Eliot Lear In-Reply-To: Date: Fri, 18 Sep 2020 18:37:03 +0200 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> To: Adam Roach X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.199.38, [10.61.199.38] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 16:37:11 -0000 Hi Adam, > On 18 Sep 2020, at 18:29, Adam Roach wrote: >=20 > I have a strong preference for Option A. Noted. However=E2=80=A6 >=20 > Our community doesn't have a good, established process in general for = recording the result of point-by-point discussions an an accessible form = other than recording them in an internet draft. (I don't consider = trolling through voluminous email archives and meeting minutes to be = "accessible.") >=20 > We need a vehicle for tracking these decisions before we get too far = down the path of making a long string of them. Unless we can agree on = using some kind of issue-tracking system to record these decisions = (which would be its own controversial bag of worms for the current set = of participants), the conventional vehicle is an internet-draft. Let's = get that in place and then start working on sanding down the rough = edges. Neither chair has difficulty with managing an issue tracker. We can do = that job just fine. However, it may be the case that some find it = difficult to resolve issues on a transactional basis outside the context = of a draft. I take no position on that. Eliot From nobody Fri Sep 18 09:47: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 497253A11BE for ; Fri, 18 Sep 2020 09:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 Zl5RSpD_iTy5 for ; Fri, 18 Sep 2020 09:47:05 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E9C3A0D62 for ; Fri, 18 Sep 2020 09:47:04 -0700 (PDT) Received: from [172.16.42.104] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BtKVt5M7pz1047; Fri, 18 Sep 2020 18:47:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <8bbaf52e-b9a8-e79a-c231-3cd26de1298c@nostrum.com> Date: Fri, 18 Sep 2020 18:47:01 +0200 Cc: "Joel M. Halpern" , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 622140421.592881-fb820d62696f83f8e38ea024cc3e780f Content-Transfer-Encoding: quoted-printable Message-Id: <3987B6C7-082D-4E9B-B27C-8CCB5BC411F9@tzi.org> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <465EFD68-B661-4742-A9F1-29F1B078C3A1@tzi.org> <51f2260d-3519-bf2a-f377-986af59c9db0@nostrum.com> <4a4c1aaf-e182-ec0c-ae01-e5bfe1cae00b@joelhalpern.com> <8bbaf52e-b9a8-e79a-c231-3cd26de1298c@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 16:47:07 -0000 OK, maybe I need a definition of a community-driven process first. Also, why is that desirable? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Sep 18 10:09: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 8D19A3A11D7 for ; Fri, 18 Sep 2020 10:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwyU9aLNketH for ; Fri, 18 Sep 2020 10:09:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF973A11F4 for ; Fri, 18 Sep 2020 10:09:05 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08IH92TA045838 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 12:09:03 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600448944; bh=K0O4xEzW2/n9mm0JfkXMx6wHtg21G5Vln64j8DZ7sr8=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=u4E5hlcrZmF5F3ZmZijbrMOyoK5qPZgfzF0amyO0NK9VSx9KNZEAXRmk9ce99uLqE LCmHpNCz/N3v7mKnv8+JYF2z2D/H0ya8wzu2GDaboCaaneN9kYBQTrqyfEgZ9hGyvS Dm1n6h+kyYg8YSpqCKaWKnAhTwFEbBjDj/NX7GeA= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Carsten Bormann Cc: "Joel M. Halpern" , rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <465EFD68-B661-4742-A9F1-29F1B078C3A1@tzi.org> <51f2260d-3519-bf2a-f377-986af59c9db0@nostrum.com> <4a4c1aaf-e182-ec0c-ae01-e5bfe1cae00b@joelhalpern.com> <8bbaf52e-b9a8-e79a-c231-3cd26de1298c@nostrum.com> <3987B6C7-082D-4E9B-B27C-8CCB5BC411F9@tzi.org> From: Adam Roach Message-ID: <6e453610-2356-8d1f-04eb-9352d5c5ccbd@nostrum.com> Date: Fri, 18 Sep 2020 12:08:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <3987B6C7-082D-4E9B-B27C-8CCB5BC411F9@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 17:09:35 -0000 On 9/18/2020 11:47 AM, Carsten Bormann wrote: > OK, maybe I need a definition of a community-driven process first. While there are a lot of details left to be discussed, the general skeleton of this idea is described in https://tools.ietf.org/html/draft-thomson-rfced-model-00#section-5 > Also, why is that desirable? We reject kings, presidents, and voting? /a From nobody Fri Sep 18 12:06: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 64AEB3A0B10 for ; Fri, 18 Sep 2020 12:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjd0buI3A30D for ; Fri, 18 Sep 2020 12:06:46 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFAF3A0AFD for ; Fri, 18 Sep 2020 12:06:44 -0700 (PDT) Received: from [172.16.42.104] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BtNc30mbzz104C; Fri, 18 Sep 2020 21:06:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <6e453610-2356-8d1f-04eb-9352d5c5ccbd@nostrum.com> Date: Fri, 18 Sep 2020 21:06:42 +0200 Cc: rfced-future@iab.org, "Joel M. Halpern" X-Mao-Original-Outgoing-Id: 622148802.336839-d9e1efc6d56ea6805faf258044e519dd Content-Transfer-Encoding: quoted-printable Message-Id: References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <465EFD68-B661-4742-A9F1-29F1B078C3A1@tzi.org> <51f2260d-3519-bf2a-f377-986af59c9db0@nostrum.com> <4a4c1aaf-e182-ec0c-ae01-e5bfe1cae00b@joelhalpern.com> <8bbaf52e-b9a8-e79a-c231-3cd26de1298c@nostrum.com> <3987B6C7-082D-4E9B-B27C-8CCB5BC411F9@tzi.org> <6e453610-2356-8d1f-04eb-9352d5c5ccbd@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 19:06:49 -0000 On 2020-09-18, at 19:08, Adam Roach wrote: >=20 > On 9/18/2020 11:47 AM, Carsten Bormann wrote: >> OK, maybe I need a definition of a community-driven process first. >=20 >=20 > While there are a lot of details left to be discussed, the general = skeleton of this idea is described in = https://tools.ietf.org/html/draft-thomson-rfced-model-00#section-5 OK, I was looking for some discriminators that allow me to tell when a = process is community-driven and when not. In particular in contrast to the adjective =E2=80=9Cparticipatory=E2=80=9D= , which would be the more natural adjective for me to look for. >> Also, why is that desirable? >=20 >=20 > We reject kings, presidents, and voting? I just had dinner, and that included two slices of German rye bread. No kings, presidents, or voting were involved in creating these slices. As far as I can tell, the creation process wasn=E2=80=99t = community-driven either. But they were quite delicious. (And I can=E2=80=99t really say that about some more "community-driven" = food creation processes I experienced in the 1970s.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Sep 18 12:22: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 BE0C43A0ABB for ; Fri, 18 Sep 2020 12:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YuieDsDAfHOG for ; Fri, 18 Sep 2020 12:22:51 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 0E92A3A0CC5 for ; Fri, 18 Sep 2020 12:22:46 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id y11so6057642qtn.9 for ; Fri, 18 Sep 2020 12:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=ve9Tg2iJKHAeCwWT1lp9dMp6aGb50+Vq3PxQoKqSGeM=; b=JIGUf7uJEGp+y8cFQSr7KiVuRKHVVZL8nd5UgVqa0I/QucWriYwd6u8jHMOol6xE9j +yFd+fQj4hYUG/U903TaE+JDsMERERE+ySyql8xoS02ocyHzFNf33sBmfm1MySnV5ekw M56QmM4pDjw0DKXxqxrZGy9PPwfZLBRLO9/Ly07kBxLGznFIyr0kUo4e+WRvIWwBeLcQ +N42VpQDJkU/hacxz9nxCgUM5uVa0+Sz9Y34Fla0mJ6ATUsZPF/wlFKg/pH8w7agzXIx GiReQs0QIH1zolsVfridFnJg3CORE/9s40fKYJkknr4n5ZDnioupnCE5ndznoE7k20Em vpvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=ve9Tg2iJKHAeCwWT1lp9dMp6aGb50+Vq3PxQoKqSGeM=; b=dVE1QwlIKCPLaIjxwcpBAzKFp1wEJ6+ZVUsXUrQN1E3+QdEddeZzD3NXxWjl0MeEBu AVnC20FwiX9Qt10IsRhf3EuNbB2EdDieXDB1ABQhoOZ0spGN0T9m2Eu/dvTwQfgqnmSt 3D8BoyMJZLJSYhPN4iSQUhlqfJt7HEGagxvpuKMp8dQZOCOL+PBSHEi1NbVqTGlcCkHC chLVyCmVyRRhPp88wxQR8K5WsYjvISmaV6id/Od72K76zjdCMa1i6SEAKEtpAHKFQwOd WmmRbHB+HS7yPV2p2HoD4dWDy104Z/ukN+HDHP6Ku8PxsuLlJmgE8TrCeAKqB/5XfEza ldoQ== X-Gm-Message-State: AOAM533dqYpf3QIEX8PabsMXbgBJuG340pevvpDbD4dczEQsKlKkID87 9SGHTBqiWL4Po0mwXV06fjsOUFSvHQtPf+ySklY= X-Google-Smtp-Source: ABdhPJw1eWXwre5QGSB5O8Vi4wdKA9AUVyv83c7H3eorxsHIRYSXjdY4vJPq9R8HWSclP/QTPknuDw== X-Received: by 2002:ac8:2612:: with SMTP id u18mr36182278qtu.363.1600456965751; Fri, 18 Sep 2020 12:22:45 -0700 (PDT) Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id x126sm2721658qka.91.2020.09.18.12.22.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2020 12:22:45 -0700 (PDT) To: rfced-future@iab.org From: Michael StJohns Message-ID: Date: Fri, 18 Sep 2020 15:22:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Rfced-future] Question for discussion - Editorial Stream X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 19:22:53 -0000 Hi - I'm assuming that "if it wasn't written down it didn't happen" or more specifically, that changes to the publication system and model will be documented and those approved documents will inform any contracts or operational model.  If anyone disagrees with that assumption, I'd like to hear their reasoning. Based on that assumption, I have the following question and subsidiary questions: Question:  Do we create a separate Editorial Stream? If YES - Who approves documents in that stream? If NO - Where are documents that describe changes to the publication process and system published? (The answer implies who approves publication). Mike From nobody Fri Sep 18 13:06: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 E5DC83A0DD9; Fri, 18 Sep 2020 13:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oWrS38eRnta; Fri, 18 Sep 2020 13:06:24 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDA73A0F1D; Fri, 18 Sep 2020 13:06:22 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08IK6KUv002209; Fri, 18 Sep 2020 21:06:20 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F5822203D; Fri, 18 Sep 2020 21:06:20 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 7A2892203C; Fri, 18 Sep 2020 21:06:20 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.40.230]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08IK6JB0029461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 21:06:20 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> In-Reply-To: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> Date: Fri, 18 Sep 2020 21:06:19 +0100 Organization: Old Dog Consulting Message-ID: <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_040E_01D68DFF.8E84E7E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGR9HXXfL/DtwnRZr3fsQ1/cPZpL6n4A+zw Content-Language: en-gb X-Originating-IP: 87.112.40.230 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-25674.002 X-TM-AS-Result: No--16.329-10.0-31-10 X-imss-scan-details: No--16.329-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25674.002 X-TMASE-Result: 10--16.329100-10.000000 X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbJqvoi7RQmPS1B5mjfppvWAcNByoSo036c8J UuVypuWwWxOQEOPrFMpDdBuyu5ReTgXa2B9iG+mdsgYw1+LBrk0m4lf0t+giOIPLx3vY4vNiH4n PxqOq/H7eb5p3ZwHBlWXdNuEp4AiQuyY5a3tPHthyAOhmFi1q9vi4nVERfgwd4nhkC0SGkyQO9t Y4JLOlga2Fv4TmNgU8aE8D90AdeeR48YB5KfXbgoBLGxfH9hskIgt1z4icQSsAZTQQTIkkc6eV0 E9NH11CbXRjJgWvj8uaWp9S5dgwyOJ/03AG4a1S1wNy55SrlSzDUlFmeugumFmT1oQ//o7XoYQt KpMlR8wahRwrzSubOustZXC9ofqOrPvkNFf532SQgeuUY0WN7OyaqBNoQEAjbOl5ensg2nuU/b6 UMDzirojVhHQbN7L6H1cjNTv9dE7G3Ln492dljwcrQiFth97HfYrr1p9yfCp+SLLtNOiBhllq0V +VXbCp6KG1ERTFu0DFgo/bUR/ePzabt8FeyP7N9FHjNotpdxDpKYVp5Qz296req3y2ZbA8uj6eT zgCucnFFMjjdyxQT7DRpCatw1hndHt78eTrC4BEIZptz4D0ql3zXVYHvBcnF+ARCn6mF99Zyk8C OvNhB2gdlNcO87BB9Of2qvwdsqz6CK/AVxMLo+9VsdrlGzy3Q6/DFZugyt27/NQTVI1I+cxFQxp 3PhHymoRv4vCWtWO3WBVXyEWl0u84LVBXtoHOWcC0gYMYIWj54F/2i/DwjSPS9JdK3W4/bgY8Qw l4o87VaKp+SUEcO1DQ43dkW3a5LDC3FGTHI3eeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg1KMqIeOstifOMB0shqXhHoy3mziD2dLpmgwOLFVsFj8D9078KNholOXH4ujMlSFBAyCq/C0 FTow X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 20:06:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_040E_01D68DFF.8E84E7E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have sympathy with the =E2=80=9Cfear of inertia=E2=80=9D you attribute = to Ekr. I know that that should not happen, but I also know that it = happens both consciously and subconsciously. =20 I agree with Adam that we work best when we record things in drafts. =20 What you don=E2=80=99t want, now that you have pinned us to an A-or-B = decision, is a discussion of other options, but =E2=80=A6 =F0=9F=98=8A =20 Suppose we adopt an empty-ish draft (perhaps has background and = objectives, perhaps has initial list of open issues/questions) and then = follow option B recording each decision in the draft as it comes to = (rough) consensus?=20 =20 If you wanted to stick to your A-or-B choice, I guess that is B with a = plan on how to kickstart a draft and fill it in. =20 Best A (the name, not the option) =20 =20 From: Rfced-future On Behalf Of Eliot = Lear Sent: 18 September 2020 16:55 To: rfced-future@iab.org Subject: [Rfced-future] Moving forward: Please state your preference =20 Hello everyone, =20 =20 =E2=80=9CWhen you come to a fork in the road, take it.=E2=80=9D =E2=80=94 Yogi Bera =20 The chairs have had an opportunity to discuss the last interim. We note = that some people liked the comparison chart, as a means to highlight = both similarities and differences. We know that some people would very = much like to have seen a draft adopted, while others were not ready to = move forward. Several people would instead like to go issue by issue = and resolve those issues before adopting a draft. The chairs will leave = this choice to the group as to which way to proceed at the moment. =20 You are invited to specify your preference on list by September 25th, = 2:00pm GMT. Option A or Option B. Please be explicit. =20 We can pursue one of two approaches: =20 Option A: Pursue adopting a draft =20 The approach would be that we would adopt a draft by IETF 109 =E2=80=93 = as a starting point. To avoid further deadlocks, there would be no = =E2=80=9CI=E2=80=99m not ready=E2=80=9D option in the hum. Authors are = invited to merge and indicate open issues in drafts. Others are = invited, if they really feel the need, to create new drafts within 2-3 = weeks. If there are more than two options, the chairs will find ways to = wheedle things down to get to a draft to adopt, while being sensitive to = the concerns EKR and others raised about inertia of what is in a draft. = If the group would like an interim to facilitate this option, the chairs = will accommodate. =20 Option B: Pursue open issues one by one =20 Pursue issues one by one to resolve on list, starting with =E2=80=9CDo = people believe that the RSE position should continue in some = form?=E2=80=9D We would pursue from the nature of the role if we get an = affirmative answer. Other questions would follow, such as aspects of = oversight and relationship to RPC. =20 If after the poll the group is evenly divided between these choices, in = order to take the fork, the chairs will spin a spinner and make a = decision. You are encouraged to discuss these options, and may change = your minds right up to the deadline. =20 A Plea =20 This program consists nearly exclusively of senior members of the = community- you are all past or current leaders of this organization = with deep experience and knowledge. We therefore hope that you will = seek to find common ground with one another when you see a deadlock in = view. =20 Brian and Eliot =20 ------=_NextPart_000_040E_01D68DFF.8E84E7E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have sympathy with the = =E2=80=9Cfear of inertia=E2=80=9D you attribute to Ekr. I know that that = should not happen, but I also know that it happens both consciously and = subconsciously.

 

I agree = with Adam that we work best when we record things in = drafts.

 

What you = don=E2=80=99t want, now that you have pinned us to an A-or-B decision, = is a discussion of other options, but =E2=80=A6 😊

 

Suppose we = adopt an empty-ish draft (perhaps has background and objectives, perhaps = has initial list of open issues/questions) and then follow option B = recording each decision in the draft as it comes to (rough) consensus? =

 

If you = wanted to stick to your A-or-B choice, I guess that is B with a plan on = how to kickstart a draft and fill it in.

 

Best

A (the = name, not the option)

 

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of Eliot = Lear
Sent: 18 September 2020 16:55
To: = rfced-future@iab.org
Subject: [Rfced-future] Moving forward: = Please state your preference

 

Hello = everyone,

 

 

=E2=80=9CWhen you come to a fork in the road, take = it.=E2=80=9D

=E2=80=94 = Yogi Bera

 

The chairs have had an opportunity to discuss the last = interim.  We note that some people liked the comparison chart, as a = means to highlight both similarities and differences.   We know = that some people would very much like to have seen a draft adopted, = while others were not ready to move forward.  Several people would = instead like to go issue by issue and resolve those issues before = adopting a draft.  The chairs will leave this choice to the group = as to which way to proceed at the moment.

 

You are invited to specify your preference on = list by September 25th, 2:00pm GMT.  Option A or Option = B.  Please be explicit.

 

We can pursue one of two = approaches:

 

Option A:  Pursue adopting a = draft

 

The approach would be that we would adopt = a draft by IETF 109 =E2=80=93 as a starting point.  To avoid = further deadlocks, there would be no =E2=80=9CI=E2=80=99m = not ready=E2=80=9D option in the hum.  Authors are invited to merge = and indicate open issues in drafts.  Others are invited, if they = really feel the need, to create new drafts within 2-3 weeks.  If = there are more than two options, the chairs will find ways to wheedle = things down to get to a draft to adopt, while being sensitive to the = concerns EKR and others raised about inertia of what is in a draft. =  If the group would like an interim to facilitate this option, the = chairs will accommodate.

 

Option B: Pursue open issues one by = one

 

Pursue issues one by one to resolve on list, starting = with =E2=80=9CDo people believe that the RSE position should continue in = some form?=E2=80=9D  We would pursue from the nature of the role if = we get an affirmative answer.  Other questions would follow, such = as aspects of oversight and relationship to = RPC.

 

If after the poll the group is evenly divided between = these choices, in order to take the fork, the chairs will spin a spinner = and make a decision.  You are encouraged to discuss these options, = and may change your minds right up to the = deadline.

 

A Plea

 

This program consists nearly exclusively of senior = members of the community-  you are all past or current leaders of = this organization with deep experience and knowledge.  We therefore = hope that you will seek to find common ground with one another when you = see a deadlock in view.

 

Brian and Eliot

 

------=_NextPart_000_040E_01D68DFF.8E84E7E0-- From nobody Fri Sep 18 13:30: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 13CDD3A08B9; Fri, 18 Sep 2020 13:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6osw3zJ4yXc; Fri, 18 Sep 2020 13:30:19 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8063A08C1; Fri, 18 Sep 2020 13:30:18 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 08IKRCIo026042; Fri, 18 Sep 2020 21:30:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=CXV3Zr5Y4EHDDIhKZscv1Dw1jmGhYRsRYhinRcDOjQU=; b=A7F2+REyS/vctGOiFvkhUAc2lkUHJ1ZxapBxqmKKxZgxCXU6ePzNVxZZJkDp8Uhendq0 uCSazxrtcP7PhoLfoC3BF31pe9Ctf9VKDMdVEamEM22TNSpGJnfvY8grrAOvEWCmOIAv Lzk3QRAk389G272RLLJExlbVvTvJRdgkD+COEoo9VAtfYyLk9TvdpynWeMYfhu2SDCfl rISbNi+eZa7/3SfbSNqkH8n44drDTvQULmiybgYYyE79kdx7HWgED9jojkDoIZZOYviX /FqrnDa3RVpmw2t46yGyHHCY8h6Kw4wIaahMdLX43Yoideij0TYMGEC/l6iJl4FloUtN wQ== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 33m934vyaj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Sep 2020 21:30:17 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 08IKHGDj013666; Fri, 18 Sep 2020 13:30:17 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint5.akamai.com with ESMTP id 33k5ukp81n-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Sep 2020 13:30:16 -0700 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Sep 2020 16:30:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Sep 2020 16:30:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Fri, 18 Sep 2020 16:30:13 -0400 From: "Salz, Rich" To: "adrian@olddog.co.uk" , 'Eliot Lear' , "rfced-future@iab.org" Thread-Topic: [Rfced-future] Moving forward: Please state your preference Thread-Index: AQHWjdQqVPjb/qTtgEuYzXHR9SSbMqlvFb2A///DUYA= Date: Fri, 18 Sep 2020 20:30:12 +0000 Message-ID: References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> In-Reply-To: <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_B6DC11CAF6C2483D83F5801471FD0AB6akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-18_17:2020-09-16, 2020-09-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=944 adultscore=0 mlxscore=0 phishscore=0 malwarescore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009180162 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-18_17:2020-09-16, 2020-09-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 spamscore=0 priorityscore=1501 suspectscore=0 phishscore=0 mlxscore=0 impostorscore=0 adultscore=0 mlxlogscore=894 malwarescore=0 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009180165 Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 20:30:21 -0000 --_000_B6DC11CAF6C2483D83F5801471FD0AB6akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSWYgeW91IHdhbnRlZCB0byBzdGljayB0byB5b3VyIEEtb3ItQiBjaG9pY2UsIEkgZ3Vl c3MgdGhhdCBpcyBCIHdpdGggYSBwbGFuIG9uIGhvdyB0byBraWNrc3RhcnQgYSBkcmFmdCBhbmQg ZmlsbCBpdCBpbi4NCg0KU291bmRzIGxpa2Ug4oCcQeKAnSB0byBtZS4gIE1ha2UgYSBkcmFmdCDi gJMgY2FuIGJlIGRvbmUgaW4gMi0zIHdlZWtzIEkgZ3Vlc3Mg4oCTIGFuZCBvZmZlciBpdA0K --_000_B6DC11CAF6C2483D83F5801471FD0AB6akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <36F1326DB78BDA43949B808A46C9B028@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjIxMjIyNTg5Nzc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi04NjAzMzYyNDggNzY4MTM3Mzc0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPklmIHlvdSB3 YW50ZWQgdG8gc3RpY2sgdG8geW91ciBBLW9yLUIgY2hvaWNlLCBJIGd1ZXNzIHRoYXQgaXMgQiB3 aXRoIGEgcGxhbiBvbiBob3cgdG8ga2lja3N0YXJ0IGEgZHJhZnQgYW5kIGZpbGwgaXQgaW4uPG86 cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvdW5kcyBsaWtlIOKAnEHigJ0gdG8gbWUuJm5i c3A7IE1ha2UgYSBkcmFmdCDigJMgY2FuIGJlIGRvbmUgaW4gMi0zIHdlZWtzIEkgZ3Vlc3Mg4oCT IGFuZCBvZmZlciBpdA0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_B6DC11CAF6C2483D83F5801471FD0AB6akamaicom_-- From nobody Fri Sep 18 14:20: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 8BABC3A0B6B for ; Fri, 18 Sep 2020 14:20:11 -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 Bn6-EMaTwpP2 for ; Fri, 18 Sep 2020 14:20:10 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12C23A0B6A for ; Fri, 18 Sep 2020 14:19:48 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kJNnG-0009Hn-3c; Fri, 18 Sep 2020 17:19:46 -0400 Date: Fri, 18 Sep 2020 17:19:40 -0400 From: John C Klensin To: Adam Roach cc: Michael StJohns , rfced-future@iab.org Message-ID: <49F36E3E1027E1F46F31BF17@PSB> In-Reply-To: <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 21:20:12 -0000 --On Friday, September 18, 2020 10:57 -0500 Adam Roach wrote: > On 9/18/2020 7:33 AM, John C Klensin wrote: >> community-driven process is a fine idea except that we have >> problems defining, and then capturing the wishes of, the >> relevant community for the RFC Series (or Collection). > > > I understand and admire the problem of not being able to > clearly delineate the relevant community of interest. However, > if the concern is that we might define a process that excludes > their participation because they don't know about it, then > moving instead to a model where they can't participate even if > they do must be a step in the wrong direction. Having read your subsequent exchanges with Joel and Carsten, I think I finally understand where we disagree. Like the IETF in many cases, interested and affected outside parties are rarely heard from until something goes wrong and then they turn out to be good at complaining. I know that Jon (who was, for most of his tenure, not accountable to the IETF all all) got many such complaints and examples of feedback and that, in several cases, the series changed as a result. I know of at least one during Bob Braden's tenure and have no reason to believe there weren't others. I don't know about Heather's term other than the case that turned up in which someone outside the community discovered that had two RFCs with the same number. My point is that having an independent, visible, RSE (or equivalent) actually facilitates such communication in ways that an advisor who is on the staff of (or consultant to) a contractor may not. That distinction is especially important given the IETF's long tradition of telling people who show up with complaints or alternate ideas to go write drafts and participate in WGs because that is the only effective way to have their problems attended to. We certainly don't do that always, but we do it often enough to be a troubling example for cases like this. Later, in response to Carsten, you wrote... >> Also, why is that desirable? > > We reject kings, presidents, and voting? When Dave Clark make that comment, he was very clearly referring to our decisions about technical protocol work about the Internet. For this situation, it is a false analogy both because of the expertise issues discussed in this thread and because we rather often handle work for the IETF that is not directly network protocol or operational work in a way that might be construed as kings or presidents. IASA, and then to some degree IASA2, arose precisely out of realizations that the IETF community was not good at that sort of administrative work and that, if (and when) we tried to do it by community consensus, the people who were actively involved (by self-selection) were not representative of the broader community, not necessarily experts in the work area, etc. In the particular (and intentionally narrow) scope of his work, Jay is rather close to a President or at least a Prime Minister -- the LLC Board is an oversight body, not a management body and, while we would prefer it, not necessarily all experts in the substance of the management, administration, and finance parts of the work. Does the community get input? Certainly and none of the proposals I've seen so far prevent that even if "employee of a contractor" might actually be the worst option. Does the community make the decisions by informed consensus? Continuing the analogy it is noteworthy that he asks for consultation and/or feedback but then he, and the bodies he is working with make decisions that no one really pretends are made by community consensus. And it would be unwise to rely on community consensus for the RFC Editor Function because the IETF community doesn't have the expertise, because a self-selected WG is unlikely to accurately represent the preferences of the IETF community, and because the community for the RFC Series is larger than the IETF. best, john From nobody Fri Sep 18 14:43: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 9F12B3A0930 for ; Fri, 18 Sep 2020 14:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS6l5dKbZwlD for ; Fri, 18 Sep 2020 14:43:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A623A0921 for ; Fri, 18 Sep 2020 14:43:25 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08ILhM01040129 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Sep 2020 16:43:23 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600465404; bh=GZFwXj0PQd45G+ENq9EFFmiYXr1rSJY9UNzIR4NT88w=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=D/q/wpjSNQVCCxdKcj3N/cpdhlfsphF2Cywlt+rlMp38FHL7ls+HTj/vGUGRvSabR zrGFQtpgzUx5nWKeSc9wsUgPHOQ2pNJWIEXFiI32jfcfi0SsE0MhAi1HVoHlxXSqpb DBXNw97ybQIDgMNl0IIw0Xh9V2n8GSLfuJoP94eU= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: John C Klensin Cc: Michael StJohns , rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <49F36E3E1027E1F46F31BF17@PSB> From: Adam Roach Message-ID: <9cef985c-5f91-fe73-c440-0c6a296e5e71@nostrum.com> Date: Fri, 18 Sep 2020 16:43:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <49F36E3E1027E1F46F31BF17@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Sep 2020 21:43:27 -0000 On 9/18/2020 4:19 PM, John C Klensin wrote: > And it would be unwise to rely on community > consensus for the RFC Editor Function because the IETF community > doesn't have the expertise, because a self-selected WG is > unlikely to accurately represent the preferences of the IETF > community, and because the community for the RFC Series is > larger than the IETF. The "lack of expertise" you cite is precisely why this wouldn't work without a expert consultant. In terms of the other issues -- the IETF has always operated such that those who bother to show up to do the work are the ones who get a voice, and we seem to think that's okay. You have indicated a belief in a bright line between technical and non-technical matters in this regard; but note, e.g., that IASA2 was run as a working group with this exact set of caveats. (If I missed your congruent objections in the formation of that effort, I apologize for the oversight.) /a From nobody Fri Sep 18 19:02: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 0E9893A0F51 for ; Fri, 18 Sep 2020 19:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxIoV2Q38vJv for ; Fri, 18 Sep 2020 19:02:36 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 76C963A0F14 for ; Fri, 18 Sep 2020 19:02:36 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id u9so3925644plk.4 for ; Fri, 18 Sep 2020 19:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=v3uz9Wyn8ESKJGdp7NE8GTFcWm0O0vPjrC2R9sOqhS4=; b=fivZg9H/mxNAe1HMwLpIhatZ/Zn8yaCzmGX+z1ow9cpn5H78RJloG3V3VXsPT+j3U/ DByFgqImWrsTl9la4rXL04gpwv1CwptrnT+pEfg2gS4qBd8848t5jsB6/Zqy3qVckws0 07uNy03MDUBbk2R1EfCNx8fzxwnU3rizSypMpl+Qy/f+d0l35xvTiIBaQgB99R5KcWS/ vW4quFj8ecI9h3DwRPn8L3zafzuAmkfhqJJtk8bOgp8uC0wTPzQvEfcz7/Fy7Hznt4Uv NDhWIVDTKpiwG/FE3U+w+j2HAl3IqSSdJkbe2VSHzN6tKOFAlAcLCoyPCZtUyvcgQcV5 wbFw== 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=v3uz9Wyn8ESKJGdp7NE8GTFcWm0O0vPjrC2R9sOqhS4=; b=iSZ7eDmw09suEM7lfneFKq1JaGXe3sMnVZwCCCoBwVMKacOxUuPax9Nx/kBC+rmRsl Dy1INlH/IVidoXVnawxxp29ai+7ezzKh3Od0NEWrkXFBfsEkMOkVTDr51KkEt7pw+Nrp r/raFqwEjXPX5n0fGWTrObh/T+Ev1uL0cu6DsRleUnxBwKPOYg+MwdzUGWd1j5gRefeQ hr1WIMhOnw3z3vX0By5c9G4EHJs2sgZ9PCciy3Z7w61hlLWC2A/bh+dOrsetdAMs4WQ3 iJXz2l4FmruRhFnSCozsvLJ7H9GObmZCkdQfPHgvM/oDHjW4IAZl9CUZEgNfvLWP6S8o xbjA== X-Gm-Message-State: AOAM532nUrEAn8jIMUgUk6fycjgAXSuKvDIPPuuzQFJY3VV7Sz4f51a7 8d6vKl+/vJgXSzL20fRug7P1YQlCX/Q= X-Google-Smtp-Source: ABdhPJxzCJo3GV6E1O/h8rG30UqiaLFUiw8ZahzW3d75jIubCiE0zUvioe8wu9semJMrCge1+1d/Bg== X-Received: by 2002:a17:90b:617:: with SMTP id gb23mr14982656pjb.36.1600480955587; Fri, 18 Sep 2020 19:02:35 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id v21sm4364391pgl.39.2020.09.18.19.02.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2020 19:02:34 -0700 (PDT) To: Eliot Lear , rfced-future@iab.org References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> From: Brian E Carpenter Message-ID: Date: Sat, 19 Sep 2020 14:02:30 +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: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> Content-Type: multipart/mixed; boundary="------------5B217E08980B31291C1A6C1E" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 02:02:38 -0000 This is a multi-part message in MIME format. --------------5B217E08980B31291C1A6C1E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Before answering that, I wanted to better understand the discrepancies be= tween the models. Loosely based on Eliot's charts, I built the attached V= enn diagram. It's quite subjective, and it skips over many details and su= btleties. Comments are very welcome (but space for extra text is very lim= ited). It's still a bit complex at first sight, but I think we could reduce the = strategic questions to 5 or 6. My preference is to tackle that for a few = weeks, before attempting to munge the drafts. fwiw, the SVG file format is almost ready for inclusion in an I-D. Regards Brian Carpenter On 19-Sep-20 03:55, Eliot Lear wrote: > Hello everyone, >=20 >=20 > =E2=80=9CWhen you come to a fork in the road, take it.=E2=80=9D > =E2=80=94 Yogi Bera >=20 > The chairs have had an opportunity to discuss the last interim. =C2=A0W= e note that some people liked the comparison chart, as a means to highlig= ht both similarities and differences. =C2=A0 We know that some people wou= ld very much like to have seen a draft adopted, while others were not rea= dy to move forward. =C2=A0Several people would instead like to go issue b= y issue and resolve those issues before adopting a draft. =C2=A0The chair= s will leave this choice to the group as to which way to proceed at the m= oment. >=20 > You are invited to specify your preference *on list*=C2=A0*by September= 25th, 2:00pm GMT. =C2=A0Option A or Option B. =C2=A0Please be explicit.*= >=20 > We can pursue one of two approaches: >=20 > *Option A: =C2=A0Pursue adopting a draft* >=20 > The approach would be that we *would*=C2=A0adopt a draft by IETF 109 =E2= =80=93 *as a starting point*. =C2=A0To avoid further deadlocks, there wou= ld be *no*=C2=A0=E2=80=9CI=E2=80=99m not ready=E2=80=9D option in the hum= =2E =C2=A0Authors are invited to merge and indicate open issues in drafts= =2E =C2=A0Others are invited, if they really feel the need, to create new= drafts within 2-3 weeks. =C2=A0If there are more than two options, the c= hairs will find ways to wheedle things down to get to a draft to adopt, w= hile being sensitive to the concerns EKR and others raised about inertia = of what is in a draft. =C2=A0If the group would like an interim to facili= tate this option, the chairs will accommodate. >=20 > *Option B: Pursue open issues one by one* >=20 > Pursue issues one by one to resolve on list, starting with =E2=80=9CDo = people believe that the RSE position should continue in some form?=E2=80=9D= =C2=A0We would pursue from the nature of the role if we get an affirmati= ve answer. =C2=A0Other questions would follow, such as aspects of oversig= ht and relationship to RPC. >=20 > If after the poll the group is evenly divided between these choices, in= order to take the fork, the chairs will spin a spinner and make a decisi= on. =C2=A0You are encouraged to discuss these options, and may change you= r minds right up to the deadline. >=20 > *A Plea* >=20 > This program consists nearly exclusively of senior members of the commu= nity- =C2=A0you are all past or current leaders of this organization with= deep experience and knowledge. =C2=A0We therefore hope that you will see= k to find common ground with one another when you see a deadlock in view.= >=20 > Brian and Eliot >=20 >=20 --------------5B217E08980B31291C1A6C1E Content-Type: image/svg+xml; name="Venn3RFC.svg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Venn3RFC.svg" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+ CjwhRE9DVFlQRSBzdmcgUFVCTElDICItLy9XM0MvL0RURCBTVkcgMS4wLy9FTiIgImh0dHA6 Ly93d3cudzMub3JnL1RSLzIwMDEvUFItU1ZHLTIwMDEwNzE5L0RURC9zdmcxMC5kdGQiPgo8 c3ZnIHZpZXdCb3g9IjE1IC00NSA3ODAgMzgxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIj4K ICA8ZWxsaXBzZSBzdHlsZT0iZmlsbDogbm9uZTsgZmlsbC1vcGFjaXR5OjA7IHN0cm9rZS13 aWR0aDogMjsgc3Ryb2tlOiAjMDAwMDAwIiBjeD0iNDA2IiBjeT0iNzEiIHJ4PSIxMTIiIHJ5 PSIxMTIiLz4KICA8ZWxsaXBzZSBzdHlsZT0iZmlsbDogbm9uZTsgZmlsbC1vcGFjaXR5OjA7 IHN0cm9rZS13aWR0aDogMjsgc3Ryb2tlOiAjMDAwMDAwIiBjeD0iMzQwIiBjeT0iMTk0IiBy eD0iMTEwIiByeT0iMTEwIi8+CiAgPGVsbGlwc2Ugc3R5bGU9ImZpbGw6IG5vbmU7IGZpbGwt b3BhY2l0eTowOyBzdHJva2Utd2lkdGg6IDI7IHN0cm9rZTogIzAwMDAwMCIgY3g9IjI3NyIg Y3k9IjcxIiByeD0iMTE0IiByeT0iMTE0Ii8+CiAgPHRleHQgZm9udC1zaXplPSIxMS4yODg5 IiBzdHlsZT0iZmlsbDogIzAwMDAwMDt0ZXh0LWFuY2hvcjpzdGFydDtmb250LWZhbWlseTpz YW5zLXNlcmlmO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbCIgeD0iMTk2 IiB5PSI0MyI+CiAgICA8dHNwYW4geD0iMTk2IiB5PSI0MyI+Tm8gZmlndXJlaGVhZDwvdHNw YW4+CiAgICA8dHNwYW4geD0iMTk2IiB5PSI1Ny4xMTExIj5JQUIgb3ZlcnNpZ2h0PC90c3Bh bj4KICAgIDx0c3BhbiB4PSIxOTYiIHk9IjcxLjIyMjIiPjwvdHNwYW4+CiAgPC90ZXh0Pgog IDx0ZXh0IGZvbnQtc2l6ZT0iMTEuMjg4OSIgc3R5bGU9ImZpbGw6ICMwMDAwMDA7dGV4dC1h bmNob3I6c3RhcnQ7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjtmb250LXN0eWxlOm5vcm1hbDtm b250LXdlaWdodDpub3JtYWwiIHg9IjQwNSIgeT0iMTciPgogICAgPHRzcGFuIHg9IjQwNSIg eT0iMTciPlNlcmllcyBBZHZpc29yPC90c3Bhbj4KICAgIDx0c3BhbiB4PSI0MTAiIHk9IjMx LjExMTEiPiAodGhvdWdodCBsZWFkZXIsPC90c3Bhbj4KICAgIDx0c3BhbiB4PSI0MTAiIHk9 IjQ1LjIyMjIiPiBmaWd1cmVoZWFkKTwvdHNwYW4+CiAgICA8dHNwYW4geD0iNDA1IiB5PSI1 OS4zMzMzIj5JU09DIG92ZXJzaWdodDwvdHNwYW4+CiAgICA8dHNwYW4geD0iNDA1IiB5PSI3 My40NDQ0Ij5XRy9MTEMgc2VhcmNoPC90c3Bhbj4KICAgIDx0c3BhbiB4PSI0MTAiIHk9Ijg3 LjU1NTYiPiBjb21taXR0ZWU8L3RzcGFuPgogIDwvdGV4dD4KICA8dGV4dCBmb250LXNpemU9 IjExLjI4ODkiIHN0eWxlPSJmaWxsOiAjMDAwMDAwO3RleHQtYW5jaG9yOnN0YXJ0O2ZvbnQt ZmFtaWx5OnNhbnMtc2VyaWY7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFs IiB4PSIyNzkiIHk9IjE5NyI+CiAgICA8dHNwYW4geD0iMjc5IiB5PSIxOTciPlNlcmllcyBF ZGl0b3I8L3RzcGFuPgogICAgPHRzcGFuIHg9IjI4OSIgeT0iMjExLjExMSI+IChleGVjdXRp dmUgZmlndXJlaGVhZCk8L3RzcGFuPgogICAgPHRzcGFuIHg9IjI3OSIgeT0iMjI1LjIyMiI+ RGVzaWduYXRlIENvbnRyYWN0IE1vbml0b3JzPC90c3Bhbj4KICAgIDx0c3BhbiB4PSIyNzki IHk9IjIzOS4zMzMiPkV4ZWN1dGl2ZSBFZGl0b3JpYWwgQm9hcmQ8L3RzcGFuPgogICAgPHRz cGFuIHg9IjI4OSIgeT0iMjUzLjQ0NCI+IChzZWxmIG92ZXJzaWdodCwgTm9tQ29tKTwvdHNw YW4+CiAgICA8dHNwYW4geD0iMjc5IiB5PSIyNjcuNTU2Ij5Cb2FyZC9MTEMgc2VhcmNoPC90 c3Bhbj4KICAgIDx0c3BhbiB4PSIyODkiIHk9IjI4MS42NjciPiBjb21taXR0ZWU8L3RzcGFu PgogIDwvdGV4dD4KICA8dGV4dCBmb250LXNpemU9IjEyLjgiIHN0eWxlPSJmaWxsOiAjMDAw MDAwO3RleHQtYW5jaG9yOnN0YXJ0O2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsIiB4PSIyNzciIHk9IjcxIj4KICAgIDx0c3Bh biB4PSIyNzciIHk9IjcxIj48L3RzcGFuPgogIDwvdGV4dD4KICA8dGV4dCBmb250LXNpemU9 IjEyLjgiIHN0eWxlPSJmaWxsOiAjMDAwMDAwO3RleHQtYW5jaG9yOnN0YXJ0O2ZvbnQtZmFt aWx5OnNhbnMtc2VyaWY7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsIiB4 PSIyNzciIHk9IjcxIj4KICAgIDx0c3BhbiB4PSIyNzciIHk9IjcxIj48L3RzcGFuPgogIDwv dGV4dD4KICA8dGV4dCBmb250LXNpemU9IjExLjI4ODkiIHN0eWxlPSJmaWxsOiAjMDAwMDAw O3RleHQtYW5jaG9yOnN0YXJ0O2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7Zm9udC1zdHlsZTpu b3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsIiB4PSIyNTIiIHk9IjE1OCI+CiAgICA8dHNwYW4g eD0iMjUyIiB5PSIxNTgiPihub25lKTwvdHNwYW4+CiAgPC90ZXh0PgogIDx0ZXh0IGZvbnQt c2l6ZT0iMTIuOCIgc3R5bGU9ImZpbGw6ICMwMDAwMDA7dGV4dC1hbmNob3I6c3RhcnQ7Zm9u dC1mYW1pbHk6c2Fucy1zZXJpZjtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3Jt YWwiIHg9IjM0MCIgeT0iMTk0Ij4KICAgIDx0c3BhbiB4PSIzNDAiIHk9IjE5NCI+PC90c3Bh bj4KICA8L3RleHQ+CiAgPHRleHQgZm9udC1zaXplPSIxMi44IiBzdHlsZT0iZmlsbDogIzAw MDAwMDt0ZXh0LWFuY2hvcjpzdGFydDtmb250LWZhbWlseTpzYW5zLXNlcmlmO2ZvbnQtc3R5 bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbCIgeD0iMzQwIiB5PSIxOTQiPgogICAgPHRz cGFuIHg9IjM0MCIgeT0iMTk0Ij48L3RzcGFuPgogIDwvdGV4dD4KICA8dGV4dCBmb250LXNp emU9IjEyLjgiIHN0eWxlPSJmaWxsOiAjMDAwMDAwO3RleHQtYW5jaG9yOnN0YXJ0O2ZvbnQt ZmFtaWx5OnNhbnMtc2VyaWY7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFs IiB4PSI3MjMiIHk9IjQ0Ij4KICAgIDx0c3BhbiB4PSI3MjMiIHk9IjQ0Ij48L3RzcGFuPgog IDwvdGV4dD4KICA8dGV4dCBmb250LXNpemU9IjExLjI4ODkiIHN0eWxlPSJmaWxsOiAjMDAw MDAwO3RleHQtYW5jaG9yOnN0YXJ0O2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsIiB4PSIzMDkiIHk9IjM0Ij4KICAgIDx0c3Bh biB4PSIzMDkiIHk9IjM0Ij5PcGVuPC90c3Bhbj4KICAgIDx0c3BhbiB4PSIzMTkiIHk9IjQ4 LjExMTEiPiBzdHJhdGVneSBXRzwvdHNwYW4+CiAgICA8dHNwYW4geD0iMzA5IiB5PSI2Mi4y MjIyIj5MTEMgbW9uaXRvcnM8L3RzcGFuPgogICAgPHRzcGFuIHg9IjMxOSIgeT0iNzYuMzMz MyI+IGNvbnRyYWN0czwvdHNwYW4+CiAgPC90ZXh0PgogIDx0ZXh0IGZvbnQtc2l6ZT0iMTEu Mjg4OSIgc3R5bGU9ImZpbGw6ICMwMDAwMDA7dGV4dC1hbmNob3I6c3RhcnQ7Zm9udC1mYW1p bHk6c2Fucy1zZXJpZjtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWwiIHg9 IjM3NyIgeT0iMTM4Ij4KICAgIDx0c3BhbiB4PSIzNzciIHk9IjEzOCI+RWRpdG9yaWFsPC90 c3Bhbj4KICAgIDx0c3BhbiB4PSIzODciIHk9IjE1Mi4xMTEiPiBzdHJlYW08L3RzcGFuPgog IDwvdGV4dD4KICA8dGV4dCBmb250LXNpemU9IjExLjI4ODkiIHN0eWxlPSJmaWxsOiAjMDAw MDAwO3RleHQtYW5jaG9yOnN0YXJ0O2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsIiB4PSIzMTQiIHk9IjEwNyI+CiAgICA8dHNw YW4geD0iMzE0IiB5PSIxMDciPkxMQyBob2xkczwvdHNwYW4+CiAgICA8dHNwYW4geD0iMzI0 IiB5PSIxMjEuMTExIj5jb250cmFjdHMqPC90c3Bhbj4KICA8L3RleHQ+CiAgPHRleHQgZm9u dC1zaXplPSIyMC4zMiIgc3R5bGU9ImZpbGw6ICMwMDAwMDA7dGV4dC1hbmNob3I6c3RhcnQ7 Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpu b3JtYWwiIHg9IjUzMiIgeT0iMzUiPgogICAgPHRzcGFuIHg9IjUzMiIgeT0iMzUiPmRyYWZ0 LWNhcnBlbnRlci08L3RzcGFuPgogICAgPHRzcGFuIHg9IjUzMiIgeT0iNjAuNCI+cmZjZWQt bW9kZWw8L3RzcGFuPgogIDwvdGV4dD4KICA8dGV4dCBmb250LXNpemU9IjIwLjMyIiBzdHls ZT0iZmlsbDogIzAwMDAwMDt0ZXh0LWFuY2hvcjpzdGFydDtmb250LWZhbWlseTpzYW5zLXNl cmlmO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbCIgeD0iMjE0IiB5PSIz MzIiPgogICAgPHRzcGFuIHg9IjIxNCIgeT0iMzMyIj5kcmFmdC1zdGpvaG5zLXJmY2VkLXJz ZWI8L3RzcGFuPgogIDwvdGV4dD4KICA8dGV4dCBmb250LXNpemU9IjIwLjMyIiBzdHlsZT0i ZmlsbDogIzAwMDAwMDt0ZXh0LWFuY2hvcjpzdGFydDtmb250LWZhbWlseTpzYW5zLXNlcmlm O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbCIgeD0iMTUiIHk9IjM2Ij4K ICAgIDx0c3BhbiB4PSIxNSIgeT0iMzYiPmRyYWZ0LXRob21zb248L3RzcGFuPgogICAgPHRz cGFuIHg9IjE1IiB5PSI2MS40Ij4tcmZjZWQtbW9kZWw8L3RzcGFuPgogIDwvdGV4dD4KICA8 dGV4dCBmb250LXNpemU9IjEyLjgiIHN0eWxlPSJmaWxsOiAjMDAwMDAwO3RleHQtYW5jaG9y OnN0YXJ0O2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13 ZWlnaHQ6bm9ybWFsIiB4PSIyMjkiIHk9IjE4Ij4KICAgIDx0c3BhbiB4PSIyMjkiIHk9IjE4 Ij48L3RzcGFuPgogIDwvdGV4dD4KICA8dGV4dCBmb250LXNpemU9IjEyLjgiIHN0eWxlPSJm aWxsOiAjMDAwMDAwO3RleHQtYW5jaG9yOnN0YXJ0O2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7 Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsIiB4PSIyMjYiIHk9IjE5Ij4K ICAgIDx0c3BhbiB4PSIyMjYiIHk9IjE5Ij48L3RzcGFuPgogIDwvdGV4dD4KICA8dGV4dCBm b250LXNpemU9IjEyLjgiIHN0eWxlPSJmaWxsOiAjMDAwMDAwO3RleHQtYW5jaG9yOnN0YXJ0 O2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6 bm9ybWFsIiB4PSI1NDQiIHk9IjEyNCI+CiAgICA8dHNwYW4geD0iNTQ0IiB5PSIxMjQiPiog T1RIRVIgQ09NTU9OIFBPSU5UUzo8L3RzcGFuPgogICAgPHRzcGFuIHg9IjU0NCIgeT0iMTQw Ij5MTEMgcmVzcG9uc2libGUgZm9yIGFsbCBjb250cmFjdHM8L3RzcGFuPgogICAgPHRzcGFu IHg9IjU0NCIgeT0iMTU2Ij5SUEMvUkVQIGFzIHNlcnZpY2UgY29udHJhY3RvcihzKTwvdHNw YW4+CiAgICA8dHNwYW4geD0iNTQ0IiB5PSIxNzIiPlN0cmVhbXMgaGF2ZSBjb250ZW50IGNv bnRyb2w8L3RzcGFuPgogICAgPHRzcGFuIHg9IjU0NCIgeT0iMTg4Ij5TZXBhcmF0ZSBib2R5 IGRlYmF0ZXMgc3RyYXRlZ3k8L3RzcGFuPgogICAgPHRzcGFuIHg9IjU1NCIgeT0iMjA0Ij4g KG11c3QgaW5jbHVkZSBzdHJlYW0gcmVwcmVzZW50YXRpdmVzKTwvdHNwYW4+CiAgPC90ZXh0 Pgo8L3N2Zz4K --------------5B217E08980B31291C1A6C1E-- From nobody Fri Sep 18 19:08: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 24E1F3A0FD7 for ; Fri, 18 Sep 2020 19:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJiwYGnJvdNh for ; Fri, 18 Sep 2020 19:08:49 -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 172F63A0FC9 for ; Fri, 18 Sep 2020 19:08:49 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id gf14so3927745pjb.5 for ; Fri, 18 Sep 2020 19:08: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=0wtObNQsoborSBCoQ4ORTN2HPo/9Hh4Apm22isGr5do=; b=u+J8W7qed/OK1hOc+wDrgarUfzwepcPOcAQnLfH3ZN4s9fgAHrT6QxitwX2Z3tBrah 2dH3jm/UtkZeODjKfx79gEzDSese/Wa2DGQyo56b+cjV4mbKgegS+XT/RqyPNTUPU2H4 0It4zHC4AwKfqBNeh3gwEvWHQabcQtNTUJJFvGCrkUSww1NOnz7CKDbXSA6B7HiAfglS 5F4B7CwQ+kzlm0FDGNn1HiQNQT/kYu9qb3LbiCG4bY75FcDz9o2rI0pmDWh677vqtXYm dmnOIJnklknEUSiW5Oy/sFbdiTfsR0ArfcYRI/5PhRBCg74eodOgWqjrcx9AALpCd5dW v8dA== 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=0wtObNQsoborSBCoQ4ORTN2HPo/9Hh4Apm22isGr5do=; b=EztRUKckPcw5qHKAmgcpTm7IQeNtT4S1sTsxb+N20vW05c6srR70PkvIzllmlb5rfP s+Q+iYcVzIeowas8EIjyHF3krqlap5OlwXuswcPMdRvkVvTqvbEJVcMQYI9o1arOxGWM UaaFpOKyBx69qfJ7UiR2hok8EN5hk1t4CaaH2iUUpYosJfmEdjE/lqudaU+7+zdsEzxy J4Q4jih4NTY962saXi7jHtiCLlS6w/kaIEfln3dgIKFVwLJDuSsbjgmucgRafAl5gR3v Yrs4GV0ZGlG4lmCVzH3jNjXEqp1ibliESNKUqG3I/+vYUmRy0NX5OI6CKjnjiKWGkqCF vZKg== X-Gm-Message-State: AOAM5320SdCr/xZisUPiKJ9QFKuQTu+WBKXkVi7ZjyTTsqZF8EMM5iVi rjyyFmJw9FNeuk+MkroapbNl7X+V8oc= X-Google-Smtp-Source: ABdhPJzd/GqAwh9ls+ffoHoSQmyR8H/tNJw5WHo9pvVBguwoeaQ+XulyH3guLQeRd7/Y8Xd0eO6oKA== X-Received: by 2002:a17:90b:188d:: with SMTP id mn13mr15693135pjb.66.1600481328239; Fri, 18 Sep 2020 19:08:48 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id h35sm4405271pgl.31.2020.09.18.19.08.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2020 19:08:47 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: Date: Sat, 19 Sep 2020 14:08:43 +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] Question for discussion - Editorial Stream X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 02:08:50 -0000 On 19-Sep-20 07:22, Michael StJohns wrote: > Hi - >=20 > I'm assuming that "if it wasn't written down it didn't happen" or more = > specifically, that changes to the publication system and model will be = > documented and those approved documents will inform any contracts or=20 > operational model.=C2=A0 If anyone disagrees with that assumption, I'd = like=20 > to hear their reasoning. >=20 > Based on that assumption, I have the following question and subsidiary = > questions: >=20 > Question:=C2=A0 Do we create a separate Editorial Stream? Yes, I believe it's useful. =20 > If YES - Who approves documents in that stream? That's model-dependent, but I assume that in draft-thomson and draft-carp= enter it would be the Program/WG by rough consensus, and in draft-stjohns it wo= uld be the RSEB by vote. > If NO - Where are documents that describe changes to the publication=20 > process and system published? (The answer implies who approves publicat= ion). Again, it's model-dependent. In draft-thomson, it's clearly the IAB strea= m as today. In the other two models, we are presumably left with the Independe= nt stream. Brian From nobody Fri Sep 18 19:16: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 7598A3A119B for ; Fri, 18 Sep 2020 19:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, TVD_SPACE_RATIO=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dx9yQqnrBRZe for ; Fri, 18 Sep 2020 19:16:01 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 4C5083A0FD5 for ; Fri, 18 Sep 2020 19:16:01 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id z1so58060uaa.6 for ; Fri, 18 Sep 2020 19:16:01 -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=g0GqfLq9sJyJD7v/vmo0ayCV5dJioA6jSfxxxNK9VOA=; b=cgqIIKk2x/BcKwWrw2JkfKQr16ebEVVb+9CJw3tpPQU2ZDVHAZ2xCu09JW+pAFP2sv GlpqEx5jvICDuyWiF3pXuBQAQTIITTfmGhS1pEzHpG0t+AP8qMOFPahnaINab1qIaIX3 6e+X/DExbjqSVXF3omm/8SyXYyUy7XKCMhG7WXh3lmq1RjwCYQKhZdtJiRMs2eenCbZh BJnDflGa7gVPrHbI5FzK/5UC39dXk2HXIilHvgBGCXiTuItvQG8HCa7BcDG9IpcDI3f4 bVq9hvAeBxY+to8h6Jh20gCAiW6DeDNOArt7rgY0gCVjKo4f/FoT81wg3WTv3TFagyEk aOgg== 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=g0GqfLq9sJyJD7v/vmo0ayCV5dJioA6jSfxxxNK9VOA=; b=DxyOCacsxYTBGz33qd6VTewXrOUQa4Xsh9ChJ/X4bvDeCylWmoEsyYaaJX+3gI/S+s RCU8fYYNCIAawbIolFbRaEVO8Q/qmj9GxbW7okEKdOv8c+3BDG32xoBfrTT8KFNOqyA7 oAII9LfnLgdn0cW/RBML+FuTGrj0DlpyfLefm6dkyK6QMJwQQRasQ4mGxdEfhax/zKCf CKVz83zXegR9wcizAXYMGD0Sj5V2Eh4cI0KJ683Cjx2tIKyVvZnMiHDzCPbt6phEpONb ESGIg9VTFfNjREVk0a5r5K6VdkN5EkktBMf92iyrCgbdlQadvtVpbZAprNGBeVew9tR5 aSVg== X-Gm-Message-State: AOAM530sX5xgSmPSt9EqOlBxMkONt+gh09tgp1r64e+Pgycubwc5rQbv DTUJ/rqlnjWIqCq4budOYDMT0bEd083z1rpY2IHJFExpvYg= X-Google-Smtp-Source: ABdhPJy7SKloUJ3nQZLfMHzH4z9CA4j+A7qeFtyK2+K8jTipX4MVpFpXVEAyBZf8Lf4xAzaM4c1tkNnKNrez6IbnmqM= X-Received: by 2002:a9f:24d4:: with SMTP id 78mr20858817uar.47.1600481759613; Fri, 18 Sep 2020 19:15:59 -0700 (PDT) MIME-Version: 1.0 From: Somchai Srisuk Date: Sat, 19 Sep 2020 09:15:48 +0700 Message-ID: To: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000c0581c05afa132c2" Archived-At: Subject: [Rfced-future] (no subject) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 02:16:02 -0000 --000000000000c0581c05afa132c2 Content-Type: text/plain; charset="UTF-8" https://www.bloomberg.com/graphics/2020-opinion-fed-inflation-economic-data -- null --000000000000c0581c05afa132c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --
null
--000000000000c0581c05afa132c2-- From nobody Sat Sep 19 03:10: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 9F8073A0E25 for ; Sat, 19 Sep 2020 03:09:59 -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 4dQvfxKFDAB2 for ; Sat, 19 Sep 2020 03:09:57 -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 9B4623A0E22 for ; Sat, 19 Sep 2020 03:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2539; q=dns/txt; s=iport; t=1600510191; x=1601719791; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=/hLenD+EydOvVs7bwUA1ojfTDGpViWS3hHn4NCKdUJI=; b=Y7kjrVFDja/rIJ+iqFxTbDRgIyiLvFvLcI3ORzunQra4/Ku59NiXsoj+ ZnGSBp7S3myQ/onKmsbHT79KyJ53aO0HmoAcndwvO/yipBm3BOY6MvG9B EGp9uGuew+6wKBChmf/q610FlOiMw62UGU6FjbKesCNYXmJfdtc09TzTT k=; X-IPAS-Result: =?us-ascii?q?A0BXAQCZ12Vf/xbLJq1fGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBT4EjgkwBMiyNO4gVJpQGiBkLAQEBDQEBLwQBAYRLAoIsJTgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgRthWiFcgEBAQECAXkFCwsEARMuVxmDJoJdILUsd?= =?us-ascii?q?IE0hVOEd4E4jUeCAIE4DBCBOIEVPoUKgn2CLQS3LoJxgxGXOwMegwyJeYUPj?= =?us-ascii?q?m2vG4NcAgQGBQIVgWsjgVczGggbFTsqAYI+PhIZDZxoPwMwNwIGCgEBAwmOX?= =?us-ascii?q?wEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.77,278,1596499200"; d="scan'208,217"; a="27312829" 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; 19 Sep 2020 10:09:47 +0000 Received: from [10.61.213.221] ([10.61.213.221]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 08JA9k7K003881 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 19 Sep 2020 10:09:47 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_35BB3534-1637-4E1B-851E-A3D6BB43E1FF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sat, 19 Sep 2020 12:09:46 +0200 In-Reply-To: <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> Cc: rfced-future@iab.org To: adrian@olddog.co.uk References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.213.221, [10.61.213.221] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 10:10:00 -0000 --Apple-Mail=_35BB3534-1637-4E1B-851E-A3D6BB43E1FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Sep 2020, at 22:06, Adrian Farrel wrote: >=20 > Suppose we adopt an empty-ish draft (perhaps has background and = objectives, perhaps has initial list of open issues/questions) and then = follow option B recording each decision in the draft as it comes to = (rough) consensus? To me this is a valid version of Option A, and we might even employ it = as a means to implement Option B. It is also possible that a draft = would emerge that leaves open issues which we do not have agreement. = That would give us a bit more than a blank page. Eliot= --Apple-Mail=_35BB3534-1637-4E1B-851E-A3D6BB43E1FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 18 Sep 2020, at 22:06, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Suppose we = adopt an empty-ish draft (perhaps has background and objectives, perhaps = has initial list of open issues/questions) and then follow option B = recording each decision in the draft as it comes to (rough) = consensus?

To me this is a valid version of Option A, and we might even = employ it as a means to implement Option B.  It is also possible = that a draft would emerge that leaves open issues which we do not have = agreement.  That would give us a bit more than a blank = page.

Eliot
= --Apple-Mail=_35BB3534-1637-4E1B-851E-A3D6BB43E1FF-- From nobody Sat Sep 19 03:11:16 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C543A0E0F for ; Sat, 19 Sep 2020 03:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADBgGXuNG7gs for ; Sat, 19 Sep 2020 03:11:12 -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 068903A0E15 for ; Sat, 19 Sep 2020 03:11:11 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08JAB5nG023330; Sat, 19 Sep 2020 11:11:05 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9C64B2203A; Sat, 19 Sep 2020 11:11:05 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 8791C22032; Sat, 19 Sep 2020 11:11:05 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.40.230]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08JAB4ee014452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 19 Sep 2020 11:11:05 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" Cc: References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> In-Reply-To: Date: Sat, 19 Sep 2020 11:11:04 +0100 Organization: Old Dog Consulting Message-ID: <047b01d68e6d$2f533510$8df99f30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_047C_01D68E75.9117EB30" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGR9HXXfL/DtwnRZr3fsQ1/cPZpLwHP8HmyARKPmvqp4d1ZsA== Content-Language: en-gb X-Originating-IP: 87.112.40.230 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-25674.005 X-TM-AS-Result: No--15.490-10.0-31-10 X-imss-scan-details: No--15.490-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25674.005 X-TMASE-Result: 10--15.489800-10.000000 X-TMASE-MatchedRID: Jm7Yxmmj9OnxIbpQ8BhdbMzSKGx9g8xhV0QSZ/pNFUHbw6NvULhmF1yM PMMidU7C/k69j8+zjinyepGp/4TvbCQRRDPpnrd6vHKClHGjjr1RvgR0hkbG4AJRjXQLiyc9AA1 a8kaMQg6BM/mWA6wWh1JWUPbsPnrs64YaJwvKvEPlCjTeYR3AARACJh4BWAPeatX9VbAjHGFSAA NZY4RuY1qZgXOe2hfh/fQcFdyvef9q0QqhYus7ZP0peXGEEBlvmHAp2UJ8+TxXG3yI9k2vbIfNL 7D/HMEOxCW4LIIVzgLZPU+b5RcHaHzrWhwAg+mwydRP56yRRA/QTttTsZbKLwNPGPNKJEnBAX0B hMCVQpfSw8EQWtEiHQH/6CIQ6zHMn0UoIZ374hfmuecNOZVsqsu99zcLpJbCfxl2qOxQoRVlmEe Qcv+8x5JJRUf02ZTRJIVdEtqJTGzuTQq+tUM08C+PrAd8gbHJWDjpLN7XhAFCI7pNLiSjfeRqQA xbWD9+4vM1YF6AJbbVZ0g740lL+QSz8fXAzKymU6s2nlVTnzX6C0ePs7A07YVH0dq7wY7u3Ye2r K3zb3bCVf1yaMEd7X4wlVJoczJD4BtI1SrYjcwOIUndlcaJoQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 10:11:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_047C_01D68E75.9117EB30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, in that case I vote =E2=80=9Coption A and B=E2=80=9D =F0=9F=98=8A =20 From: Eliot Lear =20 Sent: 19 September 2020 11:10 To: adrian@olddog.co.uk Cc: rfced-future@iab.org Subject: Re: [Rfced-future] Moving forward: Please state your preference =20 =20 On 18 Sep 2020, at 22:06, Adrian Farrel > wrote: =20 Suppose we adopt an empty-ish draft (perhaps has background and = objectives, perhaps has initial list of open issues/questions) and then = follow option B recording each decision in the draft as it comes to = (rough) consensus? =20 To me this is a valid version of Option A, and we might even employ it = as a means to implement Option B. It is also possible that a draft = would emerge that leaves open issues which we do not have agreement. = That would give us a bit more than a blank page. =20 Eliot ------=_NextPart_000_047C_01D68E75.9117EB30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Well, in = that case I vote =E2=80=9Coption A and B=E2=80=9D 😊

 

From: Eliot Lear = <lear@cisco.com>
Sent: 19 September 2020 = 11:10
To: adrian@olddog.co.uk
Cc: = rfced-future@iab.org
Subject: Re: [Rfced-future] Moving = forward: Please state your = preference

 

 



On 18 Sep 2020, at 22:06, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Suppose = we adopt an empty-ish draft (perhaps has background and objectives, = perhaps has initial list of open issues/questions) and then follow = option B recording each decision in the draft as it comes to (rough) = consensus?

 

To me = this is a valid version of Option A, and we might even employ it as a = means to implement Option B.  It is also possible that a draft = would emerge that leaves open issues which we do not have agreement. =  That would give us a bit more than a blank = page.

 

Eliot

------=_NextPart_000_047C_01D68E75.9117EB30-- From nobody Sat Sep 19 10:14: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 16EF73A0D4C for ; Sat, 19 Sep 2020 10:14:00 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG-wlDoCTSEE for ; Sat, 19 Sep 2020 10:13:58 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 EEE693A0D4A for ; Sat, 19 Sep 2020 10:13:57 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id 16so10296278qkf.4 for ; Sat, 19 Sep 2020 10:13:57 -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=GzLkYFf1u4+bu4jInnMDptmb3f6CBvoxzfA2ajBu2Nc=; b=Ao4wQV0/1MslG/Ua2HpjZPPViO2fNGiR832rom7SIh8r46QFHCg0iT7em04nqdgrX1 Imtni1WrZvJCwIoXg2Mcj3VHr34IW+xHFKgPwHUHGqeJttRc+vA/+67fFJXZX9nKrLTr WAZ43wxHJENt42+ZIR8YmL2wYVOgdr+5Zx96R31hGuDLdaN7GOkL/LagI1UKfTWt3wUT Sd02U/0dDG+fEq7KpGAjvDu1ra97dhwx7AgxSh1akIrOl8mUVoZirvaIg6n9jDmaAKf9 zySItRHAkcNGkh4iLqbqdmlhzyT1q8XPEXbBI4im7yYTtV3tJ/H0TMECtd1P8u+zEEvn yQyg== 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=GzLkYFf1u4+bu4jInnMDptmb3f6CBvoxzfA2ajBu2Nc=; b=MqrtPUfdGKFu//ouke38veckrZ+zOtBN5uDir4BRqnJQusyRqytFDKva2SkGOyheQq EDLsTp1X6Vr9vR0U/8GPgsU2e+CnJovRT8zloeJXeRR7MviCKIV0UVeNwcWc2vAPjtm1 46zDt35nJrvtIP3AIQLSvc9l9jg5og9j8mmhKDv3Fmp1iN7oW45Qp4Z1qZZDBAnNPfY8 W22bEdSSncuJiOMl6V5QdIyPmK4NsmdLtaEw17uvylTQ0FWkdHRRUp002qSiL8FlG2jf +BfL4kcJBOosIm5f/vwEuowgfVVNI2rxbfOMtAQ9/BB+Z6oP0+v4DQ3+tGeo04wX5EGF YnmQ== X-Gm-Message-State: AOAM530fM+YcD0lJpjpz04yEvc0ycmocXVrMEnoT12AxZFVL9Jc6mPsy xi6b4KTvU56EnnkJje1WuRefcPCjMnJWjzVR5i8= X-Google-Smtp-Source: ABdhPJzquqYXx0rbNKIiEtIHJokoeJ88Gzkv1CRn/N9Pnju/mI2LPAXIDYrwwfGhnl6XWG7oTrOmSA== X-Received: by 2002:a05:620a:12f3:: with SMTP id f19mr30977518qkl.110.1600535636509; Sat, 19 Sep 2020 10:13:56 -0700 (PDT) Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id m97sm4953204qte.55.2020.09.19.10.13.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Sep 2020 10:13:56 -0700 (PDT) To: rfced-future@iab.org References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> From: Michael StJohns Message-ID: <7399a374-7561-3b9e-2d04-07ade1a9174c@nthpermutation.com> Date: Sat, 19 Sep 2020 13:13:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> Content-Type: multipart/alternative; boundary="------------EE6CD5F9EB7F0534D2DDC152" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 17:14:00 -0000 This is a multi-part message in MIME format. --------------EE6CD5F9EB7F0534D2DDC152 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit For the same reasons we discussed on the call, I choose option C - we're not ready to pick a path.   That looks closer to Option B than it does option A but probably actually isn't the same.  We've talked about common solution elements, but we're still having major discussions (cf John and and Adam's back and forth) about the implications of various choices such that picking solution elements are still quite difficult.  Among other things, many of the elements are entwined - e.g., choosing choice A of Group 1 may restrict your choices in Group 2 to choices C and F. As I read it we've agreed mostly on one thing: * That the stream managers will take a major role in the evolution process of the RFC Series. We seem to have also agreed that (I think this is what I got an agreement on from Martin and Brian when I asked the question on the call): * The LLC will be responsible for any contractual items including hiring/firing/renewals/day-to-day and that any delegation of that role will be only to a "fiduciary" of the LLC (e.g. employee or a contracted role) to specifically exclude the IAB/RSOC personnel management model. We haven't agreed on: * Whether there will be a professional involved in the steering, or the model of engagement for that professional.  (e.g. employee or retained contractor with primary responsibility vs employee or retained contractor with advisory only responsibility or a professional contractor engaged only for task-specific short term items). * The model for publication of documents that drive the publication process. And lots more. I've been trying to do a topological sort and figure out which of the problems is the core one that we need to come to a conclusion on, and I'm at a loss. Mike On 9/18/2020 11:55 AM, Eliot Lear wrote: > Hello everyone, > > > “When you come to a fork in the road, take it.” > — Yogi Bera > > The chairs have had an opportunity to discuss the last interim.  We > note that some people liked the comparison chart, as a means to > highlight both similarities and differences.   We know that some > people would very much like to have seen a draft adopted, while others > were not ready to move forward.  Several people would instead like to > go issue by issue and resolve those issues before adopting a draft. >  The chairs will leave this choice to the group as to which way to > proceed at the moment. > > You are invited to specify your preference *on list* *by September > 25th, 2:00pm GMT.  Option A or Option B.  Please be explicit.* > > We can pursue one of two approaches: > > *Option A:  Pursue adopting a draft* > > The approach would be that we *would* adopt a draft by IETF 109 – *as > a starting point*.  To avoid further deadlocks, there would be > *no* “I’m not ready” option in the hum.  Authors are invited to merge > and indicate open issues in drafts.  Others are invited, if they > really feel the need, to create new drafts within 2-3 weeks.  If there > are more than two options, the chairs will find ways to wheedle things > down to get to a draft to adopt, while being sensitive to the concerns > EKR and others raised about inertia of what is in a draft.  If the > group would like an interim to facilitate this option, the chairs will > accommodate. > > *Option B: Pursue open issues one by one* > > Pursue issues one by one to resolve on list, starting with “Do people > believe that the RSE position should continue in some form?”  We would > pursue from the nature of the role if we get an affirmative answer. >  Other questions would follow, such as aspects of oversight and > relationship to RPC. > > If after the poll the group is evenly divided between these choices, > in order to take the fork, the chairs will spin a spinner and make a > decision.  You are encouraged to discuss these options, and may change > your minds right up to the deadline. > > *A Plea* > > This program consists nearly exclusively of senior members of the > community-  you are all past or current leaders of this organization > with deep experience and knowledge.  We therefore hope that you will > seek to find common ground with one another when you see a deadlock in > view. > > Brian and Eliot > > --------------EE6CD5F9EB7F0534D2DDC152 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

For the same reasons we discussed on the call, I choose option C - we're not ready to pick a path.   That looks closer to Option B than it does option A but probably actually isn't the same.  We've talked about common solution elements, but we're still having major discussions (cf John and and Adam's back and forth) about the implications of various choices such that picking solution elements are still quite difficult.  Among other things, many of the elements are entwined - e.g., choosing choice A of Group 1 may restrict your choices in Group 2 to choices C and F.


As I read it we've agreed mostly on one thing:

  • That the stream managers will take a major role in the evolution process of the RFC Series.  

We seem to have also agreed that (I think this is what I got an agreement on from Martin and Brian when I asked the question on the call):

  • The LLC will be responsible for any contractual items including hiring/firing/renewals/day-to-day and that any delegation of that role will be only to a "fiduciary" of the LLC (e.g. employee or a contracted role) to specifically exclude the IAB/RSOC personnel management model.

We haven't agreed on:

  • Whether there will be a professional involved in the steering, or the model of engagement for that professional.  (e.g. employee or retained contractor with primary responsibility vs employee or retained contractor with advisory only responsibility or a professional contractor engaged only for task-specific short term items).
  • The model for publication of documents that drive the publication process.

And lots more.

I've been trying to do a topological sort and figure out which of the problems is the core one that we need to come to a conclusion on, and I'm at a loss.

Mike



On 9/18/2020 11:55 AM, Eliot Lear wrote:
Hello everyone,


“When you come to a fork in the road, take it.”
— Yogi Bera

The chairs have had an opportunity to discuss the last interim.  We note that some people liked the comparison chart, as a means to highlight both similarities and differences.   We know that some people would very much like to have seen a draft adopted, while others were not ready to move forward.  Several people would instead like to go issue by issue and resolve those issues before adopting a draft.  The chairs will leave this choice to the group as to which way to proceed at the moment.

You are invited to specify your preference on list by September 25th, 2:00pm GMT.  Option A or Option B.  Please be explicit.

We can pursue one of two approaches:

Option A:  Pursue adopting a draft

The approach would be that we would adopt a draft by IETF 109 – as a starting point.  To avoid further deadlocks, there would be no “I’m not ready” option in the hum.  Authors are invited to merge and indicate open issues in drafts.  Others are invited, if they really feel the need, to create new drafts within 2-3 weeks.  If there are more than two options, the chairs will find ways to wheedle things down to get to a draft to adopt, while being sensitive to the concerns EKR and others raised about inertia of what is in a draft.  If the group would like an interim to facilitate this option, the chairs will accommodate.

Option B: Pursue open issues one by one

Pursue issues one by one to resolve on list, starting with “Do people believe that the RSE position should continue in some form?”  We would pursue from the nature of the role if we get an affirmative answer.  Other questions would follow, such as aspects of oversight and relationship to RPC.

If after the poll the group is evenly divided between these choices, in order to take the fork, the chairs will spin a spinner and make a decision.  You are encouraged to discuss these options, and may change your minds right up to the deadline.

A Plea

This program consists nearly exclusively of senior members of the community-  you are all past or current leaders of this organization with deep experience and knowledge.  We therefore hope that you will seek to find common ground with one another when you see a deadlock in view.

Brian and Eliot



--------------EE6CD5F9EB7F0534D2DDC152-- From nobody Sat Sep 19 10:14: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 8081F3A0D4C for ; Sat, 19 Sep 2020 10:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE_zo0_F3b51 for ; Sat, 19 Sep 2020 10:14:04 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B442B3A0D88 for ; Sat, 19 Sep 2020 10:14:04 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id n18so8353989qtw.0 for ; Sat, 19 Sep 2020 10:14:04 -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=D6xIEin7OWkfC7Hl2S32p11kAlvxnX3AvE8k5vBFFgc=; b=2FCLR1IVvzgWKdXySYl29I6VToEziwAG0AIbrcJ1hU39C/E3hC4Y4hYbr/0t6Z/rrh bIYZ82a79cmH/KbwDEtS6YlueJu6U1bOz7L5sFT9JMl1VA2S/V8wUZMG2hd7UgPr+FoS KvNmADUToS6lhwDnpq35rIbYoYC0iA2YbKrrIk7s9m0uPpqmVlim5e0DZi5byTLluo4m kxChIjgikQFpwgryRnZf8sqZn/3gBsqdr6UAALRlljL1siv5sqStjIVcLPLBnetGkrEL tek1aYUf/ZS4I1UKNLnccE5fDhGEwjHttun+FRby/DJiosXgN/5I9Uzar1aECDY1zOBm Q7dA== 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=D6xIEin7OWkfC7Hl2S32p11kAlvxnX3AvE8k5vBFFgc=; b=T8iJxJUQbRQ6lLbMlsJcOpU/rC0ah1qnHmAsWzTo2g40Yi5vFHk4OQTDMzVQ8XGjbn Oxqqtf41xTZNAk+vKRmZzfUW24raVolhcJi5YMlzxBFE2wai/Tt0brC753MQGBXzREkP ZTtRen4sI/M21N/SP0lirgCVehiuwAh4Wot+tfuFc2ztpt+50H724a1b5IyHON/CZC96 K4jgbDH/oiH83EgSxWRJl8EnrTM6UNw8GN/Zt7sPowUbnWQsy6XhZlbxPMY364v0KGAC Zru123fVqEzzpXTpe4VQAOYPt/CCTMlkJyqZqvRFXF3FacXhdV05ct93n5gWFkScqAoJ 061A== X-Gm-Message-State: AOAM533WofAB8leh/YWD33GGWGrTurbwOq77DYpaTZq7aUpjHyYdphNS AvvMXcfqICqLGkP32QEdU5dUfL4+IUNXZl47/V0= X-Google-Smtp-Source: ABdhPJx3LqdpWANpZvGt+yAI+1DSxfQpNa2/yOKVwn6PUVj05klpVoVNgXfu1wHlEPjtIVtoB42JZw== X-Received: by 2002:ac8:37bb:: with SMTP id d56mr37878396qtc.222.1600535643557; Sat, 19 Sep 2020 10:14:03 -0700 (PDT) Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id 145sm4729253qkf.18.2020.09.19.10.14.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Sep 2020 10:14:02 -0700 (PDT) To: Brian E Carpenter , rfced-future@iab.org References: From: Michael StJohns Message-ID: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.com> Date: Sat, 19 Sep 2020 13:14:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Question for discussion - Editorial Stream X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 17:14:07 -0000 On 9/18/2020 10:08 PM, Brian E Carpenter wrote: > On 19-Sep-20 07:22, Michael StJohns wrote: >> Hi - >> >> I'm assuming that "if it wasn't written down it didn't happen" or more >> specifically, that changes to the publication system and model will be >> documented and those approved documents will inform any contracts or >> operational model.  If anyone disagrees with that assumption, I'd like >> to hear their reasoning. >> >> Based on that assumption, I have the following question and subsidiary >> questions: >> >> Question:  Do we create a separate Editorial Stream? > Yes, I believe it's useful. > >> If YES - Who approves documents in that stream? > That's model-dependent, but I assume that in draft-thomson and draft-carpenter > it would be the Program/WG by rough consensus, and in draft-stjohns it would be > the RSEB by vote. For the rough consensus models, I have two additional questions:   1) Who determines rough consensus (and actually approves the documents for publication) - the WG or Program Chairs?  2) If the stream managers  disagree with the rest of the group, are their oppositions given more weight than the self-selected membership?  If not, why not?  If so, then how is that figured into the resolution process? >> If NO - Where are documents that describe changes to the publication >> process and system published? (The answer implies who approves publication). > Again, it's model-dependent. In draft-thomson, it's clearly the IAB stream as > today. In the other two models, we are presumably left with the Independent > stream. So ultimately, in draft-thomson, the IAB approves publication (per normal procedures for the IAB stream) - in other words, no change from what's currently happening - is that correct?   For the other two then the ISE approves publication (per the normal procedures for that stream) - is that correct? Thanks - Mike > > Brian > From nobody Sat Sep 19 12:54: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 51FF43A052C for ; Sat, 19 Sep 2020 12:54:39 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 M9yeJutv4fOa for ; Sat, 19 Sep 2020 12:54:37 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC553A0484 for ; Sat, 19 Sep 2020 12:54:37 -0700 (PDT) Received: from xse349.mail2web.com ([66.113.197.95] helo=xse.mail2web.com) by mx31.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kJiwK-0003ug-4P for rfced-future@iab.org; Sat, 19 Sep 2020 21:54:34 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4Bv1ch24dvz1CCT for ; Sat, 19 Sep 2020 12:54:28 -0700 (PDT) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kJiwG-00081y-5v for rfced-future@iab.org; Sat, 19 Sep 2020 12:54:28 -0700 Received: (qmail 6660 invoked from network); 19 Sep 2020 19:54:27 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.46.182]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Sep 2020 19:54:27 -0000 To: Michael StJohns , Brian E Carpenter , rfced-future@iab.org References: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.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: Date: Sat, 19 Sep 2020 12:54:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.com> Content-Type: multipart/alternative; boundary="------------C7D650F7DFE1E42C305F068E" Content-Language: en-US X-Originating-IP: 66.113.197.95 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4hnRBlQktBgUe/3r9CjehMyQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEe97QOBQtkipMuT/eg0WjBw7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsew/8UDUovG0RNBb7jVCxczEpDLc6UoRh7FXFXC/W2tUG1W2ri3uAahmrRYoGcv967XB H1fP3YU+2XWwKzL04bcfwzQZWnqpeh+UbGCVNeqba5Xked+P+aSZU/EB7YnRWs2LBDMrD7q/cJog wbqzsuok9W4olKdhVASEVFmteZlzGk7JPy9twDyaj6un7qWOkNdFyNfhj+NtXFE/xw+ePBIPO5HV /vr7sP3/9HblK1WcN3i0EW+/nh8HB0VCDAq8bK25lsdI/IYDz4iLea4eiGiG647lNwN4qOsSZg+f YhVZG3Fpf9P2WwOdPRT3EWlMd754CMBw7+ErSKQN7lw8ITGaNmGHCZF9ZXtfSxIkZLsbHZnckpWa LvahyBjmQxBKOzsmHW0N+NPiHPgn+dyxhvT1Z5EPOIlpyGKEA1x50oTQDUtseoetsROuM82YMzIj 8EU= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Question for discussion - Editorial Stream X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 19:54:39 -0000 This is a multi-part message in MIME format. --------------C7D650F7DFE1E42C305F068E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 9/19/2020 10:14 AM, Michael StJohns wrote: > On 9/18/2020 10:08 PM, Brian E Carpenter wrote: >> On 19-Sep-20 07:22, Michael StJohns wrote: >>> Hi - >>> >>> I'm assuming that "if it wasn't written down it didn't happen" or more >>> specifically, that changes to the publication system and model will be >>> documented and those approved documents will inform any contracts or >>> operational model.  If anyone disagrees with that assumption, I'd like >>> to hear their reasoning. >>> >>> Based on that assumption, I have the following question and subsidiary >>> questions: >>> >>> Question:  Do we create a separate Editorial Stream? >> Yes, I believe it's useful. >>   >>> If YES - Who approves documents in that stream? >> That's model-dependent, but I assume that in draft-thomson and >> draft-carpenter >> it would be the Program/WG by rough consensus, and in draft-stjohns >> it would be >> the RSEB by vote. > > For the rough consensus models, I have two additional questions:   1) > Who determines rough consensus (and actually approves the documents > for publication) - the WG or Program Chairs?  2) If the stream > managers  disagree with the rest of the group, are their oppositions > given more weight than the self-selected membership?  If not, why > not?  If so, then how is that figured into the resolution process? > >>> If NO - Where are documents that describe changes to the publication >>> process and system published? (The answer implies who approves >>> publication). >> Again, it's model-dependent. In draft-thomson, it's clearly the IAB >> stream as >> today. In the other two models, we are presumably left with the >> Independent >> stream. > > So ultimately, in draft-thomson, the IAB approves publication (per > normal procedures for the IAB stream) - in other words, no change from > what's currently happening - is that correct?   For the other two then > the ISE approves publication (per the normal procedures for that > stream) - is that correct? The IAB has handled a number of such documents in the past, so in practice that part seems to work. But maybe I am wrong. Does anyone remember documents for which this caused a tension? -- Christian Huitema --------------C7D650F7DFE1E42C305F068E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 9/19/2020 10:14 AM, Michael StJohns wrote:
On 9/18/2020 10:08 PM, Brian E Carpenter wrote:
On 19-Sep-20 07:22, Michael StJohns wrote:
Hi -

I'm assuming that "if it wasn't written down it didn't happen" or more
specifically, that changes to the publication system and model will be
documented and those approved documents will inform any contracts or
operational model.  If anyone disagrees with that assumption, I'd like
to hear their reasoning.

Based on that assumption, I have the following question and subsidiary
questions:

Question:  Do we create a separate Editorial Stream?
Yes, I believe it's useful.
 
If YES - Who approves documents in that stream?
That's model-dependent, but I assume that in draft-thomson and draft-carpenter
it would be the Program/WG by rough consensus, and in draft-stjohns it would be
the RSEB by vote.

For the rough consensus models, I have two additional questions:   1) Who determines rough consensus (and actually approves the documents for publication) - the WG or Program Chairs?  2) If the stream managers  disagree with the rest of the group, are their oppositions given more weight than the self-selected membership?  If not, why not?  If so, then how is that figured into the resolution process?

If NO - Where are documents that describe changes to the publication
process and system published? (The answer implies who approves publication).
Again, it's model-dependent. In draft-thomson, it's clearly the IAB stream as
today. In the other two models, we are presumably left with the Independent
stream.

So ultimately, in draft-thomson, the IAB approves publication (per normal procedures for the IAB stream) - in other words, no change from what's currently happening - is that correct?   For the other two then the ISE approves publication (per the normal procedures for that stream) - is that correct?


The IAB has handled a number of such documents in the past, so in practice that part seems to work. But maybe I am wrong. Does anyone remember documents for which this caused a tension?

-- Christian Huitema

--------------C7D650F7DFE1E42C305F068E-- From nobody Sat Sep 19 14:31: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 1A4813A0A5F for ; Sat, 19 Sep 2020 14:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvSly_HhKwhG for ; Sat, 19 Sep 2020 14:31:24 -0700 (PDT) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 C5D313A0964 for ; Sat, 19 Sep 2020 14:31:24 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id bd2so4846340plb.7 for ; Sat, 19 Sep 2020 14:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=I+uK1a/QqLfFpQ4hejV2gOCA+RgIqUGe+owAe59Bl68=; b=t3UzifVvNBwmkXIy0XAozgBLPxve2QDT8g12hYaC5T2BqevWTL1Riv1+hlh+Wy9TiT xkFtzio7Sh7K5ESeRUWbN5ipzxdeGr7IFmC+ZId+sPWaTdXXHZoMLN12Umhb0ouHnwlN /D0/VxafgcH4Uc2IPIBBvQTcNDNoJXp19ywMpDNuXVY54RQi2oszDHbZ/cEvQUxMKRoq /mUyB/gSjX5XZgQo3qsfFBUZ7693neE692ZJiUmphaKy5FhJ7uTmcK/k87OvzS6uoXH7 L8sIyqFghUh87bwL23MKAQ8kFjLyh4rNaS57habfrczBAad9Lr6BblyCXJmjJveK2q6G Az3Q== 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=I+uK1a/QqLfFpQ4hejV2gOCA+RgIqUGe+owAe59Bl68=; b=T6N+7ZaWqeEegomuy9QN2uxFtz+R5OD3akGcYHwpJMWTs6E8r8cklOSpPE6AqZWXRD jMwkqSAPmoxq++GG3/vvAqwBl4A6w+4ILqgwXM8A60LP5fA8zvLVLy+6wKHlyQMYorpu /KWCf89pZGrwC1BcKkeE9JpkGNDAY7acI6x0R7WGG621+WR+Ivf8/gB+aW6ThHPoVLFQ jGEWnJhFvPId9lcyrsziiHYv3LOCWZ6LLvJSwq+QBzqQintP7k51Rx2WuOqpv6r+JP9D XPIuNkqt78utoqO1+Xq9vHCyMc4r0/T9Jx0qCkxHpc/TvSq9uaFkgbeQ3mSiUleq2q4t Bz1w== X-Gm-Message-State: AOAM531iB0sAAY/f7Bne0vT1HZfcXl58XfES5NF258743Ab+MKN8WCEr WPLcE8/U5o1CSxUxi1ecpvlkByAqItY= X-Google-Smtp-Source: ABdhPJzq5c3NM0s1YQLBu5+BvHPGT4V7oX4q/UE2ETuQTCOtkoPldxTN1rqFTJLcZTq24dcU5kDZbQ== X-Received: by 2002:a17:90a:db56:: with SMTP id u22mr18918179pjx.85.1600551083802; Sat, 19 Sep 2020 14:31:23 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id b15sm7457935pft.84.2020.09.19.14.31.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Sep 2020 14:31:23 -0700 (PDT) To: Christian Huitema , Michael StJohns , rfced-future@iab.org References: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.com> From: Brian E Carpenter Message-ID: Date: Sun, 20 Sep 2020 09:31:18 +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] Question for discussion - Editorial Stream X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 21:31:26 -0000 On 20-Sep-20 07:54, Christian Huitema wrote: >=20 > On 9/19/2020 10:14 AM, Michael StJohns wrote: >> On 9/18/2020 10:08 PM, Brian E Carpenter wrote: >>> On 19-Sep-20 07:22, Michael StJohns wrote: >>>> Hi - >>>> >>>> I'm assuming that "if it wasn't written down it didn't happen" or mo= re >>>> specifically, that changes to the publication system and model will = be >>>> documented and those approved documents will inform any contracts or= >>>> operational model.=C2=A0 If anyone disagrees with that assumption, I= 'd like >>>> to hear their reasoning. >>>> >>>> Based on that assumption, I have the following question and subsidia= ry >>>> questions: >>>> >>>> Question:=C2=A0 Do we create a separate Editorial Stream? >>> Yes, I believe it's useful. >>> =C2=A0 >>>> If YES - Who approves documents in that stream? >>> That's model-dependent, but I assume that in draft-thomson and draft-= carpenter >>> it would be the Program/WG by rough consensus, and in draft-stjohns i= t would be >>> the RSEB by vote. >> >> For the rough consensus models, I have two additional questions:=C2=A0= =C2=A0 1) Who determines rough consensus (and actually approves the docum= ents for publication) - the WG or Program Chairs? Yes, presumably. >>=C2=A0 2) If the stream managers=C2=A0 disagree with the rest of the gr= oup, are their oppositions given more weight than the self-selected membe= rship?=C2=A0 If not, why not?=C2=A0 If so, then how is that figured into = the resolution process? I assume it would be like in any IETF WG group: people tend to listen to = knowledgeable people, and we have RFC7282 to help us reach consensus. >>>> If NO - Where are documents that describe changes to the publication= >>>> process and system published? (The answer implies who approves publi= cation). >>> Again, it's model-dependent. In draft-thomson, it's clearly the IAB s= tream as >>> today. In the other two models, we are presumably left with the Indep= endent >>> stream. >> >> So ultimately, in draft-thomson, the IAB approves publication (per nor= mal procedures for the IAB stream) - in other words, no change from what'= s currently happening - is that correct? =C2=A0 For the other two then th= e ISE approves publication (per the normal procedures for that stream) - = is that correct?=20 That's my assumption, for the lack of any alternative. > The IAB has handled a number of such documents in the past, so in pract= ice that part seems to work. But maybe I am wrong. Does anyone remember d= ocuments for which this caused a tension? I agree, but it was a pragmatic choice because no other suitable stream e= xisted (as Heather said on a number of occasions in my hearing). Indeed, = 20+ years ago such documents were simply published by the RFC Editor on t= heir own account (e.g. RFC825, RFC1111, RFC1543, RFC2223) so this stream = would be a revival of that system. Brian C From nobody Sat Sep 19 14:35: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 98B043A0A70 for ; Sat, 19 Sep 2020 14:35: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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOx16KEoeTdH for ; Sat, 19 Sep 2020 14:35:03 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 3C3CF3A0A6E for ; Sat, 19 Sep 2020 14:35:03 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id x123so5782956pfc.7 for ; Sat, 19 Sep 2020 14:35:03 -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=Zgtzab/SpvsUSfKvYh0/FWd04o8G6ZKAss6wH0+lvWw=; b=LC+EbLPTwckTNFk2TowighG1fG2itYZ7H+iG7Zd1HyUr86Fwt5noH/DJTsKyKxhD31 /02gjBKIiISlLoxBI8GYQ85a8bg8hC+kCCzUJidsdaArd8yENqdGubN1Q++jj5nq53S4 0/CqSJEZ/JKd9xiJP2tUjHIENWGdz+jSWsDKc600T7L9EdP7tbarDnckyVInd5rf3ron 7+V7pMQGjQNjxC4LLcIU6yuED/sl56Q+hDT4xBMnOx5LLHET4WTJ9sctpCWo+znrRyA3 jpTwEkT6TfnT5vVoRHzdnRHjyBeZfent6Yz+E8gFeyuTjAIpI7RS7+ehHtjvkwI/B7zy WctA== 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=Zgtzab/SpvsUSfKvYh0/FWd04o8G6ZKAss6wH0+lvWw=; b=U4nk0oUMwXGjKNwDf9HSJ7D/xXoxUKuz20NInDd2NPUOtwhYGwQZN9rqSvqiqmkzx1 dKjwTAE1eDGVZbpIWJI4ljGzgDg/DYdg87xbvZyRuGJMrmkzwRt24VkFIeKAhkPLR11Z G//gf3gfil3SABrbHgp88MZSsbznPzPWfQpmdXODtJQHF2f+1FElpPbpj5ZT1QiNxY6B VgztJRM2nLiF0/fFqjPn8tv7iNPZHBcb1rea7IJ4MuoHFQ+tlE8a++MEYAiZJ79CXVC5 RuBrjcu9TC8vvHplpzzONYFPZv92cR+JKRq78CzGpoZX36EkdXZ0ukQfx49mtaFtQu4C j9MA== X-Gm-Message-State: AOAM532zlqo/EnU7O9GZDjwgtvNcPLpSXZxTZYLMsbdYqMsNt8szNBmy kirgqGleY2KhKZxxj+EMd+kAHxEnQR0= X-Google-Smtp-Source: ABdhPJzk9oD7qyCKgImoA/ZeMLR5aNfQ7TQLQ+I1RCXP8Qg2DP5yVl6UeAVPm3Uy1xNFpzGoVHXfgQ== X-Received: by 2002:a63:c74e:: with SMTP id v14mr9532710pgg.186.1600551302104; Sat, 19 Sep 2020 14:35:02 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id s8sm6559704pjn.10.2020.09.19.14.35.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Sep 2020 14:35:01 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <7399a374-7561-3b9e-2d04-07ade1a9174c@nthpermutation.com> From: Brian E Carpenter Message-ID: <7ca155d7-ad8a-921c-6853-ce210a2f1a7d@gmail.com> Date: Sun, 20 Sep 2020 09:34:56 +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: <7399a374-7561-3b9e-2d04-07ade1a9174c@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Sep 2020 21:35:05 -0000 > I've been trying to do a topological sort That's exactly why I drew my Venn diagram... Regards Brian Carpenter On 20-Sep-20 05:13, Michael StJohns wrote: > For the same reasons we discussed on the call, I choose option C - we'r= e not ready to pick a path.=C2=A0=C2=A0 That looks closer to Option B tha= n it does option A but probably actually isn't the same.=C2=A0 We've talk= ed about common solution elements, but we're still having major discussio= ns (cf John and and Adam's back and forth) about the implications of vari= ous choices such that picking solution elements are still quite difficult= =2E=C2=A0 Among other things, many of the elements are entwined - e.g., c= hoosing choice A of Group 1 may restrict your choices in Group 2 to choic= es C and F. >=20 >=20 > As I read it we've agreed mostly on one thing: >=20 > * That the stream managers will take a major role in the evolution pr= ocess of the RFC Series.=C2=A0=C2=A0 >=20 > We seem to have also agreed that (I think this is what I got an agreeme= nt on from Martin and Brian when I asked the question on the call): >=20 > * The LLC will be responsible for any contractual items including hir= ing/firing/renewals/day-to-day and that any delegation of that role will = be only to a "fiduciary" of the LLC (e.g. employee or a contracted role) = to specifically exclude the IAB/RSOC personnel management model. >=20 > We haven't agreed on: >=20 > * Whether there will be a professional involved in the steering, or t= he model of engagement for that professional.=C2=A0 (e.g. employee or ret= ained contractor with primary responsibility vs employee or retained cont= ractor with advisory only responsibility or a professional contractor eng= aged only for task-specific short term items). >=20 > * The model for publication of documents that drive the publication p= rocess. >=20 > And lots more. >=20 > I've been trying to do a topological sort and figure out which of the p= roblems is the core one that we need to come to a conclusion on, and I'm = at a loss. >=20 > Mike >=20 >=20 >=20 > On 9/18/2020 11:55 AM, Eliot Lear wrote: >> Hello everyone, >> >> >> =E2=80=9CWhen you come to a fork in the road, take it.=E2=80=9D >> =E2=80=94 Yogi Bera >> >> The chairs have had an opportunity to discuss the last interim. =C2=A0= We note that some people liked the comparison chart, as a means to highli= ght both similarities and differences. =C2=A0 We know that some people wo= uld very much like to have seen a draft adopted, while others were not re= ady to move forward. =C2=A0Several people would instead like to go issue = by issue and resolve those issues before adopting a draft. =C2=A0The chai= rs will leave this choice to the group as to which way to proceed at the = moment. >> >> You are invited to specify your preference *on list*=C2=A0*by Septembe= r 25th, 2:00pm GMT. =C2=A0Option A or Option B. =C2=A0Please be explicit.= * >> >> We can pursue one of two approaches: >> >> *Option A: =C2=A0Pursue adopting a draft* >> >> The approach would be that we *would*=C2=A0adopt a draft by IETF 109 =E2= =80=93 *as a starting point*. =C2=A0To avoid further deadlocks, there wou= ld be *no*=C2=A0=E2=80=9CI=E2=80=99m not ready=E2=80=9D option in the hum= =2E =C2=A0Authors are invited to merge and indicate open issues in drafts= =2E =C2=A0Others are invited, if they really feel the need, to create new= drafts within 2-3 weeks. =C2=A0If there are more than two options, the c= hairs will find ways to wheedle things down to get to a draft to adopt, w= hile being sensitive to the concerns EKR and others raised about inertia = of what is in a draft. =C2=A0If the group would like an interim to facili= tate this option, the chairs will accommodate. >> >> *Option B: Pursue open issues one by one* >> >> Pursue issues one by one to resolve on list, starting with =E2=80=9CDo= people believe that the RSE position should continue in some form?=E2=80= =9D =C2=A0We would pursue from the nature of the role if we get an affirm= ative answer. =C2=A0Other questions would follow, such as aspects of over= sight and relationship to RPC. >> >> If after the poll the group is evenly divided between these choices, i= n order to take the fork, the chairs will spin a spinner and make a decis= ion. =C2=A0You are encouraged to discuss these options, and may change yo= ur minds right up to the deadline. >> >> *A Plea* >> >> This program consists nearly exclusively of senior members of the comm= unity- =C2=A0you are all past or current leaders of this organization wit= h deep experience and knowledge. =C2=A0We therefore hope that you will se= ek to find common ground with one another when you see a deadlock in view= =2E >> >> Brian and Eliot >> >> >=20 >=20 From nobody Sat Sep 19 20:22: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 B8E4E3A0EEC for ; Sat, 19 Sep 2020 20:22:29 -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, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwkMxhx4SkaW for ; Sat, 19 Sep 2020 20:22:28 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9224D3A0EE9 for ; Sat, 19 Sep 2020 20:22:28 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kJpuK-000BQs-GW; Sat, 19 Sep 2020 23:20:56 -0400 Date: Sat, 19 Sep 2020 23:20:36 -0400 From: John C Klensin To: Michael StJohns , rfced-future@iab.org Message-ID: <7DB0FD39175B52C231DE18E9@JcK-HP5> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 03:22:30 -0000 FWIW, I agree with Mike. It seems obvious to me (and was the main reaon I voted "not ready" last week) that several of the specific questions I think Eliot is trying to get at with both Options A and B are not orthogonal [1]. Consequently, if we try to go forward by asking a question, reaching a conclusion, and than considering that conclusion as firm, the order in which questions are posed is likely to affect the overall conclusions. If we are allowed to revisit settled questions when the interactions with others are clear, it will feel as if we are going around in circles. Too many of us are starting from such philosophically different assumptions that "choose one" is just not an answer (the interaction between Adam and myself is probably a symptom). I still suspect (not sure) that (as I suggested during the call) the most productive path forward would be to find a neutral but knowledgeable volunteer to create a new document, possibly building on Nevil's rather than Brian's, Martin's, or Mike's or just starting from scratch) and get an outline and what we have actually agreed on written down, then see if we can start adding thinks in. best, john [1] Statistical observation: While it is worth trying, multivariate situations with non-orthogonal variates often do not lend themselves to developing clarity via Venn diagrams. --On Saturday, September 19, 2020 13:13 -0400 Michael StJohns wrote: > For the same reasons we discussed on the call, I choose option > C - we're not ready to pick a path.=C2=A0=C2=A0 That looks = closer to > Option B than it does option A but probably actually isn't the > same.=C2=A0 We've talked about common solution elements, but = we're > still having major discussions (cf John and and Adam's back > and forth) about the implications of various choices such that > picking solution elements are still quite difficult.=C2=A0 = Among > other things, many of the elements are entwined - e.g., > choosing choice A of Group 1 may restrict your choices in > Group 2 to choices C and F. >=20 >=20 > As I read it we've agreed mostly on one thing: >=20 > * That the stream managers will take a major role in the > evolution > process of the RFC Series. >=20 > We seem to have also agreed that (I think this is what I got > an agreement on from Martin and Brian when I asked the > question on the call): >=20 > * The LLC will be responsible for any contractual items > including > hiring/firing/renewals/day-to-day and that any delegation > of that > role will be only to a "fiduciary" of the LLC (e.g. > employee or a > contracted role) to specifically exclude the IAB/RSOC > personnel > management model. >=20 > We haven't agreed on: >=20 > * Whether there will be a professional involved in the > steering, or > the model of engagement for that professional.=C2=A0 (e.g. > employee or > retained contractor with primary responsibility vs > employee or > retained contractor with advisory only responsibility or a > professional contractor engaged only for task-specific > short term > items). >=20 > * The model for publication of documents that drive the > publication > process. >=20 > And lots more. >=20 > I've been trying to do a topological sort and figure out which > of the problems is the core one that we need to come to a > conclusion on, and I'm at a loss. >=20 > Mike >=20 From nobody Sat Sep 19 20:58:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180F43A0F43 for ; Sat, 19 Sep 2020 20:58:25 -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, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=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 6rvpFdtPy5FM for ; Sat, 19 Sep 2020 20:58:24 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9B93A0F3E for ; Sat, 19 Sep 2020 20:58:23 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kJqRv-000BSp-FN; Sat, 19 Sep 2020 23:55:39 -0400 Date: Sat, 19 Sep 2020 23:55:19 -0400 From: John C Klensin To: Brian E Carpenter , Christian Huitema , Michael StJohns , rfced-future@iab.org Message-ID: <431C046D76BEA50F4FB7C8E7@JcK-HP5> In-Reply-To: References: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [Rfced-future] Question for discussion - Editorial Stream X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 03:58:25 -0000 --On Sunday, 20 September, 2020 09:31 +1200 Brian E Carpenter wrote: >> The IAB has handled a number of such documents in the past, >> so in practice that part seems to work. But maybe I am wrong. >> Does anyone remember documents for which this caused a >> tension? > > I agree, but it was a pragmatic choice because no other > suitable stream existed (as Heather said on a number of > occasions in my hearing). Indeed, 20+ years ago such documents > were simply published by the RFC Editor on their own account > (e.g. RFC825, RFC1111, RFC1543, RFC2223) so this stream would > be a revival of that system. Yes and no... and that takes us back to interactions among different questions. Back when it was "simply published...", the RFC Editor didn't need to ask anyone for approval. For better or worse, there is no analogy for that in the Stream model because, while I can't remember an explicit rule, authors approving their own documents is clearly considered to be in bad taste. The Independent Stream comes closest, but were the person who holds the ISE role to write a document and then publish it without consulting anyone else, I assume we'd be fairly unhappy. I do remember discussing whether the RSE should be allowed to publish documents directly in the RFC 4844 timeframe but don't remember the reasons why a "no" decision was made -- Joel or others might remember. I suspect it was because the IAB considered review and approval to be part of its oversight responsibility. Sometimes, the IAB has basically been passive, doing a quick review, maybe asking for community comment, and then going ahead and publishing. Other times, it has acted as if those really were its documents and they should not be published without strong IAB consensus (whether the IAB actually had the relevant expertise or not). I suggest that, if we think what got us here was a result of the IAB intervening inappropriately, then having the IAB as document approver is not a wildly good idea. If the RSE-replacement is going to be an employee or contractor of a contractor or just an advisor, it is less clear to me why we need such a stream... at least unless we can set (and keep to) rather high requirements for expertise in whatever WG or committee is actually running the show. best, john From nobody Sat Sep 19 20:59:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96CE3A0F43; Sat, 19 Sep 2020 20:59:23 -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, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snBXcKt8MieV; Sat, 19 Sep 2020 20:59:22 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61AA3A0F3F; Sat, 19 Sep 2020 20:59:22 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kJqU7-000BSs-Qw; Sat, 19 Sep 2020 23:57:55 -0400 Date: Sat, 19 Sep 2020 23:57:35 -0400 From: John C Klensin To: Eliot Lear , adrian@olddog.co.uk cc: rfced-future@iab.org Message-ID: <8A257619C61553A6C066CBA9@JcK-HP5> In-Reply-To: References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 03:59:24 -0000 --On Saturday, 19 September, 2020 12:09 +0200 Eliot Lear wrote: >> On 18 Sep 2020, at 22:06, Adrian Farrel >> wrote: >> >> Suppose we adopt an empty-ish draft (perhaps has background >> and objectives, perhaps has initial list of open >> issues/questions) and then follow option B recording each >> decision in the draft as it comes to (rough) consensus? > > To me this is a valid version of Option A, and we might even > employ it as a means to implement Option B. It is also > possible that a draft would emerge that leaves open issues > which we do not have agreement. That would give us a bit more > than a blank page. While I have trouble seeing it as a version of Option A --or, more specifically, I cannot support Option A in order to get to it because of all of the other possible versions -- it is more or less what I suggested toward the end of the call and in an earlier note (my) today. john From nobody Sat Sep 19 21:10: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 A6B293A0F67 for ; Sat, 19 Sep 2020 21:10: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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwvuvYGYkyl1 for ; Sat, 19 Sep 2020 21:10:23 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833603A0F66 for ; Sat, 19 Sep 2020 21:10:23 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id q12so5131790plr.12 for ; Sat, 19 Sep 2020 21:10:23 -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=Ze3bANVsQZsHo0IDe0+HdSWhK46QDikzhbwJr/+Sidw=; b=T2Gn+b86oaYQqp7h+4tFLPBVH24sAoZ+EiDgy/fCgT0s9cCnL0n+1dxGB+GnOTJFIQ IWPXwleBUG3Fb2sb2GJ9gWZESRz7jyVftQm3LPeOx/R+Q0DcAMca+usLxw1nUcZi3DaX UqYA0C4z8YW50h0JAHbA8S4/gpLgsxjs1cShgODElphQ0nJhbY8FXvgUz8c/uakyJahR 0Sg9OpaofUd1YfS8Jwqf11AUj8LYJcwlZed0yuLygzw5o3K3lRUQXzKYqY2JtWeLWxeZ OZna0fMKDvLwO7CaHVf+2BvF4jySA4uFOKj7X1VP/u8Fr62oO4kXk1CliYW+5i1nNEDO tLlg== 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=Ze3bANVsQZsHo0IDe0+HdSWhK46QDikzhbwJr/+Sidw=; b=D+LxSvRTq7az1jxy4W+lf48RzlGR6b45KEEKL1VQmYgjT4CJ+BrAfDIUBlkif6ez1v JoNH//D5qfxe4tl/K1k6hBZKf9cWj6sRZ1wAHm5PyafX4CB1gXA5e9ydJGeNq62ABRoU 51sNV5kWdLUTEspSAlEmmBXBOnyg+1ZLjeuykKUis3qkhfHplMUSTL5VIV3ndnUDt5rp QPUN4hWdzvYeDGPyRjQcf1VQSLOtNBMOohWMYCPahpueqFHkZAEgQTCUxViNsyT12tIi WTqrvUrmkLiMg7LhB/XV+0N7+eOSF+gTuX43U0hxurxlnyyYeqza2bmgCdgpbETHecPs wDMg== X-Gm-Message-State: AOAM533YUWfm3DdH43S9bRlNBufbGy4SE5mEJ1AV3YX2umXma8uTtSIa DQ1kzn9ky+HLGquoZ56ybewjJ22WxFE= X-Google-Smtp-Source: ABdhPJwiI76pz+pWybUU2uQA8T8NgHKwsQXQ/uKuLvaYgr0J/dalvg7A8xAKwru72JG/lDb5edW2eg== X-Received: by 2002:a17:902:b715:b029:d2:1d6e:bf25 with SMTP id d21-20020a170902b715b02900d21d6ebf25mr2241849pls.63.1600575022783; Sat, 19 Sep 2020 21:10:22 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id 134sm8369390pfa.93.2020.09.19.21.10.20 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Sep 2020 21:10:21 -0700 (PDT) To: rfced-future@iab.org References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> From: Brian E Carpenter Message-ID: <544f614f-8d96-6d7c-8180-d25bc4dfd529@gmail.com> Date: Sun, 20 Sep 2020 16:10: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: <8A257619C61553A6C066CBA9@JcK-HP5> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 04:10:25 -0000 On 20-Sep-20 15:57, John C Klensin wrote: > > > --On Saturday, 19 September, 2020 12:09 +0200 Eliot Lear > wrote: > >>> On 18 Sep 2020, at 22:06, Adrian Farrel >>> wrote: >>> >>> Suppose we adopt an empty-ish draft (perhaps has background >>> and objectives, perhaps has initial list of open >>> issues/questions) and then follow option B recording each >>> decision in the draft as it comes to (rough) consensus? >> >> To me this is a valid version of Option A, and we might even >> employ it as a means to implement Option B. It is also >> possible that a draft would emerge that leaves open issues >> which we do not have agreement. That would give us a bit more >> than a blank page. > > While I have trouble seeing it as a version of Option A --or, > more specifically, I cannot support Option A in order to get to > it because of all of the other possible versions -- it is more > or less what I suggested toward the end of the call and in an > earlier note (my) today. I agree too. Without debating the merits of over-simplification by Venn diagram, one thing that it taught me is that separating out the agreed from the unagreed issues is a very good first step. Brian From nobody Sun Sep 20 01:06: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 8E5F63A113E for ; Sun, 20 Sep 2020 01:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 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, RCVD_IN_DNSWL_BLOCKED=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 mA6bW9ig1eFl for ; Sun, 20 Sep 2020 01:06:42 -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 3DAA33A113D for ; Sun, 20 Sep 2020 01:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16973; q=dns/txt; s=iport; t=1600589202; x=1601798802; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=GgbWG3+GmiY3pHcYGSqcHZJciEmHmMhheAwYJBd6LhU=; b=VAcVURJArvzzUCJgsULu/9iRCdttnETg+h0jRr/MOauRAcwTTJX3fyOJ LDM3v+ZoJnpFZ5M31BieVoOJ9XXXf2fFQ6L0u0Yh/HlhKviGQUxU4Et7J 5o/VBp4Vp9Q9X34+Lo//YMDac2RwUen4aykQqAQi4tRO/ukKcXOtdvtYF Y=; X-IPAS-Result: =?us-ascii?q?A0BfAADFDGdf/xbLJq1fGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGCDwKBIYF3VQEyLIQ6iQKIPJwfCwEBAQ0BARgBCgwEA?= =?us-ascii?q?QGESwKCLCU5BQ0CAwEBAQMCAwEBAQEFAQEBAgEGBG2FXAyFcgEBAQECAQEBI?= =?us-ascii?q?UsLBQsLGCcDAgInHxEGE4MmAYJcIA+ye3aBMoVThQgGgTgBjUaCAIE4HIE4g?= =?us-ascii?q?RU+glwBA4R0M4ItBJA/pm+CcYMRjDeLBAMegwyJeYUPjm2vG4NcAgQGBQIVg?= =?us-ascii?q?WwigVczGggbFTsqAYI+PhIZDZckhUQ/AzACNQIGAQkBAQMJjl8BAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.77,282,1596499200"; d="scan'208,217"; a="27326843" 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; 20 Sep 2020 08:06:38 +0000 Received: from [10.61.213.221] ([10.61.213.221]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 08K86YpK001386 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Sep 2020 08:06:37 GMT From: Eliot Lear Message-Id: <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8F4F1F0D-8049-48AA-81CB-76FB39071947" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sun, 20 Sep 2020 10:06:34 +0200 In-Reply-To: <8A257619C61553A6C066CBA9@JcK-HP5> Cc: Eliot Lear , adrian@olddog.co.uk, rfced-future@iab.org To: John C Klensin References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.213.221, [10.61.213.221] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 08:06:45 -0000 --Apple-Mail=_8F4F1F0D-8049-48AA-81CB-76FB39071947 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s fine. What you, Brian, and Mike have argued for is = Option B, which is to resolve matters issue by issue. Noted. Eliot > On 20 Sep 2020, at 05:57, John C Klensin wrote: >=20 >=20 >=20 > --On Saturday, 19 September, 2020 12:09 +0200 Eliot Lear > > wrote: >=20 >>> On 18 Sep 2020, at 22:06, Adrian Farrel >>> wrote: >>>=20 >>> Suppose we adopt an empty-ish draft (perhaps has background >>> and objectives, perhaps has initial list of open >>> issues/questions) and then follow option B recording each >>> decision in the draft as it comes to (rough) consensus? >>=20 >> To me this is a valid version of Option A, and we might even >> employ it as a means to implement Option B. It is also >> possible that a draft would emerge that leaves open issues >> which we do not have agreement. That would give us a bit more >> than a blank page. >=20 > While I have trouble seeing it as a version of Option A --or, > more specifically, I cannot support Option A in order to get to > it because of all of the other possible versions -- it is more > or less what I suggested toward the end of the call and in an > earlier note (my) today. >=20 > john >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = --Apple-Mail=_8F4F1F0D-8049-48AA-81CB-76FB39071947 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s fine.  What you, Brian, and Mike have = argued for is Option B, which is to resolve matters issue by issue. =  Noted.

Eliot

On 20 Sep 2020, at 05:57, John C Klensin <john-ietf@jck.com> = wrote:



--On Saturday, 19 September, = 2020 12:09 +0200 Eliot Lear
<lear=3D40cisco.com@dmarc.ietf.org> wrote:

On 18 Sep 2020, at = 22:06, Adrian Farrel <adrian@olddog.co.uk>
wrote:

Suppose we adopt an empty-ish draft (perhaps = has background
and objectives, perhaps has initial list of = open
issues/questions) and then follow option B recording = each
decision in the draft as it comes to (rough) = consensus?

To me this is a = valid version of Option A, and we might even
employ it as = a means to implement Option B.  It is also
possible = that a draft would emerge that leaves open issues
which we = do not have agreement.  That would give us a bit more
than a blank page.

While I have trouble seeing it = as a version of Option A --or,
more specifically, I cannot support Option A in order to get = to
it because of = all of the other possible versions -- it is more
or less what I suggested toward = the end of the call and in an
earlier note (my) today.

 john



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

= --Apple-Mail=_8F4F1F0D-8049-48AA-81CB-76FB39071947-- From nobody Sun Sep 20 04:17: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 A28BA3A1275; Sun, 20 Sep 2020 04:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhhGjOA730pK; Sun, 20 Sep 2020 04:17:38 -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 4C0923A1274; Sun, 20 Sep 2020 04:17:37 -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 08KBHW1P019041; Sun, 20 Sep 2020 12:17:32 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CCD142203D; Sun, 20 Sep 2020 12:17:31 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id B79FE2203B; Sun, 20 Sep 2020 12:17:31 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.216.228]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08KBHUlw024215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Sep 2020 12:17:31 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , "'John C Klensin'" Cc: "'Eliot Lear'" , References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> In-Reply-To: <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> Date: Sun, 20 Sep 2020 12:17:30 +0100 Organization: Old Dog Consulting Message-ID: <051801d68f3f$a1dcc4c0$e5964e40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0519_01D68F48.03A1C900" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGR9HXXfL/DtwnRZr3fsQ1/cPZpLwHP8HmyARKPmvoBmf8XzQJRwxtzqcQjFAA= Content-Language: en-gb X-Originating-IP: 87.112.216.228 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-25676.006 X-TM-AS-Result: No--24.747-10.0-31-10 X-imss-scan-details: No--24.747-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25676.006 X-TMASE-Result: 10--24.747500-10.000000 X-TMASE-MatchedRID: b/1IsOqez6fxIbpQ8BhdbJr5ykm9NtIcO4NrJdLQuoG+fWK8N2kAh4y+ AfTlDGN1ixRwjbvUO2yQZBuRwqhRFoPjBihiUIJ3dPM8veyrICYHgh3sKJBzPwbYcy9YQl6e+jV zof0NuiO4iSJ1SJuw+EHklWP+Sivy/bhNbKI2qQY+YpQRXGWohnJZsqnL5DRj36BFvDcr528UFD 9AIWhoca2Fv4TmNgU8aE8D90AdeeR48YB5KfXbgksh+mzT1UnbihzZ9XQG968XifDzA2vgchADU 0md7t14AVR/Z1Vkq9kQHhXrWiYmrhpyDQhR3JfpamOGWbsSIFcm4lf0t+giOEetfYTYyR9EPgIJ 33Eqzot6OnKJXvwgWiUqEvqd7TA+n01hUgTz7Xlx+x1f5juFE/4159kh1Jlcm5BJdUjD+FWVRzE Z9aTQbRwO2DfBN9oupboK15uSCnBOnGZrvAmZisf0rZmodBaW31asM/gsp2mpVUR0SvYtSsxFQx p3PhHymoRv4vCWtWO3WBVXyEWl0u84LVBXtoHOWcC0gYMYIWj54F/2i/DwjSPS9JdK3W4/bgY8Q wl4o87lS2BlJV0Y0lfuIRg3vVpG9+5/BYKbkRnAsQvj68mG0+v6L5uWBkxpauWolGlVMiBR18Qp zXStTvkHxcbJXlk3NQO42YVKKvBTovWuZWqWkZi/JtCbSi1TJd2n2XoSRFkOFxRlsKOuiJvshpX wo4oNYGVqLWnXv2izjooby3wmL848sKVVS9YSQS9htnVEje7QevMKEpazy7LLTvamG8BJo8WMkQ Wv6iXoC+VlRHhOyFlmYwhSwhAawLhRRmviVIWLZAVphLW/basQd9qPXhnJg9ngg+efDL39/mXSp 5dimmGVFYu1LzHsU/nj13Yh4BBDqvhQjOI+Fw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 11:17:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0519_01D68F48.03A1C900 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It may be seen as a secondary issue, but I would really like the results = of deliberations in Option B to be recorded in an I-D and not some issue = tracker, wiki, or github repo. When I suggested this earlier in the = thread you suggested this was actually Option A because there was a = draft adopted to work on. That made me say I was happy with = =E2=80=9CA+B=E2=80=9D. =20 So, for the avoidance of doubt, I would like to see issues resolved one = by one. That is Option B. =20 A =20 From: Eliot Lear =20 Sent: 20 September 2020 09:07 To: John C Klensin Cc: Eliot Lear ; adrian@olddog.co.uk; = rfced-future@iab.org Subject: Re: [Rfced-future] Moving forward: Please state your preference =20 That=E2=80=99s fine. What you, Brian, and Mike have argued for is = Option B, which is to resolve matters issue by issue. Noted. =20 Eliot On 20 Sep 2020, at 05:57, John C Klensin > wrote: =20 --On Saturday, 19 September, 2020 12:09 +0200 Eliot Lear < = lear=3D40cisco.com@dmarc.ietf.org> wrote: On 18 Sep 2020, at 22:06, Adrian Farrel > wrote: Suppose we adopt an empty-ish draft (perhaps has background and objectives, perhaps has initial list of open issues/questions) and then follow option B recording each decision in the draft as it comes to (rough) consensus? To me this is a valid version of Option A, and we might even employ it as a means to implement Option B. It is also possible that a draft would emerge that leaves open issues which we do not have agreement. That would give us a bit more than a blank page. While I have trouble seeing it as a version of Option A --or, more specifically, I cannot support Option A in order to get to it because of all of the other possible versions -- it is more or less what I suggested toward the end of the call and in an earlier note (my) today. john --=20 Rfced-future mailing list Rfced-future@iab.org = https://www.iab.org/mailman/listinfo/rfced-future =20 ------=_NextPart_000_0519_01D68F48.03A1C900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It may be seen as a secondary = issue, but I would really like the results of deliberations in Option B = to be recorded in an I-D and not some issue tracker, wiki, or github = repo. When I suggested this earlier in the thread you suggested this was = actually Option A because there was a draft adopted to work on. That = made me say I was happy with = =E2=80=9CA+B=E2=80=9D.

 

So, for the = avoidance of doubt, I would like to see issues resolved one by one. That = is Option B.

 

A

 

From: Eliot Lear = <lear@cisco.com>
Sent: 20 September 2020 = 09:07
To: John C Klensin = <john-ietf@jck.com>
Cc: Eliot Lear = <lear=3D40cisco.com@dmarc.ietf.org>; adrian@olddog.co.uk; = rfced-future@iab.org
Subject: Re: [Rfced-future] Moving = forward: Please state your = preference

 

That=E2=80=99s fine.  What you, Brian, and Mike = have argued for is Option B, which is to resolve matters issue by issue. =  Noted.

 

Eliot



On 20 Sep 2020, at 05:57, John C Klensin <john-ietf@jck.com> = wrote:

 



--O= n Saturday, 19 September, 2020 12:09 +0200 Eliot Lear
<lear=3D40ci= sco.com@dmarc.ietf.org> = wrote:


On 18 Sep = 2020, at 22:06, Adrian Farrel <adrian@olddog.co.uk>
wrote:=

Suppose we adopt an empty-ish draft (perhaps has = background
and objectives, perhaps has initial list of = open
issues/questions) and then follow option B recording = each
decision in the draft as it comes to (rough) = consensus?


To me = this is a valid version of Option A, and we might even
employ it as a = means to implement Option B.  It is also
possible that a draft = would emerge that leaves open issues
which we do not have agreement. =  That would give us a bit more
than a blank = page.


While = I have trouble seeing it as a version of Option A --or,
more = specifically, I cannot support Option A in order to get to
it because = of all of the other possible versions -- it is more
or less what I = suggested toward the end of the call and in an
earlier note (my) = today.

 john



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

 

------=_NextPart_000_0519_01D68F48.03A1C900-- From nobody Sun Sep 20 04:33: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 EF1233A128C for ; Sun, 20 Sep 2020 04:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCoCSFTVkkJU for ; Sun, 20 Sep 2020 04:33:05 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B763A1288 for ; Sun, 20 Sep 2020 04:33:04 -0700 (PDT) Received: from [172.16.42.104] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BvQRd32G3z105C; Sun, 20 Sep 2020 13:33:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <051801d68f3f$a1dcc4c0$e5964e40$@olddog.co.uk> Date: Sun, 20 Sep 2020 13:33:00 +0200 Cc: Eliot Lear , John C Klensin , rfced-future@iab.org, Eliot Lear X-Mao-Original-Outgoing-Id: 622294380.6440049-39ceddb44fa1b8349ee5c0448d58e3e5 Content-Transfer-Encoding: quoted-printable Message-Id: <2A07FE92-6878-46F7-8694-DB45D87DFEE9@tzi.org> References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <051801d68f3f$a1dcc4c0$e5964e40$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 11:33:07 -0000 On 2020-09-20, at 13:17, Adrian Farrel wrote: >=20 > It may be seen as a secondary issue, but I would really like the = results of deliberations in Option B to be recorded in an I-D and not = some issue tracker, wiki, or github repo.=20 I would even more happy if we could record the rationale for the = decisions as well. Bonus, if we do this in a way an engineer can = understand. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Sep 20 06:18: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 534F73A041C; Sun, 20 Sep 2020 06:18:02 -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, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqkKsKB6W461; Sun, 20 Sep 2020 06:18:01 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D954B3A03F5; Sun, 20 Sep 2020 06:18:00 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kJzCA-000C4S-Bk; Sun, 20 Sep 2020 09:15:58 -0400 Date: Sun, 20 Sep 2020 09:15:38 -0400 From: John C Klensin To: Eliot Lear cc: Eliot Lear , adrian@olddog.co.uk, rfced-future@iab.org Message-ID: In-Reply-To: <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 13:18:02 -0000 Eliot, I don't think so, any more than I think it is really a variation on Option A. First, I think what I suggested --and what I think Brian's efforts to create Venn diagrams and the like suggest -- is that "issue by issue" may be impossible (or a way to foreclose some key topics) because of the ways in which issues are interrelated. Second, it is Option B only if Option B is combined with a new I-D used as a base document that starts with what we agree on now (if anything) and that is updated as consensus evolves (as Adrian suggested a couple of hours ago but was, I thought, clearly intended by my note and others) and documents the rationale for each decision (as Carsten suggested even more recently). That idea has been largely consistent since the call. Although I suggested it on the call, it does not originate with me but was a small consolidation of things said earlier and several (IMO rather small and converging) variations have been suggested since. The very fact that you earlier suggested it was really a variation on Option A and now suggest that it is really Option B is more consistent with the several suggestions for "A+B", "C or others", and, for at least some of us, "not ready" on the call when you suggested a choice between A and B. Of course, the same situation implies that we could somehow all agree that the suggestion is "really A" or "really B" but then start arguing about what A or B "really" means, e.g., how we document the decisions of Option B or whether Option A means starting with a new document or whether we debate changes from existing ones. I don't think an apparent decision followed by that argument would move things forward, YMMD. I respect and appreciate your (and Brian Rosen's) desire to make and show progress and drive things to consensus more quickly. However, doing that by creating what some of us consider false dichotomies and then apparently interpreting comments as consistent with one or the other of those options does not seem to me to be the way to do it. In a "normal" WG, I think it would even result in appeals. best, john --On Sunday, 20 September, 2020 10:06 +0200 Eliot Lear wrote: > That's fine. What you, Brian, and Mike have argued for is > Option B, which is to resolve matters issue by issue. Noted. > > Eliot > >> On 20 Sep 2020, at 05:57, John C Klensin >> wrote: >> >> >> >> --On Saturday, 19 September, 2020 12:09 +0200 Eliot Lear >> > > wrote: >> >>>> On 18 Sep 2020, at 22:06, Adrian Farrel >>>> wrote: >>>> >>>> Suppose we adopt an empty-ish draft (perhaps has background >>>> and objectives, perhaps has initial list of open >>>> issues/questions) and then follow option B recording each >>>> decision in the draft as it comes to (rough) consensus? >>> >>> To me this is a valid version of Option A, and we might even >>> employ it as a means to implement Option B. It is also >>> possible that a draft would emerge that leaves open issues >>> which we do not have agreement. That would give us a bit >>> more than a blank page. >> >> While I have trouble seeing it as a version of Option A --or, >> more specifically, I cannot support Option A in order to get >> to it because of all of the other possible versions -- it is >> more or less what I suggested toward the end of the call and >> in an earlier note (my) today. >> >> john >> >> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> From nobody Sun Sep 20 07:14:30 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFB63A0846 for ; Sun, 20 Sep 2020 07:14:28 -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 zFWXnlsPDM0S for ; Sun, 20 Sep 2020 07:14:27 -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 93A513A0844 for ; Sun, 20 Sep 2020 07:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20358; q=dns/txt; s=iport; t=1600611266; x=1601820866; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=+7bzBfqjxaDh7m7OZzZY/2HfitJ/tZwPe+kniSv/trg=; b=CIlc7bOTVt+DJS2Z1mE/n4N0xc98Z+amYP3p5YQ6rSjw4KpM/095buAm Y/ybcxkYL/R353eOqoq3dnTz8sg4aBshPkufp13fn9VydI6pjmYOeATQL v2ma5rF5zQmeFBdrT/EYsDuy5E7+uXm2+Q1rsmZ3tNPP/44hq587Fwp3q k=; X-IPAS-Result: =?us-ascii?q?A0B3AADEYmdf/xbLJq1eHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?QUBAQsBAYEhgkwBIBIshDqJAog8miKBfQsBAQENAQEvBAEBhEsCgiwlNgcOA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgRthWhDARABhR0BAQEBAgEjVgULCxggCgICV?= =?us-ascii?q?wYTH4MHgl0gslt2gTKFU4USgTgBjUaCAIE4HIJNPodUM4ItBI9pp0WCcYMRl?= =?us-ascii?q?zsDHoMMiXmFD45trxuDXAIEBgUCFYFbDiWBVzMaCBsVZQGCPj4SGQ1YjVMXj?= =?us-ascii?q?iY/AzA3AgYBCQEBAwmHNIcrAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.77,283,1596499200"; d="scan'208,217"; a="27330782" 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; 20 Sep 2020 14:14:22 +0000 Received: from [10.61.213.221] ([10.61.213.221]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 08KEELmV013274 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Sep 2020 14:14:22 GMT From: Eliot Lear Message-Id: <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8021A720-59CD-4961-BD0C-6EE631B783B6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sun, 20 Sep 2020 16:14:21 +0200 In-Reply-To: Cc: Eliot Lear , adrian@olddog.co.uk, rfced-future@iab.org To: John C Klensin References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.213.221, [10.61.213.221] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 14:14:29 -0000 --Apple-Mail=_8021A720-59CD-4961-BD0C-6EE631B783B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi John, > On 20 Sep 2020, at 15:15, John C Klensin wrote: >=20 > Eliot, >=20 > I don't think so, any more than I think it is really a variation > on Option A. First, I think what I suggested --and what I think > Brian's efforts to create Venn diagrams and the like suggest -- > is that "issue by issue" may be impossible (or a way to > foreclose some key topics) because of the ways in which issues > are interrelated. I understand your concern. Let=E2=80=99s agree among ourselves that we = will avoid such foreclosures in particular, and that we will work to = understand such linkages. If issues have to be taken together, let=E2=80=99= s understand why. > Second, it is Option B only if Option B is > combined with a new I-D used as a base document that starts with > what we agree on now (if anything) and that is updated as > consensus evolves (as Adrian suggested a couple of hours ago but > was, I thought, clearly intended by my note and others) and > documents the rationale for each decision (as Carsten suggested > even more recently). I think that=E2=80=99s where we are heading, but we will see what others = think. If people do not object to that idea, we as a group can act on = it. >=20 > That idea has been largely consistent since the call. Although > I suggested it on the call, it does not originate with me but > was a small consolidation of things said earlier and several > (IMO rather small and converging) variations have been suggested > since. The very fact that you earlier suggested it was really a > variation on Option A Not quite. Option A provides us a draft upon which to build. B states = rather categorically that we don=E2=80=99t yet have a starting point and = need to develop one. The chairs can facilitate either approach. We = personally like A because it advances the group's efforts, but we = won=E2=80=99t/can=E2=80=99t force our views on the group. Eliot= --Apple-Mail=_8021A720-59CD-4961-BD0C-6EE631B783B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = John,

On 20 Sep 2020, at 15:15, John C Klensin = <john-ietf@jck.com> wrote:

Eliot,

I don't think so, any more than = I think it is really a variation
on Option A.  First, I think what I suggested --and what = I think
Brian's = efforts to create Venn diagrams and the like suggest --
is that "issue by issue" may be = impossible (or a way to
foreclose some key topics) because of the ways in which = issues
are = interrelated.

I = understand your concern.  Let=E2=80=99s agree among ourselves that = we will avoid such foreclosures in particular, and that we will work to = understand such linkages.  If issues have to be taken together, = let=E2=80=99s understand why.


 Second, it is Option B = only if Option B is
combined with a new I-D used as a base document that starts = with
what we agree = on now (if anything) and that is updated as
consensus evolves (as Adrian = suggested a couple of hours ago but
was, I thought, clearly intended by my note and others) = and
documents the = rationale for each decision (as Carsten suggested
even more recently).

I think that=E2=80= =99s where we are heading, but we will see what others think.  If = people do not object to that idea, we as a group can act on = it.


That idea has = been largely consistent since the call.  Although
I suggested it on the call, it = does not originate with me but
was a small consolidation of things said earlier and = several
(IMO rather = small and converging) variations have been suggested
since.  The very fact that = you earlier suggested it was really a
variation on Option A


Not quite.  Option A = provides us a draft upon which to build.  B states rather = categorically that we don=E2=80=99t yet have a starting point and need = to develop one.  The chairs can facilitate either approach. =  We personally like A because it advances the group's efforts, but = we won=E2=80=99t/can=E2=80=99t force our views on the = group.

Eliot
= --Apple-Mail=_8021A720-59CD-4961-BD0C-6EE631B783B6-- From nobody Sun Sep 20 07:49:49 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B993A09BC for ; Sun, 20 Sep 2020 07:49:47 -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, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3yJbBx7PH7l for ; Sun, 20 Sep 2020 07:49:44 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EE03A09B7 for ; Sun, 20 Sep 2020 07:49:44 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kK0d9-000C9H-1H; Sun, 20 Sep 2020 10:47:55 -0400 Date: Sun, 20 Sep 2020 10:47:34 -0400 From: John C Klensin To: Adam Roach cc: Michael StJohns , rfced-future@iab.org Message-ID: In-Reply-To: <9cef985c-5f91-fe73-c440-0c6a296e5e71@nostrum.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <49F36E3E1027E1F46F31BF17@PSB> <9cef985c-5f91-fe73-c440-0c6a296e5e71@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 14:49:47 -0000 --On Friday, 18 September, 2020 16:43 -0500 Adam Roach wrote: > On 9/18/2020 4:19 PM, John C Klensin wrote: >> And it would be unwise to rely on community >> consensus for the RFC Editor Function because the IETF >> community doesn't have the expertise, because a self-selected >> WG is unlikely to accurately represent the preferences of the >> IETF community, and because the community for the RFC Series >> is larger than the IETF. > > > The "lack of expertise" you cite is precisely why this > wouldn't work without a expert consultant. Or at least an expert something or other. But an expert would be useful only if a WG decided to pay attention to someone who would almost certain be perceived as an outsider (at least initially). Not only does the IETF have a poor track record in that area [1], but I interpret several comments on this list, including some of yours and Martin's, as preferring the wisdom of the [IETF] crowd to expert input even when said crowd lacks relevant expertise. I don't think that is what you actually intend (but maybe I'm wrong -- that is much of what I was trying to clarify with Martin) but it certainly feels that way from here [2]. > In terms of the other issues -- the IETF has always operated > such that those who bother to show up to do the work are the > ones who get a voice, and we seem to think that's okay. Some of us have often been nervous about it. The community seems to be nervous about it when "show up" really means "hang in after all those who disagree with the relevant leadership or strong personalities have been driven off" [3]. So "ok" needs to be somewhat qualified. > You > have indicated a belief in a bright line between technical and > non-technical matters in this regard; First, while others have claimed that there was a bright line, I don't think I have. Indeed, I think some of the publications-related issues I'm concerned about actually are technical. The distinction I'm trying to draw is between topics that are clearly within the IETF's _Internet_ technical scope and, perhaps as a definition of that, about which there is fairly wide knowledge and understanding among IETF participants including sufficient knowledge to understand when someone, despite strong opinions, doesn't know what they are talking about and topics that do not meet those criteria. > but note, e.g., that > IASA2 was run as a working group with this exact set of > caveats. (If I missed your congruent objections in the > formation of that effort, I apologize for the oversight.) If you look back far enough, you will notice that I objected, fairly loudly, to several of the provisions of the IETF Administration LLC arrangements. I was told that I couldn't object to most of those, including what should have been small but important terminology ones, because they were already fixed by a legal document that could not be altered by IETF decisions. When I raised objections to the way that document's approval had been managed and the lack of an IETF consensus call before it was set in stone, I was told it was too late (and some other things). At that point, it seemed to me there were two choices. (i) Generate an appeal which would certainly be rejected on the grounds that it was a done deal and/or that it fell within the purview of LLC contracts and hence could not be appealed and then, if I felt really obnoxious and destructive, hire an attorney and try to figure out a way to challenge the LLC registration. Or (b) I could try to be constructive and participate in the WG to see if things could be defined as well as possible, even editing documents when that became appropriate. I'd hope IETF participants who find their preferred positions blocked or in the rough in a fair consensus call would behave in a similar fashion. If you disagree and think that my being consistent would require the first choice, I guess we just need to disagree. john [1[ We've even managed to perceive people who laid the foundations for the Internet as outsiders and declined to carefully consider their suggestions. [2] And that may lead back to another one or two of those fundamental disagreements about the importance of stability and comprehensiveness (or obvious relationships) in specifications. But, unless you have changed you mind, I know we disagree about that. [3] General issues of ethics and humane behavior aside, the community's deciding that driving people away because of reasonably argued dissenting opinions or demographics is, at least IMO, the reason why our development of anti-harrassment and related policies is important. From nobody Sun Sep 20 08:21: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 80FCC3A0A4A; Sun, 20 Sep 2020 08:21:13 -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, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSWYaP2OgHc5; Sun, 20 Sep 2020 08:21:12 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EE43A0A49; Sun, 20 Sep 2020 08:21:11 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kK17N-000CCc-Ka; Sun, 20 Sep 2020 11:19:09 -0400 Date: Sun, 20 Sep 2020 11:18:49 -0400 From: John C Klensin To: Eliot Lear cc: Eliot Lear , adrian@olddog.co.uk, rfced-future@iab.org Message-ID: <07953D896A29C0FE26033A10@JcK-HP5> In-Reply-To: <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 15:21:14 -0000 Eliot, Very helpful, thanks. One comment on your distinction about Option A below. --On Sunday, 20 September, 2020 16:14 +0200 Eliot Lear wrote: > Hi John, > >> On 20 Sep 2020, at 15:15, John C Klensin >> wrote: >> >> Eliot, >> >> I don't think so, any more than I think it is really a >> variation on Option A. First, I think what I suggested --and >> what I think Brian's efforts to create Venn diagrams and the >> like suggest -- is that "issue by issue" may be impossible >> (or a way to foreclose some key topics) because of the ways >> in which issues are interrelated. > > I understand your concern. Let's agree among ourselves that > we will avoid such foreclosures in particular, and that we > will work to understand such linkages. If issues have to be > taken together, let's understand why. > > >> Second, it is Option B only if Option B is >> combined with a new I-D used as a base document that starts >> with what we agree on now (if anything) and that is updated as >> consensus evolves (as Adrian suggested a couple of hours ago >> but was, I thought, clearly intended by my note and others) >> and documents the rationale for each decision (as Carsten >> suggested even more recently). > > I think that's where we are heading, but we will see what > others think. If people do not object to that idea, we as a > group can act on it. > >> >> That idea has been largely consistent since the call. >> Although I suggested it on the call, it does not originate >> with me but was a small consolidation of things said earlier >> and several (IMO rather small and converging) variations have >> been suggested since. The very fact that you earlier >> suggested it was really a variation on Option A > Not quite. Option A provides us a draft upon which to build. > B states rather categorically that we don't yet have a > starting point and need to develop one. The chairs can > facilitate either approach. We personally like A because it > advances the group's efforts, but we won't/can't force our > views on the group. Ok. Option A, as I understood it from the call, was to pick one of the remaining/existing three documents or to somehow consolidate, I believe< Martin's and Brian's and then pick from it and Mike's and proceed from there. I see enough differences (in assumptions and fundamental preferences, not just details or text) among the three that I'm uncomfortable starting with any of them or, more generally, any document that treats any issues that are still controversial or dependent on unresolved others as settled. And that is why I've repeatedly suggested that you find an editor, preferably a fairly neutral one, to create a new I-D. Its initial version would record the issues on which we have agreement --issues we can also agree are either independent of others or where the whole cluster has been resolved. It could either stop there or catalog (without taking or implying any conclusions) known controversial principles and/or specific outstanding issues. Then, as we sort things out, it would then be revised to include additional decisions and the reasons for them. Certainly that is, as you suggested, a variation on A. Or maybe it is a derivation from A. Certainly it uses a document as a starting point rather than trying to sort out issues one at a time without a document. It can also reasonably be interpreted as a variation on, or derivation from, B because it assumes that we don't have a starting point today and proposes a new draft, free of the baggage and implied conclusions of the existing ones, as a first step in developing a starting point. But, unless you want to redefine A and then restate the question (or similarly redefine B), it is not A (or B)... I am indifferent as to whether we call it A' (or B') or D (in deference to Mike's C). In a way it is an A-B hybrid, so perhaps it is Option AB or BA. thanks, john p.s. Having proposed it, I should perhaps volunteer to edit/author the proposed new draft. I might be willing to try it if you can't find someone else. But my positions on these issues are quite strong (as I'm sure most of those reading this have figured out and why I suggested the IAB not put me in the position you are now in. That would make it hard for me to edit a document fairly and even harder for many people on this list to believe it had been done fairly, creating even more controversy. That is why I have not volunteered yet and why I think my doing that job would be a bad idea. From nobody Sun Sep 20 08:28: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 DBBCE3A0A62 for ; Sun, 20 Sep 2020 08:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_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 Z6JkZ4cPHJla for ; Sun, 20 Sep 2020 08:28:07 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DA03A0A2A for ; Sun, 20 Sep 2020 08:28:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BvWfv3Fd4z6GJyh; Sun, 20 Sep 2020 08:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1600615687; bh=ti8xur2paczCe4UQMwpgm/I40yEW9f+n1LeuKq+ncLQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=J6KRN5NiOXdYB2pL+fhtDZm/YV0C82fUWmAzGIFbGAzu7YzItrRk3htFcFYmJbG/A iK/RqwYjLCJthG2IMgnv3rUNEZvXsCXmzIQB+44A/7wAt0gmB1eWmdZzg5iY7EO8ZJ 8zeSC5jJUE/SN+iBIOqB/UtjH2UlnndqFUhPJlog= 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 4BvWft5Vg9z6GJFc; Sun, 20 Sep 2020 08:28:06 -0700 (PDT) To: Eliot Lear Cc: rfced-future@iab.org References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 20 Sep 2020 11:28:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 15:28:09 -0000 As far as I can tell, option A is at this point a pig in a poke. We commit (for some meaning of commit) to adopting a draft. Without knowing what the possible drafts are or how we will pick among the presumably several drafts? It would be pretty hard to object to a skeletal drafts. I can even see a good argument for the group owning the skeletal draft, so that the only things that get in are things on which there is rough consensus. What I do not see is how that corresponds to either of the options you put on the table. Just for completeness, I will state publicly what I said to you privately. As far as I can tell, option A as origianlly stated is not even a procedurally valid option. And I would object to efforts to force it. As defined, it would require adopting a draft, by means defined by the chairs, even if there is no rough consensus on a single draft. That is just wrong. Even in the softwires case that comes closest to this, the WG knew what the alternatives were, and knew what the decision procedure was. Yours, Joel On 9/20/2020 10:14 AM, Eliot Lear wrote: > Hi John, > >> On 20 Sep 2020, at 15:15, John C Klensin > > wrote: >> >> Eliot, >> >> I don't think so, any more than I think it is really a variation >> on Option A.  First, I think what I suggested --and what I think >> Brian's efforts to create Venn diagrams and the like suggest -- >> is that "issue by issue" may be impossible (or a way to >> foreclose some key topics) because of the ways in which issues >> are interrelated. > > I understand your concern.  Let’s agree among ourselves that we will > avoid such foreclosures in particular, and that we will work to > understand such linkages.  If issues have to be taken together, let’s > understand why. > > >>  Second, it is Option B only if Option B is >> combined with a new I-D used as a base document that starts with >> what we agree on now (if anything) and that is updated as >> consensus evolves (as Adrian suggested a couple of hours ago but >> was, I thought, clearly intended by my note and others) and >> documents the rationale for each decision (as Carsten suggested >> even more recently). > > I think that’s where we are heading, but we will see what others think. >  If people do not object to that idea, we as a group can act on it. > >> >> That idea has been largely consistent since the call.  Although >> I suggested it on the call, it does not originate with me but >> was a small consolidation of things said earlier and several >> (IMO rather small and converging) variations have been suggested >> since.  The very fact that you earlier suggested it was really a >> variation on Option A > > > Not quite.  Option A provides us a draft upon which to build.  B states > rather categorically that we don’t yet have a starting point and need to > develop one.  The chairs can facilitate either approach.  We personally > like A because it advances the group's efforts, but we won’t/can’t force > our views on the group. > > Eliot > From nobody Sun Sep 20 10:16:43 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 528183A0B5B for ; Sun, 20 Sep 2020 10:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.794 X-Spam-Level: X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNpf7KOD_a2W for ; Sun, 20 Sep 2020 10:16:41 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075943A0B59 for ; Sun, 20 Sep 2020 10:16:40 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08KHEkIH000657; Sun, 20 Sep 2020 18:16:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=oMvXy04fkzmLABjo3hL7xDxIMG9SO3O7Nvd6eQM/Z+0=; b=GK6ICI1SaZEVG0amvZFp4LQZE0Gv2HN1RDAy2MPoNtPYuS2S2u1hPdWxEEMHV/T/v24b MPUfpCvFsR9U01GE7aGXuXVfdmIV8ZbRIWr+6ckDSdNNRk67VoxdgmWLHHvv/l7wbP5p r9dgJu4h9bcDp6B0YPpAkg7mfH9Tuk64EDgXbuQZ0LLqbjaW/rakpk+2IfiBjtD7ADXM PGfsMbYcXVoFBgNQrUf1xKyp25YybWr6M3aOTt8CzCzR7fizy9iRWkddPNZKBfZkOnt8 nuRTycih4cfjRPSfPZ0XGDMw2+ATBXuiIONky+xwQTyJEpbJ/JzfLfCw8ox/uTDTQ64p Fw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 33p8r5r2p1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 20 Sep 2020 18:16:39 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 08KHGOn0018613; Sun, 20 Sep 2020 13:16:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 33ndaxjw49-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 20 Sep 2020 13:16:38 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 20 Sep 2020 13:16:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 20 Sep 2020 13:16:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Sun, 20 Sep 2020 13:16:37 -0400 From: "Salz, Rich" To: John C Klensin , Adam Roach CC: "rfced-future@iab.org" , Michael StJohns Thread-Topic: [Rfced-future] Trust versus accountability [Was: Where is the expertise? Thread-Index: AQHWjGUCVqaQrvoRj0i+9HQZ9VzjHalskYMAgACer4CAABqNgIAAoMuAgAAc5oCAAJHJAIAAOMOAgABaHgCAAAaWAIACsIcA///mkAA= Date: Sun, 20 Sep 2020 17:16:36 +0000 Message-ID: <70D9DB2C-0026-4B4D-A7D5-A1F19E5B1674@akamai.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <49F36E3E1027E1F46F31BF17@PSB> <9cef985c-5f91-fe73-c440-0c6a296e5e71@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: text/plain; charset="utf-8" Content-ID: <0B98F51FA401AE4F953262D7326E37DB@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-20_08:2020-09-16, 2020-09-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 malwarescore=0 bulkscore=0 mlxlogscore=789 phishscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009200151 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-20_08:2020-09-16, 2020-09-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 clxscore=1011 mlxscore=0 priorityscore=1501 spamscore=0 adultscore=0 impostorscore=0 bulkscore=0 mlxlogscore=733 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009200153 Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 17:16:42 -0000 SSdtIG5vdCBnb2luZyB0byBxdW90ZSBKb2huJ3MgbG9uZyBub3RlLCBidXQgSSByZWFkIGl0IGFs bCAoc29tZXRoaW5nIEkgZG9uJ3Qgbm9ybWFsbHkgZG87IEkgYmxhbWUgTVRWKSBhbmQgSSB0aGlu ayB0aGUgY29uY2VybnMgaGUgcmFpc2VzIGFyZSB2YWxpZC4NCg0KSSB0cmllZCB0byBzdGF0ZSB0 aGlzIG1vcmUgcGl0aGlseSB3aGVuIEkgc2FpZCB0aGF0IHNvbWUgYXJlIGNvbmNlcm5lZCB0aGF0 IHdlbGwtbWVhbmluZyBhbWF0ZXVycyB3aWxsIG1ha2UgcmVhbGx5IGJhZCBkZWNpc2lvbnMuDQoN ClR5cG9ncmFwaHkgYW5kIHRoZSBwcm9kdWN0aW9uIG9mIHByaW50ZWQgbWF0ZXJpYWwgaGFzIGV4 cGVydGlzZSBkZXRlcm1pbmVkIG92ZXIgdGhlIGNvdXJzZSBvZiBjZW50dXJpZXMsIGFuZCB3ZSBz aG91bGRuJ3QgcGxheSBhdCBpdCwgYW55IG1vcmUgdGhhbiB3ZSBzaG91bGQgcGxheSBhdCB3cml0 aW5nIGxhd3MuIA0KDQo= From nobody Sun Sep 20 12:28:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D633A0D75 for ; Sun, 20 Sep 2020 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAPFaYyqvq_Q for ; Sun, 20 Sep 2020 12:28:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114E73A0D74 for ; Sun, 20 Sep 2020 12:28:21 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08KJSJvP091110 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 20 Sep 2020 14:28:21 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600630101; bh=wUfKyqyJAJg+q114duOn6BT0wh2W/TFxAAdK8wvfHrY=; h=Subject:To:References:From:Date:In-Reply-To; b=hDkmhn7Ymprzjj8JDqd96qF7XBkqRCorK8JRMDqPXSOh7J4Am6LhJgCM7vtqlAtGR qd8VLZxTHVVwG9fYOIR247ECcepZV5xD3dvgG/RiGPwFg4dc3VMc67ISNDGgi1SYQU WU0kXziXF652kceC8xiQuoZtJ/St693z/y2fjgbw= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <100FCD5499178A7D13417D40@PSB> <3861ac91-5d5b-3f00-a95d-ba27d8207746@nostrum.com> <22961974432A8DE0994D3A6C@PSB> <8d8bb7a8-7a07-5520-31f2-9add660a95c0@nostrum.com> <49F36E3E1027E1F46F31BF17@PSB> <9cef985c-5f91-fe73-c440-0c6a296e5e71@nostrum.com> From: Adam Roach Message-ID: Date: Sun, 20 Sep 2020 14:28:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Trust versus accountability [Was: Where is the expertise? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 19:28:24 -0000 I think we understand each other fairly well, and continuing to hash through our philosophical differences here isn't likely to move the other one in any meaningful way. I hope our dialog has helped others work though their own thoughts on the subject, and I look forward to hearing input from voices other than the two of us and the four draft authors on this specific topic, as I suspect that our various positions are well-expressed at this point. One minor comment below, since your comment indicates to me that one of us did misunderstand the other about the distinction between community participation in technical and non-technical matters. On 9/20/2020 9:47 AM, John C Klensin wrote: > First, while others have claimed that there was a bright line, I > don't think I have. To be clear, I was referring to a message just barely upthread where you say: > When Dave Clark make that comment, he was very clearly referring > to our decisions about technical protocol work about the > Internet. /a From nobody Sun Sep 20 15:54: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 C0C953A0400 for ; Sun, 20 Sep 2020 15:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=rwX3RDbY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hZycIha/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KUEvhRPIZnx for ; Sun, 20 Sep 2020 15:54:45 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562193A02BB for ; Sun, 20 Sep 2020 15:54:45 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id F0864638; Sun, 20 Sep 2020 18:54:43 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Sun, 20 Sep 2020 18:54:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=yopTHsNHFscAx/01vtpE+IcSGQ27 L3DH+/BE8Ii09Qk=; b=rwX3RDbYNPnei1WHOHyrCZ5IQPLhiTGaHcFy7vOql5j+ kBXrtDoZn2t8wNoXJVoO6iRd13/JfejNL6bYaEcHdXyHr1FxoPyRp/LjCw90Ukd5 cr+MHpYUm9uvecOZ4v5AJ9LL90lEOSLHKc3Te0kHNE+Ecq7zBLcS+1N1CvXH50HT g/r0F7Bd8dK6AQWUQqpTM9JHn4s5vY6OaSu0uhonpP5yk2Nwm0t79MLrm3a7+hnz 0HvwcuQldUa6KWRXhFiuJk34kcCfUfDVWzxyc7OGJr1Q+Wu4Ig5/boRrSEX//erg tMbvd2jNIWzPmCMuYxjv2MP4ej43TmTJF2pvkjnQyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=yopTHs NHFscAx/01vtpE+IcSGQ27L3DH+/BE8Ii09Qk=; b=hZycIha/FlmQcHHJ2myfNK Vkyn+AXUGN3MaKHObyixk5b7+C5d3stb+fSgeb6ZmxKV4n9WrbQ2f8HtMcGlqCKF fzrFUsFY9xM30pgkmJWR8f8ASJGKCm2/JNwJFNUD/t/YPPCm6m/IQJsKC2zlWAX0 IakfLaEOZZrrTBO9hIdXH2peVvFqQF2wIBT6kZbfi7+Rs2N2zsY5donVfc5P4KKK oqpOUN8Oeag9aun+9eAwL2TTJvgeq2op7KqD833pjvjafIdMSTcv5knHdjtKAwir wN4bEP7+JA3LrFN9wZz6kbOoVZ2WBnjWkOdAfbOxfZGDDCeAOEPW1wV+HeVfZ7RQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddugddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeejvddttdejhfffleeugffgheetieetueduffevteehkeeggedufedt uedvheefudenucffohhmrghinhepfihhrghtfihgrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidr nhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2DCC120063; Sun, 20 Sep 2020 18:54:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-325-g8593b62-fm-20200916.004-g0f995879-bis Mime-Version: 1.0 Message-Id: <50880e04-00d1-4017-b633-e9c0d2c0cc96@www.fastmail.com> In-Reply-To: <1144E853-B51A-4FAB-B90C-471CDCD7E677@cisco.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> <1144E853-B51A-4FAB-B90C-471CDCD7E677@cisco.com> Date: Mon, 21 Sep 2020 08:54:23 +1000 From: "Martin Thomson" To: "Eliot Lear" Cc: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] What is strategic? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 22:54:47 -0000 On Fri, Sep 18, 2020, at 19:46, Eliot Lear wrote: > > [*] My expectation is that we will need processes to ensure that a pattern of tactical decisions don't turn into decisions about strategic direction. That process is not something I've developed more, because it's a relatively unimportant detail, but I have some ideas. > > I would encourage that discussion now, so that everyone understands > what you and the others are proposing, and agrees on what is and is not > strategic. To give a concrete example, in a recent AUTH48, the editor and I were faced with a decision between two reference forms: > ... (see the "Origins" section > (https://html.spec.whatwg.org/#origin) of [HTML5]) > > [HTML5] WHATWG, "HTML", Living Standard, May 2020, > . ... and > ... (see the "Origins" section of [HTML5]). > > [HTML5] WHATWG, "HTML", Section 5.3, Living Standard, May 2020, > . This is obviously important, but minor. We asked John for help in deciding in line with his role. There are specifics of the case that we could go into, but I think there are abstract aspects of this that are relevant to what this group is debating. Any answer is better than no answer, at least in the short term. There are lots of cases like this in documents and it is easy to let little decisions get in the way. What I would suggest is that these issues are logged in a public tracker. Then a decision is made by the RPC so that the current document can proceed. That decision can be logged also. Then we have the usual issue management stuff: issues or patterns of issues that indicate a need for new systems or policies require action. My guess is that most of this stuff will be logged and closed with a note. In that way the log becomes a resource to help with other similar issues. Some will result in tweaks to tools or procedures that are internal to the RPC. Some might result in changes to the style guide. Most of that can be managed internally. Of interest here though, some issues might indicate a need for strategic input. The information in this log could be one input to a strategy process. From nobody Sun Sep 20 16:00: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 C308E3A0EC8 for ; Sun, 20 Sep 2020 16:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 BwQMA8twjdvM for ; Sun, 20 Sep 2020 16:00:30 -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 58FE23A0BF5 for ; Sun, 20 Sep 2020 16:00:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E9192BE64; Mon, 21 Sep 2020 00:00:27 +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 ZHXTBJQcCFmq; Mon, 21 Sep 2020 00:00:26 +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 D1039BE5D; Mon, 21 Sep 2020 00:00:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1600642826; bh=t+cW4kUEfpWhWCkiaRjfr4ByrVO9sAqT4DR9AX9tROI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kv6MDW6wJXLRyh4rsbd+X5C3zyrUNduDVl41gSsKeQs3Iuf7tU6KeljSDuJtMxXvt i+QVbim2dhAtj6W99Anz4YGxghGxXNtXXm9qVirkGRn4X/GCGZyR7sspgHotcg1PxN 4G7tPEBjwTu6oIr+uV4P1+K0y2oBn3un1dDOpruw= To: Martin Thomson , Eliot Lear Cc: rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> <1144E853-B51A-4FAB-B90C-471CDCD7E677@cisco.com> <50880e04-00d1-4017-b633-e9c0d2c0cc96@www.fastmail.com> 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: Date: Mon, 21 Sep 2020 00:00:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <50880e04-00d1-4017-b633-e9c0d2c0cc96@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FRO8yFlXqUDvRtgxrHrFXOyldDqn9pz9a" Archived-At: Subject: Re: [Rfced-future] What is strategic? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 23:00:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FRO8yFlXqUDvRtgxrHrFXOyldDqn9pz9a Content-Type: multipart/mixed; boundary="pgoPYBdoXDLCJFEIJ4giP2k4Cf8acXNkE"; protected-headers="v1" From: Stephen Farrell To: Martin Thomson , Eliot Lear Cc: rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] What is strategic? References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> <1144E853-B51A-4FAB-B90C-471CDCD7E677@cisco.com> <50880e04-00d1-4017-b633-e9c0d2c0cc96@www.fastmail.com> In-Reply-To: <50880e04-00d1-4017-b633-e9c0d2c0cc96@www.fastmail.com> --pgoPYBdoXDLCJFEIJ4giP2k4Cf8acXNkE Content-Type: multipart/mixed; boundary="------------E7D5A8295212CEBDCDD2E600" Content-Language: en-US This is a multi-part message in MIME format. --------------E7D5A8295212CEBDCDD2E600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 20/09/2020 23:54, Martin Thomson wrote: > Any answer is better than no answer, at least in the short term. I'm not sure I agree. References go stale, so ISTM only answers likely to be stable for the duration for which the to-be-RFC is expected to be useful could rise to the level of "better." There's an awful lot of judgement needed there I think and an issue-tracker approach could well lead to way to much emphasis on the short-term is my guess. S. --------------E7D5A8295212CEBDCDD2E600 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----- --------------E7D5A8295212CEBDCDD2E600-- --pgoPYBdoXDLCJFEIJ4giP2k4Cf8acXNkE-- --FRO8yFlXqUDvRtgxrHrFXOyldDqn9pz9a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl9n3wkACgkQWrL68XsX K+phMRAAtv5JlU6qs1VAmhWU5NoJWYzr+H9eKw49SmfCwyVI70urKyWZ9HcX3ukk Fh4iLajFW/WIOptWQ3MKlDEL13cCz4ky5Ept4eYKE/LvZ2npYYHg25x84ioIQOVj gB+eDH9QzIf3R67g6OjG+DFQqAv2Jn9U99JivE9wDv/RZ78329EbXvpuynasIdEi TBOwIWMxSp+6DAkC18awHrSGxoJZ7v4G8lZ//uPzUTcAY8YojYEz50X3AfPX0I5u BHctp9VKtqNIQ4/i8I63yAVittiFk/7UrUVJDe8a7mCcppD4E81lvfTbGowq0heg dtOXvaUFiMmyKrqn5OyEZD7A9QqTWtSdPBpdtdSvNeQ2oYNmRzf+uPTcafg3SG/M /5rCKFlQhNNIB/rTgLb9l+RmDSrgUy7ZFalomVTkjoOEElhJOxWMrBpOO21gndIh X7XXTjueRSAfGCX5v8o1Fd0wkEIVlyNkEMKv6ySpUKzZ3+u102mriHpZyP8NVVXm qowGqdc/3o+G3mvH5QU3lPk2GP0xfj5bBQIXVOkHbh9L2/bdPzTWlSVMLjhLrZi6 PvtGGfcGBJvCBuTcd8/XgQj4J+Eaa4raQeBVVMmDwiuVEDy+aDw/9GVVFCDYpNNU x9HVQu9ZzGR7FMP9EfKhVcGYbjir/VgycPAcL/wL2bHfcwLJIUc= =Aa4I -----END PGP SIGNATURE----- --FRO8yFlXqUDvRtgxrHrFXOyldDqn9pz9a-- From nobody Sun Sep 20 16:29: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 705D53A0FDE for ; Sun, 20 Sep 2020 16:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=lRMbKG3k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IYllBXp+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmvCYExopwqd for ; Sun, 20 Sep 2020 16:29:15 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579BD3A0FEC for ; Sun, 20 Sep 2020 16:29:15 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B5F8E8F5 for ; Sun, 20 Sep 2020 19:29:13 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Sun, 20 Sep 2020 19:29:13 -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=fm3; bh=Trh/44R1KpbdpbrI6F7fy2ubShzTeQ6 /X6cy8OitjNI=; b=lRMbKG3kldYlY7BPsgmfewW6+L9LNY03o7axkct5quYHKp3 WoZaIyI7pHSsZCuP8ogN2egsC/f1t+7dRK8McuI94zFu33LbmJNhH8jsDWUbSVJh yrD+lCXk8kiJ7j/qGvZ3uinDV7Jr8lVdWUmsKpDGNAGIJoBdl5qQwsm0saN1n5Rm cbcsUamQSN/j5GA9X8He3VpJ8mg7680cVHq4Mw073beMYpzhQpI+EVme3To0ggQi pTuSkcvwN4EEBmn8zIaBdGr3AwiZN2Jvmn6WSyBXn6SjrT2D5JKnZGY2ExaYcBxU WkHTg1r4qH4zKLqqC0yyepv5iCtDBHLNfzLWEuw== 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=Trh/44 R1KpbdpbrI6F7fy2ubShzTeQ6/X6cy8OitjNI=; b=IYllBXp+x7H+GUqNW6u4FU UinrtLsPOFN+LonRQ8RouZT19H1DnCadsc7ukPyH7wuJafjPW8iUo/NmLKglsgSy QW4DbelFD03gVupPnt+Eo4+isUe0NfpmDdbjbR8eLtbgn05JiGffF0bPYompXUEL hMaML+ET/eCrkvp7YqCH52JLPPE6WSkC/YSIWcXdMepBA2Z+TGrCv5pzj6hooO3U Tq1aZ5Pn+6/u4HHuZWhSVnR5NGXTYXBmYB8DueBCpl1l0egqif37wodZFK7QfZgY 4ZlUNXswydZxFuJyYRNdYJjvHHiVCSHcHNFuURgVKQ3kKI4L2tzqTpoKOuPL8a0A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddugddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id ED3C320063; Sun, 20 Sep 2020 19:29:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-325-g8593b62-fm-20200916.004-g0f995879-bis Mime-Version: 1.0 Message-Id: In-Reply-To: References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> <1144E853-B51A-4FAB-B90C-471CDCD7E677@cisco.com> <50880e04-00d1-4017-b633-e9c0d2c0cc96@www.fastmail.com> Date: Mon, 21 Sep 2020 09:28:52 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] What is strategic? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Sep 2020 23:29:16 -0000 On Mon, Sep 21, 2020, at 09:00, Stephen Farrell wrote: > On 20/09/2020 23:54, Martin Thomson wrote: > > Any answer is better than no answer, at least in the short term. > > I'm not sure I agree. References go stale, so ISTM only > answers likely to be stable for the duration for which > the to-be-RFC is expected to be useful could rise to the > level of "better." There's an awful lot of judgement > needed there I think and an issue-tracker approach could > well lead to way to much emphasis on the short-term is > my guess. So you have correctly identified the principle that allowed us to decide what the right answer was in this particular case. But that too wasn't the problem: the editor knew that this was the principle, but wasn't sure in this specific case which of the two options best fit that principle. So I disagree that this is about judgment. This is about learning what the principles are (long term reference stability in this case) and applying them. What I think an issue tracker is good at is: placing these cases in a record that can be examined. People can always turn that into a piecemeal approach with a short-term focus. That's not my experience with the people in this community though. From nobody Sun Sep 20 17:06: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 7AFDB3A0FF5 for ; Sun, 20 Sep 2020 17:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_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 Y2drciXL3bgg for ; Sun, 20 Sep 2020 17:06:47 -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 11AD43A0F49 for ; Sun, 20 Sep 2020 17:06:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Bvl9L71K4z6GK4n; Sun, 20 Sep 2020 17:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1600646806; bh=+AhroAQumQXH72Lu4EQALUZfgGyGYFg13hpmHcpK84c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WrNDOBzHOoRQNjtbuUeZW+xFVBAySThK3FcgYI2y67Y8N395fSutgqAR8GlPHeKNv k0SRGXbcYniqDE6CtcCEEHDk4TNKEhI3GVUF0S78rXxKiKhVigAXtEI82KkiYfxhDH P97/JUFqYs7u3So4C4d5IltjLTnQHA5R7F1YTN+4= 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 4Bvl9L3HXxz6G7sH; Sun, 20 Sep 2020 17:06:46 -0700 (PDT) To: Martin Thomson , rfced-future@iab.org References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> <1144E853-B51A-4FAB-B90C-471CDCD7E677@cisco.com> <50880e04-00d1-4017-b633-e9c0d2c0cc96@www.fastmail.com> From: "Joel M. Halpern" Message-ID: <0f684638-e976-0492-e006-b8918e702d78@joelhalpern.com> Date: Sun, 20 Sep 2020 20:06:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.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] What is strategic? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 00:06:48 -0000 Hmmm. From where I sit, an issue tracker is a lousy way to place things in a record for examination. Issue trackers are great for issues that need to be tracked and resolved. Yours, Joel On 9/20/2020 7:28 PM, Martin Thomson wrote: > On Mon, Sep 21, 2020, at 09:00, Stephen Farrell wrote: >> On 20/09/2020 23:54, Martin Thomson wrote: >>> Any answer is better than no answer, at least in the short term. >> >> I'm not sure I agree. References go stale, so ISTM only >> answers likely to be stable for the duration for which >> the to-be-RFC is expected to be useful could rise to the >> level of "better." There's an awful lot of judgement >> needed there I think and an issue-tracker approach could >> well lead to way to much emphasis on the short-term is >> my guess. > > So you have correctly identified the principle that allowed us to decide what the right answer was in this particular case. But that too wasn't the problem: the editor knew that this was the principle, but wasn't sure in this specific case which of the two options best fit that principle. > > So I disagree that this is about judgment. This is about learning what the principles are (long term reference stability in this case) and applying them. What I think an issue tracker is good at is: placing these cases in a record that can be examined. > > People can always turn that into a piecemeal approach with a short-term focus. That's not my experience with the people in this community though. > From nobody Sun Sep 20 18:03: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 BFC873A10DA for ; Sun, 20 Sep 2020 18:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=NaRH+Etf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XDMmn8q9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21u7WRvmh7Ai for ; Sun, 20 Sep 2020 18:03:28 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C053A10A2 for ; Sun, 20 Sep 2020 18:03:28 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 3D7C892C for ; Sun, 20 Sep 2020 21:03:27 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Sun, 20 Sep 2020 21:03:27 -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=fm3; bh=84pjux/hdcoNJnivYbfOWEhvOQr8O3W Y9rOltbr9U28=; b=NaRH+EtfOPFT/hWiJviWnlSDLSr3LYpy1BzSK1nUvfP7X9s Q35OwUmhOozT/irjNHk8hqATuGVVo8s9TiklFyBS77rnaflq0NGQCZ5YlnL/Y8nF r+x1BnDtv7tZcd9UMz/q7Pre138D1vuIdglmyeBnx/oXuXHrJzWtaNHHg7rrulKM r+EtrL6fpQp9SzsTUGkkgrpvGNqeorMr/sIPD2aI6wDz5KLHRnGYh1w8C1kPDwcl jlgRJ9PRC32jhjWGQG5MjCOceVB2zmLTnqQD/AvmQgr2zpiemQZpzkeUavv6CRh0 C6mQ/2bywx0tvo13hi80p4FEfnbd42/7rvzoHDQ== 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=84pjux /hdcoNJnivYbfOWEhvOQr8O3WY9rOltbr9U28=; b=XDMmn8q9ib6RrpitTETbZn mEXeg1alUWvequAtHVtrPlfYQwOwCxe9vKhPLhbro8iTDKdPPRwiLEk+kUK9tX85 weYfF3nWyVJUlkVDvb3NtD2ODn4HKLl9/61D1BQNnfhwn32312fC4o6QdyHlgnnZ L4jUiIGP9bGZeSPN+TRlbzJFnUqlYUVFkL8Do62gbbWa9CZFh8DMDqKW7TYf6qiV lESIhPuuYD42IDD7k8sdjpD4AvKg+EYefttiucGezn0kjkFrI4cO4MxDodRrWolH XJS1PqhOrwfW9K5OdOggwdLPHcMwDW1ysFoV8bBxoeXR1LOaiJkegcefPr8XsqZA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddugdegtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9455F20063; Sun, 20 Sep 2020 21:03:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-325-g8593b62-fm-20200916.004-g0f995879-bis Mime-Version: 1.0 Message-Id: <7ff5432b-ab86-46b8-9ca3-7420df6edc8f@www.fastmail.com> In-Reply-To: <0f684638-e976-0492-e006-b8918e702d78@joelhalpern.com> References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> <1144E853-B51A-4FAB-B90C-471CDCD7E677@cisco.com> <50880e04-00d1-4017-b633-e9c0d2c0cc96@www.fastmail.com> <0f684638-e976-0492-e006-b8918e702d78@joelhalpern.com> Date: Mon, 21 Sep 2020 11:03:06 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] What is strategic? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 01:03:32 -0000 On Mon, Sep 21, 2020, at 10:06, Joel M. Halpern wrote: > Hmmm. From where I sit, an issue tracker is a lousy way to place things > in a record for examination. Issue trackers are great for issues that > need to be tracked and resolved. As I said, I think that this is a minor point, but I've used several issue trackers that have become an important resource for making strategic decisions. For instance, Mozilla tracks regressions and looks for areas that need additional focus on proactive treatment. But you seem to be inferring from this that this is the only mechanism by which strategy would be informed. As I said before Eliot asked me to expand on this point, I think that this is a minor point. I would expect there to be other inputs to strategic decision-making that are more heavily relied upon. From nobody Sun Sep 20 18: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 27B933A10B9 for ; Sun, 20 Sep 2020 18:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=BPQnS4Qp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GJVjUmtp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmLzqlu16a4r for ; Sun, 20 Sep 2020 18:07:24 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2853A10A3 for ; Sun, 20 Sep 2020 18:07:24 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 3E1E03A0 for ; Sun, 20 Sep 2020 21:07:22 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Sun, 20 Sep 2020 21:07: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:content-transfer-encoding; s=fm3; bh=Hzirl 8Qsard9i6CZZtn7YxiUoOKZ0+TvLRxBZGse4yg=; b=BPQnS4QpDDqjN8NtcGJIz HEn5Bt0ZHCuYyKHQihVszO3qObMOi8Iy4HoWXdNk4DtOySDRJoHppjzdkaP3Ycfd lE24aaNUL8h8MbT+mI2s7JUS/KG2PvGSQWY/nzn7ftTUkSVongqkJiaOsrjBt/fZ 1hqjtfmVj9JawvQo8vRrFO9oyhzMiwxuJCbGvx8CUxXjpw4LQnbpkCmtW3NqmaxQ y55HaxrcHLHLEJZh2CPPDq7fnR/g8H+LzWll78sJ7U1KxmBnwmdjfyM6h7DVDPAu SiZs3ow9LTUYSvmYH98EdyoF0FSsrPaAY8ZZIv7+w3tojd+KYchjyFfZDyqJ91lz A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Hzirl8Qsard9i6CZZtn7YxiUoOKZ0+TvLRxBZGse4 yg=; b=GJVjUmtpM+mKbNgsgtZnUjBsVHz0wG5XQuYjwlfMunZENsSE2j9VrYnl+ 8ogCkgpfgo//qHvnAmRhrHVBv2NUyDLEzkfZPKyxAzwcCuuiAQtB1OjdA61Pn2iF vU3TY99qOwVphz4dhYIYAYanqJ+HTO+KDIoGmnBWZ/s4Y7Q/By4Kbft/hhTOcqI1 RshXJsCmOYT2xLnqm9drizTs2bye8K76HMnA0NU7fbg8JnsJWR09Qdq46/fXzL45 W9K8vjPEdazYsPfd12y3EeLKuMYPzzRc5tGtS+mExaD5Zyrf7iHveQ0mvoWAL8aL tMw7qJNdD4g2HfbqZDLuTdMgNCvtQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddugdegudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgjeeuudeiffeltdegle ehjedvtedtjeduudehgfegfefgkefgueeiteegffdttdenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8194F20063; Sun, 20 Sep 2020 21:07:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-325-g8593b62-fm-20200916.004-g0f995879-bis Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 21 Sep 2020 11:07:02 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Question for discussion - Editorial Stream X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 01:07:25 -0000 On Sat, Sep 19, 2020, at 05:22, Michael StJohns wrote: > Question:=C2=A0 Do we create a separate Editorial Stream? I don't think that the answer to this question matters, except perhaps a= s a consequence of other, more important decisions. If the new structur= e does not involve the IAB in an oversight position (or any other body w= ith access to a stream for publication), and we see a need for entities = there to publish RFCs, then we might reasonably conclude that a new stre= am is a good way to solve that problem. I would rather not focus on second-order questions when there are more f= undamental disagreements to resolve. From nobody Sun Sep 20 19:41:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DAE3A0C8B for ; Sun, 20 Sep 2020 19:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgQXGYOeeXu8 for ; Sun, 20 Sep 2020 19:41:22 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 B73673A11DF for ; Sun, 20 Sep 2020 19:41:22 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id s14so6246345pju.1 for ; Sun, 20 Sep 2020 19:41:22 -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=zT0UAz+hpAG6Hsmmgl1iYImCEZjC/qc/3/sXxK44pyc=; b=LMRNGkefdnFRxARB3PAVqSmZDgkOLijbQlR/rvZ3UUDjnhF9qV1z+O6OfnvqJEpCsb h/ipt71K7HmxySPb4eZT9j1rvoyvawZfR+Mh1GmRvMP/sJVMP0113hvsb5Ba0K9zd/+W ZQSQGSPFN7yV4K4Gq9qDYbd8oVMOQcqTbTk6BskVGI6/RPY5n3zF+gW+Em70X/wZfXMO 4e63Ts3d80rCraVULm4I6btnDi3HRCay2AqqVSNGTdra53xHL5cOFj3gC5u3yX6CW7j2 SingOQI9bhWWZctyB5PbwatyEsCt9ON07z3tkN1RxvuZD8os6xNU39crYFC3CfyjylHC fUpg== 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=zT0UAz+hpAG6Hsmmgl1iYImCEZjC/qc/3/sXxK44pyc=; b=eLp6mN4UN2gbp5aICevEJi0TnZ5v4qBxXQn19M9Hi1i/CL0EBTwy0DECSbH7hXFeJY knwOBnwCXgwUynoSyRx+fyzyvWZ2vVVQQMzRjtGCNfKFRcZ9DCMkxdmzBXmCzyG3n0Mq Ju4lGTVL33PBgRyJLAIjsiEd9GqMGqchDasQVr49loJ9Ugc6/5zB7+CIY2rqJb0A8WvD Bj8AzaFwSx/efzBralzBb+e7ZIiKVvgwWmyXfmlaT28xEc45RK9TPjjbduMMgzRRhdtf 9Zn7/Os+sfdm5Hal3EW0BwaxicG2DaAON5fi9xAqaKJ47OYq6KVDD8dFcFt2UI/IUP/q V07Q== X-Gm-Message-State: AOAM533YQvgrViAwnL2k4mVg3WMTmJc3kE85/8ycqNyCWmdI9whvJyqj H62gMt4ztFzbrvkT2hLKlBf/LTVw32k= X-Google-Smtp-Source: ABdhPJw31hH+0If+P2GKT9c2szUo8WfAnNr2fVA3kNmT8hCI6GOLIQsoy8zLVd3/JbT6HviqjXDv2A== X-Received: by 2002:a17:90a:e016:: with SMTP id u22mr24117823pjy.178.1600656081750; Sun, 20 Sep 2020 19:41:21 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id u6sm8874493pjy.37.2020.09.20.19.41.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Sep 2020 19:41:20 -0700 (PDT) To: Martin Thomson , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: Date: Mon, 21 Sep 2020 14:41: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] Question for discussion - Editorial Stream X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 02:41:24 -0000 On 21-Sep-20 13:07, Martin Thomson wrote: > On Sat, Sep 19, 2020, at 05:22, Michael StJohns wrote: >> Question:=C2=A0 Do we create a separate Editorial Stream? >=20 > I don't think that the answer to this question matters, except perhaps = as a consequence of other, more important decisions. If the new structur= e does not involve the IAB in an oversight position (or any other body wi= th access to a stream for publication), and we see a need for entities th= ere to publish RFCs, then we might reasonably conclude that a new stream = is a good way to solve that problem. >=20 > I would rather not focus on second-order questions when there are more = fundamental disagreements to resolve. Well, this reinforces John Klensin's point about multiple moving parts th= at affect each other. Which in turn suggests to me that we do need a cura= ted list of the questions, with an agreed indication of each one's import= ance. I would agree that this one is not primary, but that doesn't mean i= t's not on the list. Brian From nobody Sun Sep 20 19:54: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 2FD053A11E5 for ; Sun, 20 Sep 2020 19:54:52 -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 NUB5P9GtnvYj for ; Sun, 20 Sep 2020 19:54:50 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753813A11E4 for ; Sun, 20 Sep 2020 19:54:50 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kKByb-000J5H-7T; Sun, 20 Sep 2020 22:54:49 -0400 Date: Sun, 20 Sep 2020 22:54:43 -0400 From: John C Klensin To: Martin Thomson , rfced-future@iab.org Message-ID: In-Reply-To: References: <00f401d68c0c$b6a3c290$23eb47b0$@olddog.co.uk> <68adbae8-4c4a-9fee-3ec3-4ef187982447@nostrum.com> <011101d68c12$fe03a500$fa0aef00$@olddog.co.uk> <7B257992-54B6-476B-896C-A98D2276F391@mnot.net> <7E708355-CCEA-4933-AF31-0EA7E9BBAC66@cisco.com> <7abdc555-d751-46c3-8c98-e66b493f532a@www.fastmail.com> <1144E853-B51A-4FAB-B90C-471CDCD7E677@cisco.com> <50880e04-00d1-4017-b633-e9c0d2c0cc96@www.fastmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] What is strategic? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 02:54:52 -0000 --On Monday, September 21, 2020 09:28 +1000 Martin Thomson wrote: > On Mon, Sep 21, 2020, at 09:00, Stephen Farrell wrote: >> On 20/09/2020 23:54, Martin Thomson wrote: >> > Any answer is better than no answer, at least in the short >> > term. >> >> I'm not sure I agree. References go stale, so ISTM only >> answers likely to be stable for the duration for which >> the to-be-RFC is expected to be useful could rise to the >> level of "better." There's an awful lot of judgement >> needed there I think and an issue-tracker approach could >> well lead to way to much emphasis on the short-term is >> my guess. > > So you have correctly identified the principle that allowed us > to decide what the right answer was in this particular case. > But that too wasn't the problem: the editor knew that this was > the principle, but wasn't sure in this specific case which of > the two options best fit that principle. > > So I disagree that this is about judgment. This is about > learning what the principles are (long term reference > stability in this case) and applying them. What I think an > issue tracker is good at is: placing these cases in a record > that can be examined. But I'm not sure what principle you are appealing to because, at least if the reference is normative, I can see two separate issues: (1) There is a very long-standing publications principle that references are references and should be kept integral. To the best of my knowledge, every style manual about formal publications in English, on both sides of the pond, is consistent about it. It has often been ignored in the RFC Series, but that doesn't make it less of a principle. So, although there are variations in layout, Doe, J., "Flowers Bloom in the Spring", Chapter 5 of Boggs, P., _Events of the Year_, 1984, pp. 666-700,... and Dijkstra, E.W., "Go To Statement Considered Harmful", _Communications of the ACM_, Vol. 11, No. 3, March 1968, pp. 147-148. and Flanagan, H. and Ginoza, S., "RFC Style Guide", RFC 7322, September 2014, Section 4.8.6.2, ... work while, traditionally, running text containing ... the discussion of flowers blooming in [Doe1984] Chapter 6... ... [Dijkstra1968] page 147... ... discussion of URIs in RFCs [RFC7322] Section 4.8.6.2... or even ... discussion of URIs in RFCs [RFC7322, Section 4.8.6.2]... is considered obnoxious or worse. (2) For citations to documents that contain definitions or other information that is necessary to understand the present document, there has been a rule in the RFC Series since at least the mid-1980s that both the reference and the target must be stable, i.e., that one must be able to use the reference to find the target _and_ the definitions (or whatever) in the target must not change -- preferably not at all, ever, but at least not in any way that might substantively change the meaning or interpretation of the specification in the RFC. For that purpose, the syntax of the reference (including what information is actually put in the reference and what information is placed inline in the text as above) makes no difference -- it is the principle that is important and, IMO, any change to that principle definitely has strategic implications. This second issue (obviously, I hope) goes to the questions of what "archival" and "stable specification" mean and is hence one that is intertwined with some others. Now, which of those issues were you and John discussing? thanks, john > People can always turn that into a piecemeal approach with a > short-term focus. That's not my experience with the people in > this community though. From nobody Sun Sep 20 20:57: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 9CBB93A1312 for ; Sun, 20 Sep 2020 20:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=kROR3s9C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ij8zDW4V Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkiAyg5s0UaN for ; Sun, 20 Sep 2020 20:57:41 -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 C19343A1311 for ; Sun, 20 Sep 2020 20:57:41 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BE0845C00F4; Sun, 20 Sep 2020 23:57:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 20 Sep 2020 23:57:40 -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 f7trM6ZVnmohiV8fip67aQEhYvzdHFPbenRvoJtpk0=; b=kROR3s9CWhY3aNwji U/sNpHnAAsx3XPXJXMbuZBjQZxiEII5rKx4SL/ZEvc1vtVnon3RMW1c2fM2y4wX2 MegYxhmwINx/ZLUXyQQqf8AUR99XyBi8PXo8M/WzkaOKSOCaHgQ7n2hHOfSs08fj K+b/+cG8hmSo39mcHydA7F66mh2NlYgY04BZgS5wepwhn4uj8MmQM0Xhx6oVuMOg 0Xz9PL+D8hOzNtNz/aimv4INDqAJ1JGHMDljuXea3IJjGglDnMQCv6+oQoWoPKfr t8Vn3wgJBIg4gaTFx5e1Nb44AJqCk1INpU0YKEYdPULLz/sZtawBsap/03YWSIZU nAirA== 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=pf7trM6ZVnmohiV8fip67aQEhYvzdHFPbenRvoJtp k0=; b=Ij8zDW4Vazq4zU3KhdX0dtkYWtDQT5lOKiixwzHdOip6Jwpp4Lfhq8hN1 WDSfSVE0Fgt/waorq20LWduKIU2yn9IeQqqOIwx7Y5PQkhhzDntiJPRm8EQNEY0N l+I74SxcuMdxZJZBPQZkGQWWwdrTvHVNiKY5CDsTy06fDpvUmIiyoFESaP+NDhA/ yiYWbyVECCmbdk2Y9kKXnNtC4h7DL7fWXAdkx6K1ia9fZQlaUM6U98YX+d3cQgLK 6GnDVW4Ub/O1zm0e4tErFEq7JswfYsFO0BzSMJsH/RcsqK5spJRrIRd50huTpFQD dT/G4sgoZ2BchO6jtnMt47B8nxd1Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddugdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepteeghfevjeefvdffjeeuieeuvdevvddvudejfedthffhvefhvdfhgfduieelffev necuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrud ejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id CC2C13064674; Sun, 20 Sep 2020 23:57:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Mark Nottingham In-Reply-To: Date: Mon, 21 Sep 2020 13:57:34 +1000 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 03:57:44 -0000 +1 to this (Joel's) general sentiment. Discussion has made it clear that = the distinction between A and B is not well-described. My sense is that = the best way forward is to document the agreed-upon aspects as well as = the open issues, and proceed (acknowledging that we still have some = difficult - and intertwined - discussions ahead of us). *How* we document those things isn't terribly important, but the obvious = tools we have are a draft for the former, and an issues list for the = latter. Cheers, > On 21 Sep 2020, at 1:28 am, Joel M. Halpern = wrote: >=20 > As far as I can tell, option A is at this point a pig in a poke. We = commit (for some meaning of commit) to adopting a draft. Without = knowing what the possible drafts are or how we will pick among the = presumably several drafts? >=20 > It would be pretty hard to object to a skeletal drafts. I can even = see a good argument for the group owning the skeletal draft, so that the = only things that get in are things on which there is rough consensus. >=20 > What I do not see is how that corresponds to either of the options you = put on the table. >=20 > Just for completeness, I will state publicly what I said to you = privately. As far as I can tell, option A as origianlly stated is not = even a procedurally valid option. And I would object to efforts to = force it. As defined, it would require adopting a draft, by means = defined by the chairs, even if there is no rough consensus on a single = draft. That is just wrong. Even in the softwires case that comes = closest to this, the WG knew what the alternatives were, and knew what = the decision procedure was. >=20 > Yours, > Joel >=20 > On 9/20/2020 10:14 AM, Eliot Lear wrote: >> Hi John, >>> On 20 Sep 2020, at 15:15, John C Klensin > wrote: >>>=20 >>> Eliot, >>>=20 >>> I don't think so, any more than I think it is really a variation >>> on Option A. First, I think what I suggested --and what I think >>> Brian's efforts to create Venn diagrams and the like suggest -- >>> is that "issue by issue" may be impossible (or a way to >>> foreclose some key topics) because of the ways in which issues >>> are interrelated. >> I understand your concern. Let=E2=80=99s agree among ourselves that = we will avoid such foreclosures in particular, and that we will work to = understand such linkages. If issues have to be taken together, let=E2=80=99= s understand why. >>> Second, it is Option B only if Option B is >>> combined with a new I-D used as a base document that starts with >>> what we agree on now (if anything) and that is updated as >>> consensus evolves (as Adrian suggested a couple of hours ago but >>> was, I thought, clearly intended by my note and others) and >>> documents the rationale for each decision (as Carsten suggested >>> even more recently). >> I think that=E2=80=99s where we are heading, but we will see what = others think. If people do not object to that idea, we as a group can = act on it. >>>=20 >>> That idea has been largely consistent since the call. Although >>> I suggested it on the call, it does not originate with me but >>> was a small consolidation of things said earlier and several >>> (IMO rather small and converging) variations have been suggested >>> since. The very fact that you earlier suggested it was really a >>> variation on Option A >> Not quite. Option A provides us a draft upon which to build. B = states rather categorically that we don=E2=80=99t yet have a starting = point and need to develop one. The chairs can facilitate either = approach. We personally like A because it advances the group's efforts, = but we won=E2=80=99t/can=E2=80=99t force our views on the group. >> Eliot >=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 Mon Sep 21 04:49: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 8FB5C3A0CDC for ; Mon, 21 Sep 2020 04:49:44 -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 YVvzoUBza7fI for ; Mon, 21 Sep 2020 04:49:43 -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 36E593A0CDB for ; Mon, 21 Sep 2020 04:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=467; q=dns/txt; s=iport; t=1600688983; x=1601898583; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=OMDMquKE4sSXv1p8E7qxDJ+uVICvVLfE91N37vdcDjA=; b=QmdmLuFpGz6MQXMc18Qlc7TnrN6BCnoclce4CddzEF1nC9WTwQYHuJwB o7EIxDaiY7nrRkbqE3oremCB+KEhxVo0SYX5FFUvgEbC951t6bdOb37m2 01os5YBTrObWKViBh53qpbFAmJQMsxuYRbvz/Z1tfJFYnB5lncCdoRJaG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAAAckmhf/xbLJq1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgT4EAQELAYNuASASjWiIOpwfCwEBAQ0BAS8EAQGESwKCLCU?= =?us-ascii?q?3Bg4CAwEBCwEBBQEBAQIBBgRthWiFcwEEATo/BQsLDjhXBoM5gl0gsy50gTS?= =?us-ascii?q?KT4E4AY1GggCBOByCTT6EPYNKgi0Ety6CcYMRlzsDHoJ6ARGJeYUPjm2vG4N?= =?us-ascii?q?cAgQGBQIVgWokgVczGggbFWUBgj89EhkNnGg/A2cCBgoBAQMJjl8BAQ?= X-IronPort-AV: E=Sophos;i="5.77,286,1596499200"; d="scan'208";a="29728897" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Sep 2020 11:49:39 +0000 Received: from [10.61.214.187] ([10.61.214.187]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 08LBnbwT021977 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 Sep 2020 11:49:38 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Eliot Lear In-Reply-To: Date: Mon, 21 Sep 2020 13:49:37 +0200 Cc: "Joel M. Halpern" , rfced-future@iab.org, Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.214.187, [10.61.214.187] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 11:49:45 -0000 Well. Apparently the chairs have found a way to gather consensus on at = least one point after all, just not in the way we had expected ;-)=20 > My sense is that the best way forward is to document the agreed-upon = aspects as well as the open issues, and proceed (acknowledging that we = still have some difficult - and intertwined - discussions ahead of us). Is there any objection to proceeding along the lines that Mark = suggested? Eliot From nobody Wed Sep 23 18:36: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 E551F3A164B for ; Wed, 23 Sep 2020 18:36: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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIaT_QjGCaAY for ; Wed, 23 Sep 2020 18:36:29 -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 4E20C3A0913 for ; Wed, 23 Sep 2020 18:35:55 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id u24so886467pgi.1 for ; Wed, 23 Sep 2020 18:35:55 -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=XRgtZY9+Sx0O+11UyACqMBh4HtwLpXQHtGh6Hrju+z8=; b=qA8qhQDqfM/LhtnVQ5rTzSDdslVXzp1CvrIVF0wd4GsUWIouQHKfVE5MUFQzkOk1rU tkRlw1/FF2v+cHEPMmVQNCA21i8kk7lZPfDrg9hz58/l73WGUXwdoYxTyQW4Ea9t0nWI ntg8y43opV6cvXOyVyaP+/6RKszH+9+/6j76Ud9Nenecq4f737VRIftptBXhPvgzz+9Q 8SOD3r0bs2IuIOybezNZV8N1RDZ3XjWYZYizLxleJxq8nk6G1fCjjWvsqZB97max8h0L BZbUEpIwjZBl0S2Yfp59YMuIth0/oANvJ5Zs5z/seR/gFg6ph2I5ylidtCjR26GT5jCX HTmQ== 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=XRgtZY9+Sx0O+11UyACqMBh4HtwLpXQHtGh6Hrju+z8=; b=hc5kEKbltvm4BcEwlMaMnQsprM1m6XDRiI/LMfzyMu2zw6flZzSdDscR/CGT8wIZqZ Tzl0JkTBJ9IkK6rnpL2RMYDRvUEiv9vf4EzzWqc3s7FrmfMnK51lEdQOdikDhTesoGKH LGw6i0/fCziSo4q4jYacVslTyiz7fCl0B9s0MDwpEZoa1ywqouw3zeq6GAn/si+sXT+N a2DQhm1QeosEnv09uCLyXBuUgpCSQiwWziEb6aFRb5RmNV8NqaT3WCbgz3jWltBzLSoB 0IbdJi3Nk8JPYRrULVQdQdpx9Hu5soogDH/GMWivzT0+09BZqDgxvZVUHf6KVuxpzauo JaVg== X-Gm-Message-State: AOAM5311SA5uCDWKuQN3QewOD36+5mhNPF89rAHGHaK7hhIzMUlBua1N lyEGHGTHiJsCvCyGR+TMzZc= X-Google-Smtp-Source: ABdhPJyaf9anDnvUGKHeAuMhu6Czlm64KgJDmGwqj1XvKJ74N+BVmU6XiMToxckPD6afbZ7FbPjK7g== X-Received: by 2002:a63:d604:: with SMTP id q4mr2109929pgg.238.1600911354770; Wed, 23 Sep 2020 18:35:54 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id u138sm779779pfc.218.2020.09.23.18.35.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Sep 2020 18:35:54 -0700 (PDT) To: Eliot Lear , Mark Nottingham Cc: rfced-future@iab.org, "Joel M. Halpern" References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> From: Brian E Carpenter Message-ID: Date: Thu, 24 Sep 2020 13:35:51 +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] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 01:36:31 -0000 On 21-Sep-20 23:49, Eliot Lear wrote: > > Well. Apparently the chairs have found a way to gather consensus on at least one point after all, just not in the way we had expected ;-) > > > >> My sense is that the best way forward is to document the agreed-upon aspects as well as the open issues, and proceed (acknowledging that we still have some difficult - and intertwined - discussions ahead of us). > > > Is there any objection to proceeding along the lines that Mark suggested? I found the easiest way to answer that was to try. The answer is that I have no objection, but it may prove hard to separate the discussion points. Anyway, here's my attempt at three lists (generally agreed, primary issues, secondary issues). # Generally Agreed LLC legally & finanicially responsible for all contracts. RFC production and publishing are service contract(s). Streams have content control. A separate body debates strategy. This body must include stream representatives. Strategy body meetings are public. # Open Issues (primary) There is a figurehead and thought leader of some kind. This figurehead is a paid expert in technical publishing. The expert is an advisor (RSA) vs an executive editor (RSE). The strategy body is open to all (rough consensus WG model) or has defined membership (RSEB model). The strategy body has neutral chairs vs the RSE chairs it. The strategy body makes final decisions on strategy vs the RSE makes final decisions. Oversight/appeals remains with the IAB vs moves to ISOC vs moves to RSEB. # Open Issues (secondary) Single contract for REP vs separate contracts for production (RPC) & publication. Contract monitor(s) outside LLC? Membership definition (RSEB model). Decider for hiring RSA/RSE? Search committee for hiring RSA/RSE? There is a new, separate Editorial Stream. What is strategic (pragmatic definition needed)? Regards, Brian From nobody Thu Sep 24 03:59:30 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E053A092E for ; Thu, 24 Sep 2020 03:59:29 -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 ZdDNUhKuIHg5 for ; Thu, 24 Sep 2020 03:59:27 -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 044273A093B for ; Thu, 24 Sep 2020 03:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34597; q=dns/txt; s=iport; t=1600945167; x=1602154767; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=R+vnSFtoW3vqCQPUHbpSauqQ6xcSwmbXYdntqVj5qK8=; b=ClCtLa3hogsPZKYIHjw808vKtpCSL+3NvBGQUIFMs2InwP2hsEEYfB3o QWVzXf/IKD0HxVx1ugQ4OcnSoufaygkE3HtcOccD4vA0rXm/UzSfCSqVk vSzCCKrqQOSp40VAbtLNdg4jWTbdyzZD/13L4+c4/5oj/T2y0M8tQlVoW w=; X-IPAS-Result: =?us-ascii?q?A0DtAADGe2xf/xbLJq1gGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBT4EjgkwBIBIsjT6IQooOkhMLAQEBDQEBLwQBAYRLAoIsJTgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgRthWiFcgEBAgIBaw4FCyMgAQ0hNgYTgyaCTAMOI?= =?us-ascii?q?LUwdIE0hVOCbQ2CJIE4jUmCAIERJxyCIAGDBIVtgi0EkBiWEpA8UYJxBIMPk?= =?us-ascii?q?jqFCAMfgwyJe4URiSqFS6BSjlmDXAIEBgUCFYFrI4FXMxoIGxU7KgGCPj4SG?= =?us-ascii?q?Q2OKxeOJj8DMAI1AgYKAQEDCZAaAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.77,297,1596499200"; d="scan'208,217"; a="27449663" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2020 10:59:22 +0000 Received: from [10.61.200.244] ([10.61.200.244]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 08OAxKIk031893 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Sep 2020 10:59:22 GMT From: Eliot Lear Message-Id: <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C0A0A71A-F7F3-4342-9BDD-071FB5DF854F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 24 Sep 2020 12:59:20 +0200 In-Reply-To: Cc: rfced-future@iab.org To: Brian E Carpenter References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.200.244, [10.61.200.244] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 10:59:29 -0000 --Apple-Mail=_C0A0A71A-F7F3-4342-9BDD-071FB5DF854F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you, Brian. I remind others, if you have objections to the = direction Mark suggested, place state them now. Please also see below. > On 24 Sep 2020, at 03:35, Brian E Carpenter = wrote: >=20 > On 21-Sep-20 23:49, Eliot Lear wrote: >>=20 >> Well. Apparently the chairs have found a way to gather consensus on = at least one point after all, just not in the way we had expected ;-)=20 >>=20 >>=20 >>=20 >>> My sense is that the best way forward is to document the agreed-upon = aspects as well as the open issues, and proceed (acknowledging that we = still have some difficult - and intertwined - discussions ahead of us). >>=20 >>=20 >> Is there any objection to proceeding along the lines that Mark = suggested? >=20 > I found the easiest way to answer that was to try. The answer is that = I have no objection, but it may prove hard to separate the discussion = points. Anyway, here's my attempt at three lists (generally agreed, = primary issues, secondary issues). >=20 > # Generally Agreed >=20 > LLC legally & finanicially responsible for all contracts. >=20 > RFC production and publishing are service contract(s). >=20 > Streams have content control. >=20 > A separate body debates strategy. >=20 > This body must include stream representatives. >=20 > Strategy body meetings are public. Does anyone disagree with the list above? Are there other things upon = which we agree? >=20 > # Open Issues (primary) >=20 > There is a figurehead and thought leader of some kind. >=20 > This figurehead is a paid expert in technical publishing. >=20 > The expert is an advisor (RSA) vs an executive editor (RSE). >=20 > The strategy body is open to all (rough consensus WG model) or has = defined membership (RSEB model). >=20 > The strategy body has neutral chairs vs the RSE chairs it. >=20 > The strategy body makes final decisions on strategy vs the RSE makes = final decisions. >=20 > Oversight/appeals remains with the IAB vs moves to ISOC vs moves to = RSEB. >=20 > # Open Issues (secondary) >=20 > Single contract for REP vs separate contracts for production (RPC) & = publication. >=20 > Contract monitor(s) outside LLC? >=20 > Membership definition (RSEB model). >=20 > Decider for hiring RSA/RSE? >=20 > Search committee for hiring RSA/RSE? >=20 > There is a new, separate Editorial Stream. >=20 > What is strategic (pragmatic definition needed)? Putting aside what is primary and secondary, do people agree with the = list above? Are there other differences that need to be documented, or = are there other topics that need to be raised that have not been (and = this is not the last time I will ask that question)? Eliot --Apple-Mail=_C0A0A71A-F7F3-4342-9BDD-071FB5DF854F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thank= you, Brian.  I remind others, if you have objections to the = direction Mark suggested, place state them now.  Please also see = below.

On 24 Sep 2020, at 03:35, Brian E Carpenter = <brian.e.carpenter@gmail.com> wrote:

On 21-Sep-20 23:49, Eliot Lear = wrote:

Well.  Apparently the chairs have found a way to gather = consensus on at least one point after all, just not in the way we had = expected ;-) 



My sense is that the best way forward is to = document the agreed-upon aspects as well as the open issues, and proceed = (acknowledging that we still have some difficult - and intertwined - = discussions ahead of us).


Is there any objection to proceeding along the lines that = Mark suggested?

I found the easiest way to answer that was to try. The answer = is that I have no objection, but it may prove hard to separate the = discussion points. Anyway, here's my attempt at three lists (generally = agreed, primary issues, secondary issues).

# Generally Agreed

LLC legally & finanicially responsible for all = contracts.

RFC = production and publishing are service contract(s).

Streams have content = control.

A separate = body debates strategy.

This body must include stream representatives.

Strategy body meetings are = public.


Does anyone disagree with the list above?  Are = there other things upon which we agree?



# Open Issues (primary)

There is a figurehead and thought leader of some = kind.

This = figurehead is a paid expert in technical publishing.

The expert is an advisor (RSA) = vs an executive editor (RSE).

The strategy body is open to all (rough consensus WG model) = or has defined membership (RSEB model).

The strategy body has neutral chairs vs the RSE chairs = it.

The strategy = body makes final decisions on strategy vs the RSE makes final = decisions.

Oversight/appeals remains with the IAB vs moves to ISOC vs = moves to RSEB.

# Open Issues (secondary)

Single contract for REP vs separate contracts for production = (RPC) & publication.

Contract monitor(s) outside LLC?

Membership definition (RSEB = model).

Decider for = hiring RSA/RSE?

Search committee for hiring RSA/RSE?

There is a new, separate = Editorial Stream.

What is strategic (pragmatic definition needed)?

Putting = aside what is primary and secondary, do people agree with the list = above?  Are there other differences that need to be documented, or = are there other topics that need to be raised that have not been (and = this is not the last time I will ask that question)?

Eliot

= --Apple-Mail=_C0A0A71A-F7F3-4342-9BDD-071FB5DF854F-- From nobody Thu Sep 24 08:54: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 363773A0F57 for ; Thu, 24 Sep 2020 08:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EAr5NKrP0DSy for ; Thu, 24 Sep 2020 08:54:52 -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 148683A0EEF for ; Thu, 24 Sep 2020 08:54:51 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 2EB7621C79; Thu, 24 Sep 2020 08:54:51 -0700 (PDT) From: Wes Hardaker To: Brian E Carpenter Cc: Eliot Lear , Mark Nottingham , rfced-future@iab.org, "Joel M. Halpern" References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> Date: Thu, 24 Sep 2020 08:54:51 -0700 In-Reply-To: (Brian E. Carpenter's message of "Thu, 24 Sep 2020 13:35:51 +1200") 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] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 15:54:55 -0000 Brian E Carpenter writes: > The strategy body is open to all (rough consensus WG model) or has > defined membership (RSEB model). I this is two issues combined into one, and it would be helpful if the group could make sure both are addressed: 1. Who can participate in the meetings 2. Who can observe the meetings The second being "transparency"; using just open/closed terminology tends to conflate both of these topics together and they should probably be discussed independently. (though if you have an anyone-can-participate membership, the observation question mostly goes away. Mostly.) -- Wes Hardaker USC/ISI From nobody Thu Sep 24 12:59: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 5DA323A1258; Thu, 24 Sep 2020 12:59:15 -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 zrXFsHElSSCR; Thu, 24 Sep 2020 12:59:14 -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 51EB23A1256; Thu, 24 Sep 2020 12:59:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Jay Daley In-Reply-To: <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> Date: Fri, 25 Sep 2020 07:59:11 +1200 Cc: Brian E Carpenter , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 19:59:15 -0000 One comment below > On 24/09/2020, at 10:59 PM, Eliot Lear = wrote: >=20 >> Decider for hiring RSA/RSE? >>=20 >> Search committee for hiring RSA/RSE? >=20 > Putting aside what is primary and secondary, do people agree with the = list above? Are there other differences that need to be documented, or = are there other topics that need to be raised that have not been (and = this is not the last time I will ask that question)? My reading of it is that there is not necessarily a disagreement here, = but what we have it one proposed process for hiring an RSA and a = different proposed process for hiring an RSE, and while people disagree = on the need for an RSA vs an RSE they don=E2=80=99t appear to disagree = on the appropriateness of each process for each role. Assuming I=E2=80=99= ve read things correctly. Jay >=20 > Eliot >=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 From nobody Thu Sep 24 14:07: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 302BF3A0AAB; Thu, 24 Sep 2020 14:07:05 -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 VspF7xlYxAT4; Thu, 24 Sep 2020 14:07:03 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA213A0A1C; Thu, 24 Sep 2020 14:07:03 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kLYSD-00088T-Nj; Thu, 24 Sep 2020 17:07:01 -0400 Date: Thu, 24 Sep 2020 17:06:55 -0400 From: John C Klensin To: Jay Daley , Eliot Lear cc: rfced-future@iab.org Message-ID: <9AFA5F0D126614600909D350@PSB> In-Reply-To: References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 21:07:05 -0000 Jay, I agree with one qualification, which may re-muddy the waters. See below. --On Friday, September 25, 2020 07:59 +1200 Jay Daley wrote: > One comment below > >> On 24/09/2020, at 10:59 PM, Eliot Lear >> wrote: >> >>> Decider for hiring RSA/RSE? >>> >>> Search committee for hiring RSA/RSE? > >> >> Putting aside what is primary and secondary, do people agree >> with the list above? Are there other differences that need >> to be documented, or are there other topics that need to be >> raised that have not been (and this is not the last time I >> will ask that question)? > > My reading of it is that there is not necessarily a > disagreement here, but what we have it one proposed process > for hiring an RSA and a different proposed process for hiring > an RSE, and while people disagree on the need for an RSA vs an > RSE they don't appear to disagree on the appropriateness of > each process for each role. Assuming I've read things > correctly. ARAICT, you have read those parts of the discussions correctly. _However_ this is one of interaction issues. I don't know how many others are like me in this regard, but "how to recruit and hire X" is not a question I choose to spend time thinking much about, much less commenting on, before we have figured out whether we want and RSE or RSA (and probably more than we have today about what those roles mean). Phrases like "cart before the horse" come to mind. Consequently, you've seen no comments on the subject from me, and making inferences about agreement about either process may be unjustified. The one piece of the subject about which I do have a strong opinion is that I think it would be a terrible idea to chose between RSE and RSA-type roles based on what we believe would be the ease of recruiting and retaining one or the other. AFAIK, no one has suggested that, but it could easily be a result, possibly unintentional, of concentrating on selection processes rather than the relationship between the roles. john From nobody Thu Sep 24 14:29: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 AFCFF3A12E7 for ; Thu, 24 Sep 2020 14:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=nqj2ZGM3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tsD78VI/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khnHZ9qL2hlN for ; Thu, 24 Sep 2020 14:29:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CC13A12E5 for ; Thu, 24 Sep 2020 14:29:09 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9729E5C020A for ; Thu, 24 Sep 2020 17:29:08 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Thu, 24 Sep 2020 17:29:08 -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=fm3; bh=l/P0UUGj9Cz6d/gX0RsC9piMEdvCKNA S0gQ7gS6yt9E=; b=nqj2ZGM3+oZQhBVascyLK10Y7A3qqFv05AT2AMebLNYQmS9 JJhTiQbhkL2/EUG0wKXlvelDG4MlNnSLM2JiZ9MyL1cmH97FjGdmrBJ0wGT+Xxpr lFC6e6ft5VKly7ZuUi/jJQgmkW04ISGlRUBpRMnntGeXAlkrx2Bvi+PvBJIN9X6S ee3eKLE5X3BGxlEVWtcOsZbloYA72ttZna9fDrmmo0eEmrTDhMhB7p7AbB4+CnoA +XWXjp2k0q5zYMvs3ZmqtgFqw0PzBk+n8TDF8PtvzBd5cTagI/P1KlV4+RImW0V9 sax5CICPGjNHlvRmMGJ+LGtIGGGnDIP/Za0dnFQ== 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=l/P0UU Gj9Cz6d/gX0RsC9piMEdvCKNAS0gQ7gS6yt9E=; b=tsD78VI/9AsGHQpp+lZPMy q2Yv7YO7ecMBgVCKPpUKd7abkfB1SR5kV6NTPHEllC52nc+vPfGwLgXC118FVLGs h1kSaWoBI3vRHQjOXvApCyaxMzUphyUKkcKqvTUi5Jh7dI81wShbkEMIHrZjKqSd 18gngXt3HCuSzyySYZkxqSGeYQILhtYwzcffRT5ehAWc+FphZK5S/UMJ9iLEBsMT MZO0EiVK/nVL9/vZN9CLMMN0fB6ZpTuv42b2kSlf1remZksxoZnlYcy8DqABXJyg KfqZYVZpH+5CPSZvNQdLTpB8gFiyqJcNS7cUhxXwKRyjxU6kf0CBS7MZavq4IdgQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekgdduiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DCB8220063; Thu, 24 Sep 2020 17:29:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-355-g3ece53b-fm-20200922.004-g3ece53b9 Mime-Version: 1.0 Message-Id: <249b167b-b15c-42a1-b63f-78b0e90a8bec@www.fastmail.com> In-Reply-To: References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> Date: Fri, 25 Sep 2020 07:28:48 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 21:29:11 -0000 On Fri, Sep 25, 2020, at 01:54, Wes Hardaker wrote: > Brian E Carpenter writes: > > > The strategy body is open to all (rough consensus WG model) or has > > defined membership (RSEB model). > > I this is two issues combined into one, and it would be helpful if the > group could make sure both are addressed: Brian addressed this by noting that all proposals include public meetings, just that Mike proposed a closed membership. From nobody Thu Sep 24 14:35: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 3385C3A1239 for ; Thu, 24 Sep 2020 14:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmkHkwMowc17 for ; Thu, 24 Sep 2020 14:35:17 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 32B733A10FB for ; Thu, 24 Sep 2020 14:35:17 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id u3so540814pjr.3 for ; Thu, 24 Sep 2020 14:35:17 -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=XamDN3y4nkh6/i6H4ulgtmdL78FUlyBKb1eo8J8/sU8=; b=MVauSOlATIc8VlwML3VFTGQGSbKx9m/11GmyQ0cGmY14HhK8LNk/1On8VuT1Qpcaqr LhB4PfV2cQ90ikUhhkjziVd1A9e91ppBBeUjmRdVDcqHTu1zInClIDsUTBbHvV7tUSWR jnB8XMlSQEaC3lHacqfCnZVQCc3F2VvMu2h/JDkM+OLU80N7bealCgls9mkTCCLHHNvp pE/J0GC56XWpljNEKX4GsJBfUOJC2bM0WgANhKhoiVoeMmIo3rDfplvjgq1D5DYtRlh0 L6XULuXbVJtGviOhgFsf+ExcQp5w3PcACXrIhyldhzlJVqMoB07P/u902ssAnB4dzJ8T Tsdg== 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=XamDN3y4nkh6/i6H4ulgtmdL78FUlyBKb1eo8J8/sU8=; b=P8Ay4Imcpc+xWzwOsE/8nFB5tzwUyCEgb6IsDuWTIqY1uK1/ar2RFd3zmnrLJ2Q/3u 8KtZ9n+eXO01lU5X8PPfOcAoKPT4JXFsGrluJM7Nq7ZtamtWMtxgNJ47Hh7q30pTWaHP TiL4Rh1VS/+JDst/pRfhG2yv1PBWeS1n/yScihRJ5rPs6b5wiVt3ikbepfAEYlTaKD7R JQGReEBjR5uAO0EjB0Je3fxB2myvIOAnzGVwZ/ff1HfL5P+50qPfEuquCkfhNs0E1mmY WUL6B3k8RMDO8jqVIwGMFBJnt7VCTnye83l3i0CTAT9/EwbQha1aiBlDM2J473p7ik3F vLcw== X-Gm-Message-State: AOAM5301ESHZu3n5k+EYbrHnV9Kd6j219rCOoUyI0zYLg1/1x3hNoTE2 /rxOmXbMV9XPR/eryH4JVDs= X-Google-Smtp-Source: ABdhPJxSXyrZMYlKKmEA3wYzFiP+IEX/TgO1XF37pL+SBoimn2rZ5kocCvAm9KxeBNqlehO3T/YRVw== X-Received: by 2002:a17:90a:e64e:: with SMTP id ep14mr861087pjb.173.1600983316617; Thu, 24 Sep 2020 14:35:16 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id z1sm381021pfj.113.2020.09.24.14.35.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2020 14:35:15 -0700 (PDT) To: Wes Hardaker Cc: Eliot Lear , Mark Nottingham , rfced-future@iab.org, "Joel M. Halpern" References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> From: Brian E Carpenter Message-ID: <2b1afbfc-573a-697f-3563-208d66793f20@gmail.com> Date: Fri, 25 Sep 2020 09:35:10 +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] Moving forward: Please state your preference X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 21:35:18 -0000 On 25-Sep-20 03:54, Wes Hardaker wrote: > Brian E Carpenter writes: > >> The strategy body is open to all (rough consensus WG model) or has >> defined membership (RSEB model). > > I this is two issues combined into one, and it would be helpful if the > group could make sure both are addressed: > > 1. Who can participate in the meetings > 2. Who can observe the meetings I agree; that should be expressed more clearly. Brian > The second being "transparency"; using just open/closed terminology > tends to conflate both of these topics together and they should probably > be discussed independently. (though if you have an > anyone-can-participate membership, the observation question mostly goes > away. Mostly.) > From nobody Thu Sep 24 14:38: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 3463D3A12EC for ; Thu, 24 Sep 2020 14:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCZKUBeBlbTX for ; Thu, 24 Sep 2020 14:38:11 -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 0EE603A12E9 for ; Thu, 24 Sep 2020 14:38:11 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id v14so537192pjd.4 for ; Thu, 24 Sep 2020 14:38: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=To/Ap8gsVXLY5A/upZpJMJL+5R80ZO1BaBpRCT17tf0=; b=NrQpNa8vrtDQcVHss7NrBqVU+o0Pf16LqiWcn7Kqocst24FBdcS5rF4jDvNSBzQpqa 0RgUxcDrAIJKmZYY6p5FNibSsvCH6Epq+6Zs1lMvYkwDDSMMTz0um4MI/XQpMEoHUgf3 KgISgpIudrtFzWBwBJm03w+PITQGzWqZ/gzrFmOrTRMugKnNwEte5ShEtRGnRZptywl7 xTY5z0IuM4Vy2SGTkpu1OVpOCEwf1hD4BwW+beqppdlfvFwLmLcmvhHSWQf+l9XsHzHN 735ZrkrhrrdqSwaAL4z3NqlLMFRLrrx7sf/nOLFoufF85Gh2oBQn2VepOkKQZ+6PRQVv t4pw== 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=To/Ap8gsVXLY5A/upZpJMJL+5R80ZO1BaBpRCT17tf0=; b=RriQXVUAD085sdkyPGyBB67ZE1C3Pxw/D4xjGyrC9ncPfHhuW5KpzWDfiI2Pq2s80Q 0qg+79gBvBVkpfuHM7uhBSLN49AgzIUFQzn1Aoe1VK2tSiZifelHPL1ISFDeqhqBD+wv ypqR7obfexZcnI9DasR4fgTQauvJmH2O15LHPeiJMSV2xwHgTPzt1QsigUNXTVspggm+ FCoKG75NOgVhF0nLjMvFh6G7CMpsXBJmI1vVBz8o4exZPFQ/gSWUhjlXZ+GswtWR7G++ EjwuSqUO+5pSAF33PnSiB2WpShEE9zcFBP6g4m/g6bZmGzEWmeTwGT08hMjr0lDPHqiG AvmA== X-Gm-Message-State: AOAM530bnK9GRnxL8lrrVXiUBfsRv09bMH7/XCPjbWHG1hGZ/k4keQzN 9GstLn/sclMr3B7p/DKUSOfBcL1Fda0= X-Google-Smtp-Source: ABdhPJzm+FlgVy5W8nILAdQbDbjkYg7dWiRq6TXRvghBbNmKN5oVrwTnCqMohP8d2dnlkoJRqJHB2w== X-Received: by 2002:a17:90b:360a:: with SMTP id ml10mr842992pjb.198.1600983490317; Thu, 24 Sep 2020 14:38:10 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id a15sm285835pgi.69.2020.09.24.14.38.08 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2020 14:38:09 -0700 (PDT) To: rfced-future@iab.org References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> <9AFA5F0D126614600909D350@PSB> From: Brian E Carpenter Message-ID: Date: Fri, 25 Sep 2020 09:38:06 +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: <9AFA5F0D126614600909D350@PSB> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 21:38:12 -0000 On 25-Sep-20 09:06, John C Klensin wrote: > Jay, > > I agree with one qualification, which may re-muddy the waters. > See below. > > --On Friday, September 25, 2020 07:59 +1200 Jay Daley > wrote: > >> One comment below >> >>> On 24/09/2020, at 10:59 PM, Eliot Lear >>> wrote: >>> >>>> Decider for hiring RSA/RSE? >>>> >>>> Search committee for hiring RSA/RSE? >> >>> >>> Putting aside what is primary and secondary, do people agree >>> with the list above? Are there other differences that need >>> to be documented, or are there other topics that need to be >>> raised that have not been (and this is not the last time I >>> will ask that question)? >> >> My reading of it is that there is not necessarily a >> disagreement here, but what we have it one proposed process >> for hiring an RSA and a different proposed process for hiring >> an RSE, and while people disagree on the need for an RSA vs an >> RSE they don't appear to disagree on the appropriateness of >> each process for each role. Assuming I've read things >> correctly. > > ARAICT, you have read those parts of the discussions correctly. > _However_ this is one of interaction issues. I don't know how > many others are like me in this regard, but "how to recruit and > hire X" is not a question I choose to spend time thinking much > about, much less commenting on, before we have figured out > whether we want and RSE or RSA (and probably more than we have > today about what those roles mean). Phrases like "cart before > the horse" come to mind. Consequently, you've seen no comments > on the subject from me, and making inferences about agreement > about either process may be unjustified. That's exactly why I listed it as "secondary". There's little point in debating it in a vacuum. > The one piece of the subject about which I do have a strong > opinion is that I think it would be a terrible idea to chose > between RSE and RSA-type roles based on what we believe would be > the ease of recruiting and retaining one or the other. AFAIK, > no one has suggested that, but it could easily be a result, > possibly unintentional, of concentrating on selection processes > rather than the relationship between the roles. Agreed. Brian > > john > From nobody Thu Sep 24 14:40:19 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 C2D063A12F2 for ; Thu, 24 Sep 2020 14:40:17 -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 ETNuP4l9JDgF; Thu, 24 Sep 2020 14:40: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 6E9AC3A12F5; Thu, 24 Sep 2020 14:40:15 -0700 (PDT) From: Jay Daley Message-Id: <456AC8B8-DC6B-49A9-A192-7CF41E793B07@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_0D282AEC-B46D-4DB5-B2AB-3998EC15CF38" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 25 Sep 2020 09:40:13 +1200 In-Reply-To: Cc: rfced-future@iab.org To: Brian E Carpenter References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> <9AFA5F0D126614600909D350@PSB> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 21:40:18 -0000 --Apple-Mail=_0D282AEC-B46D-4DB5-B2AB-3998EC15CF38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25/09/2020, at 9:38 AM, Brian E Carpenter = wrote: >=20 > On 25-Sep-20 09:06, John C Klensin wrote: >> Jay, >>=20 >> I agree with one qualification, which may re-muddy the waters. >> See below. >>=20 >> --On Friday, September 25, 2020 07:59 +1200 Jay Daley >> wrote: >>=20 >>> One comment below >>>=20 >>>> On 24/09/2020, at 10:59 PM, Eliot Lear >>>> wrote: >>>>=20 >>>>> Decider for hiring RSA/RSE? >>>>>=20 >>>>> Search committee for hiring RSA/RSE? >>>=20 >>>>=20 >>>> Putting aside what is primary and secondary, do people agree >>>> with the list above? Are there other differences that need >>>> to be documented, or are there other topics that need to be >>>> raised that have not been (and this is not the last time I >>>> will ask that question)? >>>=20 >>> My reading of it is that there is not necessarily a >>> disagreement here, but what we have it one proposed process >>> for hiring an RSA and a different proposed process for hiring >>> an RSE, and while people disagree on the need for an RSA vs an >>> RSE they don't appear to disagree on the appropriateness of >>> each process for each role. Assuming I've read things >>> correctly. >>=20 >> ARAICT, you have read those parts of the discussions correctly. >> _However_ this is one of interaction issues. I don't know how >> many others are like me in this regard, but "how to recruit and >> hire X" is not a question I choose to spend time thinking much >> about, much less commenting on, before we have figured out >> whether we want and RSE or RSA (and probably more than we have >> today about what those roles mean). Phrases like "cart before >> the horse" come to mind. Consequently, you've seen no comments >> on the subject from me, and making inferences about agreement >> about either process may be unjustified. =20 >=20 > That's exactly why I listed it as "secondary". There's little > point in debating it in a vacuum. My point was that it isn=E2=80=99t even a secondary issue - it=E2=80=99s = not an issue at all afaict. Jay >=20 >> The one piece of the subject about which I do have a strong >> opinion is that I think it would be a terrible idea to chose >> between RSE and RSA-type roles based on what we believe would be >> the ease of recruiting and retaining one or the other. AFAIK, >> no one has suggested that, but it could easily be a result, >> possibly unintentional, of concentrating on selection processes >> rather than the relationship between the roles. >=20 > Agreed. >=20 > Brian >>=20 >> john >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_0D282AEC-B46D-4DB5-B2AB-3998EC15CF38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 25/09/2020, at 9:38 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On 25-Sep-20 09:06, John C = Klensin wrote:
Jay,

I = agree with one qualification, which may re-muddy the waters.
See below.

--On Friday, = September 25, 2020 07:59 +1200 Jay Daley
<jay@ietf.org> wrote:

One = comment below

On 24/09/2020, at 10:59 PM, Eliot Lear
<lear=3D40cisco.com@dmarc.ietf.org> wrote:

Decider = for hiring RSA/RSE?

Search committee for = hiring RSA/RSE?


Putting = aside what is primary and secondary, do people agree
with = the list above?  Are there other differences that need
to be documented, or are there other topics that need to = be
raised that have not been (and this is not the last = time I
will ask that question)?

My reading of it is that there is = not necessarily a
disagreement here, but what we have it = one proposed process
for hiring an RSA and a different = proposed process for hiring
an RSE, and while people = disagree on the need for an RSA vs an
RSE they don't = appear to disagree on the appropriateness of
each process = for each role.  Assuming I've read things
correctly.

ARAICT, you have read those = parts of the discussions correctly.
_However_ this is one = of interaction issues.  I don't know how
many others = are like me in this regard, but "how to recruit and
hire = X" is not a question I choose to spend time thinking much
about, much less commenting on, before we have figured out
whether we want and RSE or RSA (and probably more than we = have
today about what those roles mean).  Phrases = like "cart before
the horse" come to mind. =  Consequently, you've seen no comments
on the subject = from me, and making inferences about agreement
about = either process may be unjustified.  

That's exactly why I listed it = as "secondary". There's little
point in debating it in a vacuum.

My point was = that it isn=E2=80=99t even a secondary issue - it=E2=80=99s not an issue = at all afaict.

Jay


The = one piece of the subject about which I do have a strong
opinion is that I think it would be a terrible idea to = chose
between RSE and RSA-type roles based on what we = believe would be
the ease of recruiting and retaining one = or the other.  AFAIK,
no one has suggested that, but = it could easily be a result,
possibly unintentional, of = concentrating on selection processes
rather than the = relationship between the roles.

Agreed.

   Brian

   john


-- 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=_0D282AEC-B46D-4DB5-B2AB-3998EC15CF38-- From nobody Thu Sep 24 14:49: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 D344B3A12F6 for ; Thu, 24 Sep 2020 14:49:37 -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=unavailable 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 wbat4GHoey7r for ; Thu, 24 Sep 2020 14:49:36 -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 1B35A3A12FB for ; Thu, 24 Sep 2020 14:49:36 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id k25so684034ljg.9 for ; Thu, 24 Sep 2020 14:49:36 -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=ucCE9IC/eK/BdjELyXNh48rJ+z/Nk6/5u1zo3dh6CJ4=; b=clBfVgP9BQlEBFeRVVErdHAc4WS2wG+QfzgWpwCV7Da8RBJspuShXks/ARun1S1yrA cGzbTtiYppyvVc/XdX27LVLlU8gYp8dqi1EkFsI8xkMrPjh7ooVJgkiYmk6KVq69DnRI /ds/tlsz0IsieR1c76vZ6+DjwL3wwOufGUnYc/eRDWWzWtiFjk9RpODOhg/5heEFo8i8 YCFlNhlpmMcKdPs3HBCzh7KZBKcBWQ/SnwG+ByDLemjeFjN/gr8xf5KViYTllHGkpV64 bEhv+mao/YGJIsPgFRAzo74y+PXUbB90a3p6TABmpRH7z8ZIVFfKSMRR5dtIZ+FUpwan P6oQ== 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=ucCE9IC/eK/BdjELyXNh48rJ+z/Nk6/5u1zo3dh6CJ4=; b=GbbElr/Ox+nLn59W47ZVtYyP7hKWxIXsv8PL/NbR8zGPdz3i3oIG/As6ayIo6iWsYu FaxM5JQw832d+4HkaBc93LIke61cm+wx4gu6XiJwUWoHH6x1kfDrKCAt/IGAo76SfqOe hOb15SXjeQxif5BSTh62Qh/77jkrxEcsZcCDtZp2G/usxDE+8IZoDiXtyz5dx5jRTmZ9 pzPsHfUSYkqBzOOvm4VOa+howXGyHnEiek2UqaW8FNeodXwzIkZSBVdxateZKc137SBt +0l9yv3rhRibs+009xrsEfGgHhw20yR4Tv3IGli7U4/ybwdyD2XD6XOBIwIccW0fguUF KwVQ== X-Gm-Message-State: AOAM533ffMMTfmqckKFsM0GT4aEp3cASmmdrnfi5h1QkCASGYrnBNu2W fTDQmXAyxCrsEgC5uKwoHp1WPlt/GJaLcJHziQ6XQA== X-Google-Smtp-Source: ABdhPJzgPopo8IopJXg6SLr7pKauqABQC1s6qQH2n+IMVLGf4As12vs59MNFxpLEF0zjmniDdlzOW83neemJYyezDZk= X-Received: by 2002:a2e:87c7:: with SMTP id v7mr356353ljj.13.1600984174057; Thu, 24 Sep 2020 14:49:34 -0700 (PDT) MIME-Version: 1.0 References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> In-Reply-To: From: Eric Rescorla Date: Thu, 24 Sep 2020 14:48:57 -0700 Message-ID: To: Jay Daley Cc: Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000fc73d105b0162ce2" Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 21:49:38 -0000 --000000000000fc73d105b0162ce2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 24, 2020 at 12:59 PM Jay Daley wrote: > One comment below > > > On 24/09/2020, at 10:59 PM, Eliot Lear > wrote: > > > >> Decider for hiring RSA/RSE? > >> > >> Search committee for hiring RSA/RSE? > > > > > Putting aside what is primary and secondary, do people agree with the > list above? Are there other differences that need to be documented, or a= re > there other topics that need to be raised that have not been (and this is > not the last time I will ask that question)? > > My reading of it is that there is not necessarily a disagreement here, bu= t > what we have it one proposed process for hiring an RSA and a different > proposed process for hiring an RSE, and while people disagree on the need > for an RSA vs an RSE they don=E2=80=99t appear to disagree on the appropr= iateness > of each process for each role. Assuming I=E2=80=99ve read things correct= ly. > No, I don't think you have. Mike and I had an extended back and forth about RSE hiring and our disagreement on that. -Ekr > Jay > > > > > Eliot > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > > -- > Jay Daley > IETF Executive Director > jay@ietf.org > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000fc73d105b0162ce2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 24, 2020 at 12:59 PM Jay = Daley <jay@ietf.org> wrote:
One comment below

> On 24/09/2020, at 10:59 PM, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org&= gt; wrote:
>
>> Decider for hiring RSA/RSE?
>>
>> Search committee for hiring RSA/RSE?

>
> Putting aside what is primary and secondary, do people agree with the = list above?=C2=A0 Are there other differences that need to be documented, o= r are there other topics that need to be raised that have not been (and thi= s is not the last time I will ask that question)?

My reading of it is that there is not necessarily a disagreement here, but = what we have it one proposed process for hiring an RSA and a different prop= osed process for hiring an RSE, and while people disagree on the need for a= n RSA vs an RSE they don=E2=80=99t appear to disagree on the appropriatenes= s of each process for each role.=C2=A0 Assuming I=E2=80=99ve read things co= rrectly.

No, I don't think you have= . Mike and I had an extended back and forth about RSE hiring and our disagr= eement on that.

-Ekr


Jay

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

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

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000fc73d105b0162ce2-- From nobody Thu Sep 24 15:25: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 B11C43A09BD; Thu, 24 Sep 2020 15:25:05 -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 YZ2MaDRrMKyB; Thu, 24 Sep 2020 15:25:03 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC903A0978; Thu, 24 Sep 2020 15:25:03 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kLZfi-0008PM-CM; Thu, 24 Sep 2020 18:25:02 -0400 Date: Thu, 24 Sep 2020 18:24:56 -0400 From: John C Klensin To: Jay Daley , Brian E Carpenter cc: rfced-future@iab.org Message-ID: <38EE2B824D128ED19C71AE94@PSB> In-Reply-To: <456AC8B8-DC6B-49A9-A192-7CF41E793B07@ietf.org> References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> <9AFA5F0D126614600909D350@PSB> <456AC8B8-DC6B-49A9-A192-7CF41E793B07@ietf.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 22:25:12 -0000 --On Friday, September 25, 2020 09:40 +1200 Jay Daley wrote: >>> ARAICT, you have read those parts of the discussions >>> correctly. _However_ this is one of interaction issues. I >>> don't know how many others are like me in this regard, but >>> "how to recruit and hire X" is not a question I choose to >>> spend time thinking much about, much less commenting on, >>> before we have figured out whether we want and RSE or RSA >>> (and probably more than we have today about what those roles >>> mean). Phrases like "cart before the horse" come to mind. >>> Consequently, you've seen no comments on the subject from >>> me, and making inferences about agreement about either >>> process may be unjustified. >> >> That's exactly why I listed it as "secondary". There's little >> point in debating it in a vacuum. > > My point was that it isn't even a secondary issue - it's > not an issue at all afaict. I'm not sure whether Brian's definition of "secondary" and mine are the same, which is why I keep saying "intertwined", "interconnected", and "mutually dependent", although I I believe we agree that anything that helps us sequence our consideration of these issues is a good idea and that this one comes after deciding among RS* models. But "not an issue at all" is going too far for at least two reasons. One is that people who have been ignoring the "how we recruit and hire" question entirely until we after the "RSE vs RSA" decision is made might then review the plans for the chosen position and raise issues that have not yet been identified, much less discussed. The other is that once that decision is made and we have agreed-upon scope and job description statements, we review the recruitment/selection plan and discover that the number of people who would meet the requirements and be willing to apply or or take the position would be somewhat more rare than the typical unicorn or flying pig. We would then have to figure out something else, possibly revisiting already-closed decisions. I think (and hope) the latter scenario is unlikely but not unlikely enough to say "not an issue at all". john From nobody Thu Sep 24 15:26: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 BC1B43A08E5; Thu, 24 Sep 2020 15:26:37 -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 BQQY5cO1mXc6; Thu, 24 Sep 2020 15:26:36 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420D53A08E3; Thu, 24 Sep 2020 15:26:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kLZhD-0008Pm-5i; Thu, 24 Sep 2020 18:26:35 -0400 Date: Thu, 24 Sep 2020 18:26:29 -0400 From: John C Klensin To: Jay Daley , Brian E Carpenter cc: rfced-future@iab.org Message-ID: <5D23B9FBE0A1719F8C366655@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 22:26:38 -0000 (sorry -- posted from wrong address) --On Friday, September 25, 2020 09:40 +1200 Jay Daley wrote: >>> ARAICT, you have read those parts of the discussions >>> correctly. _However_ this is one of interaction issues. I >>> don't know how many others are like me in this regard, but >>> "how to recruit and hire X" is not a question I choose to >>> spend time thinking much about, much less commenting on, >>> before we have figured out whether we want and RSE or RSA >>> (and probably more than we have today about what those roles >>> mean). Phrases like "cart before the horse" come to mind. >>> Consequently, you've seen no comments on the subject from >>> me, and making inferences about agreement about either >>> process may be unjustified. >> >> That's exactly why I listed it as "secondary". There's little >> point in debating it in a vacuum. > > My point was that it isn't even a secondary issue - it's > not an issue at all afaict. I'm not sure whether Brian's definition of "secondary" and mine are the same, which is why I keep saying "intertwined", "interconnected", and "mutually dependent", although I I believe we agree that anything that helps us sequence our consideration of these issues is a good idea and that this one comes after deciding among RS* models. But "not an issue at all" is going too far for at least two reasons. One is that people who have been ignoring the "how we recruit and hire" question entirely until we after the "RSE vs RSA" decision is made might then review the plans for the chosen position and raise issues that have not yet been identified, much less discussed. The other is that once that decision is made and we have agreed-upon scope and job description statements, we review the recruitment/selection plan and discover that the number of people who would meet the requirements and be willing to apply or or take the position would be somewhat more rare than the typical unicorn or flying pig. We would then have to figure out something else, possibly revisiting already-closed decisions. I think (and hope) the latter scenario is unlikely but not unlikely enough to say "not an issue at all". john From nobody Thu Sep 24 15:39:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3724A3A09D8; Thu, 24 Sep 2020 15:39:24 -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 oVex4nu5RyIe; Thu, 24 Sep 2020 15:39:22 -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 1A5803A09D3; Thu, 24 Sep 2020 15:39:21 -0700 (PDT) From: Jay Daley Message-Id: <65D6B62F-5211-45C5-8DB9-97AB55E156C6@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF9C63B5-4708-4F5B-9BA5-0894C420AFC9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 25 Sep 2020 10:39:19 +1200 In-Reply-To: Cc: Eliot Lear , rfced-future@iab.org To: Eric Rescorla References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 22:39:24 -0000 --Apple-Mail=_FF9C63B5-4708-4F5B-9BA5-0894C420AFC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25/09/2020, at 9:48 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Thu, Sep 24, 2020 at 12:59 PM Jay Daley > wrote: > One comment below >=20 > > On 24/09/2020, at 10:59 PM, Eliot Lear = > = wrote: > >=20 > >> Decider for hiring RSA/RSE? > >>=20 > >> Search committee for hiring RSA/RSE? >=20 > >=20 > > Putting aside what is primary and secondary, do people agree with = the list above? Are there other differences that need to be documented, = or are there other topics that need to be raised that have not been (and = this is not the last time I will ask that question)? >=20 > My reading of it is that there is not necessarily a disagreement here, = but what we have it one proposed process for hiring an RSA and a = different proposed process for hiring an RSE, and while people disagree = on the need for an RSA vs an RSE they don=E2=80=99t appear to disagree = on the appropriateness of each process for each role. Assuming I=E2=80=99= ve read things correctly. >=20 > No, I don't think you have. Mike and I had an extended back and forth = about RSE hiring and our disagreement on that. Ah. Thanks! Jay >=20 > -Ekr >=20 >=20 > Jay >=20 > >=20 > > Eliot > >=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 >=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=_FF9C63B5-4708-4F5B-9BA5-0894C420AFC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 25/09/2020, at 9:48 AM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Thu, Sep 24, 2020 at 12:59 PM Jay Daley <jay@ietf.org> wrote:
One comment = below

> On 24/09/2020, at 10:59 PM, = Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> = wrote:
> 
>> = Decider for hiring RSA/RSE?
>> 
>> = Search committee for hiring RSA/RSE?

> 
> Putting aside what is primary and secondary, do people = agree with the list above?  Are there other differences that need = to be documented, or are there other topics that need to be raised that = have not been (and this is not the last time I will ask that = question)?

My reading of it is that there = is not necessarily a disagreement here, but what we have it one proposed = process for hiring an RSA and a different proposed process for hiring an = RSE, and while people disagree on the need for an RSA vs an RSE they = don=E2=80=99t appear to disagree on the appropriateness of each process = for each role.  Assuming I=E2=80=99ve read things correctly.

No, I don't think you have. Mike and I had an extended back = and forth about RSE hiring and our disagreement on = that.


Ah. Thanks!

Jay


-Ekr


Jay

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

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

-- 
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=_FF9C63B5-4708-4F5B-9BA5-0894C420AFC9-- From nobody Thu Sep 24 16:26: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 7E9063A0A68 for ; Thu, 24 Sep 2020 16:25: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 l4qQYX9QRQin for ; Thu, 24 Sep 2020 16:25:56 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 EEEDF3A0A4A for ; Thu, 24 Sep 2020 16:25:55 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id y2so689618lfy.10 for ; Thu, 24 Sep 2020 16:25: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=u2omisgIV7RHNzA7+kuF6ily0lL5VLYXnXjDscswHV0=; b=b/rkciTCo2f1DLO1nvGrlvif7zE259vp7X/GufFb/vFk5hZGZAtsE3wfMPzdyZEdZL lF1ytWsRmhTs/0n75EOYhlcagZtuMWDZ9SQ2t+9U8zhn2IDYAo/yIclqnANC/22mMVMv srPQ6fuy3xIBRHERO33LE6KlFY3yRUYQ+JAwmQOrrOWaZAWWT1x7r26UtWPE3b+nQXYS 3bPchsq4txjJAwnnifbTxpSf3yU1LUPTBp2v+PI9NKVvGHokrFYtk0aj/U9QB01Ydj+t FGGpe8Nl5JGJQpRGbgva47N8YCoT8/ACO2HXpcoNW4zc3lwZkK70s2yrf7iruMsXYzXy 7gPQ== 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=u2omisgIV7RHNzA7+kuF6ily0lL5VLYXnXjDscswHV0=; b=gVAiAbrdFb9o3UI72xcJx5VOVp88RoWXrHxKG9c9hyb7VoDXNMDZD4s32+cNtTyKov zmQx/jhG/OPVFYxU5vnvfX5mIM5lM+uhkDriCgnobg83hRnOR/zAa0qMfcA9OAW91Us7 Hao4/8RD+qnUPoqx84n24LQq04gkxuwfXrTATW1DDvTOW85Yu0MtPwxUqiD5KXmByYcy Y70CdjGmzMf5LZzwcCcizZW7aur9GGzc1X7xyR9ukciEqU43SRJEYow8oif+RgTzUZ9Y xS+uXx9AMWEsju4fVfXAwExbxn/KYPsrcKwlRfEiLOVa6z8RDwQVTmJFbEE4KBt0ZzqB wCOg== X-Gm-Message-State: AOAM531ffBkrU6ST0uJqlc0TZe72bfNyHRbCrDbKS7qAOB2CBCu6/VI6 04m98+kLEG41+nj4BCwH8SP4zyfT0ntTlmgK/gi8oQ== X-Google-Smtp-Source: ABdhPJwmzXgIBt9jftgbJa2MwbtgyFPSg+oqq1bpCb9DJABPUu5lv/lMZvYhMv6eWY5dtrDXrhL+PgIK04J3l127Qvs= X-Received: by 2002:a19:447:: with SMTP id 68mr386323lfe.26.1600989954175; Thu, 24 Sep 2020 16:25:54 -0700 (PDT) MIME-Version: 1.0 References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> In-Reply-To: <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> From: Eric Rescorla Date: Thu, 24 Sep 2020 16:25:17 -0700 Message-ID: To: Eliot Lear Cc: Brian E Carpenter , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000820c7405b017850b" Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 23:25:59 -0000 --000000000000820c7405b017850b Content-Type: text/plain; charset="UTF-8" On Thu, Sep 24, 2020 at 3:59 AM Eliot Lear wrote: > Thank you, Brian. I remind others, if you have objections to the > direction Mark suggested, place state them now. Please also see below. > > On 24 Sep 2020, at 03:35, Brian E Carpenter > wrote: > > On 21-Sep-20 23:49, Eliot Lear wrote: > > > Well. Apparently the chairs have found a way to gather consensus on at > least one point after all, just not in the way we had expected ;-) > > > > My sense is that the best way forward is to document the agreed-upon > aspects as well as the open issues, and proceed (acknowledging that we > still have some difficult - and intertwined - discussions ahead of us). > > > > Is there any objection to proceeding along the lines that Mark suggested? > > > I found the easiest way to answer that was to try. The answer is that I > have no objection, but it may prove hard to separate the discussion points. > Anyway, here's my attempt at three lists (generally agreed, primary issues, > secondary issues). > > # Generally Agreed > > LLC legally & finanicially responsible for all contracts. > > RFC production and publishing are service contract(s). > > Streams have content control. > > A separate body debates strategy. > > This body must include stream representatives. > > I'm not sure what this means. Suppose we have a WG as MT's version suggests. What does this mean for the IETF stream in practice? > > Strategy body meetings are public. > > > > Does anyone disagree with the list above? Are there other things upon > which we agree? > > > > # Open Issues (primary) > > There is a figurehead and thought leader of some kind. > > This figurehead is a paid expert in technical publishing. > > These first two don't have alternatives. Is the point that there is an open issue about whether they are agreed as stated? -Ekr > > The expert is an advisor (RSA) vs an executive editor (RSE). > > The strategy body is open to all (rough consensus WG model) or has defined > membership (RSEB model). > > The strategy body has neutral chairs vs the RSE chairs it. > > The strategy body makes final decisions on strategy vs the RSE makes final > decisions. > > Oversight/appeals remains with the IAB vs moves to ISOC vs moves to RSEB. > > > > # Open Issues (secondary) > > Single contract for REP vs separate contracts for production (RPC) & > publication. > > Contract monitor(s) outside LLC? > > Membership definition (RSEB model). > > Decider for hiring RSA/RSE? > > Search committee for hiring RSA/RSE? > > There is a new, separate Editorial Stream. > > What is strategic (pragmatic definition needed)? > > > Putting aside what is primary and secondary, do people agree with the list > above? Are there other differences that need to be documented, or are > there other topics that need to be raised that have not been (and this is > not the last time I will ask that question)? > > Eliot > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000820c7405b017850b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 24, 2020 at 3:59 AM Eliot= Lear <lear=3D40cisco.com@= dmarc.ietf.org> wrote:
Thank you, Brian.= =C2=A0 I remind others, if you have objections to the direction Mark sugges= ted, place state them now.=C2=A0 Please also see below.

On 24 Sep 2020, at 03:35, Brian E Carpenter <brian.e.carpe= nter@gmail.com> wrote:

On 21-Sep-20 23:49, Eliot Lear wrote:

Well.=C2=A0 Apparently = the chairs have found a way to gather consensus on at least one point after= all, just not in the way we had expected ;-)=C2=A0


My sense is that the best way forward is to = document the agreed-upon aspects as well as the open issues, and proceed (a= cknowledging that we still have some difficult - and intertwined - discussi= ons ahead of us).


Is there any objection to proceed= ing along the lines that Mark suggested?

I found the easiest way t= o answer that was to try. The answer is that I have no objection, but it ma= y prove hard to separate the discussion points. Anyway, here's my attem= pt at three lists (generally agreed, primary issues, secondary issues).

# Generally Agreed

LLC legally & fin= anicially responsible for all contracts.

RFC production = and publishing are service contract(s).

Streams have con= tent control.

A separate body debates strategy.
This body must include stream representatives.

I'm not sure what = this means. Suppose we have a WG as MT's version suggests. What does th= is mean for the IETF stream in practice?


=


Str= ategy body meetings are public.


Does anyone disagree with the list above?= =C2=A0 Are there other things upon which we agree?



# Open Issues (primary)

The= re is a figurehead and thought leader of some kind.

This= figurehead is a paid expert in technical publishing.
These first two don't have alternativ= es. Is the point that there is an open issue about whether they are agreed = as stated?

-Ekr



The expert is an adviso= r (RSA) vs an executive editor (RSE).

The strategy bod= y is open to all (rough consensus WG model) or has defined membership (RSEB= model).

The strategy body has neutral chairs vs the RSE= chairs it.

The strategy body makes final decisions on s= trategy vs the RSE makes final decisions.

Oversight/appe= als remains with the IAB vs moves to ISOC vs moves to RSEB.




# Open Issues (seco= ndary)

Single contract for REP vs separate contracts for= production (RPC) & publication.

Contract monitor(s)= outside LLC?

Membership definition (RSEB model).=

Decider for hiring RSA/RSE?

Search committe= e for hiring RSA/RSE?

There is a new, separate Editorial= Stream.

What is strategic (pragmatic definition needed)= ?

Putting = aside what is primary and secondary, do people agree with the list above?= =C2=A0 Are there other differences that need to be documented, or are there= other topics that need to be raised that have not been (and this is not th= e last time I will ask that question)?

Eliot
=
--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000820c7405b017850b-- From nobody Thu Sep 24 17:31: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 7642B3A09C4 for ; Thu, 24 Sep 2020 17:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 KODZidjvLQOA for ; Thu, 24 Sep 2020 17:31:03 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 648843A09C1 for ; Thu, 24 Sep 2020 17:31:03 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id d6so1384157pfn.9 for ; Thu, 24 Sep 2020 17:31:03 -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=n8E/fH/1xhh6vxqoMdpmwM10sUCqeyxdjxnJlOCW/ko=; b=bExxfmwlmYog1cNN+Fb/Ndwc6JE3ckCsTfDGlxMi0Xbcd2s2cWT2mUg6LdoGisNZEo M+N1hHGGzOMUQbLJvTFKlufbqm40Jy+QgCUplGnmWp9piSgWRiKi/DijPPI1pGFOXJU0 yySx/30MUJ0kWKpkoWfE8F1LUW6/7QRd4lNoUxYIOQi6hou0vzgYB/gg75O24VnJuoFX wQDDSXeAtfABt31hBGjleesr4Iclay6od1MpqNm3X0G6SA1OU89u/PaA60ypdnPU6U3z rBxiJvU1aOyuymGa6jGszvVeyeJ0tbhIAIVe6IQdkXWfFL9+AOyMZ2/KFSqHlhse/WlM bndQ== 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=n8E/fH/1xhh6vxqoMdpmwM10sUCqeyxdjxnJlOCW/ko=; b=kPehSAlcajfZFZjHR5B965OF+vXWb/DESaiG3Ua3XFFq5YdWrwCGRQBJosN3Sl48sj 1ZjYlT2jbcE7iUb/TPhgwsMygBZtCY16ifCPQLc2Z/7Dijzsf0Q7PEsrp1dSxTiNVUP7 dodvLYoYDAp+qbKpDjjt8E1QvuqwuN4HSA7aFbgRqGNnHAmJ+s9CtXjwSbZxXImqCkh0 xfm1eblSPot93zAbZI7hvHvsdjPSHNWfYB3o67KWbsjmZfh/7Rs14h4w+z4MDnIGCGyE GHLgXoTyDgm9nRd9k8AS+vieTbi0eZ7VkKjU7bJaoI71ll0Qet12LkB11pGnGUW0fQ0X fckg== X-Gm-Message-State: AOAM533fycMpbO6I7BrDzgSQPMCK/uAJJju/tXz+VsvltFKi6H2/mdg6 bcUOtiIoxcQcbezgp7KWAiuA7TcviqU= X-Google-Smtp-Source: ABdhPJyhtKlbsTs83/APoiYf0ez5kPrHjX3u+Q3t26i4XV61sQCos3gfRSBjEYi6ceoHNdFtFNZuAg== X-Received: by 2002:a17:902:b191:b029:d2:6277:3898 with SMTP id s17-20020a170902b191b02900d262773898mr1782639plr.10.1600993862327; Thu, 24 Sep 2020 17:31:02 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id j26sm593564pfa.160.2020.09.24.17.30.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2020 17:31:01 -0700 (PDT) To: John C Klensin , Jay Daley Cc: rfced-future@iab.org References: <5D23B9FBE0A1719F8C366655@PSB> From: Brian E Carpenter Message-ID: <8ea1a32e-c24d-9d58-b71c-bb9e82c22362@gmail.com> Date: Fri, 25 Sep 2020 12:30:57 +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: <5D23B9FBE0A1719F8C366655@PSB> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 00:31:05 -0000 On 25-Sep-20 10:26, John C Klensin wrote: > (sorry -- posted from wrong address) > > --On Friday, September 25, 2020 09:40 +1200 Jay Daley > wrote: > >>>> ARAICT, you have read those parts of the discussions >>>> correctly. _However_ this is one of interaction issues. I >>>> don't know how many others are like me in this regard, but >>>> "how to recruit and hire X" is not a question I choose to >>>> spend time thinking much about, much less commenting on, >>>> before we have figured out whether we want and RSE or RSA >>>> (and probably more than we have today about what those roles >>>> mean). Phrases like "cart before the horse" come to mind. >>>> Consequently, you've seen no comments on the subject from >>>> me, and making inferences about agreement about either >>>> process may be unjustified. >>> >>> That's exactly why I listed it as "secondary". There's little >>> point in debating it in a vacuum. >> >> My point was that it isn't even a secondary issue - it's >> not an issue at all afaict. > > I'm not sure whether Brian's definition of "secondary" and mine > are the same, which is why I keep saying "intertwined", > "interconnected", and "mutually dependent", although I I believe > we agree that anything that helps us sequence our consideration > of these issues is a good idea and that this one comes after > deciding among RS* models. My mental model was that the "secondary" issues could not usefully been resolved until after some or all of the "primary" issues were already settled. That's much easier than "mutually dependent" cases. > But "not an issue at all" is going > too far for at least two reasons. One is that people who have > been ignoring the "how we recruit and hire" question entirely > until we after the "RSE vs RSA" decision is made might then > review the plans for the chosen position and raise issues that > have not yet been identified, much less discussed. The other is > that once that decision is made and we have agreed-upon scope > and job description statements, we review the > recruitment/selection plan and discover that the number of > people who would meet the requirements and be willing to apply > or or take the position would be somewhat more rare than the > typical unicorn or flying pig. Certainly, but the question of whether the job is doable and whether candidates exist is separable from defining who sits in the search committee (IMHO). Brian > We would then have to figure out > something else, possibly revisiting already-closed decisions. > I think (and hope) the latter scenario is unlikely but not > unlikely enough to say "not an issue at all".> > john From nobody Thu Sep 24 17:38:24 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFED3A09D7 for ; Thu, 24 Sep 2020 17:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSJf_ThDiFZV for ; Thu, 24 Sep 2020 17:38:21 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90B63A09D5 for ; Thu, 24 Sep 2020 17:38:20 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id u24so1041713pgi.1 for ; Thu, 24 Sep 2020 17:38:20 -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=NL1o7yEXi88lPWfJq70TtWEPEeWUuR5m5h+o0jMvGcI=; b=ByxnA2h36JVAok2WSyw7SC7s0s+eALVgWKYFqVkaWZFZ7E4gPO1Gxfpvqs8zq/PiOc QX568BdkcutuNbjuotXssdTYwqaXdbV1UOIMJSc68GQyvJma72OthQrXQFBZN8XQPgne T+CmlUC5/zSMIwlp1tBBujay/XH+UReKQfbvriXuErA0qx/hMLlyQMEF+5XPOT2BnCUg 9Sw44VsmYRlkIobjw8bK6qITvDPahOAQ3vZdiNhTH1gL3EIBGQsfOqILKcE69bGLjLKZ GDkr3Py+z5z/dtz9fmAVUF0YNRwhU+gzkwh5BVoYpRp7LXWvpkjL862YSkntdJX53M0u iDGg== 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=NL1o7yEXi88lPWfJq70TtWEPEeWUuR5m5h+o0jMvGcI=; b=ikK4KbrXj0AVezofabpYrJ7UgJxHdY7ufRZTgPEL0Ty14NkaEcQXza4j30cqQrT9BQ 9OVjvIxM2Efkg96pwBF/H+lsi5cEdg+juuWgqa1notBwzGPVCayU1YTdsDPErtgS3AHw k9qN0QHnNUDh9GTg96+MhHZ0MQdM96UKFhpuIFX8DyzMRczNPFVUdmK4WvYbFd2FdiiT cathTI3Rkksdbl726fFbVZiFGMfN4XmtPXmuAkknCM44IVs313E+ut9Lrx7H7BCEav6r vuzLTAVsG+b2m3dZu+WX7UGIq6pNHH/9Ijg2fw0ENxGe7mPfxb0JKT1XJds4rtXXQXlo OdbQ== X-Gm-Message-State: AOAM532r5fUI+QVvOtg9AQ5PGTNuduMv5hM3LpBdGQPY+PJaW7y18525 KDNBVQ5bFKDfRcW8BYgKV9LpmdjDTss= X-Google-Smtp-Source: ABdhPJzv6kFxH5cKg4748bgqNeGhk+5GYIsYNoH1eVrrSiChEQYN6rK+H76vVnEgJNEBM0xLh0sOtQ== X-Received: by 2002:aa7:96c7:0:b029:142:38cd:13de with SMTP id h7-20020aa796c70000b029014238cd13demr1587672pfq.66.1600994300047; Thu, 24 Sep 2020 17:38:20 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id ih11sm375389pjb.51.2020.09.24.17.38.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2020 17:38:19 -0700 (PDT) To: Eric Rescorla , Eliot Lear Cc: rfced-future@iab.org References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> From: Brian E Carpenter Message-ID: <0748df22-e8d3-31dd-4d7d-0f634976948b@gmail.com> Date: Fri, 25 Sep 2020 12:38:15 +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] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 00:38:23 -0000 On 25-Sep-20 11:25, Eric Rescorla wrote: >=20 >=20 > On Thu, Sep 24, 2020 at 3:59 AM Eliot Lear > wrote: >=20 > Thank you, Brian.=C2=A0 I remind others, if you have objections to = the direction Mark suggested, place state them now.=C2=A0 Please also see= below. >=20 >> On 24 Sep 2020, at 03:35, Brian E Carpenter > wrote: >> >> On 21-Sep-20 23:49, Eliot Lear wrote: >>> >>> Well.=C2=A0 Apparently the chairs have found a way to gather cons= ensus on at least one point after all, just not in the way we had expecte= d ;-)=C2=A0 >>> >>> >>> >>>> My sense is that the best way forward is to document the agreed-= upon aspects as well as the open issues, and proceed (acknowledging that = we still have some difficult - and intertwined - discussions ahead of us)= =2E >>> >>> >>> Is there any objection to proceeding along the lines that Mark su= ggested? >> >> I found the easiest way to answer that was to try. The answer is t= hat I have no objection, but it may prove hard to separate the discussion= points. Anyway, here's my attempt at three lists (generally agreed, prim= ary issues, secondary issues). >> >> # Generally Agreed >> >> LLC legally & finanicially responsible for all contracts. >> >> RFC production and publishing are service contract(s). >> >> Streams have content control. >> >> A separate body debates strategy. >> >> This body must include stream representatives. >=20 >=20 > I'm not sure what this means. Suppose we have a WG as MT's version sugg= ests. What does this mean for the IETF stream in practice? Martin's draft says: "stream managers are expected to initiate discussion= or make proposals to the RFC Series Evolution program. To avoid conflict= s of interest, it is expected that stream managers will be active partici= pants - and not chairs - in this group." (My draft says essentially the s= ame.) I think we both assume that the IETF will name an individual as str= eam manager, since I doubt if any IETF Chair will want yet another job. >=20 >> >> >> Strategy body meetings are public. >=20 >=20 > Does anyone disagree with the list above?=C2=A0 Are there other thi= ngs upon which we agree? >=20 >=20 >> >> # Open Issues (primary) >> >> There is a figurehead and thought leader of some kind. >> >> This figurehead is a paid expert in technical publishing. >=20 > These first two don't have alternatives. Is the point that there is an = open issue about whether they are agreed as stated? Yes, I think so, because draft-thomson doesn't have this and the other tw= o drafts do. Regards Brian >=20 > -Ekr >=20 >> >> >> The expert is an advisor (RSA) vs an executive editor (RSE). >> >> The strategy body is open to all (rough consensus WG model) or has= defined membership (RSEB model). >> >> The strategy body has neutral chairs vs the RSE chairs it. >> >> The strategy body makes final decisions on strategy vs the RSE mak= es final decisions. >> >> Oversight/appeals remains with the IAB vs moves to ISOC vs moves t= o RSEB. >=20 >=20 >=20 >> >> >> # Open Issues (secondary) >> >> Single contract for REP vs separate contracts for production (RPC)= & publication. >> >> Contract monitor(s) outside LLC? >> >> Membership definition (RSEB model). >> >> Decider for hiring RSA/RSE? >> >> Search committee for hiring RSA/RSE? >> >> There is a new, separate Editorial Stream. >> >> What is strategic (pragmatic definition needed)? >=20 > Putting aside what is primary and secondary, do people agree with t= he list above?=C2=A0 Are there other differences that need to be document= ed, or are there other topics that need to be raised that have not been (= and this is not the last time I will ask that question)? >=20 > Eliot >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Thu Sep 24 17:45: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 D1DEC3A09E8 for ; Thu, 24 Sep 2020 17:45:47 -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 VnsKoVU1ND8Y for ; Thu, 24 Sep 2020 17:45:45 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 A90C93A09E5 for ; Thu, 24 Sep 2020 17:45:44 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id 77so898581lfj.0 for ; Thu, 24 Sep 2020 17:45:44 -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=4tDGrP4FJjVnjZESSh1RM25Ev/jvVE3L3bDryVJmATM=; b=GTJInwpg3BqQvtMA0KtTjP+fnXEUN+RSZ3xymASojRVdQGYFCYS56DhEalczDHpo0G vaIJFsIr3ldQIVaPMVCKjWTvAFvukGI0NWGo4OEp777xOM53tWsoFLI9R1ed4U3I337S h+36eVKF9TEWAbeRY9eASFMVW08jZJHQJlT1NRn03tFrmkjNhwjvyKyIVErMD9S9ItGX octApWHs8CDZTt7vW+ARm7fRDBQ60ZbZtBqpJ5x6zXnandm+W5IC3PKVCxKG+zsFuCgN 0Pj4iM4RdPGFSXwk7HLucdB5ZHfHpo3eJAnMHkWuRebKGA8HZ93a3TafVeAfSXctukUo SQWw== 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=4tDGrP4FJjVnjZESSh1RM25Ev/jvVE3L3bDryVJmATM=; b=dMJjZ831z9Oy0OyelMqKQ+SFAB3r+fD+sX0wrjBpUOIu3WqX6wo83a06qzIiYfdasV Kt3q1GjiKiLU1AU94JdLz+0CFFR/uWTY6IUqoj3VxCc6h2fTEWK4+aaGDI4xlue2IxGa Do7tfWEAv+HFlGYfAaupbv1ZFZPVt34DoPdd0LPiwXhhkgD6+DsY4efoVTDXSjcHqtiU euxWiFaG320tQN0BoENcG1b3s76YCUngB9VdMYQ/Y/WdaO/0Wd1ExWtNULL2D2PqCwiU ZOZ0wtHX9TZfWCkpyRaH2F7A3HAVe8C1ZRysp3PgHAdYt3Y2MlEzSku/y9alIAYL4NKO EcDA== X-Gm-Message-State: AOAM532swFm247PmlvQTYUXJ5eK5u6Me7hNWMxlUPi1+TSDiWMLC1cJ4 WHGOQm5h7qvhGPmlXoZwSvBCxEfOtVpoQHPW0mjWCw== X-Google-Smtp-Source: ABdhPJxZDPK+dBtZDFPx/pTpaPCSaTWEWq+LmYKDDU1PVptKDotTnXlRbDpwmyhd+M4D9A+hN0q2N+lrp+2I9fR72Ds= X-Received: by 2002:ac2:4e92:: with SMTP id o18mr454728lfr.543.1600994742766; Thu, 24 Sep 2020 17:45:42 -0700 (PDT) MIME-Version: 1.0 References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> <0748df22-e8d3-31dd-4d7d-0f634976948b@gmail.com> In-Reply-To: <0748df22-e8d3-31dd-4d7d-0f634976948b@gmail.com> From: Eric Rescorla Date: Thu, 24 Sep 2020 17:45:06 -0700 Message-ID: To: Brian E Carpenter Cc: Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000ee24ba05b018a222" Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 00:45:48 -0000 --000000000000ee24ba05b018a222 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 24, 2020 at 5:38 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 25-Sep-20 11:25, Eric Rescorla wrote: > > > > > > On Thu, Sep 24, 2020 at 3:59 AM Eliot Lear 40cisco.com@dmarc.ietf.org > wrote: > > > > Thank you, Brian. I remind others, if you have objections to the > direction Mark suggested, place state them now. Please also see below. > > > >> On 24 Sep 2020, at 03:35, Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > >> > >> On 21-Sep-20 23:49, Eliot Lear wrote: > >>> > >>> Well. Apparently the chairs have found a way to gather consensus > on at least one point after all, just not in the way we had expected ;-) > >>> > >>> > >>> > >>>> My sense is that the best way forward is to document the > agreed-upon aspects as well as the open issues, and proceed (acknowledging > that we still have some difficult - and intertwined - discussions ahead of > us). > >>> > >>> > >>> Is there any objection to proceeding along the lines that Mark > suggested? > >> > >> I found the easiest way to answer that was to try. The answer is > that I have no objection, but it may prove hard to separate the discussion > points. Anyway, here's my attempt at three lists (generally agreed, primary > issues, secondary issues). > >> > >> # Generally Agreed > >> > >> LLC legally & finanicially responsible for all contracts. > >> > >> RFC production and publishing are service contract(s). > >> > >> Streams have content control. > >> > >> A separate body debates strategy. > >> > >> This body must include stream representatives. > > > > > > I'm not sure what this means. Suppose we have a WG as MT's version > suggests. What does this mean for the IETF stream in practice? > > Martin's draft says: "stream managers are expected to initiate discussion > or make proposals to the RFC Series Evolution program. To avoid conflicts > of interest, it is expected that stream managers will be active > participants - and not chairs - in this group." (My draft says essentially > the same.) I think we both assume that the IETF will name an individual as > stream manager, since I doubt if any IETF Chair will want yet another job. > This text is sufficiently fuzzy that I think it's fine. What I don't think we have agreement on -- and I don't think we should do -- is to give them special privileges (e.g., be required for quorum, be the only people who can propose things, have a veto, etc.) -Ekr > > > >> > >> > >> Strategy body meetings are public. > > > > > > Does anyone disagree with the list above? Are there other things > upon which we agree? > > > > > >> > >> # Open Issues (primary) > >> > >> There is a figurehead and thought leader of some kind. > >> > >> This figurehead is a paid expert in technical publishing. > > > > These first two don't have alternatives. Is the point that there is an > open issue about whether they are agreed as stated? > > Yes, I think so, because draft-thomson doesn't have this and the other two > drafts do. > > Regards > Brian > > > > -Ekr > > > >> > >> > >> The expert is an advisor (RSA) vs an executive editor (RSE). > >> > >> The strategy body is open to all (rough consensus WG model) or has > defined membership (RSEB model). > >> > >> The strategy body has neutral chairs vs the RSE chairs it. > >> > >> The strategy body makes final decisions on strategy vs the RSE > makes final decisions. > >> > >> Oversight/appeals remains with the IAB vs moves to ISOC vs moves to > RSEB. > > > > > > > >> > >> > >> # Open Issues (secondary) > >> > >> Single contract for REP vs separate contracts for production (RPC) > & publication. > >> > >> Contract monitor(s) outside LLC? > >> > >> Membership definition (RSEB model). > >> > >> Decider for hiring RSA/RSE? > >> > >> Search committee for hiring RSA/RSE? > >> > >> There is a new, separate Editorial Stream. > >> > >> What is strategic (pragmatic definition needed)? > > > > Putting aside what is primary and secondary, do people agree with > the list above? Are there other differences that need to be documented, or > are there other topics that need to be raised that have not been (and this > is not the last time I will ask that question)? > > > > Eliot > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > > > > --000000000000ee24ba05b018a222 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 24, 2020 at 5:38 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
On 25-Sep-20 11:25, Eric Rescorla wrote:
>
>
> On Thu, Sep 24, 2020 at 3:59 AM Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org<= /a> <mailto:40cisco.com@dmarc.ietf.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Thank you, Brian.=C2=A0 I remind others, if you hav= e objections to the direction Mark suggested, place state them now.=C2=A0 P= lease also see below.
>
>>=C2=A0 =C2=A0 =C2=A0On 24 Sep 2020, at 03:35, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0On 21-Sep-20 23:49, Eliot Lear wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0Well.=C2=A0 Apparently the chairs have foun= d a way to gather consensus on at least one point after all, just not in th= e way we had expected ;-)=C2=A0
>>>
>>>
>>>
>>>>=C2=A0 =C2=A0 =C2=A0My sense is that the best way forward i= s to document the agreed-upon aspects as well as the open issues, and proce= ed (acknowledging that we still have some difficult - and intertwined - dis= cussions ahead of us).
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0Is there any objection to proceeding along = the lines that Mark suggested?
>>
>>=C2=A0 =C2=A0 =C2=A0I found the easiest way to answer that was to t= ry. The answer is that I have no objection, but it may prove hard to separa= te the discussion points. Anyway, here's my attempt at three lists (gen= erally agreed, primary issues, secondary issues).
>>
>>=C2=A0 =C2=A0 =C2=A0# Generally Agreed
>>
>>=C2=A0 =C2=A0 =C2=A0LLC legally & finanicially responsible for = all contracts.
>>
>>=C2=A0 =C2=A0 =C2=A0RFC production and publishing are service contr= act(s).
>>
>>=C2=A0 =C2=A0 =C2=A0Streams have content control.
>>
>>=C2=A0 =C2=A0 =C2=A0A separate body debates strategy.
>>
>>=C2=A0 =C2=A0 =C2=A0This body must include stream representatives.<= br> >
>
> I'm not sure what this means. Suppose we have a WG as MT's ver= sion suggests. What does this mean for the IETF stream in practice?

Martin's draft says: "stream managers are expected to initiate dis= cussion or make proposals to the RFC Series Evolution program. To avoid con= flicts of interest, it is expected that stream managers will be active part= icipants - and not chairs - in this group." (My draft says essentially= the same.) I think we both assume that the IETF will name an individual as= stream manager, since I doubt if any IETF Chair will want yet another job.=

This text is sufficiently fuzzy that I= think it's fine. What I don't think we have agreement on -- and I = don't think we should do -- is to give them special privileges (e.g., b= e required for quorum, be the only people who can propose things, have a ve= to, etc.)

-Ekr



>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Strategy body meetings are public.
>
>
>=C2=A0 =C2=A0 =C2=A0Does anyone disagree with the list above?=C2=A0 Are= there other things upon which we agree?
>
>
>>
>>=C2=A0 =C2=A0 =C2=A0# Open Issues (primary)
>>
>>=C2=A0 =C2=A0 =C2=A0There is a figurehead and thought leader of som= e kind.
>>
>>=C2=A0 =C2=A0 =C2=A0This figurehead is a paid expert in technical p= ublishing.
>
> These first two don't have alternatives. Is the point that there i= s an open issue about whether they are agreed as stated?

Yes, I think so, because draft-thomson doesn't have this and the other = two drafts do.

Regards
=C2=A0 =C2=A0 Brian
>
> -Ekr
>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0The expert is an advisor (RSA) vs an executive = editor (RSE).
>>
>>=C2=A0 =C2=A0 =C2=A0The strategy body is open to all (rough consens= us WG model) or has defined membership (RSEB model).
>>
>>=C2=A0 =C2=A0 =C2=A0The strategy body has neutral chairs vs the RSE= chairs it.
>>
>>=C2=A0 =C2=A0 =C2=A0The strategy body makes final decisions on stra= tegy vs the RSE makes final decisions.
>>
>>=C2=A0 =C2=A0 =C2=A0Oversight/appeals remains with the IAB vs moves= to ISOC vs moves to RSEB.
>
>
>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0# Open Issues (secondary)
>>
>>=C2=A0 =C2=A0 =C2=A0Single contract for REP vs separate contracts f= or production (RPC) & publication.
>>
>>=C2=A0 =C2=A0 =C2=A0Contract monitor(s) outside LLC?
>>
>>=C2=A0 =C2=A0 =C2=A0Membership definition (RSEB model).
>>
>>=C2=A0 =C2=A0 =C2=A0Decider for hiring RSA/RSE?
>>
>>=C2=A0 =C2=A0 =C2=A0Search committee for hiring RSA/RSE?
>>
>>=C2=A0 =C2=A0 =C2=A0There is a new, separate Editorial Stream.
>>
>>=C2=A0 =C2=A0 =C2=A0What is strategic (pragmatic definition needed)= ?
>
>=C2=A0 =C2=A0 =C2=A0Putting aside what is primary and secondary, do peo= ple agree with the list above?=C2=A0 Are there other differences that need = to be documented, or are there other topics that need to be raised that hav= e not been (and this is not the last time I will ask that question)?
>
>=C2=A0 =C2=A0 =C2=A0Eliot
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Rfced-future mailing list
>=C2=A0 =C2=A0 =C2=A0Rfced-future@iab.org <mailto:Rfced-future@iab.org>
>=C2=A0 =C2=A0 =C2=A0https://www.iab.org/mailman= /listinfo/rfced-future
>

--000000000000ee24ba05b018a222-- From nobody Thu Sep 24 17: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 409103A09EB; Thu, 24 Sep 2020 17:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj7c5eKo831o; Thu, 24 Sep 2020 17:47:32 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130523A09EA; Thu, 24 Sep 2020 17:47:32 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kLbta-0008zK-Lw; Thu, 24 Sep 2020 20:47:30 -0400 Date: Thu, 24 Sep 2020 20:47:24 -0400 From: John C Klensin To: Brian E Carpenter , Jay Daley cc: rfced-future@iab.org Message-ID: <5E9632B6B950FDDA6B68D07C@PSB> In-Reply-To: <8ea1a32e-c24d-9d58-b71c-bb9e82c22362@gmail.com> References: <5D23B9FBE0A1719F8C366655@PSB> <8ea1a32e-c24d-9d58-b71c-bb9e82c22362@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 00:47:33 -0000 --On Friday, September 25, 2020 12:30 +1200 Brian E Carpenter wrote: > On 25-Sep-20 10:26, John C Klensin wrote: >> (sorry -- posted from wrong address) >> >> --On Friday, September 25, 2020 09:40 +1200 Jay Daley >> wrote: >> >>>>> ARAICT, you have read those parts of the discussions >>>>> correctly. _However_ this is one of interaction issues. I >>>>> don't know how many others are like me in this regard, but >>>>> "how to recruit and hire X" is not a question I choose to >>>>> spend time thinking much about, much less commenting on, >>>>> before we have figured out whether we want and RSE or RSA >>>>> (and probably more than we have today about what those >>>>> roles mean). Phrases like "cart before the horse" come to >>>>> mind. Consequently, you've seen no comments on the subject >>>>> from me, and making inferences about agreement about either >>>>> process may be unjustified. >>>> >>>> That's exactly why I listed it as "secondary". There's >>>> little point in debating it in a vacuum. >>> >>> My point was that it isn't even a secondary issue - it's >>> not an issue at all afaict. >> >> I'm not sure whether Brian's definition of "secondary" and >> mine are the same, which is why I keep saying "intertwined", >> "interconnected", and "mutually dependent", although I I >> believe we agree that anything that helps us sequence our >> consideration of these issues is a good idea and that this >> one comes after deciding among RS* models. > > My mental model was that the "secondary" issues could not > usefully been resolved until after some or all of the > "primary" issues were already settled. That's much easier than > "mutually dependent" cases. Wfm, with the understanding that it is possible to reopen the primary/settled ones if the secondary ones behind them lead us into dead ends. >> But "not an issue at all" is going >> too far for at least two reasons. One is that people who have >> been ignoring the "how we recruit and hire" question entirely >> until we after the "RSE vs RSA" decision is made might then >> review the plans for the chosen position and raise issues that >> have not yet been identified, much less discussed. The other >> is that once that decision is made and we have agreed-upon >> scope and job description statements, we review the >> recruitment/selection plan and discover that the number of >> people who would meet the requirements and be willing to apply >> or or take the position would be somewhat more rare than the >> typical unicorn or flying pig. > > Certainly, but the question of whether the job is doable and > whether candidates exist is separable from defining who sits > in the search committee (IMHO). Yes. Who sits in the search committee is unrelated to whether the job is doable given that candidates exist. My point is (i) that this group can, at best, reach a working hypothesis about the existence of people who would meet the requirements and (ii) even if potential candidates exist, the composition of the search committee might determine whether or not they can be found (and convinced to become candidates). john From nobody Thu Sep 24 19:40: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 DD3873A0E62 for ; Thu, 24 Sep 2020 19:40: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, 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 QX4z7NesAGfE for ; Thu, 24 Sep 2020 19:40:35 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70B43A0E51 for ; Thu, 24 Sep 2020 19:40:35 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kLdey-0009eP-N0; Thu, 24 Sep 2020 22:40:32 -0400 Date: Thu, 24 Sep 2020 22:40:26 -0400 From: John C Klensin To: Brian E Carpenter , Eric Rescorla , Eliot Lear cc: rfced-future@iab.org Message-ID: <4B5480DC9795AB95594D3D89@PSB> In-Reply-To: <0748df22-e8d3-31dd-4d7d-0f634976948b@gmail.com> References: <1FCE39CC-BE2D-4731-A74F-7763D9A9E8A6@cisco.com> <040d01d68df7$2cbfe3a0$863faae0$@olddog.co.uk> <8A257619C61553A6C066CBA9@JcK-HP5> <00A0E339-F9D6-4C5E-850C-358971865B60@cisco.com> <37F48BB0-4E07-4BA6-A18B-3D4DDF31018C@cisco.com> <67020B58-2E2C-41E3-9B55-637ABB50B035@cisco.com> <0748df22-e8d3-31dd-4d7d-0f634976948b@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 02:40:37 -0000 --On Friday, September 25, 2020 12:38 +1200 Brian E Carpenter wrote: >... > I think we both assume that the IETF will name an individual > as stream manager, since I doubt if any IETF Chair will want > yet another job. IMO, it would be good to nail that down (rather than assume it) because any IETF Chair who would want more roles probably takes us down the path toward royalty (in the sense of those kings (and queens) we don't believe in). john From nobody Thu Sep 24 23:00: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 F18393A00E0 for ; Thu, 24 Sep 2020 23:00:52 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzPLC_Ci36La for ; Thu, 24 Sep 2020 23:00:51 -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 834F83A0412 for ; Thu, 24 Sep 2020 23:00:51 -0700 (PDT) Received: from xse159.mail2web.com ([66.113.196.159] helo=xse.mail2web.com) by mx114.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kLgmn-000F4P-MZ for rfced-future@iab.org; Fri, 25 Sep 2020 08:00:50 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4ByLqw1Fxvz18hp for ; Thu, 24 Sep 2020 23:00:44 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kLgmi-0004ZO-2A for rfced-future@iab.org; Thu, 24 Sep 2020 23:00:44 -0700 Received: (qmail 15406 invoked from network); 25 Sep 2020 06:00:43 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.46.182]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Sep 2020 06:00:43 -0000 To: John C Klensin , Brian E Carpenter , Jay Daley Cc: rfced-future@iab.org References: <5D23B9FBE0A1719F8C366655@PSB> <8ea1a32e-c24d-9d58-b71c-bb9e82c22362@gmail.com> <5E9632B6B950FDDA6B68D07C@PSB> 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: <3ea4edc5-8495-9726-3c8f-4ebe12a10057@huitema.net> Date: Thu, 24 Sep 2020 23:00:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <5E9632B6B950FDDA6B68D07C@PSB> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.196.159 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.159/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.159/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4ijstQkW85mqeDzJ463QSVyQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuED1Fn6BgYafFuB2yS1wiLW+42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGbXNqJfz6msVASTB+MD+1/pMA15fJuAAiBcDFrBhALEmniiG9nLbt4B4Ulv6G7WTyDo Oo70iqAlsD2ZyQe0MRcocwZz53KDf0UKLa44itxctQRRiI4FYjmNWKK4C97xdQjTPpuFqUUQz+mM 8JAD4ECWw1Aw2CaXIZxEGBn1EsZkohzd1TBXbJNvBC1nKO3+wSPbFq6uxUdCyEeZlt08+gXHNwnu HC9U4S9e934UytKaHFFfEoXm0/FPF8PR0w363lkSLezn0+2xsUkm4Ji1UE1wumHXledIN2OIQmiN VNnQ/HR6mMZiP8hyi9JD/oRrQtQcSyQwpbsYuxSOGTH6k0lfJmkP8s1HCfLKOW1F2ohPJ/AFMvX7 q8M4x6bP/gjzw0OgghQYwZVLClIproNi1WM01Bh4x4h9uYrmdPlyGg3lun80sIBTfGesZu6FzlJ8 P6r2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 06:00:53 -0000 On 9/24/2020 5:47 PM, John C Klensin wrote: > Yes. Who sits in the search committee is unrelated to whether > the job is doable given that candidates exist. My point is (i) > that this group can, at best, reach a working hypothesis about > the existence of people who would meet the requirements and (ii) > even if potential candidates exist, the composition of the > search committee might determine whether or not they can be > found (and convinced to become candidates). If we define the role in such a way that we end up needing a wild rara avis chase, then we probably are doing it wrong. There is a practical aspect there, that we should neither not define a role that we cannot recruit. -- Christian Huitema From nobody Thu Sep 24 23:18: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 563083A11CF for ; Thu, 24 Sep 2020 23:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt2TXzepbROM for ; Thu, 24 Sep 2020 23:18:31 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7F73A11D6 for ; Thu, 24 Sep 2020 23:18:30 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4ByMDN3V8LzyRD; Fri, 25 Sep 2020 08:18:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <5E9632B6B950FDDA6B68D07C@PSB> Date: Fri, 25 Sep 2020 08:18:28 +0200 Cc: Brian E Carpenter , Jay Daley , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 622707508.0011851-f8fe2a397a4c41693f66c748999826f4 Content-Transfer-Encoding: quoted-printable Message-Id: <2F72D661-C67C-49F9-9761-B2F075ED27D5@tzi.org> References: <5D23B9FBE0A1719F8C366655@PSB> <8ea1a32e-c24d-9d58-b71c-bb9e82c22362@gmail.com> <5E9632B6B950FDDA6B68D07C@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 06:18:33 -0000 On 2020-09-25, at 02:47, John C Klensin wrote: >=20 > even if potential candidates exist, the composition of the > search committee might determine whether or not they can be > found (and convinced to become candidates). =E2=80=A6 and even more so whether the job being carved out for them is = a meaningful one. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Sep 25 04:23: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 0C3473A08ED; Fri, 25 Sep 2020 04:23:03 -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 bKE-LaReY51y; Fri, 25 Sep 2020 04:23:01 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A44F3A1374; Fri, 25 Sep 2020 04:23:01 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kLloW-000Ct0-JZ; Fri, 25 Sep 2020 07:22:56 -0400 Date: Fri, 25 Sep 2020 07:22:51 -0400 From: John C Klensin To: Carsten Bormann cc: Brian E Carpenter , Christian Huitema , Jay Daley , rfced-future@iab.org Message-ID: In-Reply-To: <2F72D661-C67C-49F9-9761-B2F075ED27D5@tzi.org> References: <5D23B9FBE0A1719F8C366655@PSB> <8ea1a32e-c24d-9d58-b71c-bb9e82c22362@gmail.com> <5E9632B6B950FDDA6B68D07C@PSB> <2F72D661-C67C-49F9-9761-B2F075ED27D5@tzi.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Way forward and issue list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 11:23:03 -0000 --On Friday, September 25, 2020 08:18 +0200 Carsten Bormann wrote: > On 2020-09-25, at 02:47, John C Klensin > wrote: >>=20 >> even if potential candidates exist, the composition of the >> search committee might determine whether or not they can be >> found (and convinced to become candidates). >=20 > =E2=80=A6 and even more so whether the job being carved out = for them > is a meaningful one. I was assuming, perhaps incorrectly, that both the RSE and the RSA model, however we define the details, would be a sufficiently high-level position, requiring significant professional skills, that anyone would would accept a non-meaningful job would be someone we don't want. --On Thursday, September 24, 2020 23:00 -0700 Christian Huitema wrote: > If we define the role in such a way that we end up needing a > wild rara avis chase, then we probably are doing it wrong. > There is a practical aspect there, that we should neither not > define a role that we cannot recruit. But that takes us back to what I believe is the root of our problems. Few active IETF participants are expert in the fields in which we would expect those people to have expertise. Not only does "not expert" mean a list of technical skills, it includes enough contacts and experience to know who might be available and what would entice them to come work with the IETF community or to want to accept a position under an IETF LLC contract. Even when we went through the process that recruited Heather, we contacted people who seemed to have the right qualifications who didn't want anything to do with us. So, unless we set the requirements at, e.g., "was author on at least one RFC" and/or "published an article related to networking technology somewhere", we may not know whether we can actually recruit for a role we define until we try it. john From nobody Sat Sep 26 14:17: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 E55923A0AF1 for ; Sat, 26 Sep 2020 14:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 oKXRK9Q12h5g for ; Sat, 26 Sep 2020 14:17:01 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 B0E483A0AE6 for ; Sat, 26 Sep 2020 14:17:01 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id d20so6684613qka.5 for ; Sat, 26 Sep 2020 14:17:01 -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=oOFBUqbBRzMFFZ5HhSmY8KlLKW5dWXTQcbw4PP6hq7Y=; b=ucYcuA2gF57tNODkJuaR8lMOTX7AnlZyG7sKCUgTgBQX+uSLGgd1lUjIdC4ElciCcq RE7eqzGMkJ8eJxzpWpG/P3tlm+budGj8MqFqsEaYrxSUxmG2EO6At9CjrIWB8F0DHVQg LhMY5bynyYt04NMbxFk3Ww2jyzKt+hIcvR8vP0/x6WR+7U5mTGNmUmND0h5byhecJ1Rv 9jinUIz69FDi7EU3sUa/RyINTKHvNHufUWOghGUNQyltTEeYEGQGTP6ho88s16+zWvjU 6Sz1afiy5GCvquvswOQbsuDzO/3JZyGP+GVB7EUUG6hxHE8v9OZFNyPOkHenLSMN3AnV H2Hg== 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=oOFBUqbBRzMFFZ5HhSmY8KlLKW5dWXTQcbw4PP6hq7Y=; b=NpG0WrizOliKPofDfis2NeDr+0z1j0d5FVGjw4rOWdzYYAgd+fuEcuZuQLFDVq6kR0 I8OA+N8D8nQoEu2yjl7CnBU+94q0A8Kptjq6Ium7WTkAaOfrDq9OC4LZjUmqZSErTHrO 7i4ZLmSrDGParpO28ETV5KYFg/conuz9rm2v6lMekU+5KlCBa9tNc4fH4wNrHo+gpMmb VQoDHV7s4qRCMVcRCe2CFqqU9hGTQ/ZyTQ307zBCZmcWq7UhSI6biJ8lqoK+WBWi2trj Wg1MmH9aH5EfVjFnVWICw/QbBPYHfTnUFS/9z/dWP3rLXD7Ujp0Kpd+TvmVRoukywZVc S+fw== X-Gm-Message-State: AOAM531InevFsegVHAFXyen/rTTbACA29DniHdOdgxgksndT8E+qoctK uDwbdxnt+DhhhZELPiYDu+eBHlhjVELoVcBI8K4= X-Google-Smtp-Source: ABdhPJwGs20xOKoACbnnMpABF3MDSQHV08EPokwlaSseYY36/6eU4cQbBUYQeKLFbv0NVIKPbSswAg== X-Received: by 2002:a05:620a:1247:: with SMTP id a7mr5980397qkl.154.1601155020281; Sat, 26 Sep 2020 14:17:00 -0700 (PDT) Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id l5sm5509096qtc.28.2020.09.26.14.16.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Sep 2020 14:16:59 -0700 (PDT) To: John C Klensin , Brian E Carpenter , Christian Huitema , rfced-future@iab.org References: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.com> <431C046D76BEA50F4FB7C8E7@JcK-HP5> From: Michael StJohns Message-ID: <4d7e4ae8-bef4-70db-522c-7ebc96d34cee@nthpermutation.com> Date: Sat, 26 Sep 2020 17:16:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <431C046D76BEA50F4FB7C8E7@JcK-HP5> Content-Type: multipart/alternative; boundary="------------CE3B6F7DF285D67ED5B8885B" Content-Language: en-US Archived-At: Subject: [Rfced-future] Questions and closed groups X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 26 Sep 2020 21:17:04 -0000 This is a multi-part message in MIME format. --------------CE3B6F7DF285D67ED5B8885B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi - I left this to sit for a while - possibly too long, but I wanted to see if anyone would look deeper than "new stream".  Mostly no. Here's the deal.  In the end, what we appear to be arguing about is "who decides".  With Brian's note and a non answer from Martin what I have here is: * Mike - Authored by RSE with RSEB and community input (e.g. mostly paid work - other ), Approved for publication by RSEB, published in the Editorial Series. * Brian - Authored by anyone with perhaps some RSA input and guidance, consensus of the WG, consensus determined by the WG chairs, approved for publication by the ISE, published in the Independent stream. * Martin - Authored by anyone with little or no professional guidance, consensus of the program members, consensus determined by the IAB program chairs, approved for publication by the IAB, published in the IAB stream. For Brian, that leads to the the questions of who appoints the WG chair(s) (specifically whether or not the ISOC appointed chair model is viable),  whether the IETF consensus model will work within the ISOC structure, and finally, how the current ISE model will interact with these documents. For Martin, this appears to be exactly the model we had in the interregnum between Bob and Joyce stepping down, and before Heather was hired, except there's no professional supervision of the process (e.g. even though we had interim RSE's, they had their predecessors to lean on).   This model is pretty much  "the IAB decides" and I'm not sure that model will continue to work. Actually, I think we have a worked example where this isn't working. For both of these I'm concerned about the WG chair appointments - they appear to be the weak spots as someone with Chair power can make or break a process.  The chair appointment process for both of these proposals is also concentrated in a single group. I'd like to direct the groups attention to exactly who the authors were for the documents written about the RFC series since Bob stepped down.  AFAICT, none of  these were the products of working groups, nor were random author submissions, but instead were documents internally generated by mostly the IAB, or folks that have been involved in the leadership, or more lately, by (a) design team(s) stood up by the RSE for a specific purpose.   My understanding is that most of those documents required at least some arm twisting (or invoking guilt) to get the editors to accept the work. Going forward, I expect that similar documents will require similar levels of effort.  My thoughts about that are to make sure there's someone being paid to author those documents when they occur rather than depending on finding a) the right level of interest, b) the right level of expertise, and c) the actual availability of time to author those documents. Last - let me tag one of EKRs hobby horses - closed groups.     In each of the publication models I've listed above, the ultimate authority for publication approval rests either with an individual, or with a closed group.  In Martin's model, that's the IAB.  In my model that's the RSEB. Both of these groups use (would use for the RSEB) a voting model for approving publication.  The main difference is that the RSEB would be selected for its proprietary interest in the publication process (e.g. the stream managers) or according to a publication heavy set of requirements submitted to the Nomcom.  In Martin's model, the chairs are selected by the IAB which treats such selections as personnel actions not subject to explanation, and the IAB exercises veto over the output of the group through its control of the IAB stream. The IETF community has a lot of closed groups - IESG, IRSG, IAB, IETF Trust, LLC Board, and for that matter the model for research groups is that they MAY be closed. Oh yes, most of the IAB programs appear to be mostly closed. Decisions for publication in 3 of the 4 streams are made by closed groups.    For the IAB as much as 1/2 (guessing here - didn't count) of the IAB stream documents originate within the IAB itself and are not subject to mandatory external review prior to publication.   Irrespective of where the documents originate, a closed group makes the final decisions on publication for all but the documents in the independent stream. In the above, I join strongly with John's comments included below, especially with the inability to guarantee sufficient expertise on the IAB to cover these responsibilities. Later, Mike On 9/19/2020 11:55 PM, John C Klensin wrote: > > --On Sunday, 20 September, 2020 09:31 +1200 Brian E Carpenter > wrote: > >>> The IAB has handled a number of such documents in the past, >>> so in practice that part seems to work. But maybe I am wrong. >>> Does anyone remember documents for which this caused a >>> tension? >> I agree, but it was a pragmatic choice because no other >> suitable stream existed (as Heather said on a number of >> occasions in my hearing). Indeed, 20+ years ago such documents >> were simply published by the RFC Editor on their own account >> (e.g. RFC825, RFC1111, RFC1543, RFC2223) so this stream would >> be a revival of that system. > Yes and no... and that takes us back to interactions among > different questions. Back when it was "simply published...", > the RFC Editor didn't need to ask anyone for approval. For > better or worse, there is no analogy for that in the Stream > model because, while I can't remember an explicit rule, authors > approving their own documents is clearly considered to be in bad > taste. The Independent Stream comes closest, but were the > person who holds the ISE role to write a document and then > publish it without consulting anyone else, I assume we'd be > fairly unhappy. > > I do remember discussing whether the RSE should be allowed to > publish documents directly in the RFC 4844 timeframe but don't > remember the reasons why a "no" decision was made -- Joel or > others might remember. I suspect it was because the IAB > considered review and approval to be part of its oversight > responsibility. > > Sometimes, the IAB has basically been passive, doing a quick > review, maybe asking for community comment, and then going ahead > and publishing. Other times, it has acted as if those really > were its documents and they should not be published without > strong IAB consensus (whether the IAB actually had the relevant > expertise or not). I suggest that, if we think what got us here > was a result of the IAB intervening inappropriately, then having > the IAB as document approver is not a wildly good idea. If the > RSE-replacement is going to be an employee or contractor of a > contractor or just an advisor, it is less clear to me why we > need such a stream... at least unless we can set (and keep to) > rather high requirements for expertise in whatever WG or > committee is actually running the show. > > best, > john > --------------CE3B6F7DF285D67ED5B8885B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi -

I left this to sit for a while - possibly too long, but I wanted to see if anyone would look deeper than "new stream".  Mostly no.

Here's the deal.  In the end, what we appear to be arguing about is "who decides".  With Brian's note and a non answer from Martin what I have here is:

  • Mike - Authored by RSE with RSEB and community input (e.g. mostly paid work - other ), Approved for publication by RSEB, published in the Editorial Series.
  • Brian - Authored by anyone with perhaps some RSA input and guidance, consensus of the WG, consensus determined by the WG chairs, approved for publication by the ISE, published in the Independent stream.
  • Martin - Authored by anyone with little or no professional guidance, consensus of the program members, consensus determined by the IAB program chairs, approved for publication by the IAB, published in the IAB stream.

For Brian, that leads to the the questions of who appoints the WG chair(s) (specifically whether or not the ISOC appointed chair model is viable),  whether the IETF consensus model will work within the ISOC structure, and finally, how the current ISE model will interact with these documents. 

For Martin, this appears to be exactly the model we had in the interregnum between Bob and Joyce stepping down, and before Heather was hired, except there's no professional supervision of the process (e.g. even though we had interim RSE's, they had their predecessors to lean on).   This model is pretty much  "the IAB decides" and I'm not sure that model will continue to work.  Actually, I think we have a worked example where this isn't working.

For both of these I'm concerned about the WG chair appointments - they appear to be the weak spots as someone with Chair power can make or break a process.  The chair appointment process for both of these proposals is also concentrated in a single group.


I'd like to direct the groups attention to exactly who the authors were for the documents written about the RFC series since Bob stepped down.  AFAICT, none of  these were the products of working groups, nor were random author submissions, but instead were documents internally generated by mostly the IAB, or folks that have been involved in the leadership, or more lately, by (a) design team(s) stood up by the RSE for a specific purpose.   My understanding is that most of those documents required at least some arm twisting (or invoking guilt) to get the editors to accept the work.

Going forward, I expect that similar documents will require similar levels of effort.  My thoughts about that are to make sure there's someone being paid to author those documents when they occur rather than depending on finding a) the right level of interest, b) the right level of expertise, and c) the actual availability of time to author those documents. 

Last - let me tag one of EKRs hobby horses - closed groups.     In each of the publication models I've listed above, the ultimate authority for publication approval rests either with an individual, or with a closed group.  In Martin's model, that's the IAB.  In my model that's the RSEB.  Both of these groups use (would use for the RSEB) a voting model for approving publication.  The main difference is that the RSEB would be selected for its proprietary interest in the publication process (e.g. the stream managers) or according to a publication heavy set of requirements submitted to the Nomcom.  In Martin's model, the chairs are selected by the IAB which treats such selections as personnel actions not subject to explanation, and the IAB exercises veto over the output of the group through its control of the IAB stream.

The IETF community has a lot of closed groups - IESG, IRSG, IAB, IETF Trust, LLC Board, and for that matter the model for research groups is that they MAY be closed. Oh yes, most of the IAB programs appear to be mostly closed.   Decisions for publication in 3 of the 4 streams are made by closed groups.    For the IAB as much as 1/2 (guessing here - didn't count) of the IAB stream documents originate within the IAB itself and are not subject to mandatory external review prior to publication.   Irrespective of where the documents originate, a closed group makes the final decisions on publication for all but the documents in the independent stream.

In the above, I join strongly with John's comments included below, especially with the inability to guarantee sufficient expertise on the IAB to cover these responsibilities.

Later, Mike



On 9/19/2020 11:55 PM, John C Klensin wrote:

--On Sunday, 20 September, 2020 09:31 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:


The IAB has handled a number of such documents in the past,
so in practice that part seems to work. But maybe I am wrong.
Does anyone remember documents for which this caused a
tension?

I agree, but it was a pragmatic choice because no other
suitable stream existed (as Heather said on a number of
occasions in my hearing). Indeed, 20+ years ago such documents
were simply published by the RFC Editor on their own account
(e.g. RFC825, RFC1111, RFC1543, RFC2223) so this stream would
be a revival of that system.

Yes and no... and that takes us back to interactions among
different questions.  Back when it was "simply published...",
the RFC Editor didn't need to ask anyone for approval.   For
better or worse, there is no analogy for that in the Stream
model because, while I can't remember an explicit rule, authors
approving their own documents is clearly considered to be in bad
taste.  The Independent Stream comes closest, but were the
person who holds the ISE role to write a document and then
publish it without consulting anyone else, I assume we'd be
fairly unhappy. 

I do remember discussing whether the RSE should be allowed to
publish documents directly in the RFC 4844 timeframe but don't
remember the reasons why a "no" decision was made -- Joel or
others might remember.  I suspect it was because the IAB
considered review and approval to be part of its oversight
responsibility.  

Sometimes, the IAB has basically been passive, doing a quick
review, maybe asking for community comment, and then going ahead
and publishing.  Other times, it has acted as if those really
were its documents and they should not be published without
strong IAB consensus (whether the IAB actually had the relevant
expertise or not).  I suggest that, if we think what got us here
was a result of the IAB intervening inappropriately, then having
the IAB as document approver is not a wildly good idea.  If the
RSE-replacement is going to be an employee or contractor of a
contractor or just an advisor, it is less clear to me why we
need such a stream... at least unless we can set (and keep to)
rather high requirements for expertise in whatever WG or
committee is actually running the show.

best,
    john


--------------CE3B6F7DF285D67ED5B8885B-- From nobody Sun Sep 27 00:40: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 C01023A09A8 for ; Sun, 27 Sep 2020 00:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.213, 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 9_wORZNF3Sde for ; Sun, 27 Sep 2020 00:40:17 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400132.outbound.protection.outlook.com [40.107.140.132]) (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 02B963A09A4 for ; Sun, 27 Sep 2020 00:40:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ci64JvkgwGiA5a1YGptXXPO4Hw1jH81llRqA7Af7fid1/Xl/9TWdBREFAlRWooPlnjoco6Id7SZMrlnOMcXLHXTsu1j3yI6kRz6nmWF3RsOummLLb4C1O1iEQJ7nTzU3j6Js2Jkc9A/aQr/KCZfGgtBfTewPQ5BiDX7D7LXiiVDmrZVlAcT+wCDBFOtbiQLX9mSH0aRipZ108Xt4yk/qcUiDgsm7yoN80k9HmwcsLTDT6Gi+42+j3Go7T8J5A4nhvT61Qre54ptPfYpQZooL6U2ftScsg+9nbJ/yMjhNamRBDgsSs8luI51di0N5Kdxfz3QIE6SWdAqBzcofEHLOyg== 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=8Azb8dui1GSr2LKw3I8eCK/Xo/EOKENiCDaVm+wG6U4=; b=boRAs+PjBu5bdfhIdHxrPjDIbssqze4pCBTGr7WjP1Xcde2thoemfXF4AQSHz+vyg+V5/RNerIhjK9nMwWrvCT/ERuVH7YhMSn7MazBqY6soV62DUkUW1AheG+bWmh805gex5OUdt7TdkBMcGRTf4WFVGoqctqEAbw5YRm9OiKyfbsZr2IqHSrqT4SifiUmdmRbKBpB6q5Nz0CKazBi4hEpcv8+GE8dBZ3XdYWZzQEfTM11Pu0IBkzxWRBI45TkjQsL0crX5WM+msbnBzqHSmB4EG6BHJH22ErPHqCWkRhhb9qwINRgh+KxOQiiRejVemV0U+2bTN+PG30da4Q/wTw== 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=8Azb8dui1GSr2LKw3I8eCK/Xo/EOKENiCDaVm+wG6U4=; b=UQ8wDawYtywbMKScx53EYE6/3VUUr5vxWer3wKGwhQ6wnRdptGWP5/5hfsPvk+iyzP6cR+V+y4q1WenkTuJvVL8etXEQIFLWZUlzSM4Rb9zJiRlQuRKRWnVDJufwbAPqnUPYzDf/1N6LYd1TyrV2or8StGYu5Oo/qtuueuvmpuE= 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 OSAPR01MB1778.jpnprd01.prod.outlook.com (2603:1096:603:2f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.25; Sun, 27 Sep 2020 07:40:14 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::50b8:6d53:1b35:2ef7]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::50b8:6d53:1b35:2ef7%6]) with mapi id 15.20.3412.026; Sun, 27 Sep 2020 07:40:14 +0000 To: rfced-future@iab.org References: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.com> <431C046D76BEA50F4FB7C8E7@JcK-HP5> <4d7e4ae8-bef4-70db-522c-7ebc96d34cee@nthpermutation.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <5e005700-9c35-e3cd-7500-8dda49a8d0b9@it.aoyama.ac.jp> Date: Sun, 27 Sep 2020 16:40:12 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 In-Reply-To: <4d7e4ae8-bef4-70db-522c-7ebc96d34cee@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TY1PR01CA0152.jpnprd01.prod.outlook.com (2603:1096:402:1::28) 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] (114.182.253.12) by TY1PR01CA0152.jpnprd01.prod.outlook.com (2603:1096:402:1::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20 via Frontend Transport; Sun, 27 Sep 2020 07:40:13 +0000 X-Originating-IP: [114.182.253.12] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cacc85d5-9100-4375-cac9-08d862b8923a X-MS-TrafficTypeDiagnostic: OSAPR01MB1778: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AR25tDNVljXdSsFXi92D2ZPeusZlTA3K16vmdcsJjrX8WQNiNX8US5/TIa+htraCbkxJFto68KKqjWVlTvERBjbDQye5cvgC80Wd13g/TkzaLPlixHngPpDykpdqA7jbVptXii/De/1y0XUc/QjJfcVGu0H23PwA5SNXIeLMSjMz5tg3cTe20jV4NHnAtsUNz3Nb4Eqsa6y3mpLYC0agZksaTpXzSBxClxU3KS76OsVWgpwIM14ZGbgMz6kK1DDANY2FJ4/DSq0PqGq/j+BgzYZkJEa9Q6DJRgNIqnX0HI21Xs5iPHA5UNyFkpWPkdb1KFkV4DodzdXi+2/UPwvIP800LQHMqO1XxIEnK1n8ycM632snQVnLfUCBJ9hA+99hQjgGWhwRIvcAb5imwNxrT+WclUqeq9GbKSUhpkjX6X735JQjtAPTWeG651BAbcLf 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; SFS:(346002)(136003)(396003)(376002)(366004)(39840400004)(53546011)(83380400001)(786003)(16576012)(8676002)(4744005)(66946007)(31696002)(2906002)(316002)(478600001)(16526019)(26005)(36916002)(6916009)(186003)(52116002)(5660300002)(31686004)(86362001)(66556008)(66476007)(8936002)(6486002)(2616005)(956004)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: A84wUBP0ece+TwBfa/TMpOu5yQMg22rcDUKx6BH43+nZvrgoBONM2HNy/j7uZdstPjGskBBy/G9JUOMdq3pMXYx+vdl6y5YBsyKEn20l32t3VXWeh++mtWYlHh9nBj4yq7oakZ+ZfNSnFNfK0bbrLBCLS6aIhBxg5WHUFzdYJMtBP5zarjwpvtmcl3qIy9SvOtf5fXtXhNHuTqZb/YIQkHdGGhIRdSLaWLqlGRLTw8050n5o6ySC8xcTlDK3SJrd/vJkXK6X7xVZzhN+NDS76uwTiyvqsrPiZrirP/3pc6N0X6XGoiwhNLE+mPI7y6cN4aYo2HTOJBWyP1ROBGJ4nl8zqudZhNKKsp5DGv39kbWiCxJkrcaB5/jLztNTmxI7jKKr+fy8nyHiKpUF78IwE+Qj2SiqO38ZjgzmnTkzpb/4bZKXd+Mbr4AsnSVbsX9SPX5XwbK9Sbv5P14eSdKtEdf+G898rXQTa+JY2yZ17TWYatcX2hL2UxDuCK9hBEL6/E2OVV+awy7lEti/K8RRXzDIgpdZNHTwhYGlu1RrIsK90IAQm31Um0jfAOVRMxY0numuaJjdi136OgnV8W4pcUJRieIi5H/yG1jDvqBsoM6ZznRiwLdruQnwNT4+VbqmzdFFTGKktfW3Uf6ndkDlsw== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: cacc85d5-9100-4375-cac9-08d862b8923a X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2020 07:40:14.1085 (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: kZmzpeYgzuMNHD+5tMN9nI2R41BeLf74oGuh7HvCF72J9c8nfknNITTj+OgXK0spOstsWdQwSVnvX7EpaNBoeA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB1778 Archived-At: Subject: Re: [Rfced-future] Questions and closed groups X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 27 Sep 2020 07:40:19 -0000 Hello everybody, On 27/09/2020 06:16, Michael StJohns wrote: > The IETF community has a lot of closed groups - IESG, IRSG, IAB, IETF > Trust, LLC Board, and for that matter the model for research groups is > that they MAY be closed. Oh yes, most of the IAB programs appear to be > mostly closed. Decisions for publication in 3 of the 4 streams are made > by closed groups.    For the IAB as much as 1/2 (guessing here - didn't > count) of the IAB stream documents originate within the IAB itself and > are not subject to mandatory external review prior to publication. > Irrespective of where the documents originate, a closed group makes the > final decisions on publication for all but the documents in the > independent stream. The ISE in general has a lower bar, but isn't s/he essentially a closed group of one? Regards, Martin. From nobody Sun Sep 27 12:47: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 41F2E3A0AC8 for ; Sun, 27 Sep 2020 12:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, 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 MHWAHig2vSfM for ; Sun, 27 Sep 2020 12:47:45 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE643A011B for ; Sun, 27 Sep 2020 12:47:45 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id g29so6396656pgl.2 for ; Sun, 27 Sep 2020 12:47:45 -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=3FMSPdEdAeTtnFxpxugWy7tid1dUjDdHLHKwCEfaypo=; b=Qh8niiCUrbnPkoejc4HnYdkfcTCnzmOPiaQ5Ka2/L89Jh8kFSH4MokQHi6tc/r2VbS bmrLFbwiGvQHDwBkDtdH8jMzMRvQ99NVs7/L/8HyAwFp5TN0our4P5Y0OgDJg5fLp+uo MKduUWECphAg1Rh+5U58+34GFcbP8RjCi+3MZhapgbLfY14SoTmvpvVYws16Y7oqhMV8 jJgeQTfbRJ6V7SRsMu+aUALWac0pPXOviZMR/FfjR35bZqTKcOGh8UKft518M2nt+wHx c3RLupyO49T0X2ga7E2MAz0cxj/LnY3XKe7Yb6piirTq+Sx8xxbDdQriq58VGqtQjpcm 1lpQ== 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=3FMSPdEdAeTtnFxpxugWy7tid1dUjDdHLHKwCEfaypo=; b=A4UWk2vgJeSz4lqGpukODsYOqD+pZlgRo1b9PHb8Xd3g1lL7nUOJ190KBjX4SQSjsS gQ3EQ5Pe8f2h9i369MQ6UpND4mxKQJ0Q0HRQWDZ6CeiX0tBnVTgZyjDbGxmniekwH9ew ldL/szk9s+gJ2Uo1mkmzHXcehPPltpF1OcdKoWoSgmjnNk5TGQ0QfLdsAw8RUIlNtddj P1g6NKrpa2o+MFlSPy47mMecMKARso1nGLKwRSqrv4V5J5TaQynRVX7QJDYRnQJYFT8k kvTDuJCWlaa359FsGQH4hgJdY8aSYrSfoImpUccijXaVszj3bCDGCzX/kBaHGk3hUzYF rbRw== X-Gm-Message-State: AOAM533XHRml0wuaHqtyaPWgAWfuobe89gcLir/pnyb68oHUNSJcbuqv 9Y6JWkSM11r6H/1QsSfiTdnRVumJa5V9ig== X-Google-Smtp-Source: ABdhPJyJzDLh9r7wr9VxUaDgvjEbiMV6QXqVWQxZ3qTZSPcO8Tbhq8Ru6JC+ruv1ZjUVIRulUjrXQw== X-Received: by 2002:a17:902:6b0b:b029:d2:62fd:97bc with SMTP id o11-20020a1709026b0bb02900d262fd97bcmr8380870plk.2.1601236063982; Sun, 27 Sep 2020 12:47:43 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id c68sm8985831pfc.31.2020.09.27.12.47.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Sep 2020 12:47:43 -0700 (PDT) To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , rfced-future@iab.org References: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.com> <431C046D76BEA50F4FB7C8E7@JcK-HP5> <4d7e4ae8-bef4-70db-522c-7ebc96d34cee@nthpermutation.com> <5e005700-9c35-e3cd-7500-8dda49a8d0b9@it.aoyama.ac.jp> From: Brian E Carpenter Message-ID: <74f1f6f6-7613-e7df-5bfa-15703b4b795b@gmail.com> Date: Mon, 28 Sep 2020 08:47:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5e005700-9c35-e3cd-7500-8dda49a8d0b9@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Questions and closed groups X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 27 Sep 2020 19:47:46 -0000 On 27-Sep-20 20:40, Martin J. D=C3=BCrst wrote: > Hello everybody, >=20 > On 27/09/2020 06:16, Michael StJohns wrote: >=20 >> The IETF community has a lot of closed groups - IESG, IRSG, IAB, IETF = >> Trust, LLC Board, and for that matter the model for research groups is= =20 >> that they MAY be closed. Oh yes, most of the IAB programs appear to be= =20 >> mostly closed. Decisions for publication in 3 of the 4 streams are mad= e=20 >> by closed groups.=C2=A0=C2=A0=C2=A0 For the IAB as much as 1/2 (guessi= ng here - didn't=20 >> count) of the IAB stream documents originate within the IAB itself and= =20 >> are not subject to mandatory external review prior to publication.=20 >> Irrespective of where the documents originate, a closed group makes th= e=20 >> final decisions on publication for all but the documents in the=20 >> independent stream. >=20 > The ISE in general has a lower bar, but isn't s/he essentially a closed= =20 > group of one? No. You are overlooking the ISEB (Independent Series Editorial Board). True, the ISE's decision is final, but I've been an ISEB member for quite a few years, and the Editor has always consulted the Board whenever there was a tricky issue, and used it as a (non exclusive) source of reviewers. A difference compared to the IETF review process is that it more closely resembles an academic peer review process. The reviews aren't published, for example. But they usually aren't blinded, either (i.e. the authors usually know who the reviewers are). Getting back to Mike's message: >> Brian - Authored by anyone with perhaps some RSA input and guidance, c= onsensus of the WG, consensus determined by the WG chairs, approved for p= ublication by the ISE, published in the Independent stream. My draft doesn't say that ("ISE"), but leaves it rather open. In fact I t= hink this stream should be owned by what I called the RSAWG, so the RSAWG= chairs would declare consensus to publish. I don't think that this would= be a busy stream, except for an initial bunch of documents. Brian From nobody Mon Sep 28 09:25:33 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0383A12B1 for ; Mon, 28 Sep 2020 09:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, 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 2P1JAyoBZcj9 for ; Mon, 28 Sep 2020 09:25:30 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2DD3A12AF for ; Mon, 28 Sep 2020 09:25:29 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id v54so1199809qtj.7 for ; Mon, 28 Sep 2020 09:25:29 -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=bpVreP1zwRGaJEAg5+A/tE8d2yGJSEHfJJx4BguBDgw=; b=vhYWryZCpOqMGGZvndqTKWgLYSe99sFXvkJPVzcKcTocmQz9tAYiQlszJx+OuRyN46 1A1TmBD9R/miLtWQpUMmbcEfZb7x85cdHsReFua5vZoVmKUqnQ3xacUFexL2ygk9Ab03 uiLKHKEGIin3G9PYFlRSJTqge7wKb9vbM0bB9TX4wVjkVEzYP0nZEAczMToQuWnuNh4Y KhP92jDukAf4H/tOYEsc/XSHLj2kj6d366VvqaZ0M06xU/wIJRbiTmVGojRK8RxhUMnk AvH+6Qg3Frv8TvdL2+KtkUogIpulj+imTUQIiebjT59YC+iGjyX56mcKB0zt0jP9GAqI 11iw== 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=bpVreP1zwRGaJEAg5+A/tE8d2yGJSEHfJJx4BguBDgw=; b=RzI3OzHAGkeeAqEkTh753hBt9zowEcO0/UF3s9gtkPrNxEi6gQTb1mQigb8iY9Ahlu KqvA3iKLB71XG42ynDYEZwxvYhtTslvsHftpyWlMPYeaSfSsO6bIIMDAdDeg7sUVzR5w ioje7U22eHmJngHcLOhXqzVPk1UrdrV2V0PxiECkYmOBN2Wujz0G+x+NrbBKgQZPdiIA HPFbZhDnBEaoJaVkj2vb+PX4USx9ElhTcbE7l5iyTAMbOLZlgBNcmLhzpAf641/+S1KZ S0lkklzldXtcaWhfFFzbqtHKtDeKpxSv+l5u1WXUK06JdNbz7WURaElpvDV4S4o9sqL/ MW5Q== X-Gm-Message-State: AOAM5323YMhBw5ss5kUfF5QobN8JF+BlfLr7G/llMwYQhijgoNLOZivx RjgfHpkPqrnm+/TZqzDM5Q5HK9Po52GMEm/wjCw= X-Google-Smtp-Source: ABdhPJyjujtaQURfiXZfO74bFxlZ48fephmHG5w7BvrKLJ08VIcBBoDVTEz9SzP0RiJL1JhiLPfalg== X-Received: by 2002:ac8:5d04:: with SMTP id f4mr1680099qtx.290.1601310328573; Mon, 28 Sep 2020 09:25:28 -0700 (PDT) Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id z74sm1450258qkb.11.2020.09.28.09.25.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Sep 2020 09:25:28 -0700 (PDT) To: rfced-future@iab.org References: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.com> <431C046D76BEA50F4FB7C8E7@JcK-HP5> <4d7e4ae8-bef4-70db-522c-7ebc96d34cee@nthpermutation.com> <5e005700-9c35-e3cd-7500-8dda49a8d0b9@it.aoyama.ac.jp> <74f1f6f6-7613-e7df-5bfa-15703b4b795b@gmail.com> From: Michael StJohns Message-ID: Date: Mon, 28 Sep 2020 12:25:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <74f1f6f6-7613-e7df-5bfa-15703b4b795b@gmail.com> Content-Type: multipart/alternative; boundary="------------943139CC65CCBD6B68D861FD" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Questions and closed groups X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 16:25:32 -0000 This is a multi-part message in MIME format. --------------943139CC65CCBD6B68D861FD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Brian - Inline. On 9/27/2020 3:47 PM, Brian E Carpenter wrote: > On 27-Sep-20 20:40, Martin J. Dürst wrote: >> Hello everybody, >> >> On 27/09/2020 06:16, Michael StJohns wrote: >> >>> The IETF community has a lot of closed groups - IESG, IRSG, IAB, IETF >>> Trust, LLC Board, and for that matter the model for research groups is >>> that they MAY be closed. Oh yes, most of the IAB programs appear to be >>> mostly closed. Decisions for publication in 3 of the 4 streams are made >>> by closed groups.    For the IAB as much as 1/2 (guessing here - didn't >>> count) of the IAB stream documents originate within the IAB itself and >>> are not subject to mandatory external review prior to publication. >>> Irrespective of where the documents originate, a closed group makes the >>> final decisions on publication for all but the documents in the >>> independent stream. >> The ISE in general has a lower bar, but isn't s/he essentially a closed >> group of one? > No. You are overlooking the ISEB (Independent Series Editorial Board). > True, the ISE's decision is final, but I've been an ISEB member for > quite a few years, and the Editor has always consulted the Board > whenever there was a tricky issue, and used it as a (non exclusive) > source of reviewers. From RFC6548 > The ISE is supported by an Editorial Board for the review of > Independent Submission stream documents. This board is known as the > Independent Submission Editorial Board. This volunteer Editorial > Board exists at the pleasure of the ISE, and its members serve at the > pleasure of the ISE. The existence of this board is simply noted > within this model, and additional discussion of such is considered > out of scope of this document. So this is a choice of the ISE to seek commentary, not a requirement of the process.  Which in the end reduces to the ISE making the decision, regardless of how he seeks to make that decision.  The fact that Adrian is smart enough to pay attention to his board, does not actually change the documented process. > > A difference compared to the IETF review process is that it more > closely resembles an academic peer review process. The reviews > aren't published, for example. But they usually aren't blinded, either > (i.e. the authors usually know who the reviewers are). > > Getting back to Mike's message: > >>> Brian - Authored by anyone with perhaps some RSA input and guidance, consensus of the WG, consensus determined by the WG chairs, approved for publication by the ISE, published in the Independent stream. > My draft doesn't say that ("ISE"), but leaves it rather open. In fact I think this stream should be owned by what I called the RSAWG, so the RSAWG chairs would declare consensus to publish. I don't think that this would be a busy stream, except for an initial bunch of documents. > > Brian > Hi Brian - your draft didn't say that, but your email did responding to my question about an editorial stream:  (if not the Editorial stream, then where?): > Again, it's model-dependent. In draft-thomson, it's clearly the IAB stream as > today. In the other two models, we are presumably left with the Independent > stream Apologies if I mis-represented anything. WRT to each of the current streams, there's either a body determines by vote that a document is ready for publication in the stream, or the ISE does (with whatever consultation he in his judgement determines is necessary). So digging down a bit on your last comment and assuming an Editorial Stream (whatever its called) - you think that the WG (or the loud voices therein) would direct for publication any document they felt was ready for publication, and that decision  (of agreement to publish) would be made by the WG chairs.   There would be no further decision points? Logically it looks like you've got a Editorial stream document production group of N people and a voting (sort of) RSEB consisting of the WG chairs actually deciding whether the documents get published.   And from your previous comments do I understand that the 4 other stream editors would be treated the same as any other participant except that their comments may be given heavier weight (or ignored for that matter) during the discussion period even if one of their stream might be more affected than another? We've noted before that its relatively common to get WGs into forms of consensus paralysis on trying to get out documents, and that the IAB and IESG have at various times completely avoided the WG model, either self-editing/self-publishing or creating relatively closed design teams to make progress.   They've invoked that model also on the "boring" where the documents needed to get done, but there was no one all that interested in doing them as part of their day job.    If we choose an open group model, I believe that a few nuclear options for such groups need to be incorporated to ensure progress when necessary.   That seems anathema to the IETF model, but we've done similar things to complete the meta tasks of legally organizing ourselves. Alternately, a closed body vote to publish like we have for all the other streams is a worked example. Thanks for the comments - Mike --------------943139CC65CCBD6B68D861FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Brian -

Inline.

On 9/27/2020 3:47 PM, Brian E Carpenter wrote:
On 27-Sep-20 20:40, Martin J. Dürst wrote:

Hello everybody,

On 27/09/2020 06:16, Michael StJohns wrote:


The IETF community has a lot of closed groups - IESG, IRSG, IAB, IETF 
Trust, LLC Board, and for that matter the model for research groups is 
that they MAY be closed. Oh yes, most of the IAB programs appear to be 
mostly closed. Decisions for publication in 3 of the 4 streams are made 
by closed groups.    For the IAB as much as 1/2 (guessing here - didn't 
count) of the IAB stream documents originate within the IAB itself and 
are not subject to mandatory external review prior to publication. 
Irrespective of where the documents originate, a closed group makes the 
final decisions on publication for all but the documents in the 
independent stream.

The ISE in general has a lower bar, but isn't s/he essentially a closed 
group of one?

No. You are overlooking the ISEB (Independent Series Editorial Board).
True, the ISE's decision is final, but I've been an ISEB member for
quite a few years, and the Editor has always consulted the Board
whenever there was a tricky issue, and used it as a (non exclusive)
source of reviewers.
From RFC6548

 The ISE is supported by an Editorial Board for the review of
   Independent Submission stream documents.  This board is known as the
   Independent Submission Editorial Board.  This volunteer Editorial
   Board exists at the pleasure of the ISE, and its members serve at the
   pleasure of the ISE.  The existence of this board is simply noted
   within this model, and additional discussion of such is considered
   out of scope of this document.

So this is a choice of the ISE to seek commentary, not a requirement of the process.  Which in the end reduces to the ISE making the decision, regardless of how he seeks to make that decision.  The fact that Adrian is smart enough to pay attention to his board, does not actually change the documented process.



A difference compared to the IETF review process is that it more
closely resembles an academic peer review process. The reviews
aren't published, for example. But they usually aren't blinded, either
(i.e. the authors usually know who the reviewers are).

Getting back to Mike's message:


Brian - Authored by anyone with perhaps some RSA input and guidance, consensus of the WG, consensus determined by the WG chairs, approved for publication by the ISE, published in the Independent stream.

My draft doesn't say that ("ISE"), but leaves it rather open. In fact I think this stream should be owned by what I called the RSAWG, so the RSAWG chairs would declare consensus to publish. I don't think that this would be a busy stream, except for an initial bunch of documents.

    Brian

Hi Brian - your draft didn't say that, but your email did responding to my question about an editorial stream:  (if not the Editorial stream, then where?):

Again, it's model-dependent. In draft-thomson, it's clearly the IAB stream as
today. In the other two models, we are presumably left with the Independent
stream

Apologies if I mis-represented anything. 

WRT to each of the current streams, there's either a body determines by vote that a document is ready for publication in the stream, or the ISE does (with whatever consultation he in his judgement determines is necessary).  


So digging down a bit on your last comment and assuming an Editorial Stream (whatever its called) - you think that the WG (or the loud voices therein) would direct for publication any document they felt was ready for publication, and that decision  (of agreement to publish) would be made by the WG chairs.   There would be no further decision points?

Logically it looks like you've got a Editorial stream document production group of N people and a voting (sort of) RSEB consisting of the WG chairs actually deciding whether the documents get published.   And from your previous comments do I understand that the 4 other stream editors would be treated the same as any other participant except that their comments may be given heavier weight (or ignored for that matter) during the discussion period even if one of their stream might be more affected than another?

We've noted before that its relatively common to get WGs into forms of consensus paralysis on trying to get out documents, and that the IAB and IESG have at various times completely avoided the WG model, either self-editing/self-publishing or creating relatively closed design teams to make progress.   They've invoked that model also on the "boring" where the documents needed to get done, but there was no one all that interested in doing them as part of their day job.    If we choose an open group model, I believe that a few nuclear options for such groups need to be incorporated to ensure progress when necessary.   That seems anathema to the IETF model, but we've done similar things to complete the meta tasks of legally organizing ourselves.  Alternately, a closed body vote to publish like we have for all the other streams is a worked example.


Thanks for the comments - Mike


--------------943139CC65CCBD6B68D861FD-- From nobody Mon Sep 28 13:10:24 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30393A13C1 for ; Mon, 28 Sep 2020 13:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, 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 5Igc89ETvNka for ; Mon, 28 Sep 2020 13:10:19 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1877F3A13B7 for ; Mon, 28 Sep 2020 13:10:19 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id t7so1343765pjd.3 for ; Mon, 28 Sep 2020 13:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=H6XlL598qm/JimsKEjV7CpIwQreo9IrJaCMi+zJ6b74=; b=HcSTPkS8t7yhOGsM1ojNcsDab/0NgY4QL0jaTdkrdlmQ9yaVIcux7syV9W6em6U0GI RrZBJxhVWA8C8pvNHPD80KpxOWALIricaXhcRTEDA1t3Pd53vgCJFoRLCsgXldqnXEqw zDsFkwx5hylolwOE/gdYmmXOVAZA8k5PMVWYj5u4SduopSNZ7hNgS6LvQEGDt6kf0yiK 0jFn/ajv55LqRUzzkyZZvKUfv3xBqFoe/UOXYKET7yWCbMyY0SNG488lRkueuvWDgB6V XeT2gUdVGsmsHXfdOtkJUJXG0LfbTqXf/dk2kfrML+P6iyBqpxeh3zovF7b0c252vNih ACyg== 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=H6XlL598qm/JimsKEjV7CpIwQreo9IrJaCMi+zJ6b74=; b=EdYmNTKyWfuvJwpgwVjbfkAa+n4ta8wvXcctkLra6PNWHf/4Fj0C+5OGiqZX5bwUwX mBmgtSOVk01S1kFrFPHP6VwE9PtLTru5jKOa4tSyO+laxaQUL+F2sJKgonFz9cClpD3S YP2/oCOLmArtm5ZT/Roqqdt9CxPcxBuXvcfInvSSibYvYTbnf8EcIdlanln92ZAWLhQv nN6/AWDGLusUtoUdeWNhUUsB+2sXQ9RUxNjXWCpzAZQsYk6PP0IBl3jHWHOg/DR4detQ DjYhm3FCK63Jl6lC6y04hN3SuFTw+UtBUnAfqIoFdew9fC4TzMGmb662ZwPW9hxL/02N adGw== X-Gm-Message-State: AOAM530jNEv2A+zxymlzi5cqor90poYXHid8nNHjm1eKcoXgY1FKqOOY VcQn9wiH54eI+OAA+ZVbRMPQoB3wbykODQ== X-Google-Smtp-Source: ABdhPJzqNaNtILEC9l5NUQB/THCCHsXh6QhImBe6Krgyx7mOvrBLHUnxA86EPKxoKfhVgHZT+3pIcQ== X-Received: by 2002:a17:90a:ba91:: with SMTP id t17mr809655pjr.83.1601323817838; Mon, 28 Sep 2020 13:10:17 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id 72sm2473255pfx.79.2020.09.28.13.10.16 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Sep 2020 13:10:17 -0700 (PDT) To: rfced-future@iab.org References: <5133f0ac-9d26-5f34-3550-e0dc7b2049ef@nthpermutation.com> <431C046D76BEA50F4FB7C8E7@JcK-HP5> <4d7e4ae8-bef4-70db-522c-7ebc96d34cee@nthpermutation.com> <5e005700-9c35-e3cd-7500-8dda49a8d0b9@it.aoyama.ac.jp> <74f1f6f6-7613-e7df-5bfa-15703b4b795b@gmail.com> From: Brian E Carpenter Message-ID: Date: Tue, 29 Sep 2020 09:10:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Questions and closed groups X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 20:10:23 -0000 On 29-Sep-20 05:25, Michael StJohns wrote: > Hi Brian - >=20 > Inline. >=20 > On 9/27/2020 3:47 PM, Brian E Carpenter wrote: >> On 27-Sep-20 20:40, Martin J. D=C3=BCrst wrote: >>> Hello everybody, >>> >>> On 27/09/2020 06:16, Michael StJohns wrote: >>> >>>> The IETF community has a lot of closed groups - IESG, IRSG, IAB, IET= F=20 >>>> Trust, LLC Board, and for that matter the model for research groups = is=20 >>>> that they MAY be closed. Oh yes, most of the IAB programs appear to = be=20 >>>> mostly closed. Decisions for publication in 3 of the 4 streams are m= ade=20 >>>> by closed groups.=C2=A0=C2=A0=C2=A0 For the IAB as much as 1/2 (gues= sing here - didn't=20 >>>> count) of the IAB stream documents originate within the IAB itself a= nd=20 >>>> are not subject to mandatory external review prior to publication.=20 >>>> Irrespective of where the documents originate, a closed group makes = the=20 >>>> final decisions on publication for all but the documents in the=20 >>>> independent stream. >>> The ISE in general has a lower bar, but isn't s/he essentially a clos= ed=20 >>> group of one? >> No. You are overlooking the ISEB (Independent Series Editorial Board).= >> True, the ISE's decision is final, but I've been an ISEB member for >> quite a few years, and the Editor has always consulted the Board >> whenever there was a tricky issue, and used it as a (non exclusive) >> source of reviewers. > From RFC6548 >=20 >> The ISE is supported by an Editorial Board for the review of >> Independent Submission stream documents. This board is known as th= e >> Independent Submission Editorial Board. This volunteer Editorial >> Board exists at the pleasure of the ISE, and its members serve at t= he >> pleasure of the ISE. The existence of this board is simply noted >> within this model, and additional discussion of such is considered >> out of scope of this document. >=20 > So this is a choice of the ISE to seek commentary, not a requirement of= the process.=C2=A0 Which in the end reduces to the ISE making the decisi= on, regardless of how he seeks to make that decision.=C2=A0 The fact that= Adrian is smart enough to pay attention to his board, does not actually = change the documented process. >=20 >=20 >> A difference compared to the IETF review process is that it more >> closely resembles an academic peer review process. The reviews >> aren't published, for example. But they usually aren't blinded, either= >> (i.e. the authors usually know who the reviewers are). >> >> Getting back to Mike's message: >> >>>> Brian - Authored by anyone with perhaps some RSA input and guidance,= consensus of the WG, consensus determined by the WG chairs, approved for= publication by the ISE, published in the Independent stream. >> My draft doesn't say that ("ISE"), but leaves it rather open. In fact = I think this stream should be owned by what I called the RSAWG, so the RS= AWG chairs would declare consensus to publish. I don't think that this wo= uld be a busy stream, except for an initial bunch of documents. >> >> Brian >> > Hi Brian - your draft didn't say that, but your email did responding to= my question about an editorial stream:=C2=A0 (if not the Editorial strea= m, then where?): >=20 >> Again, it's model-dependent. In draft-thomson, it's clearly the IAB st= ream as >> today. In the other two models, we are presumably left with the Indepe= ndent >> stream >=20 > Apologies if I mis-represented anything. No, you're correct, I wrote that, but if I'm not mistaken it was written under the hypothesis of no fifth stream being created. I prefer adding a new stream. > WRT to each of the current streams, there's either a body determines by= vote that a document is ready for publication in the stream, or the ISE = does (with whatever consultation he in his judgement determines is necess= ary).=C2=A0=C2=A0 >=20 >=20 > So digging down a bit on your last comment and assuming an Editorial St= ream (whatever its called) - you think that the WG (or the loud voices th= erein) would direct for publication any document they felt was ready for = publication, and that decision=C2=A0 (of agreement to publish) would be m= ade by the WG chairs. =C2=A0 There would be no further decision points? Correct; it would be a rough consensus decision. > Logically it looks like you've got a Editorial stream document producti= on group of N people and a voting (sort of) RSEB consisting of the WG cha= irs actually deciding whether the documents get published. The group (in my model and I think Martin's too) is whoever chooses to sh= ow up plus the WG (or Program) chairs and the stream managers and the RSA= (in my model only). No presidents or kings, however. The decision proces= s is RFC7282. >=C2=A0 And from your previous comments do I understand that the 4 other = stream editors would be treated the same as any other participant except = that their comments may be given heavier weight (or ignored for that matt= er) during the discussion period even if one of their stream might be mor= e affected than another? If we believe this approach works for protocol designs, it doesn't seem h= ard to believe it will work for archival publication procedures.=20 > We've noted before that its relatively common to get WGs into forms of = consensus paralysis on trying to get out documents, and that the IAB and = IESG have at various times completely avoided the WG model, either self-e= diting/self-publishing or creating relatively closed design teams to make= progress.=C2=A0=C2=A0 They've invoked that model also on the "boring" wh= ere the documents needed to get done, but there was no one all that inter= ested in doing them as part of their day job. =C2=A0=C2=A0 If we choose a= n open group model, I believe that a few nuclear options for such groups = need to be incorporated to ensure progress when necessary.=C2=A0=C2=A0 Th= at seems anathema to the IETF model, but we've done similar things to com= plete the meta tasks of legally organizing ourselves.=C2=A0 Alternately, = a closed body vote to publish like we have for all the other streams is a= worked example. Sometimes the IETF process gets stuck on an insoluble disagreement, and w= e have to live with the consequences. Usually that means "no change." Brian From nobody Wed Sep 30 06:48: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 375CA3A09C0 for ; Wed, 30 Sep 2020 06:48:45 -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 h-r4ImRM55bA for ; Wed, 30 Sep 2020 06:48:43 -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 31C753A09BC for ; Wed, 30 Sep 2020 06:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2940; q=dns/txt; s=iport; t=1601473723; x=1602683323; h=from:mime-version:subject:message-id:date:cc:to; bh=B77DAeIHgr4LwnQYw0rx/DyzEgXXYVxhF3Or1tyRd38=; b=dvAWdPQLaF2wpCOrG65Y5dlNJZNKajaAiDbZCzQq6g6EhAsBG6q1ssl2 bdQRARVWDisZ7G3hYIY8wrN3y7AIympqNtmq/30472/zALptycYoJVs9z nunHDSW6ni1F+KUgTJ/atA6xm8tKHjQVwIGrbIDzAuQyG0aBXqWA2E8nc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBQB6jHRf/xbLJq1ghXJVASAShGm?= =?us-ascii?q?JAoghlC+GMIFpCwEBAQ0BASMMBAEBhEuCNCY4EwIDAQELAQEFAQEBAgEGBG2?= =?us-ascii?q?FXAyGHARSHwE9AoQYAYJ8D7UJdn8zhVOEcQaBOI1JggCBOAwQhWcCgSWBB4J?= =?us-ascii?q?KM4ItBLdDgnGDE4VokV0DH4MOiX6FE452nXWRRoNdAgQGBQIVgWsjgVczGgg?= =?us-ascii?q?bFTsqAYI/PRIZDZIQilg/A2cCBgEJAQEDCY8HAQE?= X-IronPort-AV: E=Sophos; i="5.77,322,1596499200"; d="scan'208,217"; a="29963103" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Sep 2020 13:48:28 +0000 Received: from [10.61.171.11] ([10.61.171.11]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 08UDmQjZ014373 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Sep 2020 13:48:27 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_6DE8D763-BB78-423B-AAC1-4D56B1F7DE50" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <59E1F5FE-C8FB-4498-8971-B3FB31155D14@cisco.com> Date: Wed, 30 Sep 2020 15:48:26 +0200 Cc: Brian Rosen To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.171.11, [10.61.171.11] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Brian's List -> Issue Tracker X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 13:48:45 -0000 --Apple-Mail=_6DE8D763-BB78-423B-AAC1-4D56B1F7DE50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear colleagues, I have added Brian=E2=80=99s list into the issue tracker. You can find = it at https://github.com/intarchboard/rfced-future/issues = . Please note, we = will want to lead with the issues that Brian called =E2=80=9Cprimary=E2=80= =9D, even if they are not so marked in the tracker. There is no = point, for instance, in trying to decide who hires an RSA/RSE if the = group decides not to have one of those. We recognize that there may be linkages between some issues. If you = find you need to bring one issue in when discussing another, please = explain the linkage. If you find yourself in the rough on an issue, please consider what = conditions/safeguards/or palatable alternatives would get us to the = point where we can resolve the matter. Put another way, we are all = responsible for finding a consensus that people can live with, even if = it=E2=80=99s not your first choice. Your humble chairs --Apple-Mail=_6DE8D763-BB78-423B-AAC1-4D56B1F7DE50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear colleagues,

I have added Brian=E2=80=99s list into the issue tracker. =  You can find it at https://github.com/intarchboard/rfced-future/issues. =  Please note, we will want to lead with the issues that Brian = called =E2=80=9Cprimary=E2=80=9D, even if they are not so marked in the = tracker.    There is no point, for instance, in trying to = decide who hires an RSA/RSE if the group decides not to have one of = those.

We = recognize that there may be linkages between some issues.  If you = find you need to bring one issue in when discussing another, please = explain the linkage.

If you find yourself in the rough on an issue, please = consider what conditions/safeguards/or palatable alternatives would get = us to the point where we can resolve the matter.  Put another way, = we are all responsible for finding a consensus that people can live = with, even if it=E2=80=99s not your first choice.
Your humble chairs

= --Apple-Mail=_6DE8D763-BB78-423B-AAC1-4D56B1F7DE50-- From nobody Wed Sep 30 10:40: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 3E26C3A0A50 for ; Wed, 30 Sep 2020 10:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 Rm3DRv5K7oMC for ; Wed, 30 Sep 2020 10:40:37 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798793A0A38 for ; Wed, 30 Sep 2020 10:40:37 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id q5so2631100ilj.1 for ; Wed, 30 Sep 2020 10:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=SXga2TKVHfultX4v+QIhzRHKWdQI24AcTaKyTvmqZ6s=; b=MxO/IYGMYtgRpDz65DG7DyW6xOgyeVANhqy71kU4V2adhBe+aGhANiEk0soplfy40q KIXexUdsAjhTXWRvsNKt6tvk8pjMkYpOZQdzbQKBkVBXFbS7W3UwG0Ls/904lBADdsCf OxPapwcvoCHAWePQKKiviZ1izSTF3BVuYfSYnNRTSaUMr9qw9Qc1M5Kr/Bhb7yO6GxFg qUzJQOqgs0yCNW4cwNwJujJH9w5Vpnz1N58COqDBASfdT9jtOeucUPLXul7pTU28klob 96IpeepDBOjEgd0ptrepals6CXIbsZqKOh9ARBCfAygMvAAqWaLs4Ae1VPng0EEp/huX C7gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=SXga2TKVHfultX4v+QIhzRHKWdQI24AcTaKyTvmqZ6s=; b=GuDuBSmZ7vtkXW8ULFd9Uy/vyUku0uOp+5BTZxZiXjRYmaSbEW4Cl/lNwXyIGuYqiY 64QKGlvtRMGdYo4hpf1vcoxyLq7r14JB6j0jnebNV5ABos50pZ4n2nRPP35Gwv0dc16G J/qXlWjTn1VIG5465OzGG7moPdhGFoRdrHdcVNZ5x2zp41sswpFiuC3wtwkyzAHgNIKf w+2ovl5vkO8g3PG6K0dQgpFdw4rYEJtgH+b0DRqAtC4ybV+tDD4r3/YRxVuuGBbeZG5z B1c6JX4tl0oxFhPAXNyAGZxDQzGUR+QaIR5sut3gZgqVQUACVTnlupGPnOc3hmTG7HJ1 AmNA== X-Gm-Message-State: AOAM531JQGUG1Q4SgK9oUC+qN8001w4JsU1Pf56Cvqy+hbxt4jiBnzsO Bfe0bQ74mCkHiDnkL2PtHm3DkXTi5TGijIkD X-Google-Smtp-Source: ABdhPJzvMC+RUoKXKURjuwQ2dSEuGL1prQttkxtyq4R8UdpDp6LU0gdemIV8EbDGPbr2w+XUNqy4/w== X-Received: by 2002:a92:405d:: with SMTP id n90mr2926005ila.58.1601487636482; Wed, 30 Sep 2020 10:40:36 -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 m204sm915873ioa.20.2020.09.30.10.40.35 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2020 10:40:36 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_6C71D58E-F322-415B-9C9D-F37A714813B3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Wed, 30 Sep 2020 13:40:35 -0400 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [Rfced-future] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 17:40:39 -0000 --Apple-Mail=_6C71D58E-F322-415B-9C9D-F37A714813B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So, we think we have created the issues list, and we would like to start = on one of the key questions that we believe doesn=E2=80=99t depend on = other decisions. Is there a figurehead/thought leader, regardless of what the position is = called, how they are selected, who they report to, and what duties they = have? =20 This is: https://github.com/intarchboard/rfced-future/issues/10 = Please send your thoughts on this subject. We would actually appreciate = +1s as we go through this process so we can try to gauge if we have any = form of consensus. We are basically looking for a yes/no. Your opinions on secondary = issues if you think there is such a position are, as always, welcome, = but we are really trying at this point to see if we have consensus one = way or another on if there is such a role. This is an opportunity for = those who haven=E2=80=99t spoken up yet to weigh in. Brian --Apple-Mail=_6C71D58E-F322-415B-9C9D-F37A714813B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 So, = we think we have created the issues list, and we would like to start on = one of the key questions that we believe doesn=E2=80=99t depend on other = decisions.

Is there = a figurehead/thought leader, regardless of what the position is called, = how they are selected, who they report to, and what duties they have? =  
This is: https://github.com/intarchboard/rfced-future/issues/10

Please send your = thoughts on this subject.  We would actually appreciate +1s as we = go through this process so we can try to gauge if we have any form of = consensus.

We = are basically looking for a yes/no.  Your opinions on secondary = issues if you think there is such a position are, as always, welcome, = but we are really trying at this point to see if we have consensus one = way or another on if there is such a role.  This is an opportunity = for those who haven=E2=80=99t spoken up yet to weigh in.

Brian

= --Apple-Mail=_6C71D58E-F322-415B-9C9D-F37A714813B3-- From nobody Wed Sep 30 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 726D63A0A66 for ; Wed, 30 Sep 2020 10:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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 NJZ19wlN8rxS for ; Wed, 30 Sep 2020 10:59:43 -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 9F8073A0A81 for ; Wed, 30 Sep 2020 10:59:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4C1kYC2d7Pz6GDCR; Wed, 30 Sep 2020 10:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1601488783; bh=B6yLtOJ2pkaw8vvG0qSoSmowUV4Kh88LPtSUOgHuOwA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=OEZdke1S3KNXvGl1xCi1+hYkasQZa7M5xfRDPTDin5DpDoSShgYo7hzeKafPbpIWd HNoMSoRlHRa+k3qKE2GJroZv0A5NLfUU3chLvEDjtuyQvIgq1XC7w4zb3l5E73fSI9 eKf6y5AosF/Tf2er6oKUSMwz25waZzfGm7qU1Kpg= 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 4C1kYB5mFrz6GD4G; Wed, 30 Sep 2020 10:59:42 -0700 (PDT) To: Brian Rosen , rfced-future@iab.org References: From: "Joel M. Halpern" Message-ID: <56cc1fdb-7979-f2b6-fd49-3df4a1132cb7@joelhalpern.com> Date: Wed, 30 Sep 2020 13:59:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 17:59:46 -0000 Yes, I think that it is important that we have such a person. Yours, Joel PS: While it is always tempting to argue about the way questions are posed, at this point I think you are doing as well as it is possible to make progress. So lets take the question as you posed it. On 9/30/2020 1:40 PM, Brian Rosen wrote: > So, we think we have created the issues list, and we would like to start > on one of the key questions that we believe doesn’t depend on other > decisions. > > Is there a figurehead/thought leader, regardless of what the position is > called, how they are selected, who they report to, and what duties they > have? > This is: https://github.com/intarchboard/rfced-future/issues/10 > > Please send your thoughts on this subject.  We would actually appreciate > +1s as we go through this process so we can try to gauge if we have any > form of consensus. > > We are basically looking for a yes/no.  Your opinions on secondary > issues if you think there is such a position are, as always, welcome, > but we are really trying at this point to see if we have consensus one > way or another on if there is such a role.  This is an opportunity for > those who haven’t spoken up yet to weigh in. > > Brian > > From nobody Wed Sep 30 11:21:30 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8C03A0AD4 for ; Wed, 30 Sep 2020 11:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdxMXfrfNuGS for ; Wed, 30 Sep 2020 11:21:21 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8C23A0B26 for ; Wed, 30 Sep 2020 11:21:18 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08UIGVLr002324; Wed, 30 Sep 2020 19:21:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=C/zltcxcecokXZF999kJiuBpzE+utM9pQscXF3T1JyM=; b=EnmlGs2KlUOJkVoOzTJJFFjlbOWa3vHP2cMdf2YYryP1Vu2QItHqn96gYOdDeLRm3C6o aeWhfzi96+A+UAyzv0BoMxGMZN5iYpiiqogT35nz0QpSnV6XRis70s/sD/Ee0ZfNbVtc EwXb51VPXVcCkwEC5k7Lu5vBDsMfkv8NQcziTKHIDFv/JmOrsg8Fn6+JEq3DEFkTtGoH y3sDn51stJOBQH8NmRiviDuxOXnmQcR/huxyScH6iTIsc9c4k0WQy4i24X+cg85RAkJU lEjsIMk6VbWjYIQvPHz53lE6Yw0gqOQ/doZAERrJwvVBjQ/GWnnTafoMSLpsi1dgFLdX Qw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 33t7kba9mw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2020 19:21:17 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 08UIGuL3026663; Wed, 30 Sep 2020 14:21:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint2.akamai.com with ESMTP id 33t0yxcn45-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2020 14:21:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 30 Sep 2020 14:21:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Wed, 30 Sep 2020 14:21:15 -0400 From: "Salz, Rich" To: Brian Rosen , "rfced-future@iab.org" Thread-Topic: [Rfced-future] First Topic for Discussion: Thought Leader Thread-Index: AQHWl1DTwsGNmFM/uEuyeuGuFAIjKqmBflQA Date: Wed, 30 Sep 2020 18:21:14 +0000 Message-ID: <30878A1D-F182-4BBE-96E0-284F00518E27@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_30878A1DF1824BBE96E0284F00518E27akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_09:2020-09-30, 2020-09-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=950 bulkscore=0 mlxscore=0 spamscore=0 suspectscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009300143 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_09:2020-09-30, 2020-09-30 signatures=0 Archived-At: Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 18:21:28 -0000 --_000_30878A1DF1824BBE96E0284F00518E27akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHdlIG5lZWQgYSAocGFpZCkgcHJvZmVzc2lvbmFsLCB5ZXMuDQoNCg== --_000_30878A1DF1824BBE96E0284F00518E27akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgd2UgbmVlZCBhIChwYWlkKSBwcm9mZXNzaW9uYWwsIHll cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_30878A1DF1824BBE96E0284F00518E27akamaicom_-- From nobody Wed Sep 30 11:27: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 302423A0AA2 for ; Wed, 30 Sep 2020 11:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, 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 s3aL0YTCmkka for ; Wed, 30 Sep 2020 11:27:54 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C991D3A0A3D for ; Wed, 30 Sep 2020 11:27:54 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id s131so2476689qke.0 for ; Wed, 30 Sep 2020 11:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=NEmY+6scigDsQtvbDPrsZe5pxYWrgk/H9l+igaKprKc=; b=e6eMkRf7diXxTYd+JJBnDJb2fdv2MJ/ldnfpEMxtjE51bxFbSubDzibw5LOVbdnVXS nY4KY6cVd/rg5bsg+KlIBuqwDc/4pCCFYeXIaSdJnBtdaTsg1nNZD8bzfMOG0fBFJts3 PrM2PEI4ySqLR0ZQ1L9oQPh7XiuW3FnFiCtJ6Dr3CEzX5lb6SnQHyvyhY1JKWw6a4m9g DKxyzap3HLzDUefU5ez7H/Z9liHFZVL9qtbO1Ax6SjMhIUnX0Q5ILZNx+yhnNt3Bff0l O3rnwU3wkQ5fb/g3W2tIA0t/Z17/3lEP/4KuDoNKJIms0HrHDE3P8K3QckXOpzAReP+5 zGDw== 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=NEmY+6scigDsQtvbDPrsZe5pxYWrgk/H9l+igaKprKc=; b=YGn8zcw1vwg2VjU5AXLpjwMJgO5FZbAI7niwud2JxShC73nhyO7tMfPuMsPvueNurz 8xI2pWZn6Cor2JQYs9vHrDlrcwHUkH3OICikZS1ql/kZfoKIB6c/xAny+4TOlUvVfeUq SXLyWaLcIhgtqVJaabxuZHjIXci6j+jRu5sdz+Tgok5vNsX9It7RjGz9di0YRDGT+UDg 2Z638ZNiuI+lejYKk/ZBTgLxIuANslc5E8n9iwtxeBPfXXdVGRissMZZ2HaqCd/U8An9 EEq83chzmun7/vKeZFeHZTfrsy6gc9AkSbWPMbUXXLNGvhlANEiMjn7Dq8eu7MpQmlV2 07og== X-Gm-Message-State: AOAM532k3gBXySRlQXBSWt7FduiTqb+emtYTCBG0SSzcwsOgxxCGPy/R ntSEGi3xkoy4jo3JEH41g61e3+bvO72MIVqpkEQ= X-Google-Smtp-Source: ABdhPJwrC/IhGIGlV1eN7bOtwpHRBFSxejMQ2+oMZ/SINGDHFEyk2A9imKNsBEDmhU9ZWkeSkSl6cw== X-Received: by 2002:a05:620a:1212:: with SMTP id u18mr3987036qkj.434.1601490473378; Wed, 30 Sep 2020 11:27:53 -0700 (PDT) Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id f189sm2988995qkd.20.2020.09.30.11.27.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Sep 2020 11:27:52 -0700 (PDT) To: rfced-future@iab.org References: <56cc1fdb-7979-f2b6-fd49-3df4a1132cb7@joelhalpern.com> From: Michael StJohns Message-ID: Date: Wed, 30 Sep 2020 14:27:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <56cc1fdb-7979-f2b6-fd49-3df4a1132cb7@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 18:27:56 -0000 Well put Joel. Yes, a paid professional is necessary. Mike On 9/30/2020 1:59 PM, Joel M. Halpern wrote: > Yes, I think that it is important that we have such a person. > > Yours, > Joel > > PS: While it is always tempting to argue about the way questions are > posed, at this point I think you are doing as well as it is possible > to make progress.  So lets take the question as you posed it. > > On 9/30/2020 1:40 PM, Brian Rosen wrote: >> So, we think we have created the issues list, and we would like to >> start on one of the key questions that we believe doesn’t depend on >> other decisions. >> >> Is there a figurehead/thought leader, regardless of what the position >> is called, how they are selected, who they report to, and what duties >> they have? >> This is: https://github.com/intarchboard/rfced-future/issues/10 >> >> Please send your thoughts on this subject.  We would actually >> appreciate +1s as we go through this process so we can try to gauge >> if we have any form of consensus. >> >> We are basically looking for a yes/no.  Your opinions on secondary >> issues if you think there is such a position are, as always, welcome, >> but we are really trying at this point to see if we have consensus >> one way or another on if there is such a role.  This is an >> opportunity for those who haven’t spoken up yet to weigh in. >> >> Brian >> >> > From nobody Wed Sep 30 12:54: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 039903A0B5B for ; Wed, 30 Sep 2020 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, 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 WIwbex_nQ64n for ; Wed, 30 Sep 2020 12:54:07 -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 DAF613A0B59 for ; Wed, 30 Sep 2020 12:54:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 70195BE20; Wed, 30 Sep 2020 20:54:04 +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 Snq5ZeAtdrOg; Wed, 30 Sep 2020 20:53:59 +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 380F4BE1C; Wed, 30 Sep 2020 20:53:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1601495639; bh=5oDhytavajdU0wi3Un7PbQOJ/tJ/sHDzezeni9KizQw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=S35KmKcjKBM+7Bi2kOxg9trWRrfs8FplgEKZ4LTiTbOGeRywbj40lqAWhqai2nM1X QaHT6vnAR4K8fAENFn0RhF4GxaT9rHT8IhWFYRMUhMEzRP/V5vz3WmPzal76P05i3y AxtO37CDW7GGnO/Qg5aFc5f9ybU9khg1EMhXE6Yw= To: Brian Rosen , rfced-future@iab.org References: 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: Date: Wed, 30 Sep 2020 20:53:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Yxn0KxN5I9tKHxdDlr83yTANiVCum70NZ" Archived-At: Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 19:54:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Yxn0KxN5I9tKHxdDlr83yTANiVCum70NZ Content-Type: multipart/mixed; boundary="fcTEcmOxLOo2RY2X35xKNEFDC0A1dOhPu"; protected-headers="v1" From: Stephen Farrell To: Brian Rosen , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader References: In-Reply-To: --fcTEcmOxLOo2RY2X35xKNEFDC0A1dOhPu Content-Type: multipart/mixed; boundary="------------50EF6B86F8029557C6679BF4" Content-Language: en-US This is a multi-part message in MIME format. --------------50EF6B86F8029557C6679BF4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'd answer yes for that one. S On 30/09/2020 18:40, Brian Rosen wrote: > So, we think we have created the issues list, and we would like to star= t on one of the key questions that we believe doesn=E2=80=99t depend on o= ther decisions. >=20 > Is there a figurehead/thought leader, regardless of what the position i= s called, how they are selected, who they report to, and what duties they= have? =20 > This is: https://github.com/intarchboard/rfced-future/issues/10 >=20 > Please send your thoughts on this subject. We would actually appreciat= e +1s as we go through this process so we can try to gauge if we have any= form of consensus. >=20 > We are basically looking for a yes/no. Your opinions on secondary issu= es if you think there is such a position are, as always, welcome, but we = are really trying at this point to see if we have consensus one way or an= other on if there is such a role. This is an opportunity for those who h= aven=E2=80=99t spoken up yet to weigh in. >=20 > Brian >=20 >=20 >=20 --------------50EF6B86F8029557C6679BF4 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----- --------------50EF6B86F8029557C6679BF4-- --fcTEcmOxLOo2RY2X35xKNEFDC0A1dOhPu-- --Yxn0KxN5I9tKHxdDlr83yTANiVCum70NZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl904lYACgkQWrL68XsX K+q5oRAAp4muAxfRy2Vwg7+gd29AK20ItdzEIbuwwg9uLjjKITYqJCuUCHSoRCt9 lUjUJhhVZBUQW7iMx+qEc/nXE7yeh+6TCnMkF3+HB52SWb9u3Uy8Q2IIHPTdXnmU e0KIQ+7GSCGGLHrlzL5MmrCc3Mf7/lp2YS2WwQUcbQRiiQmcjPKkjXPp8Zukk8C6 tnMfJOZ4nW1FE3cESM1X1r9UC+mZp2W9n0dm2A6NcniCPx/ZmFq/Zc4GDOsl39Hg isc2wQmlPI3kSU7W6tHa/FfUa5Vdd7rQ7vKlhsL9vK1981WGHKFmii8SsZCapAAM ICysV+mRxPeaq2CbG6/l/wWO2M4BNLgViZMz0w3R815vpwq+lbtFRNktUTqQdvUJ 7xjAUiO21XEPRtGUiD6R1paY5Xdu4K26Bgs1nERmeeKtqma1LqRKMzCLyAccZnAE SAougWMWAUnz28uNct2nuAPcmlrRSdD9btU+PkZHqJew/Bk1bkOmfrv03abhx8oR mVq6h7l9JhoXlHQq7E7V6Z7H0nX/EDsqvzg5fLj5j2jvf4bonSbBOZpQB2F/LF4+ O4v76yrcQnC/Zw9xuA5rc8fdRpVplP5ojmqhePxzzZkOT2Zo6nZBkDNwZ9m0YXMD ucLTOJtaNye1P1lTYWrC7VhZFWbVpuMjPYaibacifheicsBJTfs= =d9hQ -----END PGP SIGNATURE----- --Yxn0KxN5I9tKHxdDlr83yTANiVCum70NZ-- From nobody Wed Sep 30 13:16: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 5EF503A0B6D for ; Wed, 30 Sep 2020 13:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGo_qwdTC8r8 for ; Wed, 30 Sep 2020 13:16:14 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6640A3A0B6C for ; Wed, 30 Sep 2020 13:16:13 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08UKGA9S025158; Wed, 30 Sep 2020 21:16:10 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 255852203A; Wed, 30 Sep 2020 21:16:10 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 1012322032; Wed, 30 Sep 2020 21:16:10 +0100 (BST) Received: from LAPTOPK7AS653V ([87.113.82.114]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08UKG9Nr001618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Sep 2020 21:16:09 +0100 Reply-To: From: "Adrian Farrel" To: "'Brian Rosen'" , References: In-Reply-To: Date: Wed, 30 Sep 2020 21:16:08 +0100 Organization: Old Dog Consulting Message-ID: <04e901d69766$88e6be10$9ab43a30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04EA_01D6976E.EAAB9B40" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLK7I1Ov9H+78aSe8jtI3v+4KPWkKeY8LXA X-Originating-IP: 87.113.82.114 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-25698.002 X-TM-AS-Result: No--20.002-10.0-31-10 X-imss-scan-details: No--20.002-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25698.002 X-TMASE-Result: 10--20.001600-10.000000 X-TMASE-MatchedRID: IDdx3MBO6EDxIbpQ8BhdbPCW/PNRRp/ZAQ+35UHH2f0W6M2A15L1QMzQ WsaXju5LQsb5Omct+calwJEDbx2uyZP2Lt+JyyGsnMRCqQzD5efoo+IFfa0jSIRdbD7zug2tLig 19Jv1DVshQeE4WijN4LujLhltI9TJwRQvfWGmSQcr+UXGROVEICIk3dpe5X+hg8vHe9ji82KZmq b6kvu1WcJFkBmQRy/qRuVLdpYH7E9ftlZ0AGvdlSme9wbpQbK5BgA+oehWZhEM74Nf6tTB9oi6y FTH7VfQ4UPFlR72bqVs2Euje3tS+sp2rkLGDmljrdLFFKR7duk4CqsUSpaVG55k+B+yIc3dw0mf 419KLYU22uoEm245flgUFTT7Y9QpYTZ2mX+nxwwItCy6ZX/lL4IWSprjdsebHCP6WbPscS8wfkn 2bVbTj4vfSJuNTN/rxWGby5Hg6eAsS7de5tK9ATE06wHA1+f+AcGk+q40InQXM2Z1UyweuO/JKo 63i0vVLPtrQd14tHu9R+twE6CGWa1UZ8L9WMQHHPYwOJi6PLlKRaXN2yYjHn/nRXkdtDN8Lg4aE fqmR9fRv+j60AlkulE9Y9nltHKELDC3FGTHI3dPs79gcmEg0Ov6L5uWBkxp3s968rXGp9NBmfTk Ymv2RXoV3fjBEUHNPTnazbqgxuWiqgrnLPR5UmY0Io4Kxb861ViV5EWK7TubKItl61J/yZUdXE/ WGn0FSlnU38LCY8vtNz9YYotrJCs3zPQeiEbeRRgndEtDQrKr8QC0bWyE+w2ehJrOQ2Qr4q5q9T Cz2KRW13jtd97Yc5RMZUCEHkRt X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 20:16:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04EA_01D6976E.EAAB9B40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I give you a strong =E2=80=9CYes, but.=E2=80=9D =20 1. The responses so far have majored on =E2=80=9Cwe need a (paid) = professional=E2=80=9D. While I agree with that point, I don=E2=80=99t = believe it was the question asked in the email or on github. 2. I also agree with the question as phrased, but I=E2=80=99d note that = the title of the role is important both for recruiting (small point) and = for how the person is perceived and heard in the wider community (larger = point). So don=E2=80=99t neglect the name of the position. =20 A =20 From: Rfced-future On Behalf Of Brian = Rosen Sent: 30 September 2020 18:41 To: rfced-future@iab.org Subject: [Rfced-future] First Topic for Discussion: Thought Leader =20 So, we think we have created the issues list, and we would like to start = on one of the key questions that we believe doesn=E2=80=99t depend on = other decisions. =20 Is there a figurehead/thought leader, regardless of what the position is = called, how they are selected, who they report to, and what duties they = have? =20 This is: https://github.com/intarchboard/rfced-future/issues/10 =20 Please send your thoughts on this subject. We would actually appreciate = +1s as we go through this process so we can try to gauge if we have any = form of consensus. =20 We are basically looking for a yes/no. Your opinions on secondary = issues if you think there is such a position are, as always, welcome, = but we are really trying at this point to see if we have consensus one = way or another on if there is such a role. This is an opportunity for = those who haven=E2=80=99t spoken up yet to weigh in. =20 Brian =20 ------=_NextPart_000_04EA_01D6976E.EAAB9B40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I give you = a strong =E2=80=9CYes, but.=E2=80=9D

 

  1. The responses so far have majored = on =E2=80=9Cwe need a (paid) = professional=E2=80=9D. While I agree with that point, I don=E2=80=99t = believe it was the question asked in the email or on github.
  2. I also agree with the question as phrased, but = I=E2=80=99d note that the title of the role is important both for = recruiting (small point) and for how the person is perceived and heard = in the wider community (larger point). So don=E2=80=99t neglect the name = of the position.

 

A

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of Brian = Rosen
Sent: 30 September 2020 18:41
To: = rfced-future@iab.org
Subject: [Rfced-future] First Topic for = Discussion: Thought Leader

 

So, we think = we have created the issues list, and we would like to start on one of = the key questions that we believe doesn=E2=80=99t depend on other = decisions.

 

Is there a figurehead/thought leader, regardless of = what the position is called, how they are selected, who they report to, = and what duties they have?  

 

Please send your thoughts on this subject.  We = would actually appreciate +1s as we go through this process so we can = try to gauge if we have any form of = consensus.

 

We are basically looking for a yes/no.  Your = opinions on secondary issues if you think there is such a position are, = as always, welcome, but we are really trying at this point to see if we = have consensus one way or another on if there is such a role.  This = is an opportunity for those who haven=E2=80=99t spoken up yet to weigh = in.

 

Brian

 

------=_NextPart_000_04EA_01D6976E.EAAB9B40-- From nobody Wed Sep 30 13:44: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 D709A3A0B90 for ; Wed, 30 Sep 2020 13:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, 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 dIIUZdHQN0lY for ; Wed, 30 Sep 2020 13:44:49 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CD73A0B8C for ; Wed, 30 Sep 2020 13:44:45 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id k25so2446125qtu.4 for ; Wed, 30 Sep 2020 13:44:45 -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=LgcJJtmBbTW9Ono3jBRcCSZXqjlJTTYUVG0Si8o0rOg=; b=sdDzaE9nUlWzzHOfVPOObvSZwhIuolfj+4UW3OCk07sXT/uwisBUt5BjbDljORPVmJ cLgYNT5xw4XjAF77faUnaR82Tmrvg6yb/a5sviVw+gLjGJucPZxMc8aFCXzVJ7druFMZ 5z3gJWOE2ACXV+UkHMeZv8GkdniQnd9E6/OsMk8FFrgYMDpPlxui5Jh82CzbJbTWba2b hpAsXFv+WyMMQdwGwrNR5MtZsbJk648BuD/HI5Byr8xP0GtVPyJLDQts2EuNIo82ntew aKpxYM4dGVE1cD5uQ8xwwlA1q2d1/d8YCbxmAWK/YOez+wIrQR0hFclDXCkhlev9ajv9 8msw== 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=LgcJJtmBbTW9Ono3jBRcCSZXqjlJTTYUVG0Si8o0rOg=; b=femE4y1gHe/zbZn5CQRKZD0AOk0D+NaXf7vn8uEqXuW/7JR5VU1a1eDgm24/d6CuKZ LAXb4LENoeGI+r2Jwt/QX6Bp4OJyhjrnQkFEV6dr2gVuno/gqGLPClxObyZZWiPpN3Ln S1paDtPbyG+YYOnsQlFgtOw17c71Kvg7SYfmkuu7L28D8XWcGybBe+AuOHkAkkhNlkGn EkVbJ4dQMviMecc7WF0dTgHOQQINLIOHp2xgVP6gyH05JU3hwo1tEDd8f+n+KfDpoCRm BpsLEXh9y/vwYmLxZku6FX9FsnnaCsmQAyVi91MjV8OeCJcAxxLyuDWNb0ZMB45LTl4X WckA== X-Gm-Message-State: AOAM533d5frZRXKFEjjy/zNNMJEDAFzmauf+sSWsZ1vOdwXJqabrK8Og DQM4FvtnxMH6YEUNwJmmbFCnFhoUKUVXpAPd7JM= X-Google-Smtp-Source: ABdhPJyhVcjY7jtaueNM0Xhho3CIxnO9OKxTYC54pg8Hdbp8MJaaaRxrcZ9PEp3xdvLD6mAuRg1P5w== X-Received: by 2002:ac8:4410:: with SMTP id j16mr4390662qtn.305.1601498684236; Wed, 30 Sep 2020 13:44:44 -0700 (PDT) Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id s47sm3848629qtb.13.2020.09.30.13.44.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Sep 2020 13:44:43 -0700 (PDT) To: rfced-future@iab.org References: <04e901d69766$88e6be10$9ab43a30$@olddog.co.uk> From: Michael StJohns Message-ID: <2a675967-1674-8d31-5912-8042592b622a@nthpermutation.com> Date: Wed, 30 Sep 2020 16:44:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <04e901d69766$88e6be10$9ab43a30$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------90074E4CF99DB8BA9BD81309" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 20:44:51 -0000 This is a multi-part message in MIME format. --------------90074E4CF99DB8BA9BD81309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/30/2020 4:16 PM, Adrian Farrel wrote: > > 1. I also agree with the question as phrased, but I’d note that the > title of the role is important both for recruiting (small point) > and for how the person is perceived and heard in the wider > community (larger point). So don’t neglect the name of the position. > I like to refer to the position as RFC Series Editor, but really in my mind that's mostly translating as "the stuckee"... (only slightly tongue in cheek). Mike --------------90074E4CF99DB8BA9BD81309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/30/2020 4:16 PM, Adrian Farrel wrote:
  1. I also agree with the question as phrased, but I’d note that the title of the role is important both for recruiting (small point) and for how the person is perceived and heard in the wider community (larger point). So don’t neglect the name of the position.


I like to refer to the position as RFC Series Editor, but really in my mind that's mostly translating as "the stuckee"... (only slightly tongue in cheek).

Mike


--------------90074E4CF99DB8BA9BD81309-- From nobody Wed Sep 30 13:57: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 3D2C73A0B8B for ; Wed, 30 Sep 2020 13:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM1ZgHrLSuYM for ; Wed, 30 Sep 2020 13:57:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886D33A095D for ; Wed, 30 Sep 2020 13:57:25 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08UKvJc8094726 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Sep 2020 15:57:22 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1601499443; bh=RdLcS+jKx6JJlNbT1f/tm+vvksR8+RhVyvldHi4u9zw=; h=Subject:To:References:From:Date:In-Reply-To; b=ObBceY2QCx0sUKPNsTT+p6kvOu8i3APAzQ7XxQWFXE74dglRRCaC5NWi/7bhMYvfk sL3q4BlyiPbGIaumDujl5UxHRNGcgxubvRbvEn/cgXszXxBA+aMvoLhIdG8e//wk1B MmEuzHaLcYEAPh2sJU/u4V0qCmCWVViBTRl5JV70= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Michael StJohns , rfced-future@iab.org References: <04e901d69766$88e6be10$9ab43a30$@olddog.co.uk> <2a675967-1674-8d31-5912-8042592b622a@nthpermutation.com> From: Adam Roach Message-ID: Date: Wed, 30 Sep 2020 15:57:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <2a675967-1674-8d31-5912-8042592b622a@nthpermutation.com> Content-Type: multipart/alternative; boundary="------------9A662C1738C5D52EE6E6FC2A" Content-Language: en-US Archived-At: Subject: [Rfced-future] Naming the role (was Re: First Topic for Discussion: Thought Leader) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 20:57:28 -0000 This is a multi-part message in MIME format. --------------9A662C1738C5D52EE6E6FC2A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Changing the subject line for the benefit of the chairs, since this isn't really the question they asked. On 9/30/2020 3:44 PM, Michael StJohns wrote: > On 9/30/2020 4:16 PM, Adrian Farrel wrote: >> >> 1. I also agree with the question as phrased, but I’d note that the >> title of the role is important both for recruiting (small point) >> and for how the person is perceived and heard in the wider >> community (larger point). So don’t neglect the name of the position. >> > > I like to refer to the position as RFC Series Editor, but really in my > mind that's mostly translating as "the stuckee"... (only slightly > tongue in cheek). > If we're going to paint this particular bike shed right now and address Adrian's "larger point" of how the community perceives this role, then I think it would be ill-advised to include the word "Editor" anywhere in its description. I understand that this is a term of art used by the literary community, but I also assert (based on a huge number of conversations over the years) that its use in an engineering community lends the inaccurate impression that the role involves the literal (copy) editing of documents, which isn't the case. I think a misunderstanding by the community of the role has substantially complicated the relationship between the RSE and (at least) the IETF in the past. I would strongly suggest that we select a name that doesn't perpetuate this situation. (n.b.: I'm explicitly not weighing in on the question asked by the chairs, because I'm still unsure about the best answer. I understand the arguments for; while, at the same time, the IETF has a long history of Thought Leaders stepping up from the community to lead discussions and author documents without having a specific designation or contract in place for them to do so, and then stepping back down and leaving room for the next Thought Leader who has fresh ideas to express. I think there's value to both approaches.) /a --------------9A662C1738C5D52EE6E6FC2A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Changing the subject line for the benefit of the chairs, since this isn't really the question they asked.

On 9/30/2020 3:44 PM, Michael StJohns wrote:
On 9/30/2020 4:16 PM, Adrian Farrel wrote:
  1. I also agree with the question as phrased, but I’d note that the title of the role is important both for recruiting (small point) and for how the person is perceived and heard in the wider community (larger point). So don’t neglect the name of the position.


I like to refer to the position as RFC Series Editor, but really in my mind that's mostly translating as "the stuckee"... (only slightly tongue in cheek).

 

If we're going to paint this particular bike shed right now and address Adrian's "larger point" of how the community perceives this role, then I think it would be ill-advised to include the word "Editor" anywhere in its description. I understand that this is a term of art used by the literary community, but I also assert (based on a huge number of conversations over the years) that its use in an engineering community lends the inaccurate impression that the role involves the literal (copy) editing of documents, which isn't the case. I think a misunderstanding by the community of the role has substantially complicated the relationship between the RSE and (at least) the IETF in the past. I would strongly suggest that we select a name that doesn't perpetuate this situation.

(n.b.: I'm explicitly not weighing in on the question asked by the chairs, because I'm still unsure about the best answer. I understand the arguments for; while, at the same time, the IETF has a long history of Thought Leaders stepping up from the community to lead discussions and author documents without having a specific designation or contract in place for them to do so, and then stepping back down and leaving room for the next Thought Leader who has fresh ideas to express. I think there's value to both approaches.)

/a

--------------9A662C1738C5D52EE6E6FC2A-- From nobody Wed Sep 30 14:01: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 D249A3A0B8E for ; Wed, 30 Sep 2020 14:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2oCnP3tiRUw for ; Wed, 30 Sep 2020 14:01:16 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7190E3A0B8B for ; Wed, 30 Sep 2020 14:01:16 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 08UKx1JQ030402; Wed, 30 Sep 2020 22:01:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=92utsu3VXIHzwss3qoQluvKbj/MwbI9rG81aTOCElEo=; b=E2v+PBryJotuqF52h96MyZFVVzn67twgRvexi1yT5cudjMP8XE2Sd3gkaeetoqq8SoNA pgGSvWI6OHPnePYlXjq49YfxwEHLtyL9GDVAhlAbskYUAP6QELHVY9kzWIlGRd4ThHvp yECppMOjBpmDqROCc/IeuVb+FDhxF50y/di3wZo96dENSUlDUXDX2GKt7tMlE9sjbXnC L5P8nrV6QcteAQUrWrE0dLb1vI7X/4iALNQfrPkjnXMPFPJa8nZBQLbe8a1peEgiaIcE GkdprysbKaNhyPdomegFixTBDLCd1nM0yhCV56LAppxph7N4kHEJFq0qepWyFqImd3wT 5Q== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 33sw6cdp1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2020 22:01:15 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 08UKpWDZ018705; Wed, 30 Sep 2020 17:01:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint6.akamai.com with ESMTP id 33t0yxmy14-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2020 17:01:14 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 30 Sep 2020 17:01:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 30 Sep 2020 17:01:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Wed, 30 Sep 2020 17:01:13 -0400 From: "Salz, Rich" To: "adrian@olddog.co.uk" CC: "rfced-future@iab.org" Thread-Topic: [Rfced-future] First Topic for Discussion: Thought Leader Thread-Index: AQHWl1DTwsGNmFM/uEuyeuGuFAIjKqmB4XwA///Ji4A= Date: Wed, 30 Sep 2020 21:01:13 +0000 Message-ID: <0FE56F99-2814-4859-BE76-95D5B5D0F648@akamai.com> References: <04e901d69766$88e6be10$9ab43a30$@olddog.co.uk> In-Reply-To: <04e901d69766$88e6be10$9ab43a30$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: multipart/alternative; boundary="_000_0FE56F9928144859BE7695D5B5D0F648akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_13:2020-09-30, 2020-09-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 mlxscore=0 bulkscore=0 malwarescore=0 spamscore=0 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009300169 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_13:2020-09-30, 2020-09-30 signatures=0 Archived-At: Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 21:01:18 -0000 --_000_0FE56F9928144859BE7695D5B5D0F648akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGUgcmVzcG9uc2VzIHNvIGZhciBoYXZlIG1ham9yZWQgb24g4oCcd2UgbmVlZCBhIChwYWlk KSBwcm9mZXNzaW9uYWzigJ0uIFdoaWxlIEkgYWdyZWUgd2l0aCB0aGF0IHBvaW50LCBJIGRvbuKA mXQgYmVsaWV2ZSBpdCB3YXMgdGhlIHF1ZXN0aW9uIGFza2VkIGluIHRoZSBlbWFpbCBvciBvbiBn aXRodWIuDQoNCkkgd2FzIHF1YWxpZnlpbmcgbXkgeWVzLiAgUGlja2luZyB0aGUg4oCcdGhvdWdo dCBsZWFkZXLigJ0gdGhlIHdheSB3ZSBwaWNrIGEgV0cvUkcgY2hhaXIgaXMgd3JvbmcgYW5kIEkg d291bGQgYmUgYWdhaW5zdCB0aGF0Lg0KDQpZZXMgZm9yIGEgcHJvZmVzc2lvbmFsLCBubyBmb3Ig YW4gYW1hdGV1ci4NCg== --_000_0FE56F9928144859BE7695D5B5D0F648akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7F27C2577F746E438E79C0C33D3569CA@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0ODk1MjA2 NDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3MzcxMjczMTA7fQ0KQGxpc3QgbDENCgl7bXNv LWxpc3QtaWQ6OTQ1MjMyMDY5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczo5ODI0NDQ5ODIgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3 NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1Nzk7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoZSByZXNwb25zZXMgc28gZmFyIGhhdmUgbWFqb3JlZCBv biDigJx3ZSBuZWVkIGEgKHBhaWQpIHByb2Zlc3Npb25hbOKAnS4gV2hpbGUgSSBhZ3JlZSB3aXRo IHRoYXQgcG9pbnQsIEkgZG9u4oCZdCBiZWxpZXZlIGl0IHdhcyB0aGUgcXVlc3Rpb24gYXNrZWQg aW4gdGhlIGVtYWlsIG9yIG9uIGdpdGh1Yi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMg cXVhbGlmeWluZyBteSB5ZXMuJm5ic3A7IFBpY2tpbmcgdGhlIOKAnHRob3VnaHQgbGVhZGVy4oCd IHRoZSB3YXkgd2UgcGljayBhIFdHL1JHIGNoYWlyIGlzIHdyb25nIGFuZCBJIHdvdWxkIGJlIGFn YWluc3QgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzIGZvciBhIHByb2Zlc3Npb25h bCwgbm8gZm9yIGFuIGFtYXRldXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_0FE56F9928144859BE7695D5B5D0F648akamaicom_-- From nobody Wed Sep 30 14:08: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 419573A0B9D for ; Wed, 30 Sep 2020 14:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 cnJ8ijVWlpfW for ; Wed, 30 Sep 2020 14:08:06 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112153A0BA1 for ; Wed, 30 Sep 2020 14:08:05 -0700 (PDT) Received: from xse10.mail2web.com ([66.113.196.10] helo=xse.mail2web.com) by mx14.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kNjKW-0001BN-2R for rfced-future@iab.org; Wed, 30 Sep 2020 23:08:04 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4C1pkW4J1kz2mN for ; Wed, 30 Sep 2020 14:08:03 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kNjKV-0001hf-Fq for rfced-future@iab.org; Wed, 30 Sep 2020 14:08:03 -0700 Received: (qmail 20486 invoked from network); 30 Sep 2020 21:08:03 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.238]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Sep 2020 21:08:03 -0000 To: Brian Rosen , rfced-future@iab.org References: 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: Date: Wed, 30 Sep 2020 14:08:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.10 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.10/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.10/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4gRAP05Abc6WsAqo0v4scaJQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEIAgOjD+G97FMiE2PPlf1fw7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsezUTEAumaS8EPUiWeF3NFNfJ7Um9X1e60u5Tfw0/jsktyQGJGiI+AU6UrmF6rIdmD91 oL0KcN4ik12A5PQIEgOOrNnS7lMep1whohzQ+RYzz3uXCC1A5Cukky0WFo38JXT3Y80OmAux3oN1 3+ztUzneij0QEutzlg5q0ek9e13ZUQ9mDnaXtu0kZC/OWmUorWiLYBFzgALLju//jJE6/48O7On8 OyTLxGbf9+8YBy9DAXW8TfMUfXZNQGXIjuXCLLpyexbAnu2yCelC2Z0Fs3fqw6nIoDr0sXUZ7YZo 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] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 21:08:07 -0000 On 9/30/2020 10:40 AM, Brian Rosen wrote: > So, we think we have created the issues list, and we would like to > start on one of the key questions that we believe doesn=E2=80=99t depen= d on > other decisions. > > Is there a figurehead/thought leader, regardless of what the position > is called, how they are selected, who they report to, and what duties > they have? =C2=A0 > =C2=A0rea > a > Please send your thoughts on this subject. =C2=A0We would actually > appreciate +1s as we go through this process so we can try to gauge if > we have any form of consensus. I am not sure that we need "a thought leader" for providing the publication expertise. I observe that changes in the series tend to be big steps, such as changes in formats, or changes in reference methods. I could easily see hiring publication experts to produce an audit and explain all the wrongness of our ways, and then have a working group drive for consensus on solutions. That would not require having a permanent expert position. -- Christian Huitema I From nobody Wed Sep 30 17:23:19 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 934633A0D95 for ; Wed, 30 Sep 2020 17:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, 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 HA_PvYijAwZQ for ; Wed, 30 Sep 2020 17:23:17 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4988B3A0D8E for ; Wed, 30 Sep 2020 17:23:17 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id 5so2427192pgf.5 for ; Wed, 30 Sep 2020 17:23: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=ST0ajjtT+M/fPZlVs0i7d1Ta1UuINhDWDRNNyVl8Mg4=; b=FHiFGrJjrGygvhwvLTr24eRlxDnlEyMusexWq2RXfUnxzDO4q131vWowyutwALx0kQ 9thk8rIW+FyV1i6jD6E0WrdYks7Y78kAEAb80HuOdTxMlFB2OUztIGcIleezgh46gwaZ u1xYaisHdiH9cVxS9p3XiP2TG1s6IxQDhgB0c+SwIpGZdmQo+s3Cdm3Jed4bpRJafqN4 HrUdV0+DmY3LzSxy3nkro+W4ns2wuRvihi1jjV4Hz3+WEuJcTWK1kv4rjYEibz3H7H3P WB4qwS94KGlZ0IsQRZEsCFgY5iwJ3IiTuDnNAwfbgSHJS+BtKGfXG0W/sXaqLoHaPCFt cefQ== 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=ST0ajjtT+M/fPZlVs0i7d1Ta1UuINhDWDRNNyVl8Mg4=; b=CYB+xs+13YDSortogHdW7XX9rtZMQnWPGjMhref6AUu9nmtMwTHh86qPyHP9piGKu1 mVwkk7ZfZQ/C4j3Gv6LL3xwxX4jGqmKpYQGVgU/KXdqbjUwSVetVYDMzmIUjo/GDTsxs /VOzd7cQYa+mTB2Ip/G83x78m1cjHM6LxJPls9kLxL4hcbZP3lI60uqjZZq/LrXxywjO k8YM4cloqmykauHKge4dkL58ZdkzSZXG1hgE3JarlA8HSsFuGBm3/q6YiZEmow0ORqCh 80oo75tW/sfLgriHtJ4ox4RQIFsGydRgaF7a7Nl7u1xq8Wgm2YU0SH50qrUwa2PGRXoF UUcA== X-Gm-Message-State: AOAM532ikJ5O216EhdbqWssgpLEun2H9hTyMUOJ3795KniqS0qHPUwMA yD7ES4B9bDUwqWQnDx7ywIK6S9VwIOz9GA== X-Google-Smtp-Source: ABdhPJzZ/kH6zRNM7WV2HyNqI4GtvoGOQnlIfSagGB9JUAM3ke+xUF4VFajUq7kerR2BFcBYLIACpQ== X-Received: by 2002:a17:902:9a45:b029:d1:f575:37d4 with SMTP id x5-20020a1709029a45b02900d1f57537d4mr4644248plv.57.1601511795880; Wed, 30 Sep 2020 17:23:15 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id 201sm3890688pfb.173.2020.09.30.17.23.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2020 17:23:14 -0700 (PDT) To: Brian Rosen , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: Date: Thu, 1 Oct 2020 13:23:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 Oct 2020 00:23:19 -0000 On 01-Oct-20 06:40, Brian Rosen wrote: > So, we think we have created the issues list, and we would like to star= t on one of the key questions that we believe doesn=E2=80=99t depend on o= ther decisions. >=20 > Is there a figurehead/thought leader, regardless of what the position i= s called, how they are selected, who they report to, and what duties they= have? =C2=A0 Yes Brian C > This is:=C2=A0https://github.com/intarchboard/rfced-future/issues/10>=20 > Please send your thoughts on this subject. =C2=A0We would actually appr= eciate +1s as we go through this process so we can try to gauge if we hav= e any form of consensus. >=20 > We are basically looking for a yes/no. =C2=A0Your opinions on secondary= issues if you think there is such a position are, as always, welcome, bu= t we are really trying at this point to see if we have consensus one way = or another on if there is such a role. =C2=A0This is an opportunity for t= hose who haven=E2=80=99t spoken up yet to weigh in. >=20 > Brian >=20 >=20 From nobody Wed Sep 30 23:00:49 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770A33A0AC1 for ; Wed, 30 Sep 2020 23:00:46 -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 SwS-rDI3d4jB for ; Wed, 30 Sep 2020 23:00:44 -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 438E83A0ABC for ; Wed, 30 Sep 2020 23:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=229; q=dns/txt; s=iport; t=1601532044; x=1602741644; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Qa+zHW9DwNAwMLtnbvZnxXa6uw9m2fXuF8s1Zpbv2Fk=; b=mzaZY0KQhAUoJTS3ZoW30O1YHQTvRyK2Sh6uDRogtj4yHblycGkR8Lfm vd/nZIn7BJAg2G5bzwR4k2MSb0x83EFA0xvK2WjILLIyOoOn5OjXRyGww zAAlcGibqXFGeTIN6nozsRVjMGZO64HjLLZ8t1dMlakMhKMkIpF2WgTNK o=; X-IPAS-Result: =?us-ascii?q?A0BpBABLb3Vf/xbLJq1gHQEBAQEJARIBBQUBQIFPg28BI?= =?us-ascii?q?BKEaYkCiCGcSAsBAQENAQEvBAEBhEsCgjImOBMCAwEBAQMCAwEBAQEFAQEBA?= =?us-ascii?q?gEGBG2FaIVzBiNWEAsaAiYCAlcGgzmCfbQ1doEyhVOEdYEOKo1JggCBOAwQg?= =?us-ascii?q?k0+hD2DFzOCLQS3RoJxgxOXRwMfgnwBEYoAhROOdq8+g10CBAYFAhWBayOBV?= =?us-ascii?q?zMaCBsVZQGCPz0SGQ2OVo4SPwNnAgYBCQEBAwmPEgEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,323,1596499200"; d="scan'208";a="27602891" 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; 01 Oct 2020 06:00:40 +0000 Received: from [10.61.236.49] ([10.61.236.49]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 09160dru015590 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Oct 2020 06:00:40 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Eliot Lear In-Reply-To: Date: Thu, 1 Oct 2020 08:00:39 +0200 Cc: Michael StJohns , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <9DAE51C2-4355-4601-AC83-E3EBAC27F073@cisco.com> References: <04e901d69766$88e6be10$9ab43a30$@olddog.co.uk> <2a675967-1674-8d31-5912-8042592b622a@nthpermutation.com> To: Adam Roach X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.236.49, [10.61.236.49] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Naming the role (was Re: First Topic for Discussion: Thought Leader) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 Oct 2020 06:00:47 -0000 Adam, Adrian, Mike, I=E2=80=99ve opened Issue 24 on how the role is named. I would suggest = that it is a good lead in to discussing what the job actually is (Issue = 11), so please don=E2=80=99t stop discussion. Eliot