From nobody Fri May 1 00:36:11 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D0E3A0B52 for ; Fri, 1 May 2020 00:36:10 -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 pGvmK0bgc4SS for ; Fri, 1 May 2020 00:36:09 -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 EC38D3A0B59 for ; Fri, 1 May 2020 00:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2464; q=dns/txt; s=iport; t=1588318569; x=1589528169; h=from:mime-version:subject:message-id:date:to; bh=R2vGLXXnwjQZEmYK1YEx/twG0CMYgThI7e6Gq9iYLUg=; b=l7og3wxj+D1MvzWq6DT7lYgciDUpU30wTgZ0Ogzij6ZNM6U4VSAlBnUS Pkgm5JCjty4cVLMKrZ5thANdoduM0P/JcPaowjMeOKWgpgqmpdqhTW5xe dXksGv3IzCRGErMVLYEE+k/iJFVLrF5ha3gHaPt2VOOu4AQOdTzP3ovtE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBBwCHx6te/xbLJq1mHgEBCxIMhR9?= =?us-ascii?q?VIBKETIkBm16ICwsBAQEMAQEjDAQBAYcaOBMCAwEBCwEBBQEBAQIBBQRthVY?= =?us-ascii?q?Mhht1AT0ChBgBgnwPpEaOEHaBMoQ5AYEWhRYGgTiMW4IAgTgcghiGDoJFM4I?= =?us-ascii?q?tBLJEglCCboUmj3YdnRSZYJACg0MCBAYFAhWBaSKBVjMaCBsVZQGCPz0SGA2?= =?us-ascii?q?UNIpYPwNmAgYBBwEBAwmPOwEB?= X-IronPort-AV: E=Sophos; i="5.73,338,1583193600"; d="scan'208,217"; a="25757888" 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; 01 May 2020 07:36:06 +0000 Received: from ams3-vpn-dhcp747.cisco.com (ams3-vpn-dhcp747.cisco.com [10.61.66.235]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0417a513003046 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 1 May 2020 07:36:06 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_5DE842FC-3E6F-48E3-B3B2-CF7006118EAC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <4429DC0F-E674-4F2D-A3E1-AEE7A680A821@cisco.com> Date: Fri, 1 May 2020 09:36:04 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.66.235, ams3-vpn-dhcp747.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] follow-up in virtual meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 07:36:11 -0000 --Apple-Mail=_5DE842FC-3E6F-48E3-B3B2-CF7006118EAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone and thanks for doodling for the meeting that will take place = in just under two weeks. As I previously wrote, we=E2=80=99ll do = several of these virtual meetings so that everyone has an opportunity to = interact. This next poll is for a follow-up to take place during the = week of May 25th. I invite you to doodle now: https://doodle.com/poll/y7ia9vvzifrhrycv I will close the poll on Wednesday, May 6th. I have taken note of those who indicated that they couldn=E2=80=99t make = the meeting on the 14th, and will attempt to accommodate them. As part = of the IETF =E2=80=9Cshare the pain=E2=80=9D philosophy, the 9:00PM GMT = slot is not offered in the poll. Eliot --Apple-Mail=_5DE842FC-3E6F-48E3-B3B2-CF7006118EAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi everyone and thanks for doodling for the meeting that will = take place in just under two weeks.  As I previously wrote, we=E2=80=99= ll do several of these virtual meetings so that everyone has an = opportunity to interact.  This next poll is for a follow-up to take = place during the week of May 25th.

I invite you to doodle now:

https://doodle.com/poll/y7ia9vvzifrhrycv

I will = close the poll on Wednesday, May 6th.

I have taken note of those who = indicated that they couldn=E2=80=99t make the meeting on the 14th, and = will attempt to accommodate them.  As part of the IETF =E2=80=9Cshare= the pain=E2=80=9D philosophy, the 9:00PM GMT slot is not offered in the = poll.

Eliot


= --Apple-Mail=_5DE842FC-3E6F-48E3-B3B2-CF7006118EAC-- From nobody Fri May 1 01:11: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 D77FF3A0BEB for ; Fri, 1 May 2020 01:11:05 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=mc9s06pU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qGM/HU0u Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa6qQgOuQ9t6 for ; Fri, 1 May 2020 01:11:04 -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 1091A3A0BEA for ; Fri, 1 May 2020 01:11:03 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 0A2743A0; Fri, 1 May 2020 04:11:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 01 May 2020 04:11:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=e RKlPzsMrtxTqC8sCNj2iOUo8upqhlKuMc9fnojkznw=; b=mc9s06pUyh/RZam/u I0lA6T5Gp0FtdEaeuHq/PII4TEHKFdJifli7ZPWXUc/sNH96DAUqfMXqORSSHa9f iaSbgQLlfH77SBkpj1OrGUFvlN4MO9GH+oFIAhWdOZtq5yAqBe0k+4OPUsHyh8TB qwyRZhWrUVdgJ2NZZol6cNTn8yaS9xShdJh4/bswiQ7arryfwWL9SJi0rG4/yUDW v7AiHBhtB0dJ9LH2/O6YIqHz8Neb2iLx3Fe2AbgQHEmSfXXvBVxYjDdG1hRHZxfe 6bZ+isjexF7WUSzp57t/vK3LbSn1wVZBSOXtqEBZ2Zf5fi/XeSMJw2IatoXdwpjh g8gpw== 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=fm2; bh=eRKlPzsMrtxTqC8sCNj2iOUo8upqhlKuMc9fnojkz nw=; b=qGM/HU0uNZ0DxuHvbdBf6WoKL7z/pu1ZhBBMEynr6IMHV5TFC4ClGR1y3 COv44q5xloDmjggqqqH5pdsAmYfbLzjnCDHuSi7iVoNuI6izVPN44b3CskZ9dBpz GLXkdy3sJOhoGL/r6JIuIYjnDmL5rzbU5yV/yz7avT/P3swJu1q3Suc4R63ZjQAd /lzh0RYQ4GAZtxcZkGlV2pMi9VCsgDc3Zuw6X/I7oCt9bpZnMZZ/JdEER1I5FWit Kj0qByyJoz03ZWpkufsPzcvZGLzf8V9O6UQYc9tb6fA5rjYYwHIcRVycx1ydmr33 T3xAI4aOho/knKKDd8qq14aEiaXNg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieejucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh eptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhkucfpohht thhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpe etfeelffejfffhheehfeefgedulefgueejudekieegvdeghefffedvheffieelkeenucff ohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothes mhhnohhtrdhnvght X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id CEF033065F56; Fri, 1 May 2020 04:11:00 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <4429DC0F-E674-4F2D-A3E1-AEE7A680A821@cisco.com> Date: Fri, 1 May 2020 18:10:57 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <59A885AB-1F57-42DD-9B55-CFECF44D2C16@mnot.net> References: <4429DC0F-E674-4F2D-A3E1-AEE7A680A821@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] follow-up in virtual meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 08:11:06 -0000 > On 1 May 2020, at 5:36 pm, Eliot Lear = wrote: >=20 > As part of the IETF =E2=80=9Cshare the pain=E2=80=9D philosophy, the = 9:00PM GMT slot is not offered in the poll. I'm not sure that's really the best approach. The extremely limited = slots you've offered put the proposed meeting at either 1am or 4pm my = time; guess which I chose? I'm sure that someone else is going to be put = in the opposite position.=20 Rather than having us battle it out with a false choice, why not open up = more diverse slots so we can see if there's a time that's at least = semi-humane for all? Or, rather than using Doodle to select the time, why don't we calculate = the 'least-pain' time for all involved timezones (as we've done on the = IAB for a while now)? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri May 1 02:39: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 C80FD3A0D52 for ; Fri, 1 May 2020 02:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, 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 JAFx84ioXsL3 for ; Fri, 1 May 2020 02:39:07 -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 83D653A0D51 for ; Fri, 1 May 2020 02:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=361388; q=dns/txt; s=iport; t=1588325945; x=1589535545; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=hiVuISWVHzcoDPv6wK4bELzMAAO1SZuHsB+yzKTkmUc=; b=Lba/Zg/6FoPMbToUjb5DG9VOEHVbDq7HXhJetTo0/vfEDBgElTvgXjgz d8ww2SDxL8U+e5cOPv9cu2zI6+oM9jK7anx1xzQnNxpVSM/Ty9WdUWhPy BWRHD0Onp1dFpC0ZHdNzxhsu9r3JDHvMwmTn0uNZyVMn7uUk4oO+IHTGt Q=; X-Files: PastedGraphic-1.png : 259557 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBAC+3ate/xbLJq25VYdrBQEBEgM?= =?us-ascii?q?CAQUEhk/fNIGwGRgN?= X-IronPort-AV: E=Sophos;i="5.73,339,1583193600"; d="png'150?scan'150,208,217,150";a="25820892" 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; 01 May 2020 09:39:03 +0000 Received: from ams3-vpn-dhcp747.cisco.com (ams3-vpn-dhcp747.cisco.com [10.61.66.235]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0419d27U025889 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 May 2020 09:39:03 GMT From: Eliot Lear Message-Id: <07A54E01-C334-4C31-A8CE-880B7A78A476@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A8C81A1F-1878-4DDF-8313-A644275E00C7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 1 May 2020 11:39:02 +0200 In-Reply-To: <59A885AB-1F57-42DD-9B55-CFECF44D2C16@mnot.net> Cc: rfced-future@iab.org To: Mark Nottingham References: <4429DC0F-E674-4F2D-A3E1-AEE7A680A821@cisco.com> <59A885AB-1F57-42DD-9B55-CFECF44D2C16@mnot.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.66.235, ams3-vpn-dhcp747.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] follow-up in virtual meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 09:39:09 -0000 --Apple-Mail=_A8C81A1F-1878-4DDF-8313-A644275E00C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good evening Mark, > On 1 May 2020, at 10:10, Mark Nottingham wrote: >=20 >=20 >> On 1 May 2020, at 5:36 pm, Eliot Lear = wrote: >>=20 >> As part of the IETF =E2=80=9Cshare the pain=E2=80=9D philosophy, the = 9:00PM GMT slot is not offered in the poll. >=20 > I'm not sure that's really the best approach. The extremely limited = slots you've offered put the proposed meeting at either 1am or 4pm my = time; guess which I chose? I'm sure that someone else is going to be put = in the opposite position.=20 Indeed. >=20 > Rather than having us battle it out with a false choice, why not open = up more diverse slots so we can see if there's a time that's at least = semi-humane for all? Unfortunately I don=E2=80=99t think there is. Please see below. >=20 > Or, rather than using Doodle to select the time, why don't we = calculate the 'least-pain' time for all involved timezones (as we've = done on the IAB for a while now)? I did indeed try to do this. Based on those who participated in the = Doodle, here=E2=80=99s an illustration of the time zones we need to = cover, using timeanddate.com (assuming Apple Mail doesn=E2=80=99t move = it): That is a pretty wide swathe of the planet. The coming meeting will be inconvenient to Europe and all but impossible = for India. The 6:00am GMT slot is also inconvenient for Europe, = inconvenient for the West Coast, and all but impossible for the East = Coast. The 3:00pm slot is inconvenient for the West Coast, but all but = impossible for Melbourne/Auckland. This assumes the same group of = participants. I=E2=80=99m sure there will be some variation. Thus the share the pain approach, so that everyone has an opportunity to = participate. However=E2=80=A6 we have time (so to speak) if people want to change the = approach. Eliot= --Apple-Mail=_A8C81A1F-1878-4DDF-8313-A644275E00C7 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_B2080E11-15D5-4295-AADA-3B013FAFF482" --Apple-Mail=_B2080E11-15D5-4295-AADA-3B013FAFF482 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good = evening Mark,

On 1 May 2020, at 10:10, Mark Nottingham = <mnot@mnot.net> = wrote:


On 1 May = 2020, at 5:36 pm, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

As part of the IETF =E2=80=9Cshare the = pain=E2=80=9D philosophy, the 9:00PM GMT slot is not offered in the = poll.

I'm not sure that's = really the best approach. The extremely limited slots you've offered put = the proposed meeting at either 1am or 4pm my time; guess which I chose? = I'm sure that someone else is going to be put in the opposite position. =

Indeed.


Rather than having us battle it out with a false choice, why = not open up more diverse slots so we can see if there's a time that's at = least semi-humane for all?
Unfortunately I don=E2=80=99t think there is. =  Please see below.


Or, rather = than using Doodle to select the time, why don't we calculate the = 'least-pain' time for all involved timezones (as we've done on the IAB = for a while now)?

I did indeed try to do this.  Based on = those who participated in the Doodle, here=E2=80=99s an illustration of = the time zones we need to cover, using timeanddate.com (assuming Apple Mail doesn=E2=80=99t move = it):



That is a pretty wide swathe of the = planet.

The coming meeting will be = inconvenient to Europe and all but impossible for India.  The = 6:00am GMT slot is also inconvenient for Europe, inconvenient for the = West Coast, and all but impossible for the East Coast.  The 3:00pm = slot is inconvenient for the West Coast, but all but impossible for = Melbourne/Auckland.  This assumes the same group of participants. =  I=E2=80=99m sure there will be some variation.

Thus the share the pain approach, so that everyone = has an opportunity to participate.

However=E2=80=A6 we have time (so to speak) if = people want to change the approach.

Eliot
= --Apple-Mail=_B2080E11-15D5-4295-AADA-3B013FAFF482 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-1.png Content-Type: image/png; name="PastedGraphic-1.png" Content-Id: <38D11126-7EF4-429A-8166-B8CC3DDDADFE@cisco.com> iVBORw0KGgoAAAANSUhEUgAAAoAAAAFvCAYAAADaN3rpAABmMGlDQ1BJQ0MgUHJvZmlsZQAAeJyk 3HdUE2n8P/qxrp0UuoUkoFKEFEAUgSQ0RYSEJjZIALuEBFRsJBNAsQCZIHYhE+w1CfaykGBvkNh1 FRLsZSXBsq5lnfs8u7/vOfd37x+/c88lx5fZySSfycwzn/fz7FERpJiWI5Pl90YQZHFeQVHqxGja tOkzaL/ZkB7g8e9PTt5iGV8onAKf/8/v//vPXw/+2/duIPys9OV81xJx7IGp3E+O8QZiz/97///t p9/sOYvzwO8vwK9VebKiJQjSQwyeey9bIoPPV4PnznxONAc834YgS6bkzc+ZjSBL4f5jcnJkKxCk mASeDwH7sP5nH/Cc/T/P/9fnwx86HxzfHFrmgtlzaDHSfGkRLW1+TtGCgnk0YZF07oL8Of+HY/3/ /LNkzvIl8PcYqWxF0YJ585fQ/juChIK8oDE0Dos9FkHg+f5/nMdwCT/63229ev37AnwuBL+U4JcN fOqwvKVFxf+rRE8EIYj/038jSPgfCBJ4GkEo4PfhwQgy4zaC/PYPOEehCDJAgCDZbv/345blFOX8 +wTW7zl3LoJ8PIQgg6ciCNUC9if9/32dTCb/b+ep5//2X04NUC8ZlMmFcodAk59Csw9DC1ZCFQlQ lTu0/hX06Elo0xp4JluXQdv3QbvGQcGZOOb0Be5BIpFGgkpvaeXAZtZ64FaeCLhMOBwoEt0BJknX ALnoeGCoygEM1IDv4TRaB76Rk3fzKGjbAOCYjkC4Z9cJYBFB9LB7df974UKcIoCetHDwfb6wwJF7 3eA9BOLCe8BicSMwVQa+i1ewMgzogX0A9sa1CDLioz4N+NzYD9jRBq77iFcdfwF/2QvBPhMJotcX 5gdYhZU6GANyvcB2ljcLXE0mwbsJfJACzhvzcA44TqayEIwi5tRScBaYLDW4+swh2s0IEmQ3gJEV dN/UH3jVbAXesIJvGvTCAe4aJo8g+rZz38AqvIIB94HiEeAu401mgvfyAnlgH94A4WtwhZ7lgLPE PV0I7iFuVSkY9dycmkXAsAZwPFxSow+CRP1p6gI+sIDqUfdsb4GO7mzw6iyCGHBOAO9oRLiurxEo HwbOsDA/CFwdYTr3GDBMuBzoDIeV4ENhFvBi6XbgtpozwPyGFiC/8RTQvaUejJV/boMjTP7e2Qy2 uH2MAm4iiCEfRTZYRbyrxwbgdo9PwMpAF+DyqN+BIkErkCeuBo4o9EAQ0d+lCqC55jJwT8NH4Ipj 4FyJki+Acyvi3KEDg56BkSMSfATfTvSUIKj+0icI0vumbMO/99JJVw3wYEAkcFskCixPBt9dtkAE RqxssmwX0LcUnFVZz5o6BJH+0fAn0HDMG1hxYRJw4Z2lwPnPrgNVnxaCPQMIwi0XBSNpEEW5EFZR msl/Ay/7gk9Wnp7wGbgn6QawWgSOU1kk/QVMV4IOoOTUTAQObgDnDX15zAnYdCEFuOsO6Jfo7udg hKDmT8fBPisJYugO7C7oGmo17D+I+u0AMBbUtpGgc6jvhTsDL02RAg3ZfYDbpExgiRKcT3WW+hYw ogFcX7VbI/gMrPsC6MnYoztq4NPng8H2QZ/agBcJwusODp65x2sjYJWGXggY/9ofjGSgIwyMFu2z yVDLLHAGtOcLQNfU7kLhqxXqMcB52k5gXCMYdVpGC7gK2oF3QEZoSc/A9dXGfAIjqqEnQfgM1IMz MrzG4A960CfDv92k0WU4OJ7GQaHDEMRATHoPtM/MBD6VgBZluKIAA85wBAPn2KDWxgALDaB/GIQt lcDxd0DXNHCfgVFnWPwJbGkMJQjfGOMVBGHsMIFPdC4xnYNVWlhuAcDR7A7gsHjQJVqGTD+CIKaf i8Cxmd7Ik4C3VWuBp/EK4A7DdOCqFtBbTLNvwz3nP5sB3PkJdImWGQQxBjWDTjp6pWUEggx9b/m3 J96ePngZMCUQdInb8bHgrr89PvMa0H9hLNCtZCiwZzU4Tss7DeiTFosefLLluEkOrLoN9rdUdj4D nvt4CewpJQhWixWMpDF8G+hfjIU28F16FneqYa3OWj+QyJ0b+CA/OhUZB4Gy+aBvd4pWgjuoM7Gq BBhaD0Zo53AdOJ7OnkYwMm0vLWDU2Q52gp5gM3+E711CEKFODh7oXD8cIN98ZzvA+aWM7T4Nq3QT 3uC+6P4r0gz8M20ysGMu+Mxu8wrQH7qbKkEf6D5QB/pV90YduL+6VxjBtevOsoC7ppvX6Ykgjj+6 wfftnksQ4+UwB0MvQoNo0GEHoTAVhvpDx/8JFZ6Fziagy3+DbpgKrWNCYb4QRPO/r1qGQTtdoN0O KEE4LUbAWXZSgYShOoEx6NXtFA/66AkncLa4hU7gHAtYTuCaZX90At2l4JSTK0gxuRO4k1RxThQE 0Tg5gXF39LETmNM07YXbWzc5eYEUMzmFgBQTOi2AdUh9SOB+c/r1Pw+v3VBmDpQ7Cppsh2afgxZU QBVpUBUdWt8FPfo7tKmS1IvUq7WE5ERyaj9EGkUa2TWBNIs0E1T50+sbgpAzvR6TFOQUrz+8PpAn e/3BrCNzvR5xZ5OZXncF4eThXjdFLuT+Xi0F3aTPXqcUt0g2r0Oq3aRWL41mGem8V61uEumw17pm D1KD15q2fiStl6ojhHTIa3+XifTAq5sgKMlM0FWpI5nXyb0oBuZjmi+lgXmf+RelmtnGvU9ZzLwk OE+Zyjwt2k0Zyzwo3UBxZm5DC8jdzAosmWxmLsZ9yTpmjo4gY0xB8x3yMubEtovkeczkjg/kOcx8 +zLyGuYNgnD25YKr6xLPvUiWUZ9wu7xeUm9yXzN/UU9x23mDqDu5FiGVWsI1iZ2p07hHZSQqm7td 2Zvaj1uGfaRYuYvwx5ST3DT9OUoVN8K4hbKAyzJXUQTcMOtZSjR3miOGkskFVVwlApCFbqcERvJN 56fCAV5U5zZhT2a98znBV26Xc4PgrdDHuVzwSJzgLBZclOU4hwuOKqXOZMEmdSH1hWCldhH1tEBk mEWtFMSY4qk5glDLJCpfMMFWQh0jyOkeSJ0geEUQHoNF4C71LBA1UTxdmsR+w/e5NIrpQXddcLEr V+6yTtxP0OUiEX0VR7kki57JVrj4iW4qd7v0FDWqTc4PRVu0FufDohWGB85y0UzTHedUUaLluTNL lNbp7ewqknefdfYSU8E98Ze0HXTLHOk5SrbrGlnC0DWuq2T8wJ2ui2RhUWddM2V+gkLXKJm76Isr Q9ZHNs21p7QLVGmX3lM/dTkpPdvQ16VSurPR20UslbeEuIRIJbczXUjS4s69zn9L936MdSZkiaDz D0UfgxnSOvQMpc4tTDnfHXULUuYEvHOjK6dF4m4kZWJyo+sP5QRRoetzpa+sp+sVJUVZ6Lob/a6+ 7qpArQ1DXKeiFxpjXYPQ3S35rv3R2ttal+eopvMfl+vo3Y/7XMzKtQTBkGFgvuX9CDtJuePJU+e5 IW531KV+x9yuqpdHBLqdUecnHXHbp87KPuGmVidKl7stU4cpyW4z1TT1BrcwdV/tn25k7F3jBNd3 2K2WVa6XsKbbF133YtefBbli6h4fba7b1CaCGPkeB31q9GT8OLXniNnaFNdq9wVa7ajH7iLttvAZ 7ina6ik57jwtmtXsPkZbUNDs7qydia52+66NUzPc2rWB2t1uzVpK42C3evxLy2y3EvzVbaPbdPzj s3FuPG3gx09usdpPBOG3Wg/mdv5/6A1UDkNj4LuGun8zNHuPd+82nBrn5f7KcGRym/sjg3YW5n7F oJbcc9cbFIpb7psNC7GN7ssMadpQ92mGcMN597EGr5Yx7s4Gp9s73b4aPJ/R3Z4ZMj4+c3vbOJwg Ascar4I+qTDqqNNGvTZxXH56FJnaR6zyWGh6EJrrITLdmvTSI9XUMpPuwTcdzz/lEWTaJX/r4WHC VO0eiGkFvtv9lSnHkOB+3TTRdNf9qCn0dob7JlNU5xv3MlPxR537hpYJIF8IM8h1Trj5LLUkgGPh uFwbmmv54XHY483tnpyhHlbL93idxz2LfXqJx1VL5yKpx2nLnZKXHnstJtVAjxrLYc0Pj5WWzfoL HrmWEtNCjzjLdMtHj1GW7E61xxBLzceZHoNugzEWYoUpNtbJ2kHdz6ywJbvsoe/u7Ovh7FnQOTHI z3NOJzd2uOe0ztDMes+ETr8FhOe4zqGrLnh6dw6o9vYcZPuq4Xl8sj3TB3k8st00fvU4Z2u07PHY bFvROdwDte3ufuch75xCEOMewRQbTzgCqH8Ev3PUuuwYvaI7yn2jZ1v3Kb8wz8vder6H5/nuvRkr PHXdO+bneuLdVSvLPFXd8qrRniu7F9Wv9JzTnanb5JnUzTeWewZ3+1lSPN26h3T28bA7jnTP8njf HUEQEf/AzIryAB2NOk5GEC76wECCcE8cGksQ3sjQSIKIPDI0hCDS/If6EcTcs0OHEcSKhKFDCKIy 2hO8t+6R5zuC0Pl53icI4yRPI0gxruc+kGIentUgxR57ZsIU8/JDEkF2rQIpNsArFdyfI7xGg4Tu 7QUWalzLiJcgxWpGWOAseIQJzEkHjQCpqLg5AswmVFUj9oEUE4wAcwGd8wgwE296Ap+3Xh4B1jrt H+C7ulZ4ecEU8yqDazCvMBKPNALqdRLKzIdymUBu8jevsaQJ2de9QkljC3Z4BZPYikVeLNIY1QSv QJKvZoBXAMnn6CMvPxKt6YBXEInRus0rihTQftkrm8TtyvDSkRYTBK0/DczXvX55/SJthf73YNZD ualQARmafR9a8O92xVyoig2t/wk9eh3atJXWl9antYLmTnNrP0YbTxvfxaNV0apAlSfMnwhC92Ja yST6eOYD2mIo8z2UWwkVRNLHMh9k/6IzmfcKrtNHMW8r6uhDmbdURfQhzMuaRHoPZpPOh/aJebLp J+1P5snWz7Ru5qWOUfS+zDddp+lTWGCM0X9ywYyWUca9TV7GeMz9nd6XcZp7gZXA0HNbuC8Zu7lG QT1jM/d30VxGOfe0dDxDym1EqYzp3AOqbgafq9FYGKO5G3U6xhBuRXM1/Qd3ddt6+mdubUcz/R/u 7/YUxjgeGDveUgHISp9Rgutks88xgY6+1ocsuMqa69NHcJFH9/4iaBZ0ez8TnBG1et8SGKQ672OC fegm7y2Cndgq72UCFZ7rnSlA9ZO8xwqkxiDvoYJFZqb3QEGJdR7wkP2Hd4RwLOiWbLj+GTVQdIky fFSLaB/975Hxoscs2sjxons855F+ojbhoJEuosviPj7/iM5LCZ9nIh361eeiSIt1+ewSqfHnPgoR qr/vM10kMV7yCRfNN7f6+IhW2Ab4jBAddWh9EsTgjI2OkIK1gW+Q1EQR+/WV7mLMGpUl/cQsHJUi /cA9NYonfSl4MSpQ+lTcZ5Sr1CIbPvK79IIyaORT6TF1+Mhz0gYtf+QWabUhZmShdIWJN1IgXWxJ HxkmrbBtHxkoNXZzRqbJJKAnb0DBasK/Gv2dUh+gQDWMU6NnKElBKaOTlQO4vUZzlT0FxaMD0a+i a6Pd0PeyvqP+QZ8qx46yobfUM0eZ0LPaZaPq0L2GqlHLULVp56gMdL3l91ERaF1n/1Fs9HH3/lFp ys1gzu+MPUCQQBp2lnI3yAer8/7Nl69mjjnlO1btF/nN109NS77o6652FaX49lb3l54f/R77oRw8 2oK9UwtGH8MeateMrsEuGPSj87GjptujE7G9t5HRwdjZzmmjR2Lfun+MjlODfhB0F78DZqzP8VPU nqwv+HbvFD9XbbJ/jd9g7aSIjX6Ilpd0zbdbOzZb49uh9ZNO8L2mHYqe8jVoB6g9fDfif2sX+Bbh zw2HfYV4q+mZLxu/dJvu64E/6iz3Haj1+Bjg66t9SRBskx6sEzh39MepwcHv9Vu9NweMMmT4jfS7 Z5gfftXvukE8ZbXfecPULL3fYcPkgvV+WwwRKMdPYRiDnfHLNXhqR/vFGfoayv1G6h0mi18//avb NN9u/dfOat/nhnEfx/n+bOwDOv99I1gxhr4wGqjTwnobN3vfC5ptmuR70h8zrRtX7b/GpJz80X+5 admscv8FpkWSPf5TTdkKpT/XlIyx/EeZInGT/wCTn2Gc358mZ1O9n9n0m+WX32mTS+dSvyOmtI8+ fpdaQH8dRzaDMzZ+qPk8tSSca27wobLbLZN9cwO4llOh9wPGWnQJpAB/y96ZIwKGWXbk1wQMtFTL D/l/s6Cq9f4vLAV4lP8Ny0z9A/8jlnjTVP9Ki6+lyb/Iwu6M8s+zzO+2+xffHkUQE4qsYGUUscJq pe6P3Gm94iMMXWub7RsQ8N72k1MZ8Mz2Jf5xwEPbh+mKgBu2Z4vSA87ZHpScCDhgu1Z9LaDWdkZz MKDEtk8/JyDPttHUJ2CSrcSiChhpS7C9DXCzFXfvCPDpZBBE1DeYYtyfMMX4wxxUn83j0x0HfHuO qeteFFQzZnP37NhJY6q6Z2XuG6PsTl3wcUxR98RVe8aIusdX/TUmsdtf039MSLeHrmuMZ3dfY2MA 4ei2TA945vjD9iHguEPe7RdwttuJIKLPwRSLOQ1SjBJ7F6zMX0Zmg5Vzb+YPMMpVgSCz+VMD+QSR 0RAIOsV8RaAvQazcGuhOEFVhgb8RRP36MWAmpNs1ph2kWO2YyyDF8sYcASk2dIwapFjzmGSYYkFW ZAcYyWAF7/SICb4VbTgTrNdZ/kFglc+jBl0EKfY6CGST6GjQGpBikqACBEEDgsCaUvUmKBmk2L4g sOLXzQ2agCDNvkFgfdk2KAisXDtYQcUgxU6DzwcpxhxBmglmSntIh0mpwENed4L2kQ4wy4MOknZz JwYdJu0UuABrst+CLRUFTeDVVYqaoF0kmWp2UD1priYkaDspS9c7aDMpo+lu0A5SauvFIB0ps90R 9JA0r0vB5JO2gSpyGshKJocWRjrL9KOF04ZCmQYoVwwVDINmd0AL9gDHKwqYvrQw1QTmaFqoZgBz FI1z9DHTh8ZsOsQcQwtu3cmMpkW3X2NKaDldmcxHtEYwHxvMGgzOUE9WTzKD+Yv5i6aG/vfgbocK JkFFPaAFLVDFGqhqClTjDD3aDm06yOrH6te6mUVj0dqbWUmsKV2TWOdY4Mqz7nHB1Wf34L4ml7Lp 3Ed0d7Y/9z5LAuW+gwrWQkUh0IL3UMVBth/3viqfPZJ7VxPG9uLe1v3Gdue2Nj1le3Dvtd5hj+a+ 7+jFnswb1rWJfYRXBzrMQwG4XzhswWPyA84KwUX6Rs5hwQnWL84+wSleGmeX4JTgKadecEqk5GwW nJSO5VQJTij+5pQKjqkuchYLdJrNnNmCg7p8Tppgd3M8Z7LgYBufIxBc6FjKmSf4Zv+NYxKCGVOw i+gDggRvEpkptBBEdIqBhOSItOzKkKGiI7xdIRTRYSEn5DfRQZE1+Ltov7Q++J1oNzov+JFIg40P viTahpODdaIa3YfgraL1za3Ba0XVbTeDy0UHrPAzX9prgp+LwewiRC0F68pQf+l1Sl7oKelRRs5Y rrSWMyC0UHqCdyh0rrRROC10uvSoeFhogvSA9M/QMOku9EooQ7oT2xM6QFqLrw1xSNfr80PuS1Fj eohJWmaeGnJaqrGqQi5IbY4RoQNkWwlibDxqA/PkL+hFCh62A93PODcuHq3kKMYeQa/wZo/VoheE 3LG16O/ikWPL0FMy8tgCVKdExk5D92LdY7noTvz5WB8U098f2xctM14LtaOrzXdCn6Fa25DQN+gr R/3YAOUh0C2DsScIMu4jZqTcH38U2+09IHwptobzOqwNa+deD7uIPRI8DzuJ3RF9CduL3ZT1CgOZ pRwStgo7o3YNy8WOaIeGxWO4YUSYL6Y20cKcsBpLSBiCHbEtDeuNfe7uG8ZTXyCI8HT8PoJMGIGf p/aa8A7HvdMibuKlwZPGPcG/RT0Ydxv/JOCPu4R/EFWOO4G/kF4c14A/Qe3jKnGLmjJuMX5RGzRu Gn7SEDcuHN9nyhxHx/dYlo8j4c020ziy9rfulHEJ2j/AbHy/HsxnI1foT1NDolL1dd5buXF6eXDD +IcG18iK8a0GUnLmeJOhf/ar8Y2GHlLBeI3+K7pr/Ab9e+zF+MX6Dq3n+Ol6i2Hi+Ai9ySQZz9D/ btk5nqy/a3s/3sng2S0fzzd0EQR3lPEW7MnGE9RpPJtxu/d9/gvjquDP4RdMoRNuh581MZPo4UdN vtm9wnETreBAeLXJFR0dvsI0AKsOzzP+g9vCJxu7DKPCWcZ2U064q/GBRRPey/jO9td4wjSme314 gAn0Xf5dM1gjRx82N1NLYraZ9/g4x+43V4TERZyxJIRbJuywzErUTsAsGbNeTyizJEnuTiiyxCjW ThBbwjDXCYkWf7xyQqhlqL5rgqdloIkf/t380VIW/spM2J6F2ywTupdO6GMB649YnfUvBImrsHZS 98cvt17zSZlYYz0cspW7zjYvvCRimW13wp0Iia1u5qaIHFtt/t2IVNt6+eUIvk2hWhMRZCvEGRHu tlz93gmELdXkMuG5jW9ZOqHJRrHpJpywxXbzJ1hsnwli4mmYYpPUMMUSVsMUm7zb/jXEHr3NcSSc H5neTZ5oiJzcPWBG/8io7p6LjkayHX+XvI6kOz5UWyOdHJ2aQxE/HHf06REvHBeMLyOuOxotuRFH HRrb7YhVjnhHV0S14ylBJPaCKZb4BKQYaYoFpljSV4IIFcV9A+MvNCqOIOJio8CabdrMKDZBLFwV 5U0QJaQoZ4KoTo4C79WkRjoIQh8YCT7B+CbyEkixqkiYYsMjMZBimkgeTLGozT0GgasfC1JsDdcf rmS4fUCPDowCdxEvNEqPIEJ6VAVIse9RYpBiV6LAN0cro3wQBJscBbo53i/yO0ixy5Eg9ZpXR74F KTYnEqxVOlZHgU+z9406DFMs6jLpEFhXBpFDSeqoSPJIr+9RXPII5uGoaDKVWxgVQ+4riI7ik76K 3KOiSK8K7FHjSfcVl6OCSZdVO6LGkE5q8qNGkvbpIqK8SNuaB0X5kGpaf0ZNINV0jI6SkOq7TkQ5 SDfASB5CA/kZpaWVkmxR5TSMFgtl3oRyl0AFAdDs91GradUFx6LW0NYrUOBqlQBsUWjoUWW0ZUc/ RSlphU1Xo9bTClvPRe2hydvfRD2ibetazs2igbklt4QFVqtcHotFHs+ls8bSTnFprDCWB5R7FCrI hIqGQAtuQRUqqCoNqvEEjj36AtrUyA1gRbXi3ImstPYbXAVL0ZXB6816SxA8Mo8MrkBfXl8yxkN4 CJ3F/cX9xVoH/e8h2AIV8aEFf0EVjVBVEVQTCj36g0twfzVd5A3gDWg9whvNG91u4WXzsrvSeS95 4Lvw7gp7gSrdAju5gz9QYKXv4nsJ7rOd+XTBPd5CqOAdVLQaKg2EKjqhqh1QzXSozhPaZOP7C2yt 1/kxQqTdzl8ijOpayv8kfAzu/Quiv8G930tko4yKjhDdZAyIlonOsndGbxA18rqhwrTo9aJG0WOo dEn0WlEj6hW9WtSouheNiho1tdHLRXrddPAuXfNo+N42l2il6ElHVPRBsVfX5ZgR4lYw63smtYNZ H1d6nzIvplbaxFgQ80a6n+Ma6y/dwq+IJUl3CptiB0h3isNje0l3Su/GfJfuQBUxDul2LCzmhXSr 5nvMQ+km3eWYa9Ka5i0xLdK6trUx16XGDkPMO1k/e3DsVNkV0GE46BsEid2DtlIa4ijoCYYxbg26 g1MR9x5dHU2KK0G3Cb/GLUG3ipVxC9HNMp+4bHQj+jhOgGLYzjguWonPjQtE1+rHxXmipUZS3BC0 0tw7jozqrGPiAtAf9iNxKuVVcGc3YmBdGT8Wu0p5GH8GO+o9ZGIctpHzYeItbHm0Kv421iD8GH8V 04i3xJ/HdsoE8UexrUrX+HpsI/Y6vhKrxo3xy7AKfV18DoYa5fEpWIV5WbwAO2htiJ+N/e0YEW9U 3wJ9TISDu3xiN36B2mdSBX7Ae2pCAF4ZPCWhDZfG9JrkhB8THp7UB9eJl078Gz8kmzLxLb5XOWbi YxxXkydexrfi3ycacEz/auJ2vMJ4b+JavNJ8f2IZfsTWc2IN/sMhn/hCe48gEsL1ICsTHumbqKGT V+l3e29PDNZXBO9JtOsXxEgTxuuvCUckMPWXxJ4JDL1R5p5A1Z9Vuib01B9TO0+y6w9qKZP+0GsN pEkX9FtMgyfp9VstHpP26U/aJk86ZujhuDDphwFkZSLfCLIy8aXxLHXalM1G3PthkshYFvxXMts4 O+be5BTjc0HC5InGDtGayROMj6SNkwONt9G7k4cZr2P2yf2NJm2fhE/GUwb3hHbjYdPohKvGgxZu wnlji6044ZKpv+P95N4m0JOTlpofIUjyCPMFqjz5D/NBHxfBMXNVyEThFnNB7LhEkWVQclDiVMtv 2WcSJ1t6SIcnRpi/o4sSA8zd2KFED/MbvCOxt7nd0H9yl/m2KWjyHXOTJX7yRbPZVj75isXJ8XXy L8t9ghA8soL7RVhhfU49kJJgvemTmhpk1YdsT2NY1bH1U+bZBFNuTsm2Tc46OSXNFlsgnhJvi1A8 mzLWFoJNnuJj88e1U5xsXvq3id9sVNPoxGe2PpasxGbrU1th4nkb2fE88ZUNpEGqBKZYGg2k2JO0 Nw5nn03pD+x/hzgyHtkfx/VP3uaon5KeNNdxcpYiaaZDL1mVlOzYr4hI4jpw1YMkpmMznpE0zLFB b0rq55Cbhk9xOKQWyZQHjhzbiSm7HEMchikXHPvAGisJptjUHiDFhkwFd6nPi8zLMMWmgXVZ3MaU TIKYwkteRxAz/ZIVBJGvSi4iCLkmeTZBqIqTMwgC90uOBilmSg4kCFNssitIsdNJv0CKjUh6DlJs VRIGUyx5So/dYL0FUsmJLHACKXYtuRukmHvyDdDdJiRrwdnkJS9BEHFQcgKCyAYlM0CKPU0CR4bt TQLrLHx+0iUE0Y9OOgpS7FXSfpBiV5LOghR7ltQFUiwneTVMseRCMhVBkizku6QbSd/IdTQ34Ebm 7aS/yWu4mqS/yEsFS5I+knNFyUl/kpOlvkkvyOPRHklPyD6qR0l3yE6aI0nXSD90iqRm0ptmQdIF 0pM2blI76WHHwmQ3krXrS/Ixcj9Q5QhtHRhjAbQ/yP2SPtMI2ioo05H0hfaLiyX9TfshiEn6Tvsq 6p30D627oC2JoL1V1ANtKlnSL9oDTWzST9pNnQfYx9TUldyb1tT6PNmHdqmDkpxLe9q1S4DQR4Ix 1oeVCKocYS0kpyUXsxS0zuQCVhkrCsq9ChXkQ0UjoAWPoYrtUFUWsFTjA0SPOoAlTcbkVayyVkNy PWtz+9PkdlZT1wKBnD0KVCnhgVmAIIkXRNYKAngcepLAkxfKOgLleUAFh6GiFKi0F1TRBFWVQDVR UF1PwVBeaNMNgS+P33pMkMjLar8vqOJt6pomHMP3IAihi9AFXOGBwoHkd8Lewt70UwJCQLBZgl+C X7zV0P8eok1Q6QSo4k+oag9UkwPVMeC7ml4JBwkHtd4QBgkD218LC4QFXXkpg1IGgSp3xX1Blbei L5Qg4U/RK4Z7ipPoMVuXMlR0lz8QKpwPFb2FSsugqC9U9QiqwaC6ycB7zQNSfEXPWt+kJIj7tRMp 68QpXYtT6Tlg1pZySvoDQVJeS19RFqU6S+8yilKjpSaOT+o86TH+jtQiqV74BipOgUofQdFCKOYG 1VyB6lalyqT65nGpK6TNba6ptdJXHYGpN2QhXdq0GTIwi0y9gIL7I60f+oSyJ20KeplxJW0TqufU pN1Hd0aPSEdQdYo87TtaI76a9hWtkUWmfQIpdjOtC92I5ae9QWtwj7ROtEZnSXuEqptr0h6jeJss 7U/0WkdFuqfSs+tLukb5jiDSvmBgPpiehN2h/JG+FzvvTc3og+3ifMnIxSqjt2fosBWpgzOKsdU5 9AwZVi7bmjEfK1f6ZoiwMuxmRgZWisszEjBUPz4jApM3/5MRhq1v68iIwY51fMxYoO5rn5nxTG0F HUaIP0OQjNP4TWrfqXT8uPeMqVvw7cGpmYNwNGZgZjE+P3XT1HZ8dc7kqffxclnbVLBSUy6casJR tcfU43gJfm/qHny5ftvUzfhS45yplThqTphag++1Zk1txL/ZTZle2ocEMfWOHmRlZrz+MnVcZrP+ qHfdtEn6jcEHp93TF8cUT5+hn5VGnsbSq3Iipo3WV8keTRumX69cN42kX6OeNK2HvlRLzuzWl+if ZVr1y4znMu/qFeY9mff0WuuZzA/6jw7XaUKDGczlS4wgK6f9bTRRp09HjQe8H8/wMFYFf59x3iiN eTxzmjE9be30QiMu/jJ9nrFOdmz6LOM2pXy6wLhJnTqdZ1RpmdOZxnUG0vRhxlLjl+mDjKvNb6b3 NzZYf4EtHxyZ04tMoPPPSDE/RZAZ98xXqfKZc80GH9dZJPOmkMmzLpmXxUZkLTPPSPsxY5+5Rbx8 Rp25SSaeUWM+q0yasdp8XM2dsdR8VBs8I8+8z+A7Q2jGTV4zxpkxC2kGy7zX5jcj0vzWIZ+x1nKc IGalW8HKYFaH9RX1QNYKq9knLZtpPRGyM/uzdUusVnTeujy9aOYD6y/R9Zmt1m/SVzNbrJ/Rf2Ye t9rV5Jl7rG+0jJm1VpuBPbPU+sgUOXORtc0yaWaC9ZBt3EyB9blj7cxK23aCyF7n4ILViYdjDPWJ 6JzDxWeTuMT+PcSRI7A/jRuQ62tvTu/O6uvIy34966cjWxo/q9sxHd0464UjDTPPuu9I1PaaddkR Y2DNOuYIN2XOqnewLCtnrXWMtG2blW5/7Fgyq9SxmCByBsAUy9GAFBuYGw9S7HkeFaRYdt4nkGI1 s8EKK0OdXQqOxiM7kSAKtNlgbYUGZgcTBNaQ7UMQ2p7ZYF1myMzuCVKsIQusui0vssDMuJOWZQIp lpk1F6ZYds+eueC79EaQISuyP4EUK8kGsw2mI/s0/NNw2RjoPgnZs0GKTckeB1JsQjZYfymHZb0E KebIMoIUa8qqBylWnoUiiDE+aymCmEdngbWbNQa+am/JXgRTLJtG3oogWQrKajKSdYMykOaVdZXS g/ku6yL5E/diVjO5U9CQdYrcKirNOko+LRVn7SLjaGTWFvJazD1rPVmqcWSVkDN1l7KkZF7z1qwi MrNtXRZGHtVxLMtC9rdHZpeTk0GVVNodUOUaPZrMzlpOX0M7m1VGX8XyzFpDX8Y9lbWOXihYmFVJ ny8ak6WiZxd8zcLoaYprWWp6vKoObBmnKcqqovvpJoE9hzZ7ZW2iU9ucs87Q3Tpiswh6QNe97FN0 GahSx1qJINkclp4szXrLukd3yrrDsrHyody3UEEFVBQMLXifdZdlUxzMusfqUEmy7rOeaMKyHrAe 6PpkPWRZmh5mvWLdbb2RPYT1vP1r9jR2v641IjJbAqoQPJCV2Wd4IvLx7FJeAV2SLeKtZD3Ozuat 5IVDBZehorlQqQtUcQuqWgfVJEB1g8C7VjXdzS7gVbSey97Ca2hvz+7kPejKEW3nTycIkUIYCK5+ ppBJ/ksUJmTRb4mGC4PZKSJXYQhvL1ToDhUdhEqnQBU/oKpGqEYC1Y0RuQlDmuyiUUJ+621RkjCv /YNoq3B31zxxUgoYlWIPsQcYQSQxiTJW3E/cj+Er7inuyb4i+iX6xfeHCkuh/z2ktVA0DKp6CdXs gOrSRYSIaKaKB4sHtzrEweLgjj7iVeJVXctyAnPATE18TzYAVHkh/UEpFH+SfmAocnpJbZzQHLL0 Ab8xx016N6UHVDwXKn0LRZVQzAequQ3VrYE2R+WMlD5rc8lJkA3s8M7BZDO6NuRGFHqBu1KP/gJ3 5T30T8qBnG/oHwxzLg29xtHkxqJnopm52agupTY3Bz0q7oTKhFD0IRSTQnEqVGcE6pqLcgvQprbo XDX6piM+944ysmtX3vJSJ4LIPYJ9RpDc55iN8jTPE7vl7ZGXiZ3mEHm12O7ofXmXsdrUEXntWFVO IVR2Ne8pVqWMzHuCVWHX8v7AqvDcvIdYlf63vHtYdfNpsL2ubXXeZ+xqx5rZgWqvriezL6m/E0Te Tfw9gswm4w+p/WdPxy94i2Yfwg8Fz5j9E6+NcZ0Tj6OpDXPkeGFu3zlz8OLCsDk5eLFyz5xZeLHa b04GXoy3zEnGl+rngT2XGt2B5W0v5kzDj3R0zlmn7W1nziVrXxDEnEH65wgyR6Q3U8fPOaU/690w 10OvDdbPVerXxijmduqlacPmhehn5dbOfaIvKCyde08vUXbPvaXPV5fMvahfpPWYe1a/UH95rk4/ 37hq7gH9YvOkucf12618sH+Xfe28qYY2gpgrNYJ8mXvTeI06fR7LeMy7fd4e47ZgYv4IoyLGNn+L cXaaekFPY1Ke+/woY2Fh3fyxRlnpsPmBxgL18fkMY7525nxX4wIDaX4/41yjeR5hzDdr5/c2Vlm3 zfc2PrXfn4+ZThLEvO9mkPvzReY2qmK+2XzGx31BqlkTkrSgw1wWy1+40DwvvefCLnNy3s4FW81r C1ULVOY1pT4LVpvL1OYFy82odt2CReYSw5QFs8zLTG4LJpnzzc8XTDSvsT5ZkGVudZAXnLNsI4gF jVYwxhYOt76jHly41XrPJ2PRaOu5kPpFF62a2N35uday9GX5P6zzZjMWvrOeK5y20GY9XTpk4QPr cfWdhTeseu2uhb9bDxtWLDxi3WfKXLjTqrWMXyi3ltr6LtxgbXKELHxgW0IQi7bBFMsfCFLsaX61 w81nk8TP/k/IR8lduy1uUEG5/WL6JynTvm92Y36Uw1VG5Ic4KMqn+X6OIeqL+cMd/bX6fCdHb4N2 EWH/Zapd1GX/alm/6IndYStddMh+2BG56JkjjiAkbTDFCsAz534FYLbh80xaDFJsliwIppjsA0yx wiNglMyRnCAIGS45RBDK4xItQaivSGpBij2WrAEp9qdkKUgxQgLWaLfJkhSQYt6SCJBioflWmGKS M72SQBUwzgafLoB/Dn1oQTNIsTMFYBXGG1JQAlKMW5AOukNGgR9IsUzJPyDFJkluI4g6QHIAQbS9 JKUgxe5IskGK1UsEIMXKJWKQYg0SDYI4vAqyYYpJblNCEUTCoU4CLXovpYjmJGmgzGc6JDspM7iP JbWUBMEFyTpKiOiwpIQyXLpRUkDpjS6ViMjvsQyJgGzB2ZIo8kl9f0kQua7ZJmGR17XdAdtXdfyS bCWvsq8vEJPrQJWf9DGgipR+ljxN4sRwp/0lCaT/xeJKmHQHt13Cob8W1EqC6U9F0yQhdIt0FLBF 8Q1saVS1SVh0rWYf2B/TySW+dHnzVPBqUVuSZBa9qEMuOUIvsw8qWEW/COYLE1gnQZVrrF/kKkkR O5QeKYljp7H2QHkUqGCfZCJIgmRJAlsg7S1JZCcqLkmS2fGqDRIhm6uZKkllh+lGStLYzKZvkjns oNY/JRvZEzo8Ja/ZWV0HCs6wjaCKmgdWwAXhvK3ka5LPvBN0TGLk3WT3l5zlmXl5UMELqEgJlfpD FR1Q1TYoqALUuUvO8dqarJJbvIetVyXfeN3tfxYk8727ZFIv/h5Q5Sf8OzwFF4TTKX0K1MI59JcF s4Uy9tKCVOFSXhtUOA4qugiV5kLRwVBVC1SzEqobV5AmLG76Dt5b1vqkABPuaf9S8Fz4vCtfakhB CUKqFLMRRCoWsyk8aYyYzQiX+orZ7E6pqziYnySlioOFDVCxO1R6AIomQFWfoZr9UmdxsE4MbR4u 9RFHt36TJovndQyWasW6rlWy+TkicAcMlw0HI9RF5kJZIRssG8yokvWV9eUkyBAZwr8p/SX9lUKH ilHofw90IxQLhmqsUF2NlJASzQmyIbIhbV6ysbKxHf6yNbI1XVjhxMKJoMoD5RBQ5ZmyB+WorAv9 zHgs+4G+5hwt/A19Eh1bSEHvphwtdEbviL9DZXOg6FsohkJxOlR3E3i3WV7IQJ+1JRZOUg7qSCqs VYq79hUll7IJovCwugeCFF7DuinWwldYpze96DfMEjywaDRmjD5VFIsdS+UUpWNHctZDZU+hSgEU ewjFC6B6p6IM7EjzuaIc7HwbWrQae9VRXHRTHdXVslhRA1biRfX4VwQpuo6/pA4q+orf9Z67OAA3 BuctFuGHYxiL1fj21MbFJ/HqXM/FLfj6wjlQ5UWoOgKKX4Hqs4EbjMjim/i2tt8Xv8UvdOxf4qcd 2vViSZv2B0EsPqr/gCCLX+qfUMOXMPTXvPctmac/FnxqiU6/M2bdkk/6ijS/pUz90tzdSzP0iwp/ Lk3S55fylibqJeqDSyfpJVq/pbF6if7cUq6+wDh9abR+pZm0dJp+V8fnpdX6b/aRxTQDmJsv+cMI ZtZLhxvvUmcsnWc0etuW/m7cH9Kn2MWIxbwtLjAuS9tZbDTm5Y0sJoxpRariNmNW6a7i68asmn7F F41Z2nXFvxuzDB7FJ4yzjGeLG41zzAXFzca11inFb42P7YXLFpnAKql4jPkNghQvNz+gosWt5gs+ nstY5kMhqct2mtWxE5f3NS9LH7B8kVmUt3f5RXPiYq/lcebZpS+WR5nzalKXjzXnah8vDzTnGIqW e5vFJvflzuZp5kvLPc2LrfXLw81N9tPLD1rWE8SyfTZw9Zd9t9qph5ZPtz7xyVx+w3ohpGFFrPVA 7IEVJmt1unzleOvi2X4r91uzFh9fcdq6rqzfCr11bU3Fin3WNQ1DV9RZyw0tK9TWUtOSFeVWhYW1 YoF1trVjBWrdZf+w4g8bmMGuEDiiEGTFYUcgtX0lxeHus2mlyoGEfFrlZn8Z57Rqt/16+l8lQXbd 7JMljfbNS1JWBdgfllFWedvv1xxc5WG/05C2aojd3DhoVQ/7LZNl5Wf7NUvdypf2SzbpylP2CseQ lT8cNIJYNQmm2KoDIMV6l7iBFOsswUGKzZSHgBRTyy0wxRT5IMXmomC1tdSjBKx4y7xLfieImvaS RoJo2F+yjyAaS0rA6rFlRkklSDFuySqQYr4lC0GKuZYMItoJQl7Qey6CKFoQZNAlBejOI/YoGkCK SRVrEYTbqZgHUmy0gg9STKBwB3dvrhyMSGWuHOyvTpdvASk2Xp6PIAZneSxIsdfyYJBi9+VxIMX+ lq8DKbZcMQummHw1Bbyv5K2zFzlLvpZi8XopL6NcZb6Qr6Sc41rlMspBwQN5HmWL6Lo8g4JKz8rj KHPRPfJgyhSsUk6jsHCJfBDFWT+55Bv5m3FkyXdyp3mo3JN815ogX0g22+8pJpFBqssP0LchiHwY I5IsLznOOENnlXxgSFiZJV2MOdyfwJmCs0CBqBxs50vTS94xWKh/yWuGF9ar5BljoKa9pJ3+VXeq 5AH9eXNNyXP6/bb18iH0Ox3n5HPpVvskRSJjOKhiY/0EVeazp5EPyfuxd9HzSy6zH7Keldxi3+Zx S8zsVkFryR32ddHikvvsi1K/kkfsJsXbkifsE6rGkg72YY2ixMrW6pJLOtmbm71LPrNr2tzko9g7 O+Lkq9nnum4rJBx3glD48/aDKjd4j8kd8hX8XvTj8lC+LztczuAH8zZBhQOgIg1UGgNVfIKqDsm9 +RzNfLkPn6ULkI/iBzZ9lk/gh7R2yAv4iR295K38lV0VilP8v0GVdcIicPV5wg0UF0UPoZaByK8I T7F3yvcKL/J+yfcILwqzoKJOqHQVFGVAVXehmg1QXTzY/1JzX/kZoaX1lfyNsLv9H0VcCqurCPVL uQ6qfBcngyo3xJmUKYp6sYiRrCgUz2f/UgjFMv5iRYK4SHgFKh4LlbZA0Wwo9htUcxqqK1BMFhc1 +ytmipVtvRUbxHs7XBQvxH92laIXcnYSBFomAzMldL4smFKGJss4jJ1osIzNEaHDZRz+W5Qs46TE QcX1UJkbFN0PxeKhGjtUh6MUWXDzVJQhi27zA5+zoCMY3Ss73bVJKS9cDuaJdCUd3AGeSk/KCSVF SWG8UA5QDuA0K3spe0XPRAmUSLmB/kJ/5bhDZQrofw+sBoqzobrHcM/mDcohyiFtU5VhyrCOqcoN yg1dh0unl4IOo3ykpoAqneq+lGfK99h3b3/lF+xDsHspgnVGXysdgD1MTSglY3dy9kJlX6DK2VDs LRRXQPUjSinYnearpV5YZ9uG0jj1wA60dJM6t+tK2bSacIIoPaDtgyClJvwrlVT6GH/jnV/6GX8Y XFBGxq/GsMvG4GdTL5VF47pcVlkifrhQAVU+hqqTofgDqD4fahxcNhU/23albAX+rENX1qIN73pZ vrIBjOSyjfrvCFJ2Sv+OGl7Wrn/sfbi8v/5KsLE8TH88ZlP5bH1D2rjyKv3G3JPl+/Xriyjlh/Vr S2dB1SaoNhyqvwxcZ5xVfkJfax5Qfkd/ruPFamcDyd5vtRH+6Y7yLUYHgpRfNtqoM8v/NrZ5v1wd bDwbMmh1kXFPzMfVjUZV2v7V740leSFrPI0FRdo1bOO8Uge0hreGZZynPbyGaZxv8FsTaJxvPAW2 F5qnr5lo3GQduUZhfGUfV+FsaiaI1efN3Qiy+pO5k1q6hm1u8xm+ZpX5TMi0NdfN2tjkCg/z+nTn ijnmJXmNFQfMuYsDKx6ZM8qqKlrMM2rOVTSZZzYMrzhrnmnYWnHCPNNErzhknmo+WXHaXGQtrnhm /t2+Ym2uZS1BVPS19UWQinjrX9QjFSrrc58ZFS+st0L2ruVbj8ceXdtg3Zlevpawls9mr8uwFixu WldnzSoPXJdklWykr5tklTSsXce35jf2XhduzTfVruNYF1lY64ZZp1ovgS2b7GfW7bYlEsRaOUyx tZdAinWsc3F4+mxaV+zoFfJl3TP7uzjy+hS7Jf37eqP91OxzG0bb8SWZG8rtleWP1nfYD28sXv/Q fqjhzXqz/WCjbP0V+/6WAet/t++zHFvfaN9jm72+wi6xv1v/wPEbQayPgSm2HiMI6q/1b0CKWTdk gBSbvqEVpJiqEhxHBlZ5Ha7FqmJgilWBucJqfeVmgtj4tLKaIHbNqQRrsWM9K0FytRgqZSDFFlXm gRRjVmYShOPHhu/EWYKo9umjRxAVjiADt6o2gRRzVZWDFHNXgWziHlCBtZWwpyoQpFiECpxZWXZ1 O7i7CqobQYpJqitAiomrZ4AUi69mIYhpZPUIBLF4VoOZty22egVIsWuqHJhi1WHUJgSp2uXSj7y2 WkL19dJWz6V6MS9VZ1Op3PvVqdRegqfVcZRu0ZPqUMoT6f1qBuUier3aiXIAO131nVKNa6teUGT6 1VVtlHTj7KpWygSzqMpBCbBi1fGUkY5hqvEUPqiSyXABVdoYZnJDVbb3bPrcqvOMDlZ21TnGA55T 1RnGLcH9qlMMo2hf1TGGQaqo0jE06LSqA4xKLLRqF2MZTqnawcjR2atqGInNt6rqGRParlTdZIR2 fK0OYHDtFapRjJWgyjq2EEGqndhN5CtVBznu9O1VGZw5bFpVPieJN79Kypkk+FJVxIkW1VUt5YRL 06qWc9ioc9VKzihVe1UJx1NzuErOGayTV8nZRHNa1Ub2t7aJVVc5PTqWVgdxhtsRVSBnGahyg/cM VJnNZ5A/Vw/kz6Q/qjrPV7ElVZv5+3mtUGFY1Rb+ftEF4D5pTtU2/l50SNUO/i7V5ap6Pq4pr8L5 O3STqnbzNzVTqs7xt7X+rPrIP9JBr57Bf9y1RzUjOo0gVMOF4MpX3xJepIysLhM+Zwyrjkjpzb5Y PTBlKJ9d3TdlhHA9VNwHKt0ORSOgqrdQTT1Ul1n9W8qIZpfqoSkBrR+rhSmTO/pXn0qp6JKrjqWC 3FeViQvBGIsXl1OmqQaLNzFmV98T7+UMr94rPsmvq94kPi/8CBXPgEqtUHQZFBsG1dyA6tDqzeLf m8dXHxBfbyNXPxF/6PBSReYEd63D2DmdoMp3WQqocluWSdmgOiibxTisUsryOMtVM2ULo/urYmXS FIkqWiYVt0BloVDUBMVmQvGeUJ0BKGueo0qXKdrGqlbL9nZEqp7LPnbtxNoKDQSBrVGOQxCsQBlG acIylaGMbixKGcy5jY1WcqKXYK5KTso7zEnJyZkAle2EKt2g2H4oHgvVvcNIyuDm7RhNyW/Lw5KU CzvE2H7l713H1OtL1xGEeqR6JLjDRqhHUF6r3dRu3iFqJ7VT8Gh1P3W/6HZ1T3XP1DyMwIicS9gv 7FchBaqUQ/974GqoPgju0/xAPVg9uG2reqx6bMd6daW6squ1JqcmB1R5ooV/U/qZdiDVRf1Wi3gv Vn/EPwevVH/HX8fwa3rh7amPagbi93MTapzwO4U7ocruGhJ+R50Hxd9C9XKocVjNMNzadreGr+3X caYG02Z1vd84rWEcmFPvN/RDkJpz+p/UCTVmfZe3oea13hp8fSOiN8c0bPTQm9ISNjL1x3NvbOTq Dxf5b4zRHypdClU/gGqToPp/nxsXbUzSnzS7bZTon3R0bTxhYNmH1EoaB4CeV2n8B0E2HjDaqVkb rxtt3u832o1tIc617sbzMf/U8o0H007WzjNuz4urXWusKjpRu91YUdYPWjMVqm2GGsKhxku1WqPK nFd7zmiw+td+MxL20E1a012CqK00/0CQ2mPmP6lltR3mpz60TWTztZCsTQnmE7GZm0rNeLrXpjPm qjzjpjfmVYsjNw8yy8rwze5mSc07aAMfajBATazNLub55jOb/czlVsnmLPMte85mu6WWIDbpbYMQ ZFOH9R/q0c3O1j99sjanWx+GHNi83doSe3xzp/VQetWW0dZNsydsmW8tXXx9C24tKg/f0mKdv7F2 y1nrwoZ7W05ZFzWO23LCushk2GIAKRa2RWudYT235Yp1q33H1kjbZILY/I8jEkG2hDiCqNYtRY7h Ppu2NDl+C/m6lWR3xDlvnWt/lE5sPW83zTZtG2w/tES0LcO+tdy2TWXfUJuwLcdeuytn2yx7bePl bZn2TS1R21LstZZr2xLttTbxNh97nv3eNtT+nSC2bocptvU+SLFv24aBFOvYVghSLHPbbZBi1dvB iiyjevt2mGLbv8MU25EOUsywowGchcAdHILY3W/HGJBiy3aMBCn2cwfoJrdrd7iAFAvbMQik2Kvt xwktQdT98ZsfgmjkCDLAW7MEQYYXaOYgSJBBI4T/DoRmLIII7mhc4b+pUP8RpJig/iZIMUk9WK+p V9YXgxRbUT8ZpFh+vRdIsYz6wSDF0uvBbNW2ul6GIN1DNPn//g3s9857EaQuy7UX+Uh9GnWFF68+ iVrIVNfHUudyz9ePo04T3K33o8aLOuvdqWzpq/o+1KHo8zoHFcH+qHtMeYXfrGuh3NCfqjtEOWKs qztA2WSuq2ullFkt9f6UVY5sDZsC0rv+N8ZuUKXUW0a+WOfkM4y+o67GezIrvQ7zjua51FV5hwle 163z9he11JV5D5XidSXe/VFl3RLGX1hu3SKGDY+ty2Hc0PvUZTKOGfvU5TK05h51tYzt1pC674wG +wVNf8ZjUCWYbQBVznECyc/rhJwd9Cs7uzk/2TPraJyrvHV1DE6L0L3Om3NOdKFuJMcgLakbzdmH 8up8OduxgcAqzROgXKcH2yXNFXURnDltq+qWcBZ2HKh7zim3c+r/5jwBVQr4vghS34e/lDKgbh// PP1nXRL/HzZeR4325w+sc48eKZxbNzTaW/S+bng0Tbq2jhY9DOXU+US7qd7WjY4maQ7U+Uf310nq gqJ7NI+ri4/u1eZdVx7t3DGx7nN0VNc1zYDoE6DKWeFdUCU3pSclrJ6UEsgIrzOlTGe/rytLkfPn 1BWlVAh/h4qDoNLzUHQaFOsJ1RyH6hbWLUlZ0+xbV5mCtfWtu5xypGNYfWjKyy61Jj4VrF80VPFO UKVNfJIyt75KbGasqp8kfseJqh+c05N/pc6e45TiAxWXQWU9oOgmKBYK1diguo11jhxS8+T63jnD 22j14Tm8joD6vTlrujDNkVw2qKKQgXWlJlGGUjZp3GVVjKb6Z7IdnI31jbID0QH1KtnxlK31a2Un xW+hskwo2g7FlkBxN6juYv062anm4vodskttcfVtsncdkzQhhaFdu/Hgwm5Q5bsyHVR5qJxGuaA5 oZzFIDTVSjHnlWa+ck60WjNZuTB1kCZCKcmZDZU1QZUhUMwIxadDdf8AC5oPaZKUJW1FGrlyT0e+ xqr83HUOv1PaRBD4OnUEguBL1OGUD7hIHebNxSepQ4PH4Rx1cPQnfISak4riZDUn5xU+RM0pDIEq t0PVblB8H1QfDW1+jQ9X89r24Qnq+R2b8b3q8133tJU1KoLQ+mnBva/11npTh2nBw7tE66x1Dl6r HaQdFJOm7aPtk2rX9tD2yJ2DEzhR+Du0dAhUXQL976FXQ42B2oHagW3PtMHa4I5L2rXatV2fGrIb skGVDoMHqPLcQKJGat8a+nqf0jr034Pvar/qu2IM2l/652mzGvrqH+d2NgzS3y2Kaxiiv1NaA1V3 QbV5UP1bqLGkwV3/1DyqIdzQo+NbQ4Uhze66K7HRD/6fJxPo/A2nTT2oooZrxs/ejoZ248uQYQ2f jA9i++/qb7yadmnXCOO5vGm7WEZ90c1dEcZDZYxdkcaDNQVQ7V2oIQlqfLArxthoLtolMt62hu5q MHnZI3enmcCKb9cGy28Ismu3+Tt1zS6j+U+fkbts5ichebt7m6/H5uz2M59OD9idZN6f17ZbYt6+ WLC7wqwqO7Fbba7c2APakAE1tEBN3N0q81rz1d27zA3W5bv/ML+2z99TbDkIOrfKRkWQ/6uy+3Br 6vzDBn5cda+cUBQ3CVqtkwRFW1EScLUVSYJ1CwGsW0JA6yoEHFXbkgCuaiUBRCwJJIAzG9zZ4KpZ BxytSnKCs1Ux7/fx975/wCtXP+WCkDs55znnfh5CkrIaohuuLLvjfUNfXd7Z+4gpL2d47XGXytd4 Nbzi8mPeyrQ55de9R4V3y0nvgfwFp3t5cwtPn+7vzZGRSNV3SIMBaWed7uLN8BpPT/ZWkUdP16Hf KJZfRi1W/jAwCfeeHhAYSS8+PS/Qh/nu9D7ybXzo6WtkS1KXiu6kKe1aRTx5IeuHil1kRf6zikry eBGvQg8tVlmhgxb7t0JLFhmTKzRksf1BxWWymOBX/E6uJ80VQfJDMFgxBbVYxWposRcVR6DFXBX3 ocWSzoRDix06swVa7JczsMpNT6vshVqsMhFaTFUJo7N4UuVl2BZHKsugxSyV0FUNUZUnocVUlceg xWZWQt8H7lXODsK1ysU97mNY9XIM6/FDNQfDhv5ZHQ8tNq0avXZH/+oh6NWGFB8xbPVrBazCMqYq LkKLpSjE0GI7FWvQq9EoZkCL7VH0hxb7UQ7zIXuuAmZ4xCXFemixudXbUYvJS0JKMUweGtp/oF3x FX51eKOCiesmzVd8idfNkihG4BUJOsUA/PDqB/Ignrflufw5vinnhfwOzit4Idfi00va5OX48BqP /BDeWW+SH6D8Y3PIlZS7RE8FTrEHjldPpPwNKRdpLEiZRh85sLXqCr1llEm+maaaPFW+gXZ2dh/5 GtqphDZ5Ck2y2iFfRsvbclHOoWXkSOXzaCsLfpbPpM0t2SKfQptckySPoA3ST5dPpnWzRctTwz94 N8nttC7ke8VL2nRIISKHQcq6yMqBH6s+MCJGBaoOM/6YcriqhREz+4+qVsa0RQxw0urWqoeMiC1S cHDOWvhK74JpVS2RH0p6VXkj26qJKnekU3epqj3SYa2RT4i87XHLSyOfk+mKW4zZwaAiJHYbpMhj 7ZRR8vksWvjIqn9Y2VPsVSWs+tj5VSpW2aLCqnpWSTK16gLr9y01VZdZxTnLq7SsXwsoVQbW3lOO qkbWruqjVddZmbrUKoIlsC6Uj2TleATy46wz/oCikR0GKUsTB0DKx8T5lPnyysSc8O/lCYnnI0Pk nyU+iT1e9STx/aI3yOQVyC0tVX8nvs/ZXvVP4ruCEVVPE/89Zat6nvimel8VmfhSFyfvkfjOGi6f y6F6ouV6zgL/WcUjDvS+oir5FoYpkpN9FKEiNKV/eJH8VgozcrV8b8ri2BfyJSkbE5fKeSlbklXI jDHInHPIAg7y1H/I6kp5UsoW3Sr5hpRd1sny8pRTnmjF5ymt/mPVU/gHg8Hq3hnHIcWeoaDIFIcz jOEORVLGvUiFYnCGj5Ugf5bxMbFR7hR0SxmEzNiNzPmILJAgSyYjq/+SuwTddAflAQHFulgxWhDt WawoFuT5q6rLM7+ClJ25MNerTsjdTblZHZ67n9ZPEcgtivyg0OeeYikUR3LPciYrducqUwoUu3JV GQ+RuUnIAheyJBNZgyN1OsVvuXprnsKY+9izvXqsiOlvqBkvgjlp9Xvx95DiFi+jvKrWilfQvqk+ Ll7NWFC9VZzK7l29WPwD54/qGPF6fq/qaeKNgmXI3MtIMQNZokfWfI/UvaueK95uPV+dLZZ6Sqvv il/43TUmiSEYrDkknY1hNTukMfiImh+kX9H213Ck0YwjNV9Lo9g/1IyRMrg9akKlkfz8mr7SKQIv UjQRKT6GlIYiayrASP3smjBpjPVFDVua5nHUnJSe939QimSwrlROUE6AM8QY5Rh8lnKkciRNpxys HMzwKgcqB7INyp7KntwMZVdlV/47JabEMlNrgjVBkQop6YWU7kT+70MvVvZQ9rBNVY5Xjvd+ptyl 3EUOV32n+g5SWgxwVCofG0JwvvKZoTfttZI0YMzRytf6V3GfK9/rn3LvqDrpvambVD309zIfqfro m/JmqfrqHZKDSGkbUslH6p+qcP19W75qkv6tl6XKNrDI+NopRpj7q+R2KoapLtl74T+rbtg+0sep /rK1Mzeo2mytcRtqMVszb3otbrua6qkdbbskTK1l2lR5ptqvbYrCIUjZRqTyDtKQWDvDVmW7V7vQ 1uDdW3vA/hmZUTfe3gjn7GIiDMNqzxL98dpaI9GZnlzr8b5gqmo/elviDHUjvHbeqbrZXn0ap261 Vyl8XLfDW56/vO5X78nCi3WF3t9LuyBVq5AGK9K+sO5n729ea9157zVSWj+L2BwM1pWiFqvTB6bg f9V5AzT64frugYHMD/WR5Mf4IfXJ5POkHvW/kffTLPVq8lrWlvqH5Pn8V+e6klVFyedCyfLS8+cG keW13ZDG9Uh7C5JYU99Bisjmc2sDsMXq/0Mtdm4ItNjzc3HQYg/Oob/u4J5TQIsdOAdn7aRD56HR 0lPPr0Atdr4Qtdj5BtRi5x9Dix07D3PH2jZkw3yk4zKy5Wtk4Nb5yuCJYFAzv5caw3RfYdhnWToG hg25rhuDYROqdaEYFqPUdYIW42n/hha7or0BLUbVwpoq9zttDrSYUAtHmvSgFo3RYi0GLSbWkNBi pdpe0GItWljTtWfr9qMW0yz+/ByGqW8PmjCwXUun9h0+Tjuc+tlEvzYE/zBrqbYnTiac1LzDidU3 NE9x65Ynmjv4pZz/NDq8TNxFU4EflHbT/IJvrglqMnCO/oVmM/6VrUNzFB9LTNd2wkcEzLoJ+DRI 2UR7CSkBuofSSb07om7UO00inTK5u+Y7eu9ZrzTz6FjCY00s7dXqe5rptMdbbmgm05pzLmkiaIaC Ss0gWlXJYU1vWnGNSP2etlO/VtONtta2AS65yivTKGhpgcnaVhrMAjTiyKMYphnKmEQZpK5haMLD 1Czm3CkW+Fw1+zT456I4dTVDtvq9WsE4usWgljMO5vymPsvYVZCirmBsLIlWlzGW1wxU/8GYp3uu VjFmWh+q/YwY7wDNOgaXPKotZ5yGFGOsA1KWsKZSotUvWYfD49S/sN5EdlJPY8+N3a9exR656JI6 mT0k+Ss1nx2y5Z46nd03Z696LbtbwUz1etb7U0H1Rlag+jr4SCdR72O1WHerb7J8nhLNPDaFHKLd wxZBSjAxCVJKE49SlmvmJd4Pz1Y/5QyNjFEf4SyJtanTOD8lRqnXcnYmF6jXc7Zn9FVv5GzNkam3 cIQF8epMTsapV+pszobqKvU2TrpurbqQs84ar77DEXmWaXicev8N7SHurGBQOz8FxpHmfcp4Sp5G nvJ9uFyzJGVfZJ6mV4qKNULtSGlOFKuvpDxIfoLM4CFznMgCofpqyoOSUGR1o7ox5YEuS/0g5Yk1 TjOI/5lnvqaQP9d/RqvnP4MUWcY1DNMmZ7RQ/tQOz/gQ/lhzVxAWeUsjEUSzsjRLBJzEF5qZgtUp 3yIzziJz6ciCWmTJQmT1S83XglU6qWaRYIN1neagoMCTrukQ3Pef0w3L/DUY1HXPha7U3s49S2nS nsq9RBuuTc01MajaL3LdLLPmdS7J+V7TlPs+Rasx53YI+iNzdyALOpAlBciaCRpTbofutsYj6mU9 rMVFkzw/a3NFu/xmXVFeDKTsEMMcRscT/0Tp0I0X76Mt0X4UFzBWam3iY+wIbbm4lKPV5on/5E/W ZomrBXuRuV6kmIcscSFrBFqhuFo/QJsvvmy9qa0TEx6VbrBkkv+JfqgEzi66DinMXnUPpSvxUbpr 0lU0se60NJlxWpcv5bN36VKl6Vyabp50Lb9MN1W6IbObjiHdIOIixReRUgayRo/UL9bNlm61ddOt l/7uIXQ3pM/IbvpLsovBoL5AiR4zz1WycJZ+s3IW7YZ+ufIrRpt+jjKa7dBHKqO4+/UjlYzUED1F GZmZr++jjBTdRUrGIaVHkcpB4BR9hT5EOcM2Xz9DucIbov9VeZb8wrBOhf5+bYphCpyBxhvG4+mG CEME7b1hmGE4c4rhc8PncRGGfoZ+3H8M3Q3dU/MNnQ2dMz/qg/pg3kqk5CxS1h2p3InUBw1dDV1t hw2jDKO8iYb1hvVkgnGicSKk/G2nQ8oz+1D8kMFnx+mTDS/sPZhCwxtbR9xWw3tbO2+uEbP9nRow fmbzCH809rbdy3tk7Ge7XTgNKduHVLYhDWnGvrYm2zPjKNs/3iLjSvtYckdDD7s3GDReIGgYZmwg wvBzRhvRn843eojOzPNGv/dV3M0GzPuYV9kw0Hs/bXUDzWsSvm6I9BrzNzXEeC8XWhpivRdLByNV AqTBg7Qvb5jhVXrdDWu9j8mzDW+IfdAJVajFGrSBSLypoSkwmn644XkglNnR2CPQPX5kYwT5Jqlf I5t8nHa7MZm8m/Vj407yxh6ssZDUFW1qlJIXS682lpIXaylIoxBp/wdJrG88RJ4k3Y3/or/uaHyI WqzxPbTYwyuDoMXuX4G5YFTilVRosf1XfoEWO3jlPLQY/woBLTboanfUYlfHQYtNvgqtV3b86iJo MT+yYQ7SUY9siUQGtFf7BeXBoHl+HxWGWVMxrOs31hUYFmazJkKLjbbCqiZmlXUiei6Z9XNosWrL f9BiuOUvaLFVFugk8RHLb9BiOgusyJT3LdCDhsdmAlrsohnWbkTQkgItdsxajFrMzAuFJjTdG7yG MtiSRF02bLclgcqbWGSZQ/121peWGdTZCYcsX1KnrLZZwqgjMzDLZ9Q+uTRzAH8r/tp8Hyek35q1 +HUlzyzD5YYk82J8v32kWYRnEylwmc2BN9aJOOwX8w/0K5BCRqgpY0y7RsvCo8y76TmT7pp/pG+b 9cScSd+cEDBvoKesfm3m07lb3pi/p7NyXpu/oU8qeGGOoYeVPDdPonetaTGPoD3X3zF5aTdsR8wh NK3XZv6N1hBYZblNew0p+xiwTjWHMO5SZpoqmYLwRNO0qP6RoaabzKjZF0zXmRMXrTVdZUYkTzA1 MsO2BE0GZt+c+yYNI1hwznSRQZYcMdUy3DXbTXLGLf1K04+MShtuusCo9Maaoxlq8roln9kbUpSs hZAyj6WhfG9qZY8JzzZtYx+NjDMNZr+PdZqWsmsXvTAtYyuSd5tWsCsyRplWsf/IuWtazS4uOGJK YR8oWW3is3fXTAQz9J1M09iJVrlpJ3uFx2LG2D+RcyzfsuHMb36SqIOUA5yelG3m8RxuuMx0k1MW ucO0meNjhZkmcGmJBaavuSHJHlMMl5Kx0hTL7ZfzyhTH7VVwwjSP27UkwfQN52NNb9NCzhud1fQF x2ndBD8b8OSaXnJH+p9bvuKeCQYto1NWQsqdFDHlhDk/pTG8yTw25X3kBdNt/hQW3yTmr0psMWXz M1JikBlnkLlfIgsaTFv5W0rWmLbxN9dQTdv5G3W3TDx+knW16Qhf6OGbQ/lKv9aSlLoQUjIFMPOy TBRMp2jNTwTLad3MRwV5kf+aFwgqWTXmHoJbnGgTISBSSkxuQWvGO2SuAFnQgSw5jqyZhdT5TJcE FutPpteCgCfbvDlzmt9g+SPzKaTczG2FFEnuv5RHliRRP9pXFopoDGOG2SaKZX00F4qWcorN6aKN /G7mJaJMwQpkbiNSzEaW3EHWZCH1Q8zRopXWP80ZIpHnmLlVZPbfs3bOg3Wldbz4IqQExVfwPha7 2EHLsBwXE4yfLCniADvBMl4c5LRbOkn68jebn0pCBGbzP5IQEQ0pPoKUDkXWqJD6RLNF0tnqMQcl oz1GyzqJ0N9u/bEwGlJOSOHotO6QHsfHWZOkJbQy65fSCobB8lFazS6x3Jae5y601Eh1/HuWYumV zNmWX6XXRBKk+BVSuglZ8y9SX2DZJj1nC7OUSe95AtausghygA2T+YJBW6hSiGE2TJmFz7c+VmbT 7lmvK7cyO1nPKLexfdafldu5Z60blDtTY6xJyt2ZtdZ5ypy8PkjJKqT0JlI5D6m/Y41WZtpWWVcq Jd4Ia53SRUbajqlKIaXEwIMUiSER32DLMyykd7NtMXzDnG1bbpgbN902z8DmdbZFGWanltpGG2KE NNsQQ0zeftsgw0zJHaRsMlIpQxpotgGGqbY/beMNi7wptm2GI+RSO9vICwbtUfYoOMNNtk/GC+zj 7OPo0+zh9nDmbnuYPSwu347bcd739t723mld7d3s3YQF9k72TnlBG3wULkbKSpGqbkjDDtun79gp doq33J5gTyD32IP2IKQECDjv2l8Qo/FL9tfEcHqa/V+CytTYPxA94xwOzNvBq3N09b5M2+To4X2a 9Zmjr7clX+QY6HUVPnLg3gelkUjVXqSBRNrXO/p773h9jplEd7LOYSGk0AZm1GKOOwEmbnIQgXH0 Iw5fYDgz6HgfGBBPa+od6JwU0jSEfJXmbvqS/Dsrr2k66drTu2kO2Vy0symBtJbeaUokLbWjkMaf kHYSSWxpmk1eJv9uUgSmBoNNT1CLNcF5E3/Q3ANa7G7zCGixhGYYf/F7mznQYvubYWWYntx8AFos tLkMPS7WfBm1WLMFWuz35rvQYiSygY10KJAtY5CB6uaSoC4YdJn7XcAwb38M6/TY2xPDBl/xQOr4 M552aLEIjwdabLAHVmGrr3sU6LXAPQXQYirPJgyTdPbMwzAZ2zMK1tjZ7n9h9vC72wLbpd71AsNa KG6Y57XXeE6hFnPdHjwLw1wrw65QOJ6e1PqhjZ4u1JqJse531DOzcLefejLhlJugipM7u21UUUaC W03NyP3VfZq6XKx1/0plSx+5hdRxqi7uxdQBxsHu6fhrxxeujbiRyHW14Or2UM9EHHa/61GEAVIy RhspK50fx1wM3+ceH9Fpkso9hv5uVsA9ih5YNNQ9iP44eZa7P/1exjJ3F/r1XIHrDb1enO/6hy6V Slz36QeVJ1zX6JmGUlc9fan9tPM1Pcz71iWkDwvsc1+nJ0DKB8YHSPmNeZay2TUqihte4qye2iUy x/UD8+7sVlc607aoxsVnXkv+1bWKqc7Ici1jVuemuJKYJWKOK4FZII13zWPuVs5wzWauN0xyRTOT 7HTnPuYA72ZXH2Y4+cKdzoS96h7OQikX2ELKPlci+1m4ztkaty7ytHN3nIfFcz6I25CY6HTGpSf7 nK64lRmlIC93rdMdt0A8HYyRDgSn1ATg6zR9E1ySarvonMq+5XnnNLCfkQJ3WByMIPc8DvSL6xlH SSlz/cLtGv7IFcFNjrztbOReYB1ybuN2cEKdR7melJXO49y/Mp44T3Jv5x5wlnCt4pnOUu71kg7n aa6h5pqzkntBf9RZxVXYNjkHclM8Z50nuAXkAFc7bwCk7EiBEeH+gj+eYnA18dfS+ruy+H8yeroG 8Z+zbjpNqTTOSmdJKjvF6ixNjRVMc5alzso1OE+nxohXOitTv5L2cv6ZGl3T4FSkMvV5TmXqZNsC 5wj+Q4/IWZE6zH/f9TIVZnPuekEFpGwSWCmEO1zwL+1rlyVzNIPl2p65mN3HNSkzl3PW+T5Tyqc5 A5kVgn1IEYYUS5DSSGSNF6k/jLQlOtdkLvPsdz7KLPFb3KOE30DKW9F6SLks2ot3c+8QyWjr3VNE DYxdrieih2yOS5bXhfOfa0PeMP4uFydvrKAFKVqAFFuR0nSksidSfxFp2+y8LXJ6/nQtyKP7W93b 8tzBoIclicYwzwDJfJzmfiBZQTvuPikRMC66V0j2s4+5R0j+4C5wPZco+XddtyTazDjXVYlBJENK PkdKpUgYY6CeQNoKXEkSoafZ1SjR+Tvc7sKfIOWwrBekbJZR8RgPSzaCdt0zQPYl44XbKYtme9xn ZHO4J9zbZZzUKe7FspWZZ9zzZPy8rkjJWiQclaBSiDT0Q9rqXU9lQ7yd3d/J0smhnsTSLyClHb2O vee2sgVf7qlVPqa99BxSPmeO86Qo2+PCPdHKf7lPPRTlx9QD7peqbsKebq+qZ95mt0vVS3IVKZuC VNYiDSykzesWK83eaPdTFZWM8dxR3Q4GvUkGOZzHYg1yfId3rEFOH+bta1Awkz2kQRGX6nEYqnlM T72hJtXrOWFQCdd6Dhhq8+56RIb6wvFI2X6k8j+kYTfS3s/zjWGvV+g5arhOpnvXGmGLeRvtWyHl vF2In/BW2jPoc7xH7RuZRd499rVxUq/Ansbb5V1lT06b7F1oXyVs8MbaV+RP9063ryg86p1mXy57 jFTNRRq0SHusdwj8d967xL6DFBO9HeHBIDGdmA7rACbBxDXERGIi/QdiDDGG2UiMIEbEPSBCiVCe gRhADEjbRfQkemaFEl2JrvlHCIzACj94g95g6bdI1UmksTPSvgPpDRLjifGkntARcOYnPqIWa8EC U/ErLZ0DE+nHWroGIqI6tXQPhMWPaekV6J8U1tI30DXtcctA8l3Wry0hZPueQS2DyWdFB1uGkk9K n7QMIx/XTkEaDyLt/yKJrBacdJIvWnIDMLdseYdarLUztJijtQ+02O3WUGixb1vp0GKi1khosT2t s6HFVrXCpbM/b12BWqx1HWqx1izUYq07oMUCrTuhxWKRjtPIliHIwKlWTtARDPrHDLiPYYGd2E1Q jGGDzgT2Q4vFBHZAi4UG1kGLLQig54uNC8BqK+OvwAgME60l4ZZJCBJGZ2k8eR7Dak+QsC5reESm YVjzKBL2wcMkHxe9ir+/ArWYf0IYNKHv8tBEipQ8HDJ2aBeyIIQ2sTu5P2TIrDHkrpCBCc/IzSHd kn8iV1LfZLwmF1AfiZaSTKpDUk0OpWpk/5KdqBW10/2Pqb81CPzXqVubZP5K6tJWU1sTHmyf7J9I pULKtNGvIOX6FxjlT9/isV3D3/vrIiomlfurI0pm0/1nIo4syvefijiUbPcXR/wkwP0/R2wWLfTv jFghyfNviJgvq/Uvi2Cq3P55EUMbuvijIro0jfaPpD9tjWtbSt8WOONT0ysgZW5UV0hxRmkoat+W qZm0/m3/TYtiUH3uqIrYaN+DqFOJk3z3og6nMHxNUQcFMT5L1E+ib33Xo7ZIVvr0UatlGb4LUd+p 8nzVUdONh33lUXTHGd/xqH4tF58/Yu4LDPYtYEIj+1ewA5DyNk5AsfjEcS9pY30j43MZUW31cz5j d/cx41cmPgW/TzntY8QnCLaD8aIVvsj4GZIFvinxE2WzfJPiR6mm+ybEU4zTfF/Gd3ZM842JC7TM eL43Lon8va0tDuY7/q3ofRf8YdzTlIe+S7wutPm+Rbz1jBVt//Bs7Ki2wqQITmvbDd5zPr3tFu+J 4FqbhUeIRG023l+ShW0OnkM2pu0274aqZ9tdns7wou0+r87e0vYX7wxx5/m33A5yapuCB2PQf5jv hpTY1OGUDt/TVD5tk29/ajXjZ9/o1P/Y69rsaTO5Q9uOpG3ky9vK0viZw9pOp60WXWirTFshWdtW lbZENratOo2rfNumSltosLadS5tnl7ddTIslxM9jUn/xv207mgbzO/+FTBi//k2ZOnyIf0QmSSvy XROOZlz0bRSuYkt9YcIi7vI2p1DDf9HWKDRnbkKKXiIlhW1XhGYZG6nq1HZVaDLcbLsmvGk/3nZD eJ3Y8jxV2NtPtCmEKkhx58G49v+RJ8Sj/UvyjtA0/p55WsZT38W8J+wHvo35/bh/+CbkT0qd4euR H5d52dctPz5vClLSgJT9gFQNQRr+QtqlSGLz84t5e/1kG5kPs1Tys8JhkGIvZOAJ/iOFC2gt/sTC dGaYv1dhXhzVd7WwhOv1HSi8lLrHt6rQLOzl4xQ25W1HSt4hZRIk7H3Q4EPaq5BERhu9cADZyzen 8BakMGR/YxjZXfYa/8F/p7Qrvaf/ZGkIc75/denYuG/9tNKveSN8vtKFqWafsXSVcKnvz9I1eSbf 2dIfCmcgZUakajnS2BVpv4AkhG0lMjn5ha+qdC2k8FVVkDJLVYfnkoNUGvo4/1PVNeY2/wWVIy7P v1fl5q30L1b9kzbQP1H1Uljup6je5w/z91Z1FIqQsrdIVR7S+Onr9iv+PqoOIts3TpVIfuMfWtsL UoqNayBlh3E9/ju5wriJ/h0ZbcxkSskBxq1xdf6nxl28I/5Goygt0S8z7hc+9+83/pK/zr/dWFBo 9/9oLCiNRKrkSGM00t6EJLb5rhk+kJn+E8YqSLnlCIGUC44Q/BxZ6qDS15E/O6jMq+RGBzWuhVzo wHm3yEgHNe0XcpAjJGs82cXxeb7S/8oRWjTEH3AMKs1Cqh4gjYuR9hYksd0vtJ8lT5JjHPPh3NyZ qIOUt4QSv0I+IxR0EfkXUcn8h7xBlMf3JM8RUt5/ZBlxMs1AFhLHstLJPcSRfD+5nSguWkUKieLS S2QmUVzbF2ncirS3I4kd5GQiiTSTRsIDKTNRiwWmB6bjmgAjwKD/HhgfGB/VNUAP0OPHB4YGhiaN ClAD1DRfoG+gb9bRQPdA9z0RgS6BLkXHA1gAK31LBslgLQtpPIZ0dEJCShB9BNYFoIvaw1CLtQ+F FrvePgxarKkdrcXmt4+CFtvdToMWy2sfDS22vB1mPNl4+3hoser2SehxsXb0N4q/t0dBi7UjG2Yi HX8gW/ohA7+2Dw/+jZ73jCeinulC/O8d0UIVyPGfXv0q5gJy0ZJPryFyFJl5Cpmfiyz+9Hy28g+f Hr0rQV6LQt7VIf+eiXxb+/Hs/94BZqgF/X/4Cjw2GAwJDNkGPp84F3w06x/QmYiDdj50dkhjphWs y88HS4vhHoaIy7Xgj+dgD4esumoG4+6in/3iCZyJQ/q8Hf1xHPXTK/R/YUQpY+/h8N1xbTS45tE3 J0P3j26MhdXs6MuJ10AlH7bu6LLMDrAofy+YV/wZuKU8B1xW/xKMu8oHv7wDa9rRA54wgsGI12+K O6rp71HK1AaUMi0fh9VM9Hza22Bw+nAm3LZpg1kwq5hG4fwC9uR74ZIfhbBNprbn/wY+LILtPbWp HLbAVEP976Diygvw2B342amix7ANp657/apjctQklBJ/AaXMmY0ng1Y6HKlzNzDh83ld43bB56Fc mLXMHZAKX5nbXbgdLvMxXwa+KGoGn5T3Bu/Xwz6ac+PKz+CF2ybw9OP+YOHrpA+G+FEoJYmOUpL2 45kgSYeZ4OJUJlz/4rtxJ4PB72fy4JYv9qbCllz8l/Am2JzfCJqKYB8tbih7Al6s7w4qrsCtXiy7 vRIsflQA7nt15cNm3iOUkvZp76d/ju9HvwGnfwVeZJ4IBtcMiNODKbxzYEkafHfN3qzhoCifBHcV /QVuK4N7tEZQ9wDc0NgGpt7uCi5/BMfAGs6ruR9i0w6glKxPv73Ouon/AcdDJ/piMJapAfPj4FZk N/Dg2M1+k4aevYpnbQAH7oHjauuAIrjOrf3KbGCfOgPYqxHG29buzXBPt3Z5CHOK7ODLRx9isgaj lD3pKGXPIVwO1tEzwFamMxjcS42HMQZTBNgaezenwd7f+0vWcbBwz2xk0QckStlbWKdCNkqRzUeR D48gX/7+YW3+CZRSzEApxQtxNbiBDvev+Ffmf6AqHj1mcDsJjvbi1+mQeLh/1hVwyJ41yOJ+SJRy eEhdKbIxD9m8EflwNfLlkg91RcNQStkblFLeA4dOKx9Kh6O7nBEFR2L5t/EwJsvXJMH8uPyndMgq L8p6Bsr2/AqWFdOQKKW8rE6MbExGNn+NfDgS+bJPR89SBUqp+zSTrVPhsDfrdHQlaIkaC3ri4Sir I5PgeKwLpkNiff/snuCQPfBz9SOLZyDL7Mi6XcjGT19p7oZsfYB8caFjfW08SmmciVIa2TiM1cZv 6A0gNwpGWuPK+GxwTRKspRoF6bAFGndkw5m0MX8P7N/GA8WLwIMopfFg3RpkY39k03Vk6yHkiyUd 94xulNJ0HqU0XcLhqG9S02+A+qg5YEM8bOem60lw+SZTOmztJns2bLem23tgKzXdL14GPkApTQ/q FiIbCGTTHmQrE9lOfkxwZKKU1r4opbUPDiOztTfdjIz6BuwVD8dIa88kMTI9A5k9EbnHjr5bvBRd sgxdvk8dA9mgQDbNQLbcQbbv+tjc0gmltH/96T26ZuB3wal0uJ3tkVELwAnxcKvax6L70k5PR100 MjsCHLYHRlr7kGJ0mbCyS+Dgus+RDdlIxzNky2ZkIBhMDewLfvr3vwbANUi6BRnF/nSG2/7pDLQb mb4EmT3g0xFW9ekImPBphB5D1gaQDTOQjiIk8emaA9v/X8L/73t/Ctegx4XgX6c+MG66uYLBl19g WPcCDOsoDAbfw5HTUYphXZwYZtidlpL16X07O/3ft+78P2LQcw/iM3JtAAAAVmVYSWZNTQAqAAAA CAABh2kABAAAAAEAAAAaAAAAAAADkoYABwAAABIAAABEoAIABAAAAAEAAAKAoAMABAAAAAEAAAFv AAAAAEFTQ0lJAAAAU2NyZWVuc2hvdGpavhEAAAHWaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQu MCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1y ZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAg ICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAg ICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjk3OTwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAg ICAgIDxleGlmOlVzZXJDb21tZW50PlNjcmVlbnNob3Q8L2V4aWY6VXNlckNvbW1lbnQ+CiAgICAg ICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj41NjI8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAg ICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KC0FGaQAAQABJ REFUeAHsvQeAXMd1JXpmpifniDAIgwwQkcgkQTCAOYmkcqRMShZpWVqtw1q7Xnvt/3e/48qWFS0q i6REipQYJOYEBjABBEAkIg4yMBgAk3P659zXr7tn0DPTqUamzAKm+/V7VffWDVV1362qW2m1tbUD iEgDA4N+Ii0tDUPvRWR///J9DrzPgfc58D4H3ufA+xx4nwPvc+A9wIFImy7Q19eHvv4BM/Riq/sA +vv6kZaexuz6c5NkdBp0GqDOEnHonxjilpZ+I6Gnu5vYHCTSkREIIJCRQTLSHSAIgxzop+zFL5dy IZf6qZc9Pb1uxEJ+ZWVlGQ2uZc+3p6COuZQLcagNO2+Tnh6nOdaxvt5e9Pb2uNUxysWUy0X3QtgB tseMQCblMgZ95Vi0Sekx/5zrWJy0SHw9PT3o61NfEaMwrRPmRwz51T9kZWWHO8CYr36f2uTY0KK+ softXvaFC9MinbLMZL9vemyyj1FfYpZ5REbR0tONfvbLMdHCbOrzMjiGp6enj2onGC2ZQVqYf6Tk jXHhHCLdpzxQUlaG1s4eZGXneJUN5zvnSnj6ewfQ0d6EnNxCZGQGRi1zDpAYbqiCPZ2d1tlkxlCv GECekyWdg2UvO45e4snKy4+pMzgHSAw3hKe7vR29VISt77wGDW6pTn39faiunozpM2chMydH7chZ 6mxrRoAdYiz6kkglxK8+Gn5nTp3A9u3bke7A2NBLz+Jly1FIuQeyc6lnIzegROiwMgTb192F/u4+ 5BTk24tWwrBGKkiBd1AuuXmFYO8xUs6Enwlqd0cH23s/cgoLnLR7VS6QkYZ97+7EgQO13gtNwjUe uaB0QMaMC/3qJezJNdMwd+48tLW2IEdy8XvckasV91O1l/aWJmTl5CE9M5MddOobv1RKL6/qk3Py i8aAlnykZwTIi9FpCdDIfmfLRtQdP4aMdL4Aj5Y4uOjlUildL8wjdJYyFHLy8rDqorWjQT3nudpL O9tkdk4B0jL5y3t3OidfMje8saXDDJrs/DwnbdL6494+dLaTFo75AUdjvvD00mDav3kTzp5tMCMo Gd4MLStZ5uXnY/mqC9Hd1U5aCtj2qQtDM6bgt9HS3Ym9m99GY0NjDLSwHgO92LtnNyZNmoKCwiJ7 cRyuKgMD/cxTgvNXrGCb7ODYUjiSGg8CI73MzUwLvfvwRTXACvLNLiOLDWh0dmQE+milZtrbbVo6 33JZNtVJFmtveo91zumsV1oM9Yq3DvJiZLCz7NebujpOVz004aqjyUgbQBc7URmdqU4azHppBIa8 DqkXSajKAcneZMJvB7KXZlo3Tvl0dnbF0HhCVYv5woxw4kk3L02A+hXDwBEz9CEZ0znYcCxLJ9/g gl9Cxw5BbTKdg6EzY5Zo0gPUXeJKT3fTJkVKRkY6O8M0dHZ10gCUEeAmqc3oTXvo23EqsPXyJU9e DHkArb1Qz0I9bioQRMJgO0lXPyz5p7vTsYyMfgwEOEbQAHDVV6pPluGn2QxrLzEYgOJxX28/+4pO 8iAGfWG7H6Ds1UWOagAyl+DrL/5EL7DkQlqsf9HIm/LEgZxtMo3GjatxUrLOCPCP+qXxJY065qTf J55AgF4zyqazK/X9Pn2YNF6pv6Qho1cyVZukDZBymQgg4Qb6Odb3xkgLDUCO383NzWjnS3YmHSx6 0R4u0WpBFo1l9Y/9lIv0c4T3mEFg9B4a4AuJ7yeIaDGxWQ2Wi43IezuLrcygGsT8QyITfFc4gnCN lpgrlUBG4hGOoAfAxYCjSrmCO4hgahnH5uBY5lYuxjJ+uKDLhxkUySASnfwgHZ4uO4E+tkAlGGdt 0iPFpex9ZkkH/D//Xqq+ff0yeM6VzF/CImyu2mSQM06MmCBs+yItwe/YafFojl2WxGA6HOySg9eR tQhdC/RIz0MZo1xoRE60bBRw0W8F+WVMcyX7MH+9OowNnkFtKDrx8d1VtZ3Lw69SkEfEJ9GMTov6 IpqNwRfSUXWZg3CIFJO9jzfWb9YvWMVQk44Fjo/U8vLD/x0r2ljzhazZWCoVK9Co+TgsC1mQGVGz JHlzMI9cEeTDlaHhPgnHYLpSh9OnxDkdzhGISUG+jAWuELLUySISkk8KHdl8CXBNkGv4okyERFLo 4NpQ8MNnngMUDkGHauu39d+bl5gQZe4uJJeQejkSki8XoyKELLU0DcJB0EN/pwqbB9cREUMq6eux I7E449EQMvhTlPBfEmzjasP4Sptia51JfMXOrfuIdwTcs55HzJaih75CpAjcEDCe90eGpsvG44lR cnEoGBFg8D35DCE0RT99HCkCNwIYl6zy0Zo0DJGr7sYX+fBTBn5dkv9WZyOvgztaTL/ENIdqHOaD QyRSY/5Lk8vcsaJJJloX5NLSNIk77/eDYjexONIxk4s0gEhcdcgC7xK24FsSj0iHU/3ycGiTmdda HMlFfYoQqH9xxDujxOeV2OYx0c2n4SEGR7SorYd74sQpCXkAYwHh887n2NDf/v2kv4M65gx+qIJO hzLDMpiGWLgcqlwcFz5cDThxFEsgq9/8B9OVAKBhijiufhirEeIYmw/eZ1oY+3vuyifF+unQD1dk jAXDiGMs0BiL3CEKi8IhDiJRe3eHIZoehSmL9jSpe2NAiGofGl0ckRLZBztCcY5tGYkzKRkMKezB HQPBEIWwuOKXyHIJewjb+JNalgTbuKozvtIiziz0OMudW/GR7rBOY9XjEFWooY5UpYSfyU4P8syR ZhirDAkdui7lEkZEitwQY/5So0EEuU2u3jQja226ZfS44ZdwCXw0HTYO8sPabESlQr95EW+tPDzx lopAPtqlR8xouVL03KGOkUWhftIhGjHCWGY4XMqFusJF865TND1ONU6xynplz+pINXgPnsGWErgB H0TCryACjygHyKRTlAqVzMPkSsd8uBwBHMklSInxSG3GWbJxUtCdCYWwPbtC3wOaZUgwcX+Pl2Kp qphmYgpmtt++3BKsQNRiJikicSolYXZR+SEUiVdKIcZ5P1P7GUQixTPepRZ6GJrMMyUqH1E6aqeO O5ogNR4hwR+OvkKyd49MnYBNChCnj1ZUKaJUhoU7Cd/t4w4zzeb12y3v/miy9Eurr3Epe08S7vkV bJCOBB8J1u3UvCcXfbrjWbgbFg5fEyJpTOW1OzpCtRwDFMIVGpcdiScsF0qFNLkgy9q6iBEN/HPV 9j08LihQ5cc2mVzGhBQZf8nRFojX2jZdtj4tScwj1tsl7CGIiUqrG/z3myFPU/IzJCQxz0EarHDi nStEBC1iTDymCS6oSVqpY61USC6xFkggn3TL2GUy8a4SADNskbAUaOgxpkEW/zIZSiWcZKxH6IP1 tHrLVsg4hV3oRw8tQdXM16Nha2kPLCdzD5srjDqBK289WwIFEyri05JQ4ZELkeUmeVkBDtGoEh7P JGP9uZGLgR2LBiOCHCczzESLtQVH/CJshWdxJQ6PRZ68jQKHojfQIVpcIRJcD/ag/iqFuuBBD8pb X7rhJPmOEgF3hSSIw4giMdZ5x09MKAxMkC0jQgjn8a6c9Qc+z8IIR6xX4g99RIlDGLXkIBoG/Ri1 aOwZfLj8dkySD96Z7GMn+j9+zqBYfJ6lqsJq66G1nrzIZvDk7OJ8nligmJ7sGLRgmwLypiBhMfW6 2rtsLAoE0hnEO9sCumYQUEZmBjLpEVR88l6W8ewVr3OJlLGRIkJ4EXk/VTRFwnH5MhbG49GYatmE 4Y/NVUguDgnx5c3ImexeZNY6RDYmbAs2TOe4gnxyhM6Xi8hwhCLU1tWXCEckzlSyLwzXsW4Zo4gj 1IGmkgoPlmhxTEWw0uopk8MUiNfaFv+8MskhHpntLmEPwUzFjpcHQyCM+lMDtsnJlG/U7HFnsMYj JLZGxyXvZCDQu2QEOSJG3YyR4JIOj8Xu9Vh4JBd9J8cvgRAErdlQUPFMRnP3YDPoqMHPMDStLa04 UHsAjU0NKM2v4DRvD7ZseRv1xxuZnUch5aejoqICVZWVmDVnDiZMmIAsBvgN8LQrO7aIUDU93MXg ur3BOaxQzVneUCVJC1EMm0wmHpJh86TmgcyYSE9paqCGoJBpxq2gmEL3nVy4l4t0R+F/girhhAoD an2LWwXwuEUBha2O1NPjWwFOSfFapuvxy2//Ib6lnluE6GORWMLXqUQlqF7/YlepBB0FllPBEx9p MBTJ0RLyAAqWQI2UBpHEH2qrTmTlV2QQwpFqluizIKLkeDgy8kE0DPoxcrm4nkoQLODzLa6y8WQW HiLx+eUcXzx1SyCvKa9DIkzcQX7FWT0VtbHQrx4H3yzaK9n04MnQ13M90jST1vQ1N7bYMYM/v/8+ 7Nm1F5nZjA7flY6zzadQnl+NCSU1zN2HtjO9OLn7ABq6N/AIxEysXrUSl15+OYqLi5DNCPQKRqoZ 5Bzi0fGFnUNOLvQ8i54aEOB7Onm+LBOSGzpM9L4A3aDwVMwQuUFAqIP00Bt1nOEaE8BuRRIiIYTG b6yhJ6m5MLkIFBHJoRXClxrwBsXG+Ah49tsBIg+PA8ARdfcvndgsPnB+h+QScc/JJQlJlmNxrwEU SvvnmotipBOuhYEaCfrQnyupBcGbpFwR5I0CJhentIRYJ7Vz1KsJrsCnQL9Gq6HQGC59O0yGJwZ+ mRhFPgtIHXO4ni/Dc+/ZPZ1dqdTPszkFroPHBun4oP3792HD+tftMPG9u/fh8iU3o6S4FM2tjTh8 ag/m16xEQV6xefgEoq+vF1097Th28hDWP/0qNm/dgdkzpqO4tAiTJ1VjwcLFKCjIg5yMMgK7uUbQ MJtMRI1+eVSpPqlMQuGJ3g38cF19r1n4TkqvyCLrnkWG/oyBKcUQBZg7ucjC8Na0kRhXfaUokvvZ kW75DDO58Id5gzxl8x+l7ls8Iin2wpQ6qEMgeUqlo8FcJtMq0eJULvQwB0XvyqPptQ4hcZ/Mi+lK t6z6nuzNJS/rP8EOxvMAElYsbBlKz9DfKWNrkLaYKpUEUhsCgrT7KJMAN3xRH7gzhnnS89EMX5Hk n4RwxKIwyaMbFUKoPsGcg5oCH1rbiAZlaMFoeZK9x8rEgkZjheqZpkGWOHVOYyYNP52LqwC/0lOd 8atnPVyst3PHDhu8XnjueezZu4cGYRqqcieiledMr150JSZWTjWvYGVpASpLqg1GD8+OjEzZmfmY NXUhJk2Yiv0n9uLkrhYc6DqOZ7ufxaKly/EHn/008vNzuamE50xLb23uTzXQ3+9HcmwCGqs0mIlj 0ksXyRXcc+sqKsKe53Ofp+aOS9syVEOXAgkhiWgpjoRkRobR4q3Pi0CdssuhVXc1hAluuD0OxZoy cgxQGE9q4frQjEeSi3NlJhJfl/WdQLI1gPGVFfv4L75CCVTN7fuGVcgGXNHilhiD7hKF2ouPxDEt wuOhcNVIPSNIOhaZIn+FyPUzRDz0DCkOVT4fIp4pu3a+aqOE3ZZ3jfmU1VXHJpwetuH5pbrk8rx5 GXm0/ZhUx3RO6fZh37596O7pwozpM5FfUGBevx/84PtoPHsWkyZPwr79B3HDRR/FnOoF6KOxmJ6W QQ9fj2dwRKA0en2e2P1+5uMGEhqCC6YuMx70DfThwMm9eP6F3+CKKy7BefPmcX1hP3LSORUsz4zY 5XgRmKpodQ1+GjscfPiscADaA2ns8ihxSYowWP9lqCIE7oIwa1wuAEfCJCFBtkXeTeW12qPnnXXI L4EWKa4Vje1RL44ukxlnJhaXgiENAs8/532xY35JFtIxl9wa9EqZhI7FtQYwrGRuFS6Mx/2VvUW5 RvP7wy7XnCJ8r9n4LAs1otAFc+ghf8vI0+1I/fc7K1XUpl+YQbkMHq8z2GHq1Kxs7n4tzs2xzqaX T/sJZNBEil8BAUo6RQGm+vO26p5D4y9Ag2+Aa/mUU4NGe3sHamv347vf/g56ugZw4dpVuPGmm9Bw phErlq/At775TcyYNQcf+diHsOmVzchGJqaOn8XCHgy/yqK9r7+XXrw+ZKZnGr86ezs5Bdxpawa7 ujvR2dmKHjK1I60VjWdOoqK0kGX6eL+Tm00yORXMuvUOgNWwjQA+7PfydxSJpJYcytVLzjF5uu2j c/jtcmD2q+2eWx6mkHh8xO/Rb59f6kecyscp8DFmvpimv/e6EhgdvgYkxsOAz4uYiocYpgv+6Ss5 /NHR+jBD+KJnS/5ukIbkAY0MQRZLaApt5KyJPyUtaqT6U2/gKJlo9CEU9sMBIpEingkH/xTIWJd+ 8tH7v/tpOCnJa+aTrvVxTU1NyMrMQm5eLne1dnI6M5uhUrK4Fq4fXF6HnJxsssvzhPXSG2bLj3if lxYk2aAmSWO04npj15tXJrf0KhSLX+fag9yc0diO2bOm4b5778WuXdvRWN+KK5d+CK8+84St9Ttx og5Lly/DksVLsfr8Vbjw0guw7Z1NeGXb06geV0NDMsvkYhwz/qXhyOl92HFoOypyysjPdNS1HsKp 08dRf+oMerkesL+/B2kMIphfmIMJEydi2tSZeOShX6Fm2jTcfMstyMvLQyCD3kV6TPv7CDQaUaTn vZVIRKRSOaq8NUlHsMNgx04grjF5InEsGNdEBAUzFmiMU0TkCpfge7C9K/VVTmxBI4TI/O+wcqf8 avBoknLwQRpcSSSivv4YmcSYHwgZDRFwh70kTZ4aSAm8qbph8ybzgEjkBXEuKKq2KXMSDIyJTHmd XOqDCYW0jEHjUW9gpBiy1BMliCYOXmg6NGz80UCjhWZGXpDpmsZpppHXxI0QGRkBFHKKND8/Hz1c C7f/wH56vbpNh9L6aBjSLkofYAw87nTNpufv+IljNGjSUVRUjFz+zqKR6SdNE/fS49VNC1CnZSQl u5BQTEhm7GVSt3MUz0W3+JdOo6yJYVu+973v4vjJs/jju/4Q619+AWmdObhi9U2orpiKyzNvxpt7 n8fBA7XYv3cfzlswH0tXn4/dXAO4f99BrJ57OQIBejTpuTNM7BzaO1px7MwB7Dj2FkorSxgrcIB4 TuPk4WPkWzOqJ1ejoKiUlchlHWiQ0ljOopew/0wAfZwa/s2Wx7Fg0UIsXrTY5FCYl4Puvj5yXaax G51Oite+AGP5pn55HmJxy02SLtsUoIjyrXwHqNxREFnZ4NIM8c0hQnvxc6wEkotSSDbez9R+ikfi FWlxxy4fshCltvqR0DzVtUnzyNupvZZSSe7877CpELz3z6FQjC+iwaFIiIPWkRAk2RjpiJAS+Ypk dY/9wy2FrjlodCdIeew8spyuGeVVZ2xoIS6X5LAT0Bq9zGBQY9GkTvQs17y1tLQgryAXxUUlNEho pNBzVXu4FhkBxsDjfOqp0ydQXFBC440bF9CNqqnl6GjrwpnjZzGhqtKb1mztQUNzGx555lfo7+jH zGnz8JGPfgx5udno7u6xnbR5ubk0htIRoMHZQ3dgF+0d9U2JpXMLErSsPpuCbW1tQ2FhAWlr5Xq+ vTTMWvDss89hyqQpOF57CpVFE2y6trioHOuW3YpZkxbhrR3r0ckp4lff2IBnfvs0Zk44D7Oq57OS 9NKxLdOnh121m3CgbgeyCtJRWlGCcVXj0NTYiKbTTZjN9YKzVyzmVO84M5zJcVaIHSOrKn5n0Vru 7G3DnrotaO9sR1dnl/E4i17CTP7JEO+kgTwkQkxi7PmdlXLfWgwDmaoX2XO1IHWEG2yXCFJX1dEh jSUdznFJA1zqmQiQQeO5SlyQ48N0iSOkFLSazDxL0qgJwYty4UmDnyLMlWgIO/HxIkqlo94Sp5In IbQGMCqOKDd9hXDtnTMGeivio9QiVbdSwcIY6kLFdvlWE0MNUpolpbSoEYaVytpkJr15+Zye9dtn L3e+njhxgmvQGPakI4BT9fUWvLi4uIQ7YAdQOiGfXr1MdHZ0o6W+GU1n2lBRXcxTLtKRW5CDyonl yMzN4lq2AeTk56C/pw95k7NwcPthPPbIwzh/2TLDd/DgQRw8eAhXXX0VJowfz9MyuP6NLUQbaBl4 JbFkzPIo0aWuFNpFU78nTtXhu9/9d1x33bVYsWIFbv+Dz+OdrduwYMECvPraKzSwerBh59PIL+Ip H+nZKMuehKqSSbjlktuw9+S7uP+eh9Db0YXbb7iNRrOc+TQA6cE7XP8OnnjzAU7pFmFuxWw0nG5G WkMeyssmYsqshRhXNIkGtryFXC9o895BAaiCMlhonB49XYtTTcfxxGNP4AD5tHjFQlSWl6GsssJ2 J+cwa1uPZzQmxphhSqkKYpLz5A9pLhF5/Yuv3q4wGbtMz1xh8OCKDveyITWOaQmrl0PJGGh+hJE5 E44nfwkn9SgE25bCpB70MBCF0QEhIWxjJZAQQncXJMU85klgiNsA9HCNgWK71gMjZEyQjMHbQBIa EHdR780j7mJDChjnaZBJAbWZI7LJ5zLicUeABg2faR1fSyuDHPPM2gC9gmXVpehq4yYG/h0/flRO L7Q2tiE7rwQ5eZzCnFzG8YObFlh2gGU0luQWeWv9fCRp6To1Iw0nj5/iztpC3Hf/z9DW3UjvH49L 4zrCPfvfxfVX34C1l15i07NZXP/W4YXei1uWHmVWG2IkvcHBTXc05drQcBYH9u/HBasvwJVXXol1 665kLs8IG+h7GacbjuBUZx+mTJyMA8112Ha0DVPK51hsv9KccrR01weNP0H0kqawp1bMYky/qTh2 5CimjpuFlQsupdFJ7x2f9XNTSF9vj589/G1vXVoD2Y+iglIsnr0GGd25eP7Fl/Dyy+sxrrIK133w ehqry2xKOCeDnkDyJVgsDCeZK49VyUCIsaw00HXycJiuu0blK7dDPNJfTTu5NQLDeuyQFOOWO78Z a26i54dzcoiDG79S2wgHc95IcU/IYKTv5V/OZR5mTrKOuAQNQE8lwtVwcCUmjgka90jcY3DA/2FB Jk+NIMgOyqanibO3NCY8V6+mem2dH59ro0ZHezuO0oDp6G3lyRbc58rMOss2sySfa9fyuEGiBfVH ztA4zELZ+BICleEElE2iZ5DGn58E10/C29PTj9ce2YwDuw9j1tLpGLe4EJXV9IrR41fIYMhvPr4Z v/zVL7GE699KhTMnD7kZmVz/xvqxfAQ4H6z3zWf8zxShvELI/zn0+tnmj+BGFdFXySPZ/uZv/tbC vTz59FM4e+YMrrnmWuzbuxf3P/AgxuXXoCyjGo299RbYecaKWWjkNO5rr7yGvrQAlk5bQYNuCukP T8ZqWnx6xXmYcsksboDJQc9MbvBQjTSdzTWRsSStI6womIB1C29kndMwb1IDedaBbXs34Qff/x7G T/hLTJ0yjbIjv8lnfsYCNrY8ApVCcLEhdZjr94gW7xhIh7waQ9DOxWJdTrjfcUcacZhFLopSj8+H GDI0/BvuCHrPQ1aXPzaJiJKUR8A623gr7Oua/51qan2i4q1X3PXQ0EVkrvEYn3yi4q7k6AUEWlrn 9tXcq4fPK3MFjF61qDkIQ6dcBBSHj6m7t5ur0Ljmjl4/7TQVOVrvt2fPHnqjelBVU47sbO7e5RMZ c2bQsWhxZQHaWzvR2tSGPk7rBrIz7JlYkUFDMTrHCZ9x8srGleC8y6/E1DnVnCamh1DTocSbxrfp hZfNxyM7n0Pjbx9H8ZH9SFtzKTIvuZSeNp6+wWlPmZZezXmh6+AP7euQKavfBGeZtJZxgB5NRp3h fdWPeCinfm6mOFlXh/Gcaj64/xB+evdPUFRYiaNHj9O4LeJ0dSauWEYDjPS2dLTg1e1P4kV64hYs XohLLr6KU7OPY97E+TYVrjoMTZk837efhlyAa/aUhDeeZPUMGtGF2cVIyynBJUuuxcMv/gRbtr7D uISzzPCM5EM88IfLK7XSn/tk0naORt7csWiW7pFQ0mp7rjmWaoUasb7OqQn1DSNWI6mHYlhQxxyQ I+jqOTwbUy+xpgZJ1fj3vbD1LGOgx95ImZzQtXAodomSKKNLRfhPg11y6IdXBSmaex4KgxHjFpkZ LQ6pMTLUCbiSRoScQiiCvIt4FOulJnfl9dOO3tOn6/HWttdRkluB+ectoBFUwGnfZuiUi97+blRO KUeWzrXlJo9B5KkeVJLiikLGqONUL33ZkZ6+4eqiPIHsAFZcvxAFFbk0YrhhpCfsQZM+5BXlYuq0 CtT98Juo0CaT5iZkr74QGTRCtY5Qy+ZMmvzQt0xNndyRqXN6ldSmgj1lGg05qypvt7Uxtt+BAwxL w/V8ZRX45QP345LLLkN15STuTs7F8tlr8fb+TehLr2V4lg4cPr2XU7mzUcLp2LULr8OM6nnYe3AH Nna8iqaOBrR0taI8UEHI565Q9Hnhf6taCSfGEKQA7Pi43swe5OfmBxngQfQC0ZITJFS0JpO88slC ia0GwmJyjC173LmkBobBOSKhcc2zIPyxoMVjXNz8jrWAzynnu4BZIbU/Vzpm9TeiPRw+XbHyIdZ8 qr9eRFPSlwyHdBCTBv0YrkRC92W3WC/lDoXJ25UswkSTACJJFk9oCjgmQKFMQYUL/Q5XKyVXHm3u +zRjn0NN8JlBFN4g6YphQiQnvUv4HjEhHAmgkk0klZWxZJ4+dipP/OZRvL3xKRpXZdgyawk+9YlP 4PDhQ3j6maew4pLlyCv04vZFI00dUk5BFj2E3JhAYzKeKmmKWJtLvE0QHm0hCjmlev7VC9DedRa1 r7TjJMPMXMR7uWnZ5gXUkhvREuCga0e2Ebc/mHR0tPPkjl4UMBxNOr1v3d3dNAzp2eTfu7v34J/+ 6R85nVuMSy+9GBXjJ9ru3wnLxuPiy1cxoPPLWLfqZjy/6VcoLS/HW7s3sFw2qrlpIy+nAHOnLMW0 cfPw8uYnMI5TtLnayBEX1ZF0hq+jtwDdJUdNaGk0/rrw1s6XGE4mH0uXns+NMd50snY0UwxWD5mh OrhOv5NL0WuUHMyhpYnDNRqhEAuNO+6QJc3uoayJ9tuQuDU0hNbjkjteGWkCPwZu2VBfaUhT/+G1 O/KM9LjSgaFwk2/bw/AhiEi0eGPlMPneA7dNLp7L1GltU/Fq4R0FZ518bHWVnGywi6NMbJCH5CIX 6XRwnKRtROGcFiFxmEwo9uGclgHyymNXsMXGQJbPYonTM5jE9nTU1x/D4V1v4ZPXzEN3RRXuvu91 DPy0FzfwxIu5s+egmydR5NIAHClJFwOcYk3l26mmg3NKGPPutmvx9sIZeOu5Ezi/o9MCIisuYRa9 kZpZVUgUpV5uqFAImaamRjz5xJPceHEc11x3DWbNmokXX3qRawnPx4wZ0zkd289g1BmYN34lXn3u dZRy3eK8OXO4e7kTH/3oJ3Cg9v9g2/4N9AhOR/NAHebOqsFjz96LGy74CCaXzeA6vE4L23Lpig/Y mrxARhbpjm9q1+dlWCO9YSr0Zmwdl2TLMC80env6uhgKphW7jr+Nhr6TuOu2u1BO41TGs1KWvJ5S CLbXXgsPk9xg5OmWgXb7wSrbsXZhRqQcn4HWh0OirBU6hB9iCnGozQYttNDt4S58tsbeS/iQWNKx N9OrG2vmzJohLQIvnjmVDU0AEjNgC5N9/qX+22eTL9PUYxDEoKY4Fou02JRY6NwSRPBBmkReyhNh s/4ePYkDD3oAY3uzM2UL4QoqnwsaXcAM1TvyQogca4HQCYXR5AqXD9f/FlJHyZdNiKboePx+z+ew 1vxlMPAy7SfyQ8euDeCpp5/DQPNpzKuei/pxBVj36QvwzN0vYtGiJVh72SV47LHfMFwJT/IoymGh 4Q2dVBp/PjXaQdxHT+XOw2cxbfoM89qJFhmHMnoUKkXewzPcuLF91w4c2MsAzfv34ACDMk8unY2f /fRnuP7G6/CNr/8bVq5ahf/5V3+FWTPnoKykFHkM2Hz96k/i9S0v8qi3b3P37zpcc+21uOuuL+Fb 3/oG9h7agclTqnG2mRtcuntxpP4QJpbV8PQSGbrkA/+0xi8Ruk1DuFOmnzC09rKzqw1dfa3o5CaP Tq6jHKAxKxpl4LV0NKOh9yzH4w5MozH6uZs/g5kzZtIwHDzl3M+88nZmiifaGUzb0Jd7ZPPyBxKf x7/Lb01pRdYt5XUxZREfUuGjHb521pz4WOicJvJLS0xGw+O3e73sBVkQV+VGx5ACKlkx1c3aQgrA DQvCZ5YQ+dfDZo7/gfGacF3qQKjqhkwGLUlxQIsnDBeAz+Wr6ZgIc5Q8Vo2FJhOHCT9xYgIaRLQo Pfak/PqLvURCOcnFZK3bUfEaDR49zt7UyNogmlGrk3AGic9HIsGYBiYMbdSCnuxDSM/JL/R6qrcL 2ny2MzdTFyyoM271LcOuqaEJZxm37tDZDvRzp23p+CIsuHg2fvPbxxiHb5xtlKg7choTayqRzane RAyecyoXyw1WPoOhYmq3HMHZXU34zJc/z5iAWi7L9YPatsyk693b9+Khhx9GLWMHVuRMRH52BS5e MBfTx8/Br1/7CfbX7kdNzVQ8//xzuPDCC3HrrR/E0lVLsenFjQzovBBrll6Nw3VT8PxjLzMI9D7c cvOt+KMv3oUNr27Aq/zrbWrHp677EgoDBTT99D5pQg7ht4s4PiQThYFpa2/EiYZa1LccR2t7CzJy B5CVzw0qlIXwZHPNZXZBJiZNL8OSypn0UjLQND2yWrPZ0NiAbJ6mksVd2ZKjpt63bN6MyVNrUFVR joDWCxKRDAAl/1s1VzfjU8CiUZPue4+GyRC1VPw3BV38dNbHiFbfkyVkYr6jJF30UAmJI76pUXtM G5YWZVHr0LIAP7s2Q2mxgORqLLAPD5TqHLW2UW+mjnmhdmSVdITMp1OySV3Vo0AKURPlWWpuiU0S lEtMaofSEeExfKmp+jlQvDZ/zu3U33CkVuGK+grGO9a4EtOyoAfQ+B6GPcyVT5OPygQ2TN6kbocU LikoMRQmIhHlVuPCMxr+gBBDzeLLolYTmwzjgztCbl8ZhmZhPbQblvssLL6fDGv+NMPjDDd8PMe1 fV1cIzdpcg2KS4vR3F2Iv/3meqz70CpUXzQXs86fgRO1r+Od/cd5Ju5cNJ9pQfNpBnZmIOeQNTEU Zyp/s7KKI1h34Cw2Pr4Lt1x/K+bPX8A2xq5Df/ynQNXHeCbvv33v35HbX4Lrl38UxfmlZjz1ceet QryUlFTZtPCdd/4RfvqTH/O4uiZO2/ZgHje6PPvwenrfaPSSh1Oq5mLcmhqe5fsk/u1fvknP5xpU VJajrakDV6z8MHJzCnmCCdcqJtnYJAP57Q7W7cW7PBourzgLC5bKsJtnJ5LolJAOGuddXRyuafyW FBdixtQ5mDWXU9dZmeji2crr17+AHdt3Yur0abjqmmuQzbA5ku8TTzyBhQsX0sC9lXXtRzb1XOF4 5PGV2eolen3lWWQlGLt75HA6wRIuv8SPsUiaZhYunwupxukK7rn1FKbhsakLVbvXEYfyjsvwt/ZC i3CAAmfkJbsnA1FrvPrJF81c8jbz8SMyiWEuk+AbzqGIU4s0NKw4QuM7bsRP8+E4wOPLxgft/04t pzwd0JS5l/zvVGMZG3jikfHLZ5oztEFFToJdtgYwnvp53Rk/Q8KKp3Q8ecW9JCiLBZWBFy2xZE4i jw/flUIIrg00ROScGPFBBJ1LjFDrjSI3OAj0cWqwmUec9XCqse7kSTzz+GPoadqJyqpiPLH1FdRU pmPuhH5sa87CoWNtqCYNgdw0XP7xVWilV/DMrnYaKoxl18FpSZEm1K6S4JMA2lo4tuckNtP4u+Li K3Dt9dcZqS3cCHLy1CmGm2FYmqpx2L59C7oa2nHjZR/nwKfNHp2hmtm5xBllPIHjNMZNmIBb6Pmb NHkyvWeNeOnF9d4RbDy5o59r7HoZkibA6dx1y27G0VMHsPH5N7n+rwXLZq6lJ67AnocAJ3ghvslw fffYJuyu24Y1a1bhggsuRH3dKWzd/A4O7z+C5rZGHvmWjvy+PDNkuzO6uf7vt7j+g9ex/rfg7bff xne/80PMrlqMV1+6D1OnTsHixUtskJ933jzU1h6wMD49lDntReOlTSVzuliGn85dDgQyuQ6ScRg5 va6N172s2NABRTrkqbBq7S459P15lWbzsL5SNLolJYJJ57bJiIcJX3oyCgomCi3W7nnfjD9+d3d1 oaGlDeV8wdM6WYVAkqD1HdBMgP301oxyhcPgIwUF3zHDvDGMvHLDLqPPV2y346QIiCIQrwYp+/Sx eHxLGdghgIKeUpKT7MvuEMChnx4d4pdrngV7F6doPOW1vjKJwTHkAVRdPZAhfp1zoTx6Y1NSp8AX PV/PvZup+rSKELgQukwiQjiEzxUuH659+z9STRThCrQr8KHqevzyB2lvYAg9NPQ5WTKoeR4tDYGt m97Aqxs2oKmtFU0nD2PmOODTn12DouJcnG7qRhk3eLS2c7BoaEU9jZ3DNIYyCDSN04qZnGbsH2g1 b0J2vqPpX7HNWhD1mu64Np4osn/bCRzedAJXrbsWH7jlFhvAumn0PfjQg3jtpTfozQ0waHQZp0tp 6NCIS2fj6x/gKDYkFTKsyys7tuOf/+Gf0NXEo+dKs1E1oQJvbXgTn7zyK9wwIX+cKTrbEEPR0FCq rpqOiVU1DDjdjeyM7EEBnoeAj+tnBjeLHKzbhTd2PY+rr7oSBXmF+M53vofm+jZM5NFyM8ctRWlN mR0Pl8VpYHX0/azTs2/9Ghs3vYkrrrgcD/36QcyftBTruAHloQ2nseWdTVi2bLntcr70snU4wVNZ 2rkDWucwK6C2jL4jRw5j245ddm7xuKoKzOGGl3IGv5ZRkMGNNJ2MqShvoMeFSJLOvRP5NDXXwuEZ I6mB97uBYk3ecbsPNpFogjJjXVyUcacNUtoI9PgzL+BZBiv/73/yRUxlnEvpd0amV8lu9gu2jlbH LDK/1ozyPShCBxwTIzGNhXoF1UEvXsY/Bzg9uQgwWyy/HKCwuhvcoFiEc2i/HyQ1qS+DmxSEeAq7 4FQYvzemuMXhYZN2JZdsDWA8IKQHstDDUzvxlI41b7JkxYjHI4ZMDFrsMRaLO5vIUasJNqK4y49S wOtgCD+ExxEiEUA6vDc0Y57VzK74kc2RQMqfzinEN994GY/9+OuorinBJAY2vnX1bCw8r8rY0Mcd s2V53NDADQcFDN5cPKGYU4/8rTlRJSMleK2fKe5x+ohHYWAUP7CjpQud3LVwilO+R7YdQe5AEe76 wz/CkiVLjFb1gHv27sb6l17GmtnXoKpwAnYdfQdvbHkBbV0tOHmWGzQqpnPqc/DRagUFZTh7tgWr 5s7G4iWrse/odry+cT3xBugF8fhotEZ89NEAlpIoCHTk6R4RWRK6lH7UnTqO7o5ebN74DtAZwIzJ SzBjzTzbkKKj3zQo0+rzpptZ4Ej9XpztOolbVt2K3/72cdQfPIuLLrnRdgRrHaGl4FdJSREqyhfR K7qdNJ/FxWvWYDdPM/ne3d9H84l2eoRz0RVoReWEibj55psYRmaRrSfMotHQZ/oUJstkHRZ9+IGD K6ftXiI2RSYxooe/XSbPaSYkqWeeQTSZD6ZFeiXjL5tGXIAvbfIItDGG58OPPIi07i7wtY0q5dVH /YJOmFn/1iae3lOLm669AYVFhZwxoN7pLcBPPh7/t4Nvkwvh2kAdrF8q0IgflsQm0ctv22meCuBR YXgIrc24Eb1hNSyiKaTIEfKKWq9EboYJ8AyoRGCMXMYwhOTtgoYwfrfQhcekEkQobJG/g7dj+Ap5 AGPIG84S0vTwrffqld8ZuKy/pwyJCSi+erlXu6H1kSqIMr3gKyKIBoSernY8+8QjPJ83wGDGaWjd /S4+sHYy2lq76WVrRwE9gNm5nCdk8gZ8DhRaEDRGqautG/vePojO/na01nF6ubufBmkVbrj8Vqxe cyGKi4rDYU7orTp65IiduDG+bAqnuXKwcu4lmFQ+FY9uuA9v7XoZN1w4xdY7amezkk7gqCifgA9d fQemFtfIrsKsKYtRM2Eu2jrbuDZOQ+NwsuKTUCeVGoYonMvcaYtRWTqetFWgtJhxE/lP4Ws0Pe8n SUDHfR08uRuv730SCxi+5mDtIbz90tucor4FOVlcj0hPZXtrO724pUaDTmwRf2bNns1wNlwn+OIL PF85H9+/+25U5E3HVZettanfDu423sQg19/9xrfw5T/9YyxetJgeI09nuuUM/T1Nw0k59eSmFpO1 Rn6YTqiydiNca7V7tXWt9ZVHV4Ze3fETts71//2rv0YRX/qKGe9SnmAlFe/o7MZTj/4KO7duxcql S1FSep6tGQ0jsaxj8BGiKmZcRj4/7JulxG2/meqezw/NiolinhrptXG/AO85TakV/zlVFfixIcUx IaTDPYZz2Pcf9kbIAIyFKb7C+5of+p1q8nxNi6VSSeHWZJePLClAwxcOrWcRMa4IIlySIaNC1LjC IiJ9bkn2wiPDj048enTISbMG05DBRWDrli/GO/sqsevYSRT3peGNzfV4cctBvv2fwGc+dgEuvWiG LCUD4sMU/LFIWTkBHNh2Eq88twGXrVuHO+76PKaMn4qy8jKbSrEYdyIuWDFd5uRw1yu7doVP6WU8 vvEVU3DTRZ/C6/teYtiTDgZl5ukY2gHLJAMuJz0LMyrmmDGo0C299DbKM1qYX2KeEMs4Rh/CX5BX giJ6JTVQy/PZE+X0EO3caOtpw/rtT6OL5y/X7juMosxCXHvBx1i23Ord3t1CL2ALFsxbYCFwfvKT H+OFF57Hn/3Zn6N64iQsXbYM3/rGNzChdBoumncZPZ7cAMAp9MyMHFx63hV4vPU0Hnn011i4YKF5 ATWTIDaLx37y7vi/XH2Pjda57l+Mb9YYU0ePIKkpK9C5dnnLS9vHGz4tvrEj4y8gi4dJm4j+4R// kZ78Dvz1//oblJVK1xhWKChY6V1uXi7++At34hTX0k6ePNVeslRaJwP1+o3NoDn+ENJIhRsFnXVr zMNwo14fx2utYxVPBEdf6gPFC/WDmmHoY5/XpZ1QJptRECT42OetitswEwdNsaIMV98DHokzVhix 5PPgSjDuk2EROY7QeaD16fHMHUVskRS8r2aJ4OFZwPFxwYizFhFfuXgq53U0HhvjKZdQXpLhd2wJ lR+1EIczsUofjvTBb5TavRqvPEetfmQGIQrJnkcBkiSFfNACf00hKqBxRiCDx5plYc0NH8ei1mb8 89f+FWdbC/HDJ7fh8MFTWDGvCtXji81jxj7UPAD9NEj66E8wPkXiG+Za1aBNY4ofa5lIUJkMczJ3 5SwcP3LSdsA+9/izaG1rw5133oVxXLOkTluduDpzpV4aMDJk5PPwRSjPWUXxOFx1/i0cKHk/aPxZ AX7IGB/QjpKI5Hk7fzfuLhmBfWL4iIlTeexQFk9bgrbeTswatwATyieSDg5qXJeYwfWBdU1HLFxP SWkp7vnZT7Fl4zYOfjm4+9vfR24+j+VjvmmV53ETyyXcUCOfqMcxw89p8tKyUurDcTNEqTrWB/s8 VdX0EpGITEcka5iHTts9iTL41vaHqUCKbod5FsnJxIGn0/DL5jIF7eLOoDDkwU7rT6ch77VR7fb1 N3QonuLevfvw5DNPY+fOHfR8V+AgwyIdOHQc5y+aj+wcHoUYVDvp/4zpMzFbQd6DJ8lI2Nl8ixzg etC+FI/IXusN88Hnju7bS4Y6khiS9FQbXLR0Q7qpYlrvqDWsMryy+czCXDGfzvjO0BpX8jA3N4c7 ncN9Rgyo4syi+kvL+B0bKXHCD2cPT8u6QhSGm+oZEJ8KYfDooNCcdjLEZPA9TfPxp/Y7+JosFEm0 m5AHMJaqmvJH4PMbQ2oJ8xqYwTTiUg09Ep6GJ7dIBuuZK1xhuK7eBH2u+c1UdKmT064+DRInz5zG fffeg+nTZmDtJZehlDsA80vKcPsdd2DP/n144Bc/xEfumIkbr+KgQK1r5Q7axrYuHN5Zh01cfzft 8oUI1OShn9tDjWdhknzU/GZXR0Ozu73HQsOUjC9AFsPDxNNh9HO9UcvZNmx5c6sZIbnVGajvPYJ3 Nx9CBw1YoRWNGQr2zG916CfqTvAil7QyFE3EoCHtyWJImHjwE+R/2CQ6sjNzzHhTR6mQLn004sQR BfbQWsH9h/dg4YpFeIqhXza9uQU3XfgZTiN32tRwOr2eNBdQmFNOfoWNPxGcTng9NAD37d+Ni69d Rf6Kb/6k+VCW+Fo29H4qfxOH0ETVsxThEQqX8EPVTw6JtTefZNY5i4ZOQOs5qA/SAelCFuNg5mbq LGwaPPzQvXQaNx2d7fjOd7+DFza8hrnTa/DV//FVLgEow6O/fRrz585CDs/P9nks/dJyBP3pXh83 DCm2pP5yAv1ot/clPkiOHKPEQPigWFfhZndlIvc+fIJH/hZvckmvDD71BZ3c4ZzDGJgy8nIy2TYI U4ay4CsofP2JI5gwqYYvOmUM4ZRFWoEuWtB8nPKkuvlJlw5QWF8cgit+8s8VLRY3M5Ion7gUf6vf VnLGsxTXd3hwpIRKnYw81AsPDz/KE2OaXgnjLBcF1Ai3VCd7fx4hT4oekQ79c4dNHGMSv4KX3o3U fYYapXCYXBwjIo4cdog61s1/ozpy/BA2v/Ycju3cgEOHD+Kzt93ONUBFmD59Op5+6mloAnXlosk4 cqIFR4424Oiuk9h/ugv7TrWjpakFNy6cy/Nz29B2qhUlk0qgUy8ik2JedbV1op2bNlrOtJo3q2xi UWSW0a/JqKb6FjSdbsZ5K2Zh9prpKCzJxkuPbMKN19+IKQzVYovWmU+ejaamJmx7Zxs3TmzGrKoV nOLhujnbqBFGpY7/9y0p7uDQJDm3dDbgTNcRhrcpwIZtr+PalR9DXmYRd3IWBntTtSSp4GAvp2kj jYU9x7cjLa8bV195jfHXupGhTknxc8xYKkSu2orIIHy/ryT/XCXpoLFMOOLQR2VXrTh7ad584wZv yPbTS129DJpT9Zg9Z7YN/NmcAw3I/cdn8oprd7zay5Tqalx24QXcAFSPQ4cO47rrF+MPb/+EBRTX 804e6Sj9ycnh2dX8rZeBtvZ2vPzSesycOZt/XA6i/oQ7w40SjxjWyi7iZptoIgoz2kKFVWfKQs88 lSNsZRqFX+zijDcyUvfs2cOYl4/j+htuxJxZs4wW/0Sgvfv24dGH7sOh3Zsxf+UVuO2ztyOP54HT zCVefo6OKlTV2C9EjXiUGJ9iw+Ph0AY9j1U+zthKx55LDBIplJHk4iBZzX15C5cbNB5gE4lLJOb3 DYo+cTyhUdbqOwrTI3mnrP7vUYrF/Tgk/1gqFTf0yALuzD4fy2AeuSLIh6vG42N29E1DjLO89AiQ d+y0u7nbTydX/Oaxh3Hp6in47392BU4efhu/fvhRrpPps6kexYgbSOvHPY/swg9+XYv1OxhIOWsm wM0I42iAzZ9VgW0bdmH9L17Dsd2n+abNHlOv68GkDqFL4WKOtSA/UMSBJA8llQXI1PTSYAb7RaJ/ sxPLysvE+JoqLLpqDkon5mPjU9vQfyodH/roR236Wuxrb23FkWNH8e1vfYtTmz9ATfF8zJ7CBevy XPwnTdocso8GXO3BA9j61lasW/xBlBZUkScyAnrp8OOfrfk61/izwNqnj+L1nc/jtttvRzUNBhkG Ghi7w2KO4KxrJRYq4hgDNK57mEHsG/Qjgp1DLkW2+gmtveNyWORy+34Ojbtc/oW8e/Rwbd++jbvf X2JeebjELzZ8FpRxuG3bNvzt3/1/fBF4F5dcshbT+PJ04/U3oHLiBMaM3MQ2mkXPXgZO1tXhG9/4 Vzz37NMhb5+Cjf/i/vvxd1/7F9z3i3u5FpCTv+xLLEYgaYiRjCFUeT9VVrDksVMy4zjYR/jrFe1B HB/qfwL0fj7z9DP40Q9+gP1799hJRr6hsnHjW/j6v/wDasqb8LdfXsvzzdfjoV89ZEZygHzUFLFX mziQxpB1UNfnAgHrMAhHlN8xVDOmLB4eR0QMqYEvjWT0bAjIQT+H8mzQw5T+ECX8lwTbElsDGGxc KaVlEDBRpHfBJCgbBG+EH+Se35BHyJXEI+uS2Cv5b1BJgBqmqBTOUwLxyyHPiEida44sQKLRcWnP Pvc8nv3NT3Dx+ZNxzUXzuTs0G3d+fDH++e6nsHzpEu4kXYi/+OpX6fU7xkE/Dft378LuHRvR03wU 0yZylyDfkh9/dQ8mza7BquuXonxysU0/dTQxJEqQFL19tnLaVgvLpzAAcfP2Ju4wzo7P+BPvCK+g NI/r1Dj1SOtj1xv7cHJnI/7iL77KKWttzuhHY0Mj7rv/59j01pvooIfylss/i9IiGTqMX5bU0DSM 8N4Dt+Wx6eXavi273sRA1wDWLLgGEyoncU1YeAexT0ZQZP5Pa8NnGk/i+bcfxtp1q3DxRWu8dZ/U pa5o9rQUWUCGAgpBTOWFQyTBZi861EkruRpw1H95OEbH4LNXa/w0zcuWTN3mixqNMB1zqKlNpTau ie0LZGPGjGlsZ940sPKLEsXpbG5pxnNPPoG3N25CzeRJ2LFtK2Zyfd9KendPnzzGk2EWcAo015YK 3M0d4f/rf/0/tt5WAH7FmJK/efUNLLr1kzi06SWeQNNuIWFkrFn9jF2j02IVHfJh9QveE11nuDQl k8ZbKdesKslvoj8bW9RxxpBUr56uTtzMgOiLFi/CksWLGTS90wza7TSE7/3Jt/Gxqydj7cpp5F8a vvLJ5fjH7z7Cc7NnYPWFF/Ee10zyvUgvO7FhjKFSlkXQSLHxK9Yy8ebzcKjf99CkloJwbQjXhEfp xCiXcNnYrowSKZiSU54JvhFzrgVtyFPxYRocBJQ4MSEPYCwghvLO/50KciJhhOQfS6UiC8Z9LZVw pdBeZQbzyBVBPlw1nriZEHMBgc7k2i0bCPhD0zgvPf88Pnz5dHzipvnILcjhKQC9mMFAyYvnFeLl h+5FN4NAq/Ndev4Snv17Fs/95l6sqOnCH3xgDs+UTce9T23HsvnV+NwX1qByRjlP/eg1Y6+T6wON FhqNLTwWrb87DRMmTqTRmY48DiwNJ5vRw/At8RrvFu+OQjm+rx5b17+LO75wuy1K1/0unubxwx/e jR2v78OUgrk8j3gq65hvA6SrTilm5v8OM6qr6e7p4rqmCbh13Wcxc/Kic4w/aaD+NL2mXaPy8Gmj zP76PXh2y6+x9vqLccfn7uRTJj7TCRC2r8a78zv4pAKnsK349IdbIj1sXB+aybVzCnqtfmBwX5Aa kn18Bm3Qj+Hge16/THql0ikHrWl7d/dO/PTe+7CJp8IobEtTUyN+ft+9+Pt/+Hu8yGlaWwfIdueD V1vQRq/igkK00RA8QA9/Jo3FfbW1PMnmaZ6W04s9J07bOtCaGTOx5sYP4t09uy2Y+FtvvIkHHn4M s6+8ES08C3wGN4Tk5fGljNWNty1HpZCVlH9CsDoYmFwbUurr64cw36ckKoRBN7UZTFPHonkS+59L L72UxiqXPTBXF43CB+79Ea5eMwnrVk/ni2UfDcVenl0+Dh+8dgYefuBnxH2KHlNOncuujh3toDoM 98OFPg3FNRTH0N9D8yf62xXcaPXxX+RTLI4QqrGjRZRIN0Oo475IcA2gunklsTAJ7AYj2od1B6lu L9EQ2WBkHHQmNfJIEuJ/VygE11MC8c3jXXRik7+bzUXdGTzSSwP80aNHkVdQhF2H67GChpvCRihp 6veGy+fiH7+xnsGPN+PitfT68F4ZN4Zkl07C7iPd2LlrH7Y1pGFadTk++6Hz0Z2bgU6eDvLmI9t5 RFk98rPzMG36NBqU3eho7GHYiCk26GihdS+nG9M1qNIzwe7ecMb8QV710Yv17sZa3Hr1h7B61UW2 lqmbnfmvfvUgtr65Cx9c+wcclArR2d3BzjuDvPX1PWYsv1cZRb82h1y36sPcIMAg1YOCXnv6pvA4 PZwKPtF4jEZBgxkNZxpP4GzfKXzkUx/Etddca7aGdQ4AAEAASURBVDyR3sj4o+0eNZmh7atx1Byp vJmatqJeUJ2V3761e1wDfj6nVnMDWgcmLxtfMHQmLjNZfqIWdiX99q/txpAPH64yRcsnnunfaJDU R+TI88f6qdXoaMPfMMj3KxtexanGFnrrfou/+su/xNatW/AcPXvTll6Ejq5GWwtbxRNc/Ml94Wtt a8d5CxYQ5QC2vL3ZwsAsXbYCn/7MZ3D8xDFUF+djy5bNePDBhzBQWIZ3jh7hMo5WnJ15mmdLZ+Hk q8+hsrgAn/zylzm9GjB9sdh5otGIHI0rQ5gU8dOKE0hubh7P8eamM+ILAuVSFM//Z9nFWA9ZROnB l3r56dAOZXnx+JcePPVHntItW7ehq/UorltzBfsQndftldURmOcvq8F9Tz+J3e/uwTgeHakp6Uzy il2PJ//BaBL8FaRFeIO4EwQ0QjFPDrYG0HIlLpcRkPBR0Hkh/oQUfuQS8T61mvtCEr90w1UyPEaM IwySPVPoIzFiQruADc4oVY3knfL7v0cpFvfjkPxjqVTc0CMLiGmJMS4SykjXg3nkiiAfrudpGIxz pNqN/Cwkh2A2g8ub2iDRwymjDa+9islTJuGF53di2YJTOP+8cTbQKfzHhIoCfPjq2fgFd/9m5eZi 6ZJFmL9wIf7rn/w5DtNTMH58FabtPoAtr9xHw47hRRo6sfX1g+g+24OrLrwWjz/+BM7mNqEov5iL xGuQTy/BiRMncOzYERRVFmL8hEpbs2cGw8hkBJ9KzvRMcR6m/ugZrFq6GjdcfxPf2ge40WMrfvXQ Aziytw5X8Eze7Jx8C5KcybAn3sAaE4Lf60zqlLO0aoweIj/JlOmk17SRsf3OtJ7AwVN70Z/Vj7lz p5vhPHPlUqxeudLOQdYLgGTVTSOo07ckfEC/k2/qQwqavkDYmrMIWFouZ0YWeSZvqJKMwhyumw1Q 33roUfLinvvTal5VlDOY3cqo/QmsAonoW2Xo8x6Ux2/5VmDQD7sz6CONBojB5IfObP7WN7+BLcfr MaliMibmncH4kmK8xaUPb23ZismX34TM/CLsvu87DAau9joefQzdIj1oZMy/FctX4MorrqCRtxN/ c+R/2sk5n/r0bXyhWm0Gnc4D/tcHHwTGT8XC6z6EjT/8GlatWImVF17I9p6Lmmk1WL5iuQWMlnHc Q73okl6I0CSS+CdDkg5Om84uKCgwaNI9sj3IOyEZhVkRdRD3pbPyBOZRhp6Bn4EXnnsW58+jcUej WvUPJXpLn3x+L5q681FRpdOPgs8isoTyJnHhgzUQ8ZEUM9ZBOFhq6O+YAY2S0RXcaGj9VpdicYRQ jR0tooT/KPtEcSa0BlA7ojwmumKhp81etxfiq5sLr0d0A9ugkkeGI3EhjVY5CV8oPG+YXYxWZPTn BKNZC/ZtljTs99FtoFhY6tCyabRVlpfjmd8+iCmlfVxIriXl4dTb04cLV05HS3Mn7vnRN1F3zS24 6sorUT2uClOnTDEvQC4HmK2b38TX79/PHYPpaG8D7rjzDk4fL8VM7rLT0WJ5NB5b21pw8FA9zjac Rn5ZPuPQFdpUVahjDaONfkXmdDZ3WdiJNk4nB2jKrGMAaHkI3njjdXzr69/ChJIa3HTxbcjjmcQ6 skrpfeNvMDuH8iOdU5xHzxzAI+vvQWNTA+bMm4OP3vQprpFawunzCuSQvzL8FFjbpoS5FdIG+cFg B/2yt3/pXIrUeBDwc37EhyRabrW7UBtRQ+Sf9NLoIL7Dhw/TQEg3D7a1GxqC9Ed5Hi8aFPIMKa88 LPKK9vBPYAwu88nrlGXzh5pRlQHNMEhkjvL4SeXj6Y+Vt4vGXEdagIG+01GWC3zwI7fh9NkzeOqZ Z9FROZlBm0tx6NWnsWblcsw/jxuguONXSXJ8lR7DQ7UH8aUvfYkettn4+r99HSXFJaYDjz3zDJcI TMa0mqlo4TrC7EnzUbdrM4p4bOLay6/ExAnjUXNHjYUBkl74xl8HrTZtNhGPRbtaXyJJRcVnGYEe XyQPD5r4J8WyPPqMZOIoyFRGXlNyngZgBqeWa7kreCc+8YWFlGW4rhSnrTE+XnsWH/n4p3HevLmM h8nQN8xDR6LhHgVVHI81QhIhDXt3Kcgz6akhcYVL8icC8S8OucRDt1HiKVeqBXFuNcLEnPssJXck e6bwR0JQQx5AwRlNtKJJebx8nsBcyCoE04hLiK4YCw0d0mIsFkc2X9+8Iq4I8uF6nV0c1YuaVdDU keVqnRC/1ZGq49fmXNtdxxeAdnbuz7GzX7eiAtesWc1dcRnWmYcAMr9eiq+7ZhGmzTiNH/zkHoaC 6Ufd/ncx75KrsIJHQVXy5I3bb/sMao8cQTrXEM3ioulKTpdIw6bV1ODtTZvM46e1edkFAZRXcwo5 L2swnhDC6BdWd44G9ccakE+DpKykgsFqK5GVnY2Ghgb88Ec/wszKxVg2Zw2x8h+NP69bda8b0Wv8 3rk7wI0xk6um4cNXfQ7NXN9Z11GHJx59Er/59WO4+rp1uPWDHwx5Xdq5X2S4qH/nUjxaT3Ruifjv EIfQUL9HSnocqg1/aENMZBG/ffdRb44cPmJrIyfwzGOV6eFRe/fc81MUcK3cF//oj9HONWkyBvPy 8tmOFP9OwNWP0qzgdY5+0wLspgtR04XaPaqXbW/6zcuXQ4Otj15s79ToIdUfVFnCGiapLcuj/sdf +jLOHudmrCmTbZ3c3//d/0bWrIWYNH8Jah+/F4umTWU4Jy6H4EYttYbT9afx2muvo2rceFSNn2BL PbRxpICw9nCN34/Zls7ynO/czEzc/smPMhzM9fj+vfcjm2vmbrv9C5hQVUn+9NhA30sDVCsrZDx1 2PtWJFeHqXist8l8gjbemrBCAowVQJR8rJ6McW2AUcV/+8g9WDA1gMlc76y1f1Z7fVCWTVwOc3yA 8TQrykPo1Xf6ukL2pyT58AxYimAOrZhwRIK235E3hhZI8LeHxwHgKPXxe3aJywXGQXKJgj91t0QJ /yVBRIJrAJPAGBP1gj+4o42pWCKZxD39OZNaUM2IwxUKazwmEuGQQghnEonF8zj4aGpLi8K12zOL O+n80ApaU/M8I//v5Rvwn37iWvSwY9S0r+ICWjUiUHdxQJg/rwJXrJ2KH//0p9jEXXN/lJmHRZwO fvrRh7DvzZeQTm9RUVmNDZDLlmTaGaKbGEqi9kgt7+ejsrqUG0+8d5V43g4VxFieyO42b9DRLsUc ehTledAankOHDqChuRWXLV9kxonR2t+NupajqMifiPzM3DiMlgii/xNcSsM0yGoKuK2jBQEelTch ZxJ5W4Wd727BqwwNdMNNN5v3SnuFbUCOhS/WHplxqCLFUjbuPEJyblvRndAT/vAdLAp/MrQNmz4y 86lTdYybV88XGW4OONhFTzl31NJYUOw4raG87+f3oI5r7rJoHGld2nKulysp4c5z4mrnZiptqpCO y8MuT1EWd9xqqlEe1N17d4MxtjFvxnzaHv2cXlZA5XC9VQf986JOC2L0xN6B9iVDpLC9agPItKpy zJ40Ac8++wz+5Wv/hN40trXiShx95te4iDv4P/CBW1BYyA0P6rsI8lmGcvnav/xf3HXnF3HHHZ8j L9Jw9Nhx/Os3v4nN77yDQh7oNnnlWtRzJ/3GN9/Cf/vq/8AcnhEt2ippNCqQuB0rx7rL89fLfmpo be23ffhSiE5LzHeHIiBY7xY/wx3niOCUTSceSTZiRBPPv37pte2oqejipo8eejPTzTsr2s42duKX T71L2gowrabG+hrxSeF10tkfycNr9i7RD63aiJWI+pCVMbknDykqeLvp4RiLNYDGEOmaGO4gGSWE b0lfbtAE4QsB/xzRosoHKfHwJEiM3jkthYH5d8799nnn883/fW7O5O6EeBZLpZJC5RmZLtEM5pEr TD5cSsa/TIIv3PZgpdXfHWcH/0vu3D1Rf9y8EXrQS8/GeTzLdTlDIvzv77yIv/qnF7FlwyE7Ei4a 2k7O+13EXXKlhX02AKZ11NNbcghvPv4oLihtxiVT2CWm78E9v/4p7r77e9h/cC82bHwZZVVFKBtf ZMaaDXKDmRkNVfgeSWg43szdvnVoO9uJKZNquLbPC0QrD4ii+peUlKMoNxsHju7GaW5YOHXmKF7Z 9jh+8dR3ceKs6Ak5yMNw378yDmi67rimf1/+MX5Ofr2x52m0ZB5DB9dtrrpqJe784hdpxAQ8z7Hm 4+JKfg8TV6E4MxPHEDT6aX/sFfWyo7VdWsunb/35/ZI3dUmvD290a6fzoX04fvwYihmbcuKMKuQU Z+LtbRvxd/SoBQrTMW1JNbYdexMZk9vQWlSHB+hd+/a3vkmv2xm0trbYCTpHjx4xPRf+LBp4RGvw d+/eg+//+7+j7sRJ+z2UyHg4K9iaiuygB7GXhqR29+pINp3KUlk1geGOuBv3zAkaeF/AspWr8Bg3 Mezdu8eOSRRjyumxv/KKKzGfbd8MX9J/YN9u7GLw58KJk3DlNdeghOdkV/a0Y8Hi8xlE+hSDq0+x TRC0kFiGDk66Ljs4NdATxfgbSlu8v0Wf/kZNMWUKQ9FQq7N+Td6dXThx/Dg93Ndg18EWbNx5FPtP NGLLzuP4yQNv48///gk89cphlGR147cP30+jn6cISUgkXka9ThXJihN/uCaDryK7w3j0YDCUkX9F 4lDOob9HLh37Uw9uihgzClpv1E/JUBkVkytZnItMlIT7pXOfj34noTWA8gyxNYwOPcEc3vum3mnd 4Yismq8QkfdSdx1UB/HLkWao8Zg4vI+kq54p74OqS7gvPvcod8c+gPpDp/Hf/vwvOT3lRf9v5CkZ 2YUl6DiUgdqjp3B44QSslsVor7eDq6C4ezkFWfjcZy7ClTyDd9OeY9j81tu46cQRLNt/hAGd01D8 4auQvbgXr/3iTfzohz9EU1szT+ngerw4eKas8tbIASqZBrguMUOrwflfi8E1nSYvn+Qgz8rUmhp8 9OMfx1OPP4kTR3bblN2Wd95mUFtORdMTogHy/RSdA+Lv3lPvoLiqEPPy56GQ05zV4ybT03slauZM MYWUkS1juzuKTkSHyrvSYf4fmxRGZFf8sDV5EcjN+2XTfp4iSm9krKmekydNRi+3NJ86UY8yLk8o Kqe+MuB5fkkuzpsxHUUns1E+rhTTFkwyD5HnxR7AfJ5C88w9r+PBX/4Cn/vDL2DSpEnEq93mxME6 aK2aLvW7pLgQX/jCnRaqSLhVC3nx9O3XPswy3R09yR7voCGWn8UL6vgF3LihdZsKWZJfVIzxlZXY cegoDvK4xD/98z/D7Z/9A9x8yy24Yt1VDPp8uXn0VDdNfZ533gJcznWCein88Mc+gWJO9zacbcC3 GPtv/4H9uOvzf2g6ID2Q4anJUr/e0WpqTy1DbLQol7J7Y5IH0fqAaMCD95TfxhYxOYaUSfmrP1T/ oTXDv3rgRyibOB6FPLHo/mdOoTC/g1Py/Xhn6z6eGJSHdWvnYdHMUjz02It4pyoXHUsu5yaSdsyY PIu8y2bIHBnCMoiN0BhqMFwWn3o+94gaLmMS9z0cMn6lZ9Z5JgFt+KLEI/hEYu1g+IwJPzFKjIgg roQhjVbQh+9MKKxApHVkghmtUlGfh1wcsVRVvBMTvQ+TlXVUUSEnc9OQEEDidMWInZ2YP78TY4m4 sw2iYdCPuEENXyAM12fd8HnPfeKX9svatzWUPrTQM3blipk8z3cPp6rarPMXy5588ikEOvbgq3cs 5/RUDqZOLOBgOPxI389dw4tmlTLmXyUaH9zM9X0bMY9TrF2dVGTG/Ovu7LWB85KPr8KzP3sZh/ee RFlxGbLpoZMRp9eB0VIvF5p1cP1NFg0/jqfIL85l+UycOdYYPnyeQDQYKcmTc9mll2HVytWkrRU7 dmxHW2s7rl7+MRTnVXBsjBap2Ir+p/8QBwMMB4SedBTmFSOjOxe//fVvUFFWiTmLZtq5ypoS6+Kg H9lVxca40WUdG5yRcg3BwUYQafxpyquV+t7F3axaL5fLpQMyAFo4/Xeam5E0vauBqqK8wp7l8Exq 9VdSGb1kKNTJqquX2FSnnWzDqkjflHJL8jFr+RQcffu45b3hxpssSLIMPDYTesfSuVGEXGMVq6sn WUcrmKpxJ3eK9NFw8Nus/x3qlA3D6B+SCWcveQKIDJs0i8VXUzONYOgdpDE3b/JEXDSdIZvYD2i5 hO6n8zs7eO05dQdQxo1gf/JfvmLP/Trk5ObQuAxg7qzZ7F+9umr3N0/5DtV7+BqSyiGiGT4vZcaH immo9zzJT4lVDRqd9vPcjzjgRxYW9CPHTqKqoAeXLsjHjzjVf9Ut1+FihoF55rmnkdl/Cv/9tgtQ VpmP2n2n0NeRhnd2n8TLr/0Lp4obcfWNn8Vl3Hym92SGQEUn3y+9GhNwfGRbtayLDlZwNKM3mC3u L+EwdqmivLDfCfJvJOQeXDHBAfAhiF1jCMl0CN7U/1Tfyn9JEJTYGkBhTAbrqJwQRWPDxjSbilB3 6Aqf3mhIjj4cofA7AntzMjyjI7IyqpJlVQVVPW32YFU5CA1oGoox3xatvAaPfPdrKBzHgUidP5Om Rmexc3/j2bfMABhfncdO2BsQBc6DZlkHffRz1FDYlYVzyrDzSDs2LViOQ+WgEbYM6VxhLSMxrzgH az9yATbQSGw820xkQMm4QmTx2LfhIesRzxdt7kZDnWLQDaCQMcYCCuPCdUdV4ybQM1HMazUXDg78 k62qNYJaM5nL9WulDIGx/pUXOXUzHiW5ZRyYhzdmWfw/ZbK4iyZgypp8m1O5FBveeY7ermX83Yf2 /kacv2IRjSZtUeAAx6/g8viY+WUyGk6BYoYSW0Zpg3ReJPnGn+R+pvEMjwPs4CkS9TS2+lCQW0QP 3GwzhHoY7y2TVlP5hFLUHayj/vD4NC4taD7dhs427vakkddH+nPLGdtugLvVtfp/SFIbaDjdiPKy idS9HCujl5JQKBTm7+ZCQK2pzchQg6TnjGV69BfFa+TxTFSM1PqGVEI4BJoLNLXJmL5xMwTlfdR0 t7x7V/GIt4tXr7I6SiReUGRVR2sQNaVJw4tl2WsYcN1XDbRu8Cv/5b8yHAzbHw1XvQhoh7OepTpp Y4YMKi9pMGQdKBNbr8lKmzfVfxzKpQs+9KyOIU/P/anpcp1ilEbeXHvNVfjnd97E86/v56adApQX 5+Hw0cNY/9Sj+MNb56CwNNfkuGHjYew+3YPOrN34o08twom6Yjz17LNYzrBIRfSSZrD9ZPNPNitZ SeNYVdKLbjxJhHt9WpyijweJ5RVfveThjBvAqAVCQqRYwtejFosjg9U8qKNqU04U0upDTMYv8cwN LYJrEgl9JIYn5AE0OKMwM5QnKKCQToxSLu7HPi0hhHFDiLGAjyjG7IlkCzFJuFwRRLj8Hys1Ep/y al1LOnclcjg3ymT8WZgJfgc4zZTG6awLVl3AKY6/5hRfLoMAa00Xe3J6CK684nI7BeB/f/dn+NAH 5uIDDPwso0BxyrTA3IN4LsN0P5MnebS3nULBRZfiiSN7cPqFWiy6uQzpBTx1g0ZgSVUB1nxoKXY9 fZinBbQSXS+qJpexnN5XhkL2qJYhp3I5POv31NEGhpvgJo48TvtyMJD3RkllzftHEF3E00BvTiG9 FYpD2Mm1UMeOHkcRw1/YVDF3uL6fwhwYoFdqXO8BrpmsR31nDQMaZ6G6sBgfufRTOHTmGJ546xe4 60tfwLSa6WbQyEDQwB+7VoZxeSZZ+LebK09vDDYv9UsDz5kzZ3HwaK2dapNXQsOuscN2jGtHr9bL 2YsB6crkQi6t+Ws608gjv+TxbOfzXrT1tKCOyyMGuNFBO4aHmn/pfFFqPt2Mo+/U4ZIP3sCpS079 CjanBLvY5vwkQ08GYSD4HsJL1dB/HPr2bgcJCN2N7ULQeklL0DFpRomMkSwarTqlJ5M75bVbXjhk yLbTsO1j6BhvgGZoJTYRxTVMZz+huqn/kEEow1Xl1CmpvXnvA+fWnRmSSlIv3+sn/K0tTejs6OTa Xm4a41SrjKt+dXbKGJlUlSG3Ih8PvZbH1byu7PsqGBD7s3fcidc3vIYbebrRWZ4y8r1/+j/49NWT sGAed0bzzVLT0St4LNyB4w24au0sLJpdySUouXjkxbftiL3iYnrMZdxrqQ2RmfFPPnaK+cQVa4ok Kw5yYgVv+YTDq5H3GYkzLkCjZPbgxk77KOBGeUw8DlGJFu9VyCESo1BjNHFI+AmiCsRrbZtCCGmi GEcRjfc4QWpigj0kE2lxPeCE2OWolVrj8ZHY9xAaI3+SteyjbTGypn7UOWqgFsd1GLuOLepmR9RL 75gGMBmIS84/34wnrYmzN2pmllF18VoacI/djxmTitFGg6qtoQ1n2ntQls9df+X5BnMoyTLwqiuL cd6kDGx85WGkF7JjfO0g9mbnY/ktS9Sj22CTyWnciuoSFDGgtMpkcEAyOiNokY3W1cLQGhx10tiZ KvVyoMriIpv83EIUFQ6OF6j+VYOUaDV6OfhqekttoKWpGYd4bNTk4vOCTwXt/RTiABk2Lu1dTOyp xeT0d6kH9Lh2V+JEewV+vmMrbrr1BlzK9WGaxtSA1mkWi7gcX7L+KP5i8SEJ5vbbvd9khLv+dD0K eIpF2cQStDNmZF9dM42hbAvxot26pTQu+ql4ojMnPwdnTzShubkZEyZMoAHYhZMnT9g6L60/1U5X KRrfTWxcF1ldXO7w9tM7uQN3Di5ccxHzeCdIKPSL1UN5I6jxDL+IG8NceiyLLDlMxhFuq30oyTOY Rg+kjrCzROAWN5DT4dm5XmBl3ddT7ViONFrUJiV/rz6ed8vyqEBMKc7+mPjNk0vmqW86TYNM/VsZ vf7mDeR1kIoQdq9u/BzaoYRynHvRSSJyafSn0VqWwa8/9Y+3ffaz6O08wziPS8gGQWZtWI8p1J8v f34t+6IMezHICvClId3bCCPo0jXFVuwiw7Kzc8xolrrIUxpinjKOmERZUG9GzJfcQ8OiscIqNpSb ycEOl/bhasbMvw4/TcWV0SEZiZTYmZwQakORUMlYC/k8MqpiLXROvpAH8Jwnw90QZRRQcmiHAz7G 942HPiPHGLcLdDFoncwk7UTTW6o6qlN1dTjFQUvxyaZPrkZOaQWy+UyDl6Z81BgV40xJUyGdfJ3P 53FwWpPU29dDr1w+j3brwPOb9+DMqWauByxEd/spfOUPlnM9GAcL9WoRSZ10MY99+/xH5nN3YQ/q GDbhez9+A5tf3o3yqWWYd8FM8yCZVEhPDo1JJa9TiJQV3/h5fNXpIw3I4TSavIMaOjI57TR16jS+ cXtn+KosUXpGLr/FItGeTYOxqCDPG3R5781Nb9BzeBqrVk8O0auy7ydxwFMs6Y6WTGSmdRlbCvKP YP/hHagoKcNHPvxR9gmaKvM8PvIE/8dOYV2KrKnaRCY9wpq6zC3MxvhpVTh5/ASnM+lJ5vKEE2wr eimSoZPJdW6F5YVcF8aNTAyTVFpagrKyMjQ0NuDorhNo6zrDKcFCvrxkkhvcMUzv1K7XapHVXYDb 77qdQc5zzJDUi5XWsGnck8dK33GnRMoMi4TrA9Vs+aeJJplzfbRENXU9WlIxL9j36HmjwhIf+CBS JlHzKQ8z9YhZ+k8eFtE4z80vNEb6RsTg3icSUnz1ExxtYrHYqLQwVT/J7b9+5U+4E/gN/OTRDfiL 21fxxdObpVD/qADe0qc0vrw2tPRxSUqe3VMttJZ098bXsZe6c+0Nt1B3OMMR8KbLrbeNuXrKGAu3 hDWJlJBSJoHPZdHfI1piVpNh+BkyAKVCowGLVDMzpHnDCS+tIvwQEpdJr+ZqPC7R+LCNJv9Hqoki XMFXh61vjdSGj9965F/zp9ae6O1Tb69btm/Dwz/+HjJOHeIZlek8v3IFPvDFP0U630hlEGoqt4ee QHsrtbIcDmjQaRpYU4KK6n/H57+Iowd2Y/bCSh7ZNg+lZSX49re/gbvv2Yg7PraMOwrpwZMFFpGs U6TnrbAkYCEhpjLcS27pROx5/TCmLqARWpBDOtgNWt0Hl/XBiCZ5UwJ8w1Yw2pxADioqqzj9U2Sb EzQAqKThDoIQ3aZS/K01iyqnwLR7GcT25z/7OZYyGHRR/vubP3wen/Md5KPv3xE/z9CIbzl9Bh0M DF7EuHZSNtpG75EkgoIGV7Bparf4mTOn6eXro/c5n1PBWRg3pcQ8zAEtFejo4qkynVwPpsaWjtJx RVwyAMbDO8yNFLl8+ZjKcCnlfLlpReu+JhxtOGYvSxmK/cH/S2auxDXXXsu4eFVm/IlR8rxrI4Nq IyNLHnjFi5PRMVqyagflMlreRJ5L1tZmVHlDlgiUeMrERwzDfFr/pC0yWi6pOIvSQeOlgYoCL8qt WGooebTREM7RSwJfCKT/5zNe4vyFc/F/DtTh57/ciI/zXPMcBqtXF6ykPJqhOHD0JCbTyCspKkQb Pcn33nsvXn3ucZxuacPESdOxjsfq6eWJ77H0nrOPZVm/nRmgKB8huSgnaUqQrCiQw7eEw+AGgdtv B4g8PA4Ah0kZs6uwXMYCZXKNMuC/KcVa1WDTYhtzLazkCIuJHpGgzoLfntBiKhVfJsMRLOKKJLV+ /mkNXpo2bxCdBhQdrNTDgUq774KkWh8uWrVQ+pUXX0D58R34+AVT2REN4AevvYzSpRda3K7p06bx OCht7uBAxNHIO/+SC94ZxFldguSvtXKrV6/GAP9EWktjPbZu2YCe1pPYf6QJrR3slo2xwh5O6hQ1 yG3degT3PbwFE6fNxuc/dSf+79f/Dfu2HETNvCncNceQF1xHxSVHUZPOI9bUkyD3copYx1j1ctAu KysN6aY6VGVQFSKD+KpzleFXW1vLnb878DwXZ08qmou51Zzqfn/nb1R+R78p+WTg3foGdJ09y906 NJTIa+mf5zOOXmqkuyYyCdUkO1LO5J5JX0Mp+EM6ralcTXc21J1BQWk+vX0c7LnDV/2evEzlnNrr Ku6jpzsYtoX3Ff5FuzxrD9aiZmqN7ahdsmQJQ6TMxymGVuls70A/p/8KiwowvnwC0mjwyUMUmfwd wlqSIA98OtuHzp8VP2JPIiSuArGDFtxge7LGHkfJuLKq+urP4khipf1ZMa+sqqr2r+9BsiZcyVIp Stdk90f76OTyhwEaglrrSCueRmcOPn/7Hfju1/4RP73/Lay97DxM5EttQR5dhUR1uPY01r9Ui8s+ 8AW+UBTiGI/R27LxRXzo+tnYsLnO1p22tTEYOOMx6sWb+825ltSr48h18eUdS96RIY301Oefz7eR 8ib6TMauUcEPjQ8uksctl1SEa21YnIolKHvhsPaSGM9Cw2ssdVVjUvLz+r+9uyn8FC38S4ykeOoR RGK9hDtstFO85IphFIg2OxRwoArQs2XGjqZ4iTWDyLUurotvlb3sWKyh8YHa2OyZ0/Hk+nTu2kzH /PGZuKS5FN/5169xnVMu1l17Cz5w8602vZqtDbhMgqhOVYafkgZMDWQKidHc2oYf/+DbaD67H9dc UIPzbpvP6ZBMW89nmfkhNnSr8+Si8Zde2Y97n9iLnbuO4KOLLrCp5Kqqiah9/QBO7WhCO4PJVo+r 5kL7Is+i8IEIDivf0dmN9pYOM/4yuVu5jG/XpWaAeMz2jD/tovTw+sW1dqujowOPPPqoHV+V3pmF aePmYs6U8y2Lr9t+/ve/IzhAXvqNUvpzlt6/bcfaccMNN6BkIo8/c6XfEVVI1aXagacp3suB4EqX tYRgUnW1nWvbw00d2lQUSZd5nEt848+rjZYUyDA8c7wR+2v3YcqUqfYgLz8Pk7KqpbBeRrWXIB7p p9qp2lJHRxteeOFFxpLrxhWXXsHNS5w2pgc8jUag6jlSGjt9Fb+8s3pd4jRqE0CgIkNnGsS3qNzT TcMRulDWuJKmubUr24IT8HWnunoCvvI//hpPPPzA/8/eewDZdVxZgqe8975QFt6D8IYgCIAGoBed 6CSKklquW61W9/T0xExE98bszk5sxLaZjp7p1kbLi6J3EAmABEESJAGQ8N4DVQUUynvvq+ac+/4r A5b5v+p/itQqgfr//ffyZea9mXnz5s1r8Pzbl5AQXsTTEB4Hc3N67XItcuffivU332ynJ2Wl15EU E4K1N+Vh75EK7KYLmaryEmzZejemz5zLTYcMcW5wEzNK62xcEoQB0dRRnvvj1o3lBmyKsyKplzjp xlr9AclQGUMzf+ieP68GceSC48/CR5TlgUTommRdjhGITzsuVcp/k6xwRPvH+0EsBnYYCGkO5gK1 43DBM1QFGF8R1EeKpnsKEUFJwrq5o6R5A8IZx1NHTBqUpqDNFUhQa7FbvGI1Xnq9AP98uBrfWJqA TXmx1IujD6+V+Xh5xzZKQvrw6FcfRSQt+oSjispKxuYtx4wZdHJLAwstXg4RCrK4ukdOnMfffX8Z Zk9PMz2+G11ghFBqcpgM3uET11HZHEmjga3Uh3oT5xg14d/qmqkHk4nHv/oETp88jT0f70FSVAoZ QOr03DC61X7VncI4nLLKVKg36SkqZqnaqTZpjDLLYJL7DkVdqKWSf0dbB5qb6MYkZSXyMmfw2IUh 37jgymXMH9M4GPCMYX31ctH59aka9M9dyxiv6WR8ijFv/vzBY81xShn3keiKU42nsnFzT/6hStcY cZPGjaTCVdSJlRROGyptbDycgmXT8axtgKSwNyzZeDMmMIl6pHWoqqyyfLqv/FJ54H9L2oyxGKOf 0sVVK2oZEeTXz/2S8zSUMbJXUXLETY+S5x3nx+ifVoLGvDXJixdGL2biu4JD9HIk6BO/N5kcAa5D /W6rC2GaShK1kKujyDBaa/NakVIe/8Z3cO3aNZRwPlzlt6y87107HYsWLyFjH8VQcU3YtfNN3Lw8 m5vWCGxZmY0uwltRfYGOwdvxZz/6Md3oiLZqA8BCJ8IFO97YP+WbGjgsYPRkaGL5w+fL6Dmnctcz tljPFLtl3EY4MAQIUcNqFh0LbHJgsHk/hcpMAiikeDV+XKDsm+/wOyCd5faPW1/AMKkKPodF34XH sOxfYASBXCEoZJWOdetrq3Hw0AFcOnkCKXQ9sPnBR5GVPc2eh5KAy6pQO1f5/UpLTcH//d/+O155 /VX8Zs+r+H82F2IDdflClhcgMzMZ//jvbxnz+MSTT5pkZNu2N3Bw/3uMGrACG++4B/PnzTM9Oi10 0TwuHmD95VVNfDcOkWQ6BxMbKZ1DSTQOHirCkavBeOKetTh3/hyW35SDTQwTd7G1FzsPnkX1O2Uo vV6KmcvzkZ6aphcHixm8YH3hVJaJoHRGA7A/GWisaWJs3xIsWrTYsmlsalHX0VpzSzPDUtXSTUQr Xd9EIi4yBYuyFyAhktE+6IKj74/HvoOo9eZCfXn4WjNKumPwn//0z/D6q68a06RxYGlwvHtT2mh5 plzAaIWOuGfMjOeO224xfs3NTbzLscrjPW0uBvolQuYYo2JjY2WzUQuFJxTxk6TGTSpDahLBvNlN Qykd+0rarHzaWHRx4smViCuB1+mhMZN8lpyahB/88PtIi8uiY+l03peeLet3C5/gW9gaZZZM8JaP jwmHGIxA98xEEk8fWz16dgLhL3w5TKATKi6URhxmTDe90DbJ8l6gikLkPotjSePr008OoL+jFBvp X1FHvrdvnMM42mE0pqrHv/zmDOoZRzmebmJodkPSJzbV01Kh/wbkq0uUdFuXNzzWoymnwXKtcrZm lHZMuRIV4IHFL2V5U4iLNG/y+pjH+sUYcx9f9Dk7gVC/TAEW0wF0CeCE9bMiGxBWqe2hJnxl0hmI Rf0LeBILLXjc2RSICrVzVif5MRlmPOgxHontFwP0wk/+JzqvnsGiGP5u7sHLPMb6/p//mLp8oeaG QErTFoKI+cWiNTXWo72hHlGCn7iQ9a+OLfKy4vCnTyzGP/z8dcydPw/r1qzFpQsX8ODN1JEKqsAL v/yf2LjlK3QFs8kcKcfFxNKCdh1+9/FRHDhWhm89usyOkjW2urp6qQMVhDOnKlBWB/zFj3+EM4cO IgLl+OaT6xFLlxnh3cFoL0hH2flKhOfnYva8AjQUdRJtYyGOTzxiFUkz+6inGBoazm7Uguu8I7cd FRUVaGpo4i49FmnxmcRDJKEWA0xLTopExy7fj531B1SUhlwrB9HOi9W466kfIjMjAw8+/LCFALN+ YJ9IcDHZ5HSdZ2BPthBv3tOUpL6saIzaq52wFuiMzCxKcK4igWEOZWGeTFdE0ZSKN9e20LqdDCGb VkM/k2L2UnOSZAfiSUHM044Ouo6RC5gPPnyfUTJo1c5NUhAliZFkDuR83BwiswwxDhRKI4jSo2i6 Vrl1zW1GgmQlL7dM8gGoUewVJjzj3W1JQL6tDiHN20ZNthWqwyuoJ1uBgSDMilYY7Z90Sc6Lsnhn ACJGApHlr4xDPKy7aCyrEJ1R5yrCypmTRzB/ehznSzT6uik+5P0+DoQrF8oQE5OIWI/rKu2fIyVp 9rSxh+PCdLmFf08SHbfuMEbRvev/bzVBaVjVzg2/fnoq8YDs16KHFTZI7z3VDXvkt0sXT4PMu99K Hl4QAXArckbB8IdeXw+SL6/fsIzOwBtqgG9vT5hbg0CZBgGc8I1JZ/gcqjA4ph73cQhE4UaTUpI/ 1xGqjn5foySm/NBe3JebgA2zMrGAIYmuXDjHo9weB58evNr7LKOHgex/9at/xyfvvo111GGqIbPY xD+FberjIj9vVhbuX5+FN7e9Tke1vUjlUV87V7HH71+Cp+7Jwbuv/gw7t79lko5wHj9/85vfxje/ +59xrjwEH9ETfmN7Fzoo9dtzsBS/fPUkfrXjIu589NuUEGbj7OVT2LJlPhe/MLQzMGkHNd4jYyIw b9V0rLxjCSLjIk0SMgT16FdiY5vqWhh2qZ+77hnG/ImwS8/v8pXLaG1qR3JcBv/SSJwdh9B2LPd5 DK7Rm/ylvivcltV1ojkmE2vWr+exaS9Skhzn2QJMTM2XI3EWeCa/Tv51qY1DMmGJoSqB/P1FKlRh e6fpmbZRbSArMwOzyCCmRMQz6keXOSgXPvTXzTHcRqfRcbGyQg9BeU0p3tn1DvEh+1RHOqgFXVJ4 ZzLSip31KuKH3InoT8fDcsTeSXcjcm+iefqFSdYYRwcwkG1yYP48qLKf62DD5bxbxhvt7D+5jGmm hW876Zpos6TmnR2t6Gmjz8BpKeRx2edEZBPPkD/cexkffFSFTVvu4/hLNPUcjSl5KqCxMU9hgsgM 8noURs/wpSHlZ3DcPr6x2IDtNVQR/1T+jXW6bfHftzPK/FfeyJKGxnCgIVFNU4NFbt0dbmIkDGP+ MpD0yhQrHrMCzwMbaFODbaIq7LlVEeB6LB6mn2aomiqpgxTIhyf9XD6rEF1z52F7G3WYGqkbF5GK exjEPZpOm9Vvw4ejrsMoMdty9/0I4pHVofZmHDwjR7f9KOgpwqZVWQhmmKPVq2fjjX17cJ2+0L5C o5Cf//3/iXULKrCM7lq0Dfj3517B4qXLMIvHHlHUFVy0cC6e+cbT2PP2a9SBOYk0hmQ7eqUedZ10 7Jychw233EL9mKtcQJtRWtpIIhiG4mMVqM5IQ9rKHGdRJWNLFTOvUgdDdrU1dNLdTKY5p9axmyQu csjbS03tTNYZHCSlfc+u3KtS/5hpNAy4pOJ4WROy5t2CpGm56OzsdKg2X9CcpaDZjvrl2Hgyi4WX 3T5a83y+N7wuRcQII4DSLZUrF+kAahNR01BNd0MNlHLTOTTHUFRFJYIpIW9kGB1zpC64uclprGoh I5xqx3el16/a5qWxpRFnTp80tyCFhTNsvoVzMVdYN5e9ExNIwZDNJQGgdjhyyeGtGx80IwXDJ/f4 2Sf5VIwuK/G+WZOqx4R/BtCkXvfqpUEQJjNAvajBfGCy7G5ZisiKXJI8/lYITXMqTgnyufQ41HIe HTrfjIa2UNzx1Pewfv06ZhvqyHpa1msMZmZmmnRaY0fugYZyuFeDEHnROt+yqGSjnOwT6xbdcKv1 raiJc7tgBKp8tmCQb1Edbn0Tt8ynHOrCAA9htodUgvNxqiDQTMnK8glAe2eqNXtTY8Dr8IyCAA4G genwfv4BRnrp2k0qWWgqMjwK0q476++8G9lzFqK6qYX6dWcR3dOBDdQ1kX6g49iZEkM2hgKKQUJz y80b6K5iMWrqG9Ag/2dd9Xh71wd06nwSD39lKePoxiMpjn6srhRh86ZbUbhsA3YxDFL+7HTMnZON tPRLqKooo0XxDOrTUXpIFxo3UzI0Y+YsXLtyCsXXqnHP6nQsmHkTByyPwsLDkZ2dgVUb7sL+85dx 9d1jqKcD5lvuXojM4HwSGw+jpj4ZNzlS6FZKXeR4Lp1HkTqCdJM51w0OJ7zUdvwj8+eiZUrfGmM6 ojxDp7YrFy0xya/c8ZirHy1wHGf6JylXMPMptJWvkm8xAMYETKml3rx8w6Tn0OnTxorELZJ+MJUy KfFTmEAtyhHUce26VgJU1dCTejhSC2jdS8MrTbxWHvtqDGZwDGqB72MYwiYyf7VN5fjp8z/hiO7D tx7/HpYvXWHSnAiWZ2G/bNayXjbFHe4OBq163z7UOQFN6suhdgasKhcRAatgeMFCWgArdAg/a3CM gCIiorBu0xa8/dabKNlVR1dCsZizeDXWrV1r+thqicaapH+djLry0osvchNdjB/RMCSbetzGVagT RvS1p/0BBMWKtsYNx90fr8fEABGmbgp0crpkahWZEYgvDXXG3tQq9aY+8Tie+eNN9knmsaE9yXe9 f80f2DK8Cyee2S/jBun8dVDPLT+/AF2MRbrv4EF8+vGHaK+4hqaaStTy2Grl2nWYScXynt4u4lOO RqWXooL4x99qWyp1lWQQEhQ0CwM93UikU+bnf/MLvPDaCWy8cyEt3bg6GhPl5G+nc76qhm5KNxir t5MSk9xMO+YQ4RIB06KfRbcg+lvF36pXUjl7RiYtirGAH33kCR6PdGHHzrexd+crWLkkE/V8Jji7 6eKll0fRIwndEL7VlJ6Obssnf9HhjEwSSibYTfLXlpGRiUtNF9HU1kj3OHGETcdXar9qcJJ75Y/+ ccv8Q//u7uDRVm8ICmdMR8WlC2jnBmQax19oaJhZ0WpY6Vo7yyD6cfQZt3rB55cmg3W394fedVQD uMHiLf3JJYyYumuU6FUUV9KwqQeZebQ8p3FVUBRj5LKdGn+KV52Zls2QXop/K+k8oad+YSEtPbNn ZOLc/st47eXXMJP+LhPoqFyxc1X7cDA/2xor6gv1od4UTf58GPTAgi7cBxTnwwpXWERT1eER/8rV N3PuzKFedDfdxKTQVRY3G8xrm1dNHk/S+EtNSyXdZrQlzicbbLw3fMy4eZ1OGfwVoItRaw5QXV/y Yj9HVGnNnUrymQF0YPNUqq8AASvialR4KtBN+O5IhmDC7JPMMNkuctGr7+GSP3W6CEZHexvDoTWg kVZjYvxqj3yMeWlhWJERgw+op9WZnYeElFQyZ9I2YRk8QnB1BrtoGRtEwhLB42FXciYl+KtFxXjh 2WexbvValF0txr+/XIRUWswuXDDPFviZ0/Ox5/0z+O22izh+tQKFObMpFGlm8PVKunFJsDioYvQU ScFtv5hN/VbSs73796H0ahHdhizGnMJpKEqLQhxj/jZyZWlubMPR3aeRy/uhwZGW314c/AhCe3MH WqlwHxMdg0SGfLPg7zx7VNlK+pabmoKCfFoUX0dnU5tZ4sVGqn0kuMxmzKomj61mARrEg23+w7gQ zhjqGR09QThx7BjK3n8TRa09eOYv/5rjZTX2cQwmxsVi8fJV1gehZHR0FOxTUnYfX/Gp/MHM6vMb KuItDSGaenDDoq0WxzH/WltbqavXjtCoGFyluC6ce5N45qNaFtpaOum0OcRCwLlFS9oeQd3W6TcV UC2BahEbZuPtn+xHSUkJ42ov4XsyQXIiptzQAreISXz7r6SxKrfNU8CrCXgFBl6gahksl+PDNut2 gxI9bqKjqNCnfk9LTbWhp7Gm0wmT+nJuGf0STWIK52bioQcfMpde4Tw10eaEQvXPDFnLzDmmR4FN Trv0Gfi6AgtJwCFwUBVoIKx8jaGpJJ8ZQBc2VexeT6UBo76rsll4wMofrNQh8oM/A3YhqZj3hQ/C zQtz6swp53L6YtZ0LenEtJw81JDx6aN0q+LyeTwzLxaLcmmZyOd7L9YhO286ktN4NErmS8dMSnom Kd++l3+N7rRpuOeBRxwG0dPAejp0/nDvB0hMTcZf/vV/wulTp0ySl0gny6r7tttvM4nj5UvncK5y OyL667H9xX9FSHQy/QregjtvvxMRkRF2kFujOMPV1cgvcGLzqv42usd45aXnkB3fhusXDyIlvZAR Q4CTZ6rQl92L/W8ewsVjRSj8fj5FgUQA22U6lC7Z4e+Opk5Ttp/FY2YjoIJJ+Vi+wODabb9T6UZG gdYbm3gcV1OLmsZW1pvOfMFo7WriEabzXmRIOE/zyGy6daihf0yfwYDwG8aQZj10XLznxV9gUUQ/ KqnP9OJLz2MtGcBPPvkEK1csN2mvXnbkXJ8pZvwbrCTwkn+nCYJncK4Na5Xua75wWHEsBSMvJx91 1Mfqoj5WFSN7JGXQTYdENFx42xo6uAFJNP1TjUF3nkoy2NnaTcl0KJlHarpynsrthztOKcT2W1J7 beD7rcSxC9L8GhVpY7/i/RPhXHMwwCobhq8AgKGxZGNGMGjsyJTXU5nGUztNwKXHJ80Bu8/MGi/y P9ne0IAW+imNjE80h/Z6V6o9Efwz367k/uRKaDTkWxWq3FMXr758Se3/XNLoOPxcqvZ3JdbfU+t0 DkUVMJlC+M5kXvMGCe5gCFT53rTBr3l8BIhEQbTDfcuuRCioX1dTU2N6SSmU7CnmaAKlf100vay+ RB9mJBKNVDzu7OxnVAE6SqZEzi2llxTIVVqXontJWSUteN/F8jW3IDOd/vBI2cXgzZ03F//2v/4J 8TwGFvO5dOlSDwPpdIZ8Wi1eshgxlLzteHs7FmXQdUZ6Bg5fqMEvfv5zLLtpOXJysm0R3779Tex5 dwfufeireODBR2wBDKMCYnxCElatyMbC2Un45QuncOpqHa5t62As2XicOHIOq7bchKyZdAlzpM6s j9kwxvzlUCVC5PW+l5aSUYxWYgjSMFTb+e1Y2wlkB3PSR1QcztycXKRw111y9AgSKq6gk/fO1Baj k0GXdNScFJyA1fM3mZL+H5nAsQe+8BwTEYTHFyWTke/BuyUtyFmyCjmZ08zf4lNf/wbHZCpx2u3p j7HL+v0/GZpdN7ZFT4xR80iHFR84MjKShkV0UUT9v4T0WJtLXTSe6u6kdXwe/VUOSxp+nbQKPvru BWTkptBJej2m5U5DPqXnYtQUnlGzySREw96b7KVBMjY4ky121PcMN6M+8cNNFi6mJ4RMknAoHBFd /k8uEO63H2qQQr5sPSLMDYwYPx77MiawLIM1jKQWozOQbhKqUNIwncZINaaJxnCf7DuA0uN70caN VU9sOu64fQt9rS4x+EXTOmlZbLzfsBXBabIA0CjiVot4CgSq3DLFmOs6IP0hYKxwXTAJrAAlBx5+ BrAONd2zBAUICqvBen6qFchpkbXWQczExSmfDbsAQ+jslL1t1cTtHj2Hp/wADwbNTm/RpSPaIeaP lmRcTFt4BNVQV49rV6+i5moxrhcXoaWlhYsQXQNQEhgbHYnMWQvwZlU4XjhVj9+ebUHTrFW4++57 OLEcWYN2oDoJ1lFCEBXVZ23aikuXi/He7t2kuhJnaHJT2Z1HD4uW3YK8ghmWV8ylfFB1kQgZIeLi 1UUF5Qxapj1OPb6a6hhQYIfusAw89NDDPAampFB1EKeNzdSNig/GnnfegCzatNuN4kI6b8EynL9U hZzsJDz9yGLMzVGkETpLZSMXrZuPNfcuJYHkjpnHa9WMo1l7vRH1tJhrLG9BY0Uz4xFHmNd9tVeJ /KAxsPbD86G6OqljeL30uu2wpXdYmJGFKIpmYklt4glnWmo0XdtE4XzFcbR2Nw7iYXg5f7wewoDQ LQfKW+enYEV+HJo4Vjds3oxHH74PrW0Mak/jB+ljKvVyzEyGmfZ2ngy1apJXRvbGn/gax26qoBW8 LMuj6KpIg1tHxO2NHabPGhWl+NhDKS4+DquXrsbyvFUoPVSFpssdeOA+WuPTvYzRNUcbYuiFKV4N tXKKBY37uhgNpvFRNm4J4z2U1D6cKgPxcTH0JhBOfUsesfNeIMaDQDAwhvXveG2b6JnaKBct0q8W /Q4iodW9CB7d6p5JNVmIYIwgqXWMpQZQXl2O5178GT7a/QJPczqwaXMmYrrO483XX0JbZwfzS9VH fiE9LVCjh/2ZVbY9cphMTy6/fzloIhyqO2CJQLJ8q8OFNwB1qTcMjADWIWZWDL+npgBAoSJJXW0s TK1TNMcMIfqeECduXdpuMLc6y09ziOUNS25D3PqGPQrMZYArsp5Sy8evR8RDREK5ZMXaxKPLOkr8 etpaETrQY4r101MiUVxP/T769rNeYAf08Qhh48aNiLn3dlw6cQI5GTmYvmINEhiLVFI9ERF1lnaR WtQGeCS8eOE8HtutwIcfvI8nn3h8EK1aoOSmwk16V9JDxwkp+5yMYCilQDrS2njb7Vi5ciWJVbfx kAn0nSamVGVobNx2++14pfIaEqg7FU3GT6V2kClTnj4ykT30gZWTEYv/8ueb8dbhGlQR8hmMjxkd H4bORhp5tHXrHNGY3OCBUC4M0cZgxjGguvRirK0sVN9ucq90L5IK1pKSKslpdDD9GLa2NKGiqQkt 7fSA1Cafax08Nl+FaPp2c5llt6w/fo+OgR4eZWUnROHpBSk4sO3XKDqWibiUWXjo8aeQlZVlrkwU bWai8T566Z/XXQ0c75toWSmETuTxbyh1ufrp562Nuqi5mblmgOSOQX0r76JFi2xurLt5nc3BvLw8 zjv6+uM47FKGCWiBcnifRDGsUO9fmURO1eDPWtRqoUHbzwiuRNKNtHuqhRKyYBrS8CgDvbw5bIrr raklfwLBloj5i+CpgmheGzdClaUXkFMwl9GKojk2ginxc/qcZNN+i7GrbarBL3/xE8T3lOI/PL0C mVmkPxwfFw5GoCsswXSW1UzzAcgLndDcmFis0XVpqvq1Y4ZVpP5wauanmBp/94VblypSTU5l7t2A fBNbAU3CkZMCDIzGhKoYqtCt2OtvnyKBjIArwLAJqMBy0MSRBwYRbVd3x2vM+ZRxYmRpV2jMH+Hu otSvrqYc9ZXViCMFzORRQgylXqE8XmhoJ1NEn2QJNHKQtavargOlEDJkixetpGuWJU7LdJ/PbXCQ wkaQmHLdFo0hoR0gI5WCv6Tyfhn9mrmtU3YdOchvlfCh8RXGnThpsbm5UFnhni1DJ/WhmpopheSR TSwZTenaCYahhZCL4IIFSPzhX9lOWPEty2iQsWfX2zh3/GM8ekc+Cb+84PcxBBaZyY15ODkQgRAy p4ohrGU0Pi0W0QmRlDjyqI1Hah08IknksXaoR5fK7QK13x2bajPBsEVFlsHJyYwTx9RKJrqU0sBu Shr76HF/WfZ6JEamkwFso9uPGMLNqCB6+Y9pXAwIz2LuWqhqsKkgAQtSe3CB0t19772MfdmZeOTJ r1MC4kixPXY/45Z340N1wefSC1zMJM0cj8ZoHLm25fLF1sYxVFfegAQaLGluhXJTkkjH0Upqt3z4 mYU9v2WlLyfZuXm5znPm14LNoUz4xqvVsvv4odnizgAfX/U2O2GyGtQ5U6yKZMT6WMUIvwycYse+ 8tVZxbjI8miQyY2EWVVLmZJGN0Sb35LDoos0qiFTG216W+HfyLsyBeHjjz5iLPP9+JPv/AV1oRke k3eNHnGsiZnL7gKMAABAAElEQVTT8XYvN+wvvvgyucVr+PbXViMmPpI+S3nSw0gzp0uakT4nCjWU NqelpdsmNjxMmNLfyGQnLQMhtBQW80mopgbKyMKH/RKalFy8Ob/8+6kZ4TSf4+yzoPqtskEYAliH 09jBmvzW9pEFEQAXBnX8JJHGqcfkw8sCSx0VoLFmzbEPVeACOHTX/1eBroPlm580UYFRkqo3nRc9 Y0e2kviV8ag3lO5LpseFkfHzRK/wPJf0JZI+yWRoISvg+rpqRi6gmxO+KyfIskAc7E5eyDefeksK 6MFsgyIT0IjTLBjnLVyEBfzrpqsBTUC9JyKlJAekXV2d1DFMNAIXRQJnjDKZPB0B/+bZX9P9RZlJ 5xQGblrebKxkKLjERDFcQ6NjGgm5dKCuXCnCS7/9KWZE1+Ovnl6MFPoX7FesTCWujGqX/KWpDcZ8 8iKEDG8o4YzkP0nw2hnV41rpVYZ2a0ZhYYHlE929EbXmaJcPjCbzuSSOPZSY6tg8jpK+WB7RKWZr /0AvwslY9/X5c3lhhX+QSQwAJRkcX3uvtmJfRRdmZlJhPawH62nYM52OxCv2vYv+rz5l01aMkCiF M5omg5ChMTSZtyd+R21zR8jouUVXJXmRIEr+AGfNms1NxDVUlFRQuhOGnKxcY1I0L+yfJ782WV1k kjs5pvtocBUczE0H82i4SwqvMe7XpDL5x0/+2YVfi7fCrD8nV6zgVctcsLXR1Z9UXUzqx2tJzs6d OYM33t2D+qZ63Ll2Ne65916jL2Gc4SJj6o8vYhJjryRjO/kj/eoT36Wec7KNCdEikVQZf0gaKHdU h44cQ8n5I/jR15YjhhGPtAlWiokKxTNfX479n5zH6z+9jKQZS3DP/Q8jjqoDrW1N1CslTSb9lyAg NjqCIQqT6OSfEZO4uVBEGUeybEV9sT+IDyV9uX1qKNTH4GmZcnx5kzMkPAMjoGBMrQ6HAWQZ3hRz Yx638/wOn2eAeNWoKVRuyxOBEvMTsCSkuYhzqPRgVbrt6IM4k6GdURVK6SoiqqMZOQkRlL6pXUEW ezWUVDSKO0E3eq3a3NbWjqqyCqRPkzSDf+wQR4rFp6SwnfQReO7sGS5zPZi/cAkV2GOtMVqcTFJB qtrNd6orrlEKFs2g9BlsKhkxPj98+Agaa8vI1N1CQhNHvbsQHn1FUi+HMXu54H+8aztDws1ETn4q msrLse/DE2igM+m77rvfTlLFVPZyxZPbg23b3qBj3HaEd5birkdWITE5lrtgh9kTfAqB1crj3h7C JwfCIXzWw+gekvyFB4WxrQ4CY5MoqWPe+uo6i9YgxnmspEVYjCFppRFIGcvk5eegrrScyontCO7i 7jxjgTpg1CJsTLB4B5+jZvn/zU3Nk9B++iMjg374eit21kVjNh3ahhOnZy+cRMqn72L6pRosyXc2 G0KMG6f5i4wkh0EdewzpiaTixgFyCIbREEl+AaWaEcs5kSp3HkwaI5wyxNJQ0vjrpIFRO8d9JI1I NIKFRzFD/kzOzPBniZ8ty6HzAtC32gSq4NU01RwWs6cb+m144EcXaV5dXQ2Znk+x++OPETJ7GaLy Z+HlbduwZPEicyiv/JIUanT5JbE86xDnY9JFqhjBIZrUT9jk63T5smV201RvyO1LyhzO+zL6MCO+ 2nq8984O3LwkHbnZcYwHPAwqDrYZuYmYMW0ZrpU14H89/wE3wHGYxihJNeUXuYGt5+aXsaZ54pKV FIusgqVYctNNpM8xJkXtJxNoW1nfumlc+J2+d8auMrq/x31pjIfClXAm5l/faqaml8q0P147k0hP A5cCW7oHRwIu4Mysh55MASDyFb69rYXR/vn43mS604/jeNTqDQR3VI6awz83B1F1A0BiPUTclPp4 7Ft+7SrCuNPLTYq0GJD9fFE7yNLmLkRRxyQjNhRNnOGxqTE0DuliVI1QFBYWmn8y19my+tNA4ow6 efBT7Hjx51y/uoDv/Q2WLV/DySemjJWyLUHckXY2NuLV3/6Cbl+y8PVvfp/3e+n3rJlxdItQW3mJ iu9lXPSy6W8vEtnTF1IKMst8By5ZtIyMWDXW3hSL5fNz6Ay4HM9v+4CMIne7nOFNdGlQXlmHGXMW MCZmC/37NaO/vh37D13HgsU5aKe7mUie/aQkRqOmognvHa5Ef246ZlCimXOlHM3BUWhOoPsYHo9E xtFIhMjqEWPIbW5CvHRkHMbtBpQ6yOSn0Kpn8unGaEzk84JpuDINcYQXJaWIqbpAJcVC9EfHm/TU fVGESO/28ehJIb7kG9E5KlJ5Y9Xmvv2H+S2oY3qoh9rXhg+Km7Hgrq/gm09/w/DR2nEXSsJjcLn9 eay5/yESdCquE4mydhSd8DXZ2LXXfH/Xt7okoXT6eqL3JOHRRkaLehT9Zs6ePcd0UKWKIB1ZLWI3 Dg213sYLLzSmNCkDDdFnGqF2+SvZYkYIvADCsvBD2iLagEnypUVfqa+PR+OUjOqEoYlz8XLRFRw+ egJnKqqQvnQ90mggppOBy+++aR4PZsyawzqJYTGfwqMfktMTky9PoLjjVDBaeR74zHDIOlzMjaR/ wXbC09jAsICUcJ44tB8JKMOm1TeRo/WcgAyDqZ+4Udn509OwaG4WDn2yG2UplDanBiM7ib5N6YCy PYR+ULlpf+/EUbQ0P4it9z7AuuhiJpQbe6JKfvs1Zv2VVJTB7E3nD6tUcCi57wtXim0s2q1HwpX0 y8m3Wq4gDhY7OfDgT3f9mZx2OJD4s9zRyrI1wwP/aM+nfo/QWPn80NycZF2OBJCt0fvWD+O0THmM 2HnyqIMD0lduQyYJ1Dgg3PDIU5HtbANUmVusfbs/nGaQJxlMNTVV6Gmuw6wkKg7zvkiDFpyq1l50 BUWY5K+nmXcZbD6eO77rDEsV1EXXKZTaiUmRDpsxgaxCO9GO5mYcoL7dutgWMG49du54BwsXLyMx pm8pEgo3BVGv7sqx07jaeRxrVq5BLCWPn36yD5s23oG3tjfj/OkPENSUiit01vfp0dP4sx/9B0o/ YvDU936AZ3/xc7z8+ils2DADcWTSHry9AKdOH+bi38foIuG4fP0yfnfhEr762BOUnoTT4ph+/i50 4Ez5NYY6ou5fWC8liHG4XlKFjw/VYumKeKSevIQ5x48jfMFiVNy63IxgREhDKYGUVbB8A2bn0c0M B58IiP4EzUjMOtDpnoygB4hPSWnEREoRv4/9nRARhzbe6GRb+yndUgkqp7G9ke/QOKS9Bd19ZLwZ RSQ5JpUGKIz+wPzOeB/Cn1PTH/6nINZmJSM+nNavdYwNXYY4qiJEU7oVfMcWvH76NJbyO0L9QkyK /Zt8+jzwqxYOm4DjNZbN0Xw0fUCCFUW4lcT86d9Yi60xBgJlKqiwmsb+sKJFiANZh8rWnxfdoqYI q7bYE2Fa7KXT29BMwytuBBupDtLE72ulZTh3+RLKqdYRm1WAmfc8jnDSti5uPq8fP4jC9FRK/2Zy LnIjpnluSPY3kF4CdQP6xcyKkRGdto2ogGaS1PsaozNpTsj4LJybdqUuqp/s2LEDZw69i5vnxGPt bQuREEvnzmMMHNGYProXumN9IZYuoj5kcgw3ytwEW2n84EUQ8nHw4BX87I1XMXfhUuTQzZBCfqpt moFdk4nC45Y/7FugWbd7KrffXowDtcP+WJaya0xIf1wnXr1SVWK/hjMQge6Fikaz4BB6p4iMDLdD GU913gy5Ya319tILALwtapR8nuEwyhM/3+JA0b+pJDMC8aUAdYwdizkroS+v+pB3akD5UJGAsUU9 kJ1mqBJI7qj2XNoxLK+lMF5dVY08MlGyfJOxht6p6uhDC5ed3OkFpv/RTaXytKRkNFPpvr6KSsLU Gakv60Ioj6Ni6Dchg25OsqisriTmsZcSipiBSCzMiMZHp07jOg0+pptSuth4B8exyWlYR79TJ559 Dv/6P/4Ra9etxa9feRF3MeZpaloWivojcefGWVR8j8F//6c9OHvuPFavXI5pDPP2/T/7IV74xf+H Nz4so8VxBObNiMJdd82lXgp1FyNDMWfuNHzv77Zj93vv4+/+7m+xjmVfOHMKl4tLMXvuPPRWleI0 9R3b2juxdk0BHqYVaf5pxktNeQPZC2/CtMwca2d9fZ3HkW4Eo5KkIpbRJmwMeqAYhlbe+Wwy/DOT 8rXEJqA1pgHBKYzSQN2/mpqr1LtsMAa1t5dGNt016KQ+Ul9fB5LS4tFRN4C4hgRkJuYgJTaTjGCM MZ9u/Z+t7Q/0DodLCDcWW2an4Pnj7+Gl+lrEpWdhPo/pZs1mX+polDqj6TT2mUpyaMtUSvD+XRFP b+VyGkPaONhe0QaUU4+t4c5UGlkxB5tDnPlQzycapCPf9vGXanIrGa0xPhY3WnYXZreaUfK4i364 h/HToi994QsXL+IgI8dU1zdRH7gOzfRT2knXOYmZ+cij26fo+CT6U+xEc8lFNJRcRlRDFb71tacY ZzyD81AbNAke/IdAd+4azfcSXcqrFug7gjshMX+6Iaa2mSoBwaQlinrzy1/9muop2Xjkkcco5eym ukA9jd/K8OF7u/DElmzcfusswsRNKCV94ybiOzOJcdNTqSPIvP3SE3Rxz28dKc+dl4v494rx0svP YdOtmzF3/nyLjsRDGHRpYHoJ27jt4EPBreTtGBOOwrmOuSpMzttsMweI8HX+8hU007XZKvqTjaca iXq3jypDwYrdThoj/7OCT0NuiEke2Qq3TF++VYLb935DzpgN8BPyxyzfxYcyqK7hv8d86TMPBiWA 3jTXpQFuKTf+du9P+duFxZtGTakytyL3e0qFjf7yCBhG/LD8ktb10PAjiBNggFaFVW085qTYSq4D GjkhcvKnG8HQLjIvLx8VFWWorKlAIh3S5pBhlA5fY2czLnzyPq6eO4OvPPUtFHLnHBcfj5lz5uD9 bQfwV7mFyBhox6effoLcrEyzxg2jG5UsLtrB0VGYs+wmxL2xDZ+cOEPdkmhMS09BX+N5lDCecDeP ajrp5mV2cgbmTU/Ep/s+YtivlVQ67jEn1F/95ndxnEc4HbRie2/PLrqJuY5N6wrM+CSETKkY05yc HNvtRbGupStXY9mqNc5EDFqIZaTuzZXl6OFuULExQ2g0gkW0ZCZcwUeO0LdcJiWOsSbl7O7rJi6G 6cwQnRqDE/WeSK0U+eX+JpmWql08UrpQWYvg8k9QWlmCBB65pzBiio6L79y8notUE6IZZm7F8uUM JVfKCBf7cOHSEcTVpyAnZQbS4rPIkDKknL8o7Ogj5wt0l6SfRFn6pwUJYfjO4hT88tCneO3tRjTR 1+RNS1fiqUcfQzR38LZaf3aY+wTL1KSH3lblLes3VJ4YkYnG2lBuz5VWwwAmQ7U+7Ig2MBUN0vlx QBHzF8ZJFk6Jn9xZiXGrp7ul0ydP4KW3dqIlPgWJ+bMRmz8P+bwOoSEWY1FaVJkGngi0lhahv+Qc pk+fhUef+D4KcnM5lMT8yfDIz3CpTwwoLwYqswo2Sb/lEYFfBp8idWgjvmPndtReu4CE/k608bTg wsWzDFVZigPTsnCtpJhqMlfZNV1YWhCBubl0ks5jX+lYe5Ok/iM8DiZVrsRv4UVGI999YgVe3HEG z//qLO5/9DvYtGkDQeunvi4FCb6PVqf8YZ9u34txUvXu72FZPnMpo+Uw4seGPl8Q7ZAKTiPxtevd XXj/0FFaeneigZbOd2zZQkPGGlRU15pkvY6qQm5d9r6Qz6QvYa1f45ywe4dBe3Xkh1OcM1/c65E5 pvxLOJp0+3yqnTRsihX5rAOo+mRg4EwFn1rrQ2a3Z6YInTc1siq3Nm+yTyaPDWS9OAwcXdpA52gJ 4244OiUNFbSkDKVj524qcfTSPUkud5Lyt3eRREVGGAMkij3yuUcikkzXMDKCiGE5EdTPW0LF4NPn D2Lbb0Px1Pd/iEwSIB15tpFxpLIf1mVF4x0yMsmUnp0+uBcRZHAef+LrSGU4uVnzFuH7P/xzHHt/ N85yF97R2YY1N9E6mD77mih9nFmYSkawCyuXTMPP3rxIVxbcrREoifJT6E6mo6MVs+fNZySPBOx6 9l+wZGYKkjMTkBAdhttWFaC2sZKE8TwW0uLYdBRJDIYoCWGg5LKHkoJmHlvLIKSfui6NNCiRVCCE +EhJoWUxO6nkajH1Ht2jWBHGYQjlrzETs0kZW1KECOIzhw6Lb1l3M0q58ORVp2PzptvodiKbxxL9 SCYM3cSvpK3RdEibkZll7T5//jw+3P0hzpUcRlXjNMzKWsAj0ESCMcFOfsxGfXkeaH50hUSieYA+ FeniJSichjh9dYhJCcVs+reThevyFStssXKP5TXmRQh9TTY+Aj0hBxvlW0U+5SbsgyymTy8ONs7r iyGcTQLh3tZCGBwwRgKjX+prHYnK0lV0QS6XLl+6hP0HDuEEpX9BhfMxb+UGi8qjBXxA0jIaqHVQ laCltBh9lVcxjfRs00MPYPmqdYw2wwgaPBUhKbDwZ31+Zm7VZmNnxkGXCyV5Pkr8pMfoMDFSD5Hh Sgf9iR7Y8z7efOU5fG3LdBQkxqI+pJfHmHkoL23BucM7eHQbhrXrM3lakmD0O4x0z1vmz5tu0ZHz jJx4/MU3VuJ3O47jk/17ccstN1t/6Gh6gEYoLhzelDdWHqFJY8xJ4yBN+fhHLSPjEbq4fsj1Vi4j Q2ld27ljO7bt/RQFt9zBDfkAdu79EA0UMJRR/7Oc9D6cvmJTuC5lxUdZfHcFOXBPyVS3lc2PfvIf 2ow5yWnP+K0ayvm5zEmuNS62vF6jXHC8/vbUwX4RPzYZWquqBrXB1OCJkKgxYHn0wWv7PdFLqsXX pDIFkRiFgCZ3J+EBKAB1Dc4bGxH2MViLjWFOYg30vPw8i1wRSXcT3WTa2kggE5OTcOkSGTJKCAty ZtH8n0erZOCuVzBKBid3spgaNl3xcBMoEXxiaS5+8slh/O7lF3DXw4+ijYt2Y184SmlRu7YgDtfO XMfeF/4NSyh1P3GqDXvzCvDIU99ALBnQe+++F4tmzsCPfvh9FKZFoqq2DXNnZ2Ipo2Vot6sJl5NN Z6Vt51FXdp18QBDDqzHMFXXlLpLIFxQWYtXypdjxajaOn6vE5sw4xNJVxtOPrcBbey7gtVeeN6Kb RGfRcZToRUTR5x/DynUQzqslxZRslqOOitJiPrtC203S11PPhUXH2HQzIylgRlqmKd9LMqDhoVOU kRgdRO1nLrTpJgvtwdcA/bPlYf369YSLbnG42KhAZjHfbZpQETSw6dHum3/ysbiEoZnmz12IY8eO 4NU3XsKxiw1Yu+BOupFRoPZBavSZev8QbpC8sE8icHFgDcJoUBTb24KlM3MQ3VyD7XtPIjw1D3ff v9UWCW1qiD5zWi7nQpNL6olAJ9ahaibbRG+aZ2AEsgK3+arIKvOmVT7ncWmY5txwpOm+9bUkf6TV Yjpqa2rwLqMLfXDoMPrjkpC58T7EU5Wjl3NWIRz7qCbQTpWOtnKGYrxejByqjtx6+yYsYwzpRLqc 0qZS0YdEb+StwN/MnwE/iCr1zeAPe+T2lmiATg3CeNar8G6SxEl3Uao6ZaUlqDq2D0VVJXjg7sXY snWmwS5L55XU3ylltKIMniokkpERzCI69m9kVVbfVD+0qb12qZIGdy0IS5aOsoxItG76pzL1sZXk Kc5+T1C0jnD1V1VXhxdefxXf+frXeSLUh50f7MGsrY8gdvo8MqcUIjBAwNHzxxCWlsuQkjez7+mV 4soZXGfIxVYaCU6bNs3xBUloHEkoy+UY05hTpCilwfFhOHbuTfQ5QfMnen3C5zaG7CPQNakpHFlT qEbRyScEaHgGwSUi7+t7w8uY+Jrla6R9HkmgsJ7A1abl04OzGyoR8yYHnhLny0ginEdowm0YnSrH UJfKuY4ylycp6ZncPfbS1Uo1wyQNcKcUZuJfl/UQI5MeG4YnFqbh5cO78XpjNZKpW5NChrGFTpSj MqPwxKJEdFCXJIGKtp0tZSimlW5vTzfKysrM8WoIjzAWLpiH2TlRKKsOwocHz2DryiRsuXuBKXL3 9oUgfKAblXQ9c/DUIWy9ayv2HtyH+ooSlnEN8+bNw0JGBjl0Yif1/XgMQbFAXEwwvrJlPhqfP4Zt L/wMqTzSTUxKpQuNbDOsKKssJWN6AJ08UW0lExvBdyJoaRnC46GB/mC6uuklY1hLSWMawyVNYz85 ux0ZGviUmF1MoIVPIo6lh6OoJI4Ej0dWvCc+TvgMZkaVrvxKOtpSH4VSYXnNujU8Lk7GP/zD36Oo 8gzm560kfadz7j/wJCvYjqBEtBBPJT3BiExPwvysSNQe3YXLFy7Sl9kd7Kc6GgPFm8+8SftuY/mf X1JdN0xKf1XOYp1FnyNKMAWQnql4hZ5yYAkM/kimmIbKFjg6FlXINhmhiVZJgr/td2/gvSMnkbZm M8NTzuPhQzgX9m70cq51NNejrawE/dT9zaae8OrNt2D12nVm1S/pu6TuOl3QVo2BVpgEk/+TAwU/ VfwQSJ7axGR4aiaQpp9dXYNyOrG/ePE0SkouIbSjkse50fjm7UuQnkIfrGy76fWxuHCWOTs3gb95 BNs1TF3F/2DYkBI9Ky5vxJ7DVfjb/7renOTLH6G7Lky9WgdJ6l8HVTcgbZwKOunZop8+MKVuVFJy Hp30aRs3Yy76ePwrZMflTEdsdj4lWNqaS9JKxPM0qYcw1ddWgYsKZsyYYTVU0uOEpIEpdOwv63uN PzG6GoNKA7wweq3pNrxTncf2aS3XZGHSlxhJ55fd8uPH8II9DfRj6U5R4itcSAXF5OoxTDpiUX5q ljv/R22uB3eDz278PfhgihfqXCWH6DjXgfl0IJ8s8rxp00gc3TDc+FODVhs2HS0IbOVQq1wc5Ofn G4GVDkVLYz066PsvkxZkOm7p4O6yg8fF2hV1UZbb0NFLVwEReGZJCi5Xn8NAA7B8cYK5ldHRqnwJ xtM4o66lBxVkBGflZeL48RN4/rlf4Zln/oRKxQvw3T/9MeqaWhBFw5KrP/0paulzj8XbZDt6shR9 STkIoyFKDB0+Hzx6Esc+fQ+b5iZj5/ZnaZ2bRf3A1di3ZyfqG1qRzbBZvWyflKaffGAeikvrCG83 rtKnVfHJMxggwU9OjsCjt2ejMzcHxTzepXtmQ2sH/d2UHa1jvfR3SL99tSTCsqyLpgWmiBHRNakk plt/nWxXMy2bQ+jbTQRIx03OdHJ7QcU7zDuzUulb+k3K002iNJNHLevx4dufYlb2YpOQqk1/6EkS jp6+Vuw9tZ3hufpRmDUHrcFNWLTyDlTQKOn5557DA/d8BbMXzDKGWUzjMA0m79Hj5yO/0StmP3vo zOjP/XBXVdhEDlxFn8eos6E9CIuDF8mYxPxJsb+TUr3r16gre/AQ3j9yArPvfhRRWfkm7RvoJeNH dy8NV85igIxfLkMIbrhzs/mvi6c7JzFYYvxEBxVJpbmlzVRiQsg4OtTQD/0wZhFD2FMPSepHUmVJ 87mTR73y+fja68+j8dp5ZFID4valmZhTuJRMKz0zkP5q4z1UikNb+kUwPoekfpFDlUWLcrH0UA3m FUyjqoukgJS2EqH+GHXW98NgufH3sEd2KVwoj1RBctJS8MzDX2HUqSQ7KdGxbw9PfHTyYzTco889 QA8WSlY28RnCdSAiKR1NtRU2PiQcqaqoMMlwO4+MY+kYW3GWFQ5Up2c6oRFzKMtzhQ0c0SFW8rAP Prf1dYJsw97w+dLgsLd87wF7w+vXHEhEYobq9K25oSbapi5GLKUyOm7Tbs7O3Vmi/Rs+ulm2fmqi +GV0jdlWYUC1e42JMUvy5kFgaxEUDkM3WidZ3aQXdIs8CK0YcRFYJU0Wd0R3c+ckliScDEsDLema eQzc1U+pHEf+CcYlPUvp4Iq8ZCzMjERmfKoxNZqIPTx+aaf/vJbuPjTz+3hZJ7rzF1APbhV+/bNn sf+jDzBv5iw6i16EAvrdKtRk4jgonFGIhtoGlJY1GpO692gZj2u+hoXz5mDmjOn4m7/5j7ifrgru 2jgDte0HsW/X2/j2D/6a1sh5OHO+lla8ibZASO8ljkc9SxfkGIxL55ONIgMq4hnOo1btms/R4rmb hiRhrFv/dGRgTDG5T0VdUJLrAFtQiR8bh3bXtw/DN1+WwUc3F58w4neo/90r93tomJsRHnEpghtC Cexa6hDu//ATFFecw8ycRSxNRP+GyeJb0774uQleJ3foLT0N9A95nbqjBbhl4Rpaha/iIvkanv31 s5jBiDDzlswl4daInkQSNdOLk3rZ1/oCWAlxNTijbScbuLo0J2xeBHD82cj29I2ueSpqxhCsGCeP n8JvXn0FDVQ5ydl0H6XDucb8KXtLVTmqjx5ATkg3brvzVqxYsdrUOUziR1UXN0KK+Y0U8zLY9Vaj rx06cX4Wq56wtcVThX7L6tSluSpEvktrqquob92EvIxu3P/AdGRlJ5pPQ0n7uklLf99JfS4G+tyV OoTzmD0iQeFB6WKFcOnPP0kFcXxxzXdG8EQFk66ycgks5Cw9jky+UkHhdKTHhKOCLn5yVkhPkXp8 ZABF48UM6ruvn8xhZzuJTDt62pp5msCITVyHtB7qeoABCBpoWd2ojTs7K5IMYBT/Yqj/nkTJoGNB 7MA+Wis9kFh7PMA414H41OBXGm3Rd5589pN51Z/yP6uJYHPaGaz8eSNEw7kjT12fLXHCO6FtNMd+ l57Jp+XkI5Vm9/GUsiTRgjQ0nM6IqXMmQwMHBqcB+rQrfghGX+CbsDWeDINlTh4uL6sSEMwaQALt jgOnQUMAuVc2sfhjOPGRorTIi/n1I2OhqSdGLpF9I6tfOVAVjmJSE2i1m8iYvI04erIKZedrkJcc xbyR1M3rpbuFPjQymkZzH6WHPKW82NyL2uAYC9v29MOPUYcvDzN4lLdm3QZMJwPoTEJn96oQcnff cx+ef7YWb+y+ysgZvYjLXIhbb17Pico8Yt7Im8YwHF335Qrk8yjkQFEd29VLxeeN2P/+85g3p4lj ib6d6B1a7e0i0bQdNpESpk2ERP8Ux9nxKw1VlBQnU6J9w5sHSTp+7acEzhlvLIhJr6vMySZ1uSPf 864E1a152cO2hHAByM3Nx8Y7NuDtN9/nMdA0GrwkG4PqXWlfxlxEAJFWVV+GPo6tTLqAWU4r6Xzq rsZSR1OhvHIogYhgXGeKIb4EALIzNX4C2VRVoUEqfASonhHF6odg8nOyucgyDZZhZRsDQjrw8d79 qGR8yRVffdrq7++l/SkZgK6mBlzlacAGeiN48muPU7E/0fRtXR0/zSVTkWOZLnth8AQAhmHNHnap WsmseJg/Fz4ttmWl18lcMILSrDQ8sCGJ7XYskrWZ/iIk4V6RZs6crcTHRxg674GnGXGGm37S7V7i 1V/JaO6wwuz3uMWTKWX9PRROUGOIjqlJ87m4JXPtun/LVjz76mtopLeHSOpz99L6t4vMnjb7Orbu YwSseP6F93QhjiczuTwVkjBK9D+H+oBXSq6ijzryIWExXOOC0N7diVZaFldVVWIhjUfECLp9OKzJ Iy/ZdpeZCtB0cdYuq3VcRA1rF8cg1zwJexQ2VWu9og6FUxVMghjNJTkUd4nIUKmEhHmnsg7SSXuo ieAPfLrXCotMTKf1UiLisnOQn5GOJOr0xNDxb1R0LC15KCHU4mxNcT4DQnGMirkkYRieAnEpbOrP KE8gKmDBtgg4DIxqMMyRgzFmyFOldSrzaWIbb8T7Yv10NGlHsHpGUbisVdNpNatBrB2P7aTr6pFC b5r3LJ+GuTTauFxDZ8uNPWjoj0FbcASaSBjiGVg8c2EKbqWLlXn0wSc9Cr1799e/g82MKhJNFy2S yPG/ybJCyHDlcQLqSLii6BQV9DqQvWQlErgT03sRjEG59c67UfoP/w1z43vRFJ+Mufc9SWIajtWr luH4scN47b3rPCaMxqyCWIaxC0FlfQemsX2pKTEmGfSAbgO+n7L7TkoAy0+XcfMRSl9/0YyOQqLA yCVdtHxWoyRJtF0RCcLQJHBL8f17MmX0sA3SCZQ+4O13bMW58xdw8tIBrFt0p7VtQgLkezO/IG84 k2RG1nz6J5uGj07uxHPP/Qa33HwLFtL/2NatW01Xdc3qNZSOdLtD3ue2G/5U1WQ6x/fa+EaAJr6m /ecDhNFtpy7BEkDEGR3jos61SDRKK502bDVVZJYS6ZA+lNa7NFjTw05ayVYe3otMmtB+jcxfHP29 yXVUH+eumD7NI85m6zHn0y6HtT5AsLBYB0P89FTsbr572L5m+u2Te5r+vk5kpzPiEGHpIqP1RUlG /9gP9fVUxThdj8OnG7F60wNYv4Ebc+n+ESwx1sLtcLxOvv1OP2ij7uDN+T1eeaqbsgcEcfGSc2pz 9kwkb7ztNoYRbcPb+z5CJw0/YtvrkUAJntbBGBr5iYHri6TwiYInhe6UFNGlp3quU6dKhh1tp3SQ g42nRTQIob54WCxVh8gouclpp/tr6NsDiXNDmXQjUElzRUkcszeJeNLaLp+StQwKoX6OoBBO1tOR ERSi0FAzmI7FxRAaXth4fetPElJHB9ibikbmCU0gs/et7/0ZK25CFf2xnS++ilIqdV8sZoge6nbI YjOf/ueyKPEQF59C/S9VGEqDBR0ZSwfEgdUB2IV7ZDW+/RrE2Vg96Vtx4+R2O8f9HifrJB+NxIdD 8twdp4oU06VdmwhnF3dCEnnLAMQ6ms2ikGwosTAbt7yv6a1BIivaCk6KeQmhDDEUgZ3XulAbkoDI jFwsu2Uj8rlzimZ5EpFrIIlIyLpVxxgqK5h9GEPGXiWL+VMAe7VZxhhB1CVJjItB0rKbWSEnY68I ODMxSVS9mY6du57LQffBT7HkzuVIuPMhm7CKFPLNZ57GydPncOH8aZx677JFH6nvCOIxQBVWzE9G NHURrQFqA+G4SmvlC2WtaL7cRgfUqYyAUk6H0rHG9In5y2I4OhEB4UtJbZxSr03yZdXewzaQLzXl 9YceegT/+P/+Pa7XFaMgbTb1mKTE/oeZRIwjGRFFi2Iu/SEev7YfHdyFXy+7bj4qC3nMo0VUi4VO yL4YspKx+sIm0VgP/XNfVQwSM/8UeWMpmsODacSPwbtTvtBcs+SRZMrlixZ2wVZJ3awixi9PWT/H 6JgmdVtNDcoO70dQfTke+tY37chX9EKb2XZODxU3GnsyWI+nusB/uUwNaRAXUnleKCoqNtiyM+O5 AMu4JfCt8LYG4Vt6kqXXG/De3qu40hhH/b+1xhh1UjdO9F1kTSIaf829G+G/8fd4bddqJ3XIYLmj IbkP49p2L2PF55KfkO+/wukzkZaWZkxOBKVd0RQq7Nu3D8VFRZo4pPVCvtMBWq+i6CamoLCQupkd 5ilD9EiMn8Iz6luSMzf/mO2yaS8sTZhzzCImejCEI6eeifLbczY9OTXNfOGKhsoFmrx/tLQykhdP aQcGasnzhph/Wuk+aizU08patDiUzKHCLSo5dXvGtYM6uz/WR6iIdS87KIaSvpnxiZg5ez76br+D ziwbUVJShNJr18xNx/kLZ43hS01NRxxF+TnTcpGeNY1cewyjk3GycGFwz+uHEDBWtRPdF+IEhA8I nKjIsZ4TkYGthr1gdRAez6W6SoO3i5ISiXy7Wxgnt62FR4xkzngUGkeny8l0sRLBAS9zetFdzQN1 +vCkMsK5Q8jgJKptCUVNVB7ybpqFtYsWY9bMmYMm9CbZY16zelUBvNbcsuI81ypfO/NeVqb7XRwT 9EtNtx/MT+JtdesB87upLywCoQ89hrC58xFLaeAAXbvI2bKYxRRKHDdvSqeEiNE/6Camk1aA8qn3 0Ud7sI/h4VKiOhwpAivmPhH1XeGI7IvB/Y8/iPnzF+DAgQM0UDnK3WA4j44SbJILXlWvkeGfNBKf 3pVJiQClFyHcBAUT1tk8Op8zfy6KKAmcnjnXEZ96V9CXMJejc3Sh4gTD/J0j8QnFW7/bxh1+KL79 7e/Y5kI9Ix0g/XEg+AyjM84m9arPdU2mfV5XQvBHY3K8ft+HjMKZU5e/5sXolWuzL90/GXXJ8Eyb STmXD03LRvbiFZybdKnEdaPo3TeQnxiDB777PaxdstAYQ9GbLhGYCbDiwKFxEyBY1C8iY2qHqtAP 1UbCEkMDsxiedPUz7nVaio4T7dEX4kN9LP+kJy/U4b2DVYhLnYc7ls/Fi6+9ir2HD+Hhe+7GnXdu 4RoiWi0mUJgeicXx4FFevedBh4fOOnhRSd7rAH4WXV3qdq4nJPPGqK2gpwjhWzD1UqggfWEJReSO y3Tg1FD+Cf3GA/JbBmjuoiVpWFT00Ii3dcEVTOilMZIeOW/ZxRi5/HR7OCK9LFIqWEphPOYOpy/M GDpLl1qeGMJ2+tZsa281gU9jQ4PxDXV0p6RIKlkFM5FFoYkEJpHkx6K4ERAvpgE+Xp+rLnaJEjMS 0xQgOz/5qfA8i5auwk0r1qCHu3xxm5X03H3lwjkUXaGE8OxZDrZ+Wvik0CpyFlLJEGYyikN2RiYr l+h2sCifLwbf1agMaHIb6QyNQFTljgOnbA4/D0watKWMG9lP1whJNKeLjaaxQ3AYRef9KK8ppTV8 ExJSUs0pqoJkD3ALJTcxsnpyk8oIZ2dPy8mh5/zVWLF6rblQEcMnf1o9Hus64VN5dfyiBkjkzg2v MZfaNanvFZBbPpXUPNJ5itfJ5Gi6eBrcTXcxkhJLPC9dHpXHbQdw191oXbOWOofcsVy4YBMsnpuJ hAQORk5U6S8sXLDQ4Fa7nnziCTsG6OtpMTA8NbJuDnoyvNHczalNN920BLW1Nc7Oju9ZfXxDzZH+ hwicjVv7nsQHm6/3J5e0s6W1Gp0i6yg9OTkVpxv28pS8mZLTyMG2Tq7sL85b6huHDDu9pMFRTknn hbLjqO8ux5rV67g7becpAf1DMqlvtJkUg8xfdu+L+8E2BrqZqkLzJIAVjcCyfqg6PycjASxXbp2i qPogZkChu65cLsI777yD9PWMAU2ff7304Vl39gTSaen/1z/6L0jnJtZZ0J0N5aDPtjHa55AaF19O JoNvBJDC6RgFeHFbI1pjUzROcOhbSf0kCVp6UgLKqjp4tN3HU4vhxy9Ovt/HpzFKpNHHzlThrY+q sXbz/bht063U3X8HNS0d9E4QjTOMxX0XabHwLRUV/h9Mopda2V3M3og/4V14EM0P1cLAa1MtIn3T OxYC0fO+B12DZXt7ISawn7SBmkAUNNBhttUZhJLiYtTU0afq6lW21ghWayc/hrdTSxebY75c1VfD 26H8ej48/5jtUj6rwaFQetffyRnHKnWSpRssQ++KIUyMSDbpoK3r5McEq/Bw4dxZHD9xEpFUD0ul yl5mTh6jfWXRh2IOkiisGzqhHR1KDwM42kMyDLTSkUBHaFeorDTqns3jYt7OwN7tVPouJgNTUnQF Fy+cwb5DB0w8+cMf/IDGCukciFMRQgt4z6IzWtP8eM8ItFOdH0sdXhSHqvUWIfKMWmfn02sKrPPo BiWGsXPc7g4n5x6bGIUain+b6Ci1nQxGMI8iesirh0YwyDg5fVlXuYWJqdJ0iIxLQFhklOnRqSzp y8kO0yJreHCpo1Z5tVeYHqV+EgsxMIo/rB0aBZDGGEZydooQDNDVh6SGcodw4uhhnDp1imHcVuLW 9RtstyY4WjgOdu3ZjeqyK4xe0kVGboBGAfHIzi7A/JuWm7hfDj7dJBREsZ1B3GmzWaZDJOveaFnj sjwRMB3H6FuwKVkf6YL5NSpEPDgkjWE1xLFOF3/K5nVSv0wy6U31p9o5Y0Yh9sV9iCsVZ7CoYI35 PZtksV+c1wggnUlQykePfhoYBFay2mNFn6K5vRF33L4V99/3gMc3o9NHwonFsbZemhwoznxkSSos 4EmVaDAFILHYSY5KnxsjnDl1CRb/I86mCTmESErjTSeOqkGHKHV6f/8B1NKSN50nR300/Kg5dgiN dOz79KMPIT09zSR/rr6ft55RhnCmmU5GhqRKR85uUjm2v3BvePnt9DIZPvE3HMvDe93wRyBFuyJ4 moXaOtQ1Uuc5bWpxrb1s2qjZRFvUTnVnBzfyh04ynvDBOty59SvImzHHJK9JjJC0hScs9Y0NuOPO Ox2aTADllPvGJIbO+XOOZcUwuSmUjJ9ovqRGLq2Vvn8Y35E+Yb+sOSh4UN+LaTahwbD33XIm+lbf 9bJMuTALkc8Wwnfy9CnGY69htKUFlG61mbTL+oj1yJfiiGr4Y7DvR3TgRDU7z/XKYIkqeHgZ3hXh fS6bNKrDD5Wwre4ctzWcx+UJCTTevPkWtFDi3tTcwtNantQWX8QZzsFP9zQiv6AQX3/mTygRjOe7 zjo6WuPHYQCHZ+cg4ECwwcFvLdBpVFjMyi/EzbdsomuIdpw6cRT/9i//w/wmJdPCR8vHlyK5HRXI xo4yBjSJNJkUHkiDcvhA5wkqMmPCkEz3J91mdSYJWBfq6erlOiWDBZS4yk+fDQoOML3bxR1rG93E 9GnXxhvqcqdUp3KNwwj2tnQFxLRUMKZwQ3kZ8mfORjx1DyJoRKIkf3c2AZm/iAxoCY9ra6qq8NGH 75lS6szphWikJFCROaQDepID7uBH2/HUvTPNP5Msuuqr63Dg5CUcO34I3/nBX9rRr8vMaUII9lZu IprpOLiWcY0bG1vpgmYO0jPzxbk6cHkQIhhlYdpFy7AISkD1p/EnnQ9jBNlOkyyw+SOxaOBM8OHg ZoJMoz/WrppzQUdht966iUrZtXj3jY8wP3eZzXn1wZcxOYtjMFq7m1FWU4yk6FRKpds5nnqRkpCF qBhuNDoaUHTuGl7tfgk//NFfWF8IXu35tOBPAatTevfLiG+/tjmAY04Lj3SQ5DOzitEw/v3nP0dP ej4WPvwMYkjv6y6cRPHHb+Ox++9mfNe7TXig+dHJo4XhLq4mhndo9MgQTcfNrr6hwFOMdKdMZ5yZ KsbQKyOKH87miaYavfDkkE6ZIgrpeE1/OorUSVcvrVKjyO+ITip85NRG84jmeP+D8MjtVEtbB9ob 2nDhehs+PtlIrwyPcd3Nw3/9P/6OnlIaMWvhEixbud5OWhTuU2KwVqoTdWsjbpIb9RkFB2Teonm6 otMj0XdN0l6uE8xutCqCsOoIVkY616jP2UPVpPRMxmAnMxzJdwZYdEQ4N+zMrz51rLfJoAk9PiYJ K1Svkmj7EholNtG9y+tvbWeAgTLkUIolx9GWtGiNRUgnUbdT6Jf/U3hzmHCeABJXhdSlnE73bQP9 m42J/vjD9/HqS8/jkceeoP5/IvvMWdtHg9xLBtB5VX1heOeHDQQOGN2I4FGfwraYZMrJMVpdXt9T vyuN1ffOU398kkSwMg3KMWjIlCsZDoPV4QFOHTg4E0apRV0mcbkUZ90UHRGESzU8ZqHVb46kgEza 66lIMXWdtJYNoShYwbdFGF2YxCA5Uj0n/1nqq7394q/QWVqMgg134vFvfMuYKjk6VmEi9uU0LHn+ uV8zyHk5CrLisWUtA5m3duPozldIEMJxz333MKB3Gw4f+hjzpidiyTxG6RBx4X9MT8fSZb34v/5p F64VnzXrJt41XGsXev16Kfbv3YfKa2doddKEU5fK8NiTT2H5GlosMxi4fAS2UvlVkke5IrpGPdTu /i67jqDeYTylnXGEPyLSwwwKfgGrur1NzO+wzt6+MDKfdCV1bC5XPVpYFpEY73hjJyoariE7pZBj 90uyARoJFpk4SoUp9WvqbMTOT1+hD7Q8xCTTsrzkAlbP24hluavQnDHbFpj9B98mwelgf8RRgMwY qdLzGRx1NxTs0091ZqCTDYBAV2Jj3j84Gb2pzpD3ZeCPXs5Ed61HSBekpyTDwMKZc3D88hXqwXIN IO25umcHcpLjccfWuzgPyVxxXjiGQL7SVs+2lRWKZmmDJdrWSkX4OBqXyVWG3E/Jiljxec3ClN86 6lIbXUzolwzorN28737L4E50pZ1CC20se7s7uGmWP1Aym6Rf0dx0p0+LNd+j4whOJkLXlJ4L5kul Tdj2HqOOdFFIkFiAh5/4KgrycrCDx74V1y9j+caNaM+chdcOHEE3o2SUXmVfPPYkjh09hgqFUuPa LP3xKG6Yk1OTMZPumuZTNzyJOmMSBISQC5OzaOFNG35J/04fOYJnX3qJLrcYmjQnmzR8GaOaMOQj dSMjyUDqtEgqR8FcnEL4J0Z8bNbCOxSkU3/9pZ/+HMeq6s0fbA0FE/IkoPEjumokxbuivM7ljkh3 rHj9opcZh8p1R52XL/qcjXOFeFKYRTJkfDvIrO2nUR3PNRSZqEifGEBNLxckVTx07YTC8V0CM3rz nJKFRreG0fP55S6rCGwt7nAYWUsnpXXhPGLV8Yab40Z4Rtz3EF/twAc4WW0HwE6XNEwlR1JkHxsd yUmtyCCcoJ776idyhGTOmIllyN/S7p07EHn1EO4oyMS/fvgBtj70KK27k2wQ2bEDW/TGqy+j/upl /PjHtyA5LsImujy5/7JzPy5dIbFhcSXXy1F86TT+43fW2UCUjoeSiEord5ldwZGIpH88g1zt578L Z0/h7d+9SsJbhVtXTOMMT6LleRVOnr+Ky1XP0f9WOXXIOk3aGBtMF0Q8Km7vbEVKjto3QNWDTotT XNcQQUXtNAsNZH6S2CBtekfgzFozzgfbNJXUTXg1gfppEpybm4cFN83H6bOHyQAWTKXY38u7lAFw Z9+DovLzNla6GL6LKyOiksOxfOUyOhJnNJYGhheMzGS+PpTUX8K69Tfb4iCci/5MdTEwwKfYJ74h b2r9P25dRIozl5grgNWoDY7UVlc+jX694FVSl8gvmXSCVYO8FKxZugwfv/sOzn2wC2lkBrtombnx rgeQRUMvSZB0fNfF+eoutl5VxExkRwxdpsfGiklKUHz5Ina/+y7uvuMOFDBakaIFiTkQ3JLU6Vr0 yF40FIhxdH4Or1eSPukVNzPwQQi5mEjueJMS6Eg/LJoLZghpsQoijCzD6Obwlz/H6yA2/uR50taq SHznu99GbnaWtfvN135NRu88vvv121FXsBVV0ZlIWdiNdsZRP/3qT1H+bz9FH5lk+QPsSSDd5aQM o0PrM5eu4r1PDmLdpSv4xmOP0aAu0o5hJQ20MUo8qs+2MW5vY0wy0hctx7mLZ3Hq9TcxMzkO2WQo kqkbmUijhDmzZpt0UMZAcuTQwX721QWJO0pFt69T0LDv0/2Ydds9bEsw2s8dNUmkTpesP/2Id9Xr zElesasDl4aX70Lr79oMGoJBQJxLVqCTWkey7S0p8IkBFCEYAc6IH34EUOXqz2a1H8v9TFFiSTQS VFmARoRbLL9d/GkQNlBvI5pbWUnNRHDGTcwvhq+aPhQ6KH1L4m6subGJRxfd5hpFon0dJ0fRcqiH Ehxz6Mydrt4JpwKpYFMdjXSaWU23DW2tzUiixVAX70dSHy8kRHGFhQsxUdT8IqGUaX1UGN2d8Lqr R+1km6tbcamyH0tvzePRBMuqbyLjGYyCaXTwSj0VwaV8kn3t/ugyouLzUTiDYcFYthjSy5cv4bXf /gyL8oF7ti7njjIYv3r+MLoGonDo6H4s3DAL09dlMcwcDSm6Q3D1YDWq6ROpl6IE7caj4yIRxb8+ MpdtTTwOL7tmdaamprIL2Xq3K8dFpuehgJ1i0tjpYb3BXOiEx0VLFvNI/HnrFxnL/D4XEZ9Bo8SY 2zgcuPwRysqv0El4KoKpMHqOxl41DMO3adNmcwGj/pB+0J1r1tHh9wb2IZdjwi9pj9/mkB29+QyB jy/4YQB4UWOgx4BDXnwZ+F40+oYspiOmnSqraeax5Cf79+K17W8hJC0L9UXn6CS+DYvnzsb8BYuN fmgqTkUXVHTSqiNzN0Aa9+G21/D8Ky8iNz4a0+cvtBMO9Z7+GukUX9ajwoA2ntyzkNZ4SAEbIumh 1EW0Ua6tqWaM2UpMS4+mNJEeFsg5OgyqMxY4jG2Tyc/fW1I7K+raceAE4+AWrkB8dAROnzqBd3dt x+zMXvzJQ3MRl5SGN2qiUU4n//LLG0lL0awNdyE8OhEJPA40Omw7foIhaSy/2mvK8d6bLyA1MQkr li5GBA23EikwCKZAQSc+pddKcIkb+pkP346YzEIkZOWht60JdUUXUVLdgv5rlQhiaLbZORl4kkeL OTQ8FJ5DyABSBmz49xZptlkksoMpAEmj+tHWzZvpgo5Hz9xYSsddOHB6hOWyT42064PJve9tXaPl 80cZo5Xr3tNYdFKga3Lrmfy3TwygutkFyeGkJ1/x+G+yFlGBzyEFcYIIpsDV5tlRshaBpLpElNqo A5evYJouQseClS+J4anu7EVlZxBNw2OoY1eFAeqqyGqjLtrZoVVWVNLdynk6WU61sDlXKKUr4c55 3sLFjPyRR6fKHdj+u1dw/tOPERybgMvBaVTmD8ea2zbR2TddH4jDYjp35jTKrl/FXL63f99elB8p wqwV0xFMxuvogSLGHE5DD639rlC/Lzq9wCQ/vXKUStgU6aOdjODZy9U4fLYdjz7+uEWJ0CLYLj2P V1+lYnUP7r97GY9vQ+lrshYXKwYwZ+Fs7gQvYs7KOUhIjWSZfeho6kV8cgzbzSOb6h601MkXkqye QxDBdiZEh9EYqcMC0Kenp9vCY2OS+HRYWQNn3A8PTRk3z0QPpUsjwxrVKb1IMdxtXa1IDEv+UjGA YmZDuBjE0aO+lMrlc3HLXfdz7HVi96638cmn+3DPPQ/gsc2KIEOXAzwWsqDzXAAk+PXXUY362B/9 MlG/Oc81+QI0822uO9tLm+MBqkZwSMnbkcKokokIit7wPqlEHbVqbnXx6HT77t3Y+eFHSJ2/FGvu X4hKxgJP7mzGj//0hxbzVXPXwrtxgXeYK+/rsn5nhZHUfTGDA4JSy41maUMjkqhnGBoRjVY6yo2i BFJJLqf20m9cT1eX6brpniRTbuqgb7wq6i+LPoRHhpNZrCX9ieKpASNJkFNUfd7SCrfMgH8T1wcP F9PAspZx28/gndeuo5V4X0PfqfduLDT4eqmTmxFWiwtd+YSBGpactxlL1thQdl2JDCr+s9/Uh3GZ eZi+5WFs2/8RDp86iaS8AsxJTUIc1WgkaTl45BAiZixAZEo28SrVLlrsxiQi46a1yBCWKFjoIP6O vvsW4sn8f/tb3zZdPRmKmLEGT5m8ScqlrBodmuvJNGR55mtfo056uakvFXPdqq2tHSxKtiICQEER 1F/2vvrNrn3rPefdz2NOsiY10FqrWgORDBpn/E6hCp8YQIOJVQ4mpw2DP/124QI0rCq/lT2iIFXk /o144L8fDtJolu8cbkg/r7W1jdxSB3ehztHqWJWJ6CrgeEVbH2qkcEbpXz93ZYkU6iXFkuvgYchZ xuqtIO9WfukMju1+C9PnzccdDzyCU2Tknv3JP2PNqrV46Olvk6gCR3Zvw8MF8ThTX4r65Jl48Omv Ib9wkQ0i1SX9mFd/+xu0Fx2nOXkBUtGGhEruxk4VU+E7kRJBVtlai3ZKEEPIIEaTcWztor4emdP+ 3j4cPVeF81ebudPuwV33PorlK5Zb2dIvOXToMGqvncST31pBYs0y1ebSevSGxtD9QAfWrJ/OeNQM sE6Gz2HkxJBSJyc+Eu1NXUiMTUFrI30lkvglMh6trJzD6Ck9JiNukHkl7fRdF3As5Pt4X4vRbFrn JaUm4krZWaycu5FEi8eoX6bEIab1M406Q2vXrMGDVOjX9Hj/vXep63mY7p+KkPC3f4st+VvtmEYS E/n7Y9f7NWlGBj45m9mA1iX6xXkVyKQqrI4AVSP/azr6lVTm+vXr2P7K88ja+ijS5i6js9o2dNI/ 2fy5M5BOv5/aRJpu+BSkwfJhJitRk9jR9djuba8juK0dCxjr9sSJ4wwvV4fbVsZwEgAAQABJREFU Hvwq530WuQIycWTktKHW0ZfeURJjIRoiJ7qV1IeT2ypJrfu4SwmjApzcXnnIsuX/In3IOCWBO8o/ fXIVls5Op4EHsU9Rm6PTRfrG+SbJWX5kCyJbaaXLxqvrFQN41OQBVHF3k3KnI5rBHDrLS1FEy9vz xWWI72bcXc76HlqVTl+/njiUJbAjDLCNBdcfS8RndGo2ctZuxJlPdpk/OrXJDuxtEI5a+2duajrI sIeCPTKurJcnTJeLi6j6U2YbCOllysOIDEGkc6h+VL9az7pjnN9qldzb2C3152dqGu+GKvftjfFK u/GZg3K3sTc+9d9vDys7pQJ9YgC1IDso1wTyR/VjtT3wyBusmQMs0LVpEIdKa1b443UzCVM0J7GO LMZMzCd9vsr2PtT2y5KLx4zUy5oWQzcxZq3hWIrJhUxkdysWxrYjO7QWv9v1BnaFR/GoZDHysjIR VHwIbz4XgrmrNyCmswfr85MwPy0S/3z0Anda9Ty2ibIjS7VrgBMtmnoe+QnhuD2LzEsu3c7Ekums p8++xjasJhc5kNBCB837cZCEY9PdDzJmYyyPafpxvKgaL+68iPWb7sHt962x2MIqU0nRSj7+6D2s X5xMKy+GkiMRk9FaYysle531SGwIxZxbl4ByzWF94byrsHByGSC3EulBGejjMU4EFYb7uUuN5FFO GxehxgZKrmgYIkIhCUBvnxb3iSe407xx+mDMzhnlAQvTURPJldXtAX2UjF/UW8QXGx0Xk8TFPIeW 3nQETzdPiTwyUrSYnGn5phpQzeNg5VPS+Owmrv2ZbMx8TsgL6Mw3dAo3/PMvikZBtwvJxGN+lJfH vCXmTwYD8uuqVFx0Gc0tbZiVkmE7hfqiCwhvacDm279nR3XSATYn4B6eYcyCx3rA+qTGonmkY903 Xn8NlW+9iXszkhFL1xcVNVex+9QBxDKq0e2MO6xxeTP1UHdTKikmUAyJGMEGOsrVhkyWr3n5+Y6a DGGQ0VhzWzel3JJ6fQGSO86HcaNBZGZuWcMTF22S1URPl5pk3INXUcn0sGakhrbhei9DtBo7NDE8 YhIjomgEMisRibOp7kMXXyAdJ4FFEAM5SAfPZf4+U5raSNz2k2GLoMqRrIvFRTurmpPbBUdt9jT7 M8VEcChp+RI8LdRPPHHiBF767csI7eNxNPsoMjGcngZorUyXQ9E8opZ6UwTVkSLEbLICCRPsW9ee edXPC5IiprFqdZqhpw590e/ATsrxW+K0Z2qfw9ZKA2xypTkz28t3BzvYzR8oKN1yA9tHhMIbNsEF dpLfhEG1mFEGr6Vj18qBn8jjX0msRk16hxOkkgxSU0gkIhinN5x+tvLiaejB2aOxrj/yO2TWopAV F440HtEuLUjChsIEHKfLloO73kIBvaU/tZTWuRXnaGa/A6k8dg1n2SkxjNebFIwd23fzaLbdGCfV J8Xb++65H5c6IunYmbGAWbYlm2kccB1duLkwCXdmDODcnl0YaK7GHB4FNtc2o66F7SucjUe/+jhm zZlrE01liphfvlKMltoSLFuWz13b0OYhmjiICaUuYnc4Sq78b/LeO7qv48rzvMjhh5xzJJjAHMQg USQlKlrBVrAl25Lb3T3tmT7d3p3d8czumXP2nNn5p8+Zne3eaXfbPb09ttuWLcmSrWRJlChKYhTF IIo5gETOOWdgP996+IEgCIAACVLss0XiF97vvapbVbdu3bqxwVuSU4yJ1DUdxDoScYpE/djCeHQh aQsmr3B3f7uVVpU5ou9nOLVfqRr/n9eJKV79eDbFT3O+xOJoIjJ7Q22j5SRh9wixFTz+rXnO9X0F D3DMsE1LH7bNSx6wE4dP4NBy2hmfF+TlWxrG/ZFEmS/ntC67HJX5HL6ru3vrar7Szu1oQ+vY7UxX mp3nT24mWFPzXSQgkSRO8UD1uby8wnZ+/Imlr7rLwsn7Ldu83pJTtmJBoYs5JroGf4AD141Boh44 nQaLV4zA6bNn7TA07NmsdFsZnWR54N7WhGxbRI7ws5W1jqaKGSgvL7eDBw849bQOgLKLLieUyUXM Ybo5aMfgFMFp0alJ4+KTONjgNEHO8Wv2shsD+8afEgBiwHr4mzR9o2JoOCRLyyGJqv4mTrHU/ZFB A5YcQEBgTFDmUqQyljpXMWADkIoGENYpIJwxglJdF1eFCLpPh1xNthtE9gWuay+TragXTNpjTkQm /H+CUrdrz9KLPLHffOP39qufv2Sp4fl232ryGS991NLjco3stzCnZs0N7VZbXWO1pWVWdfmS1SCB bkZyKcZROYW9UDdeG4rZrTZmVSYO5qwemNtN6qcHy6whmnC/npn9c3OD7Nq758QACjAxM5reW7qx uf57SCSQrwzotR24qSvgs+f8MGkF3lSlkx5W1a56veDMwcJRnr9QxdSadKv/q9ZZC2rVNrJjJCen ovbtsrRIch7K4N5/k2qjAnli6d2l9IMIr8iKs0cT+iy3/pg9nRNu2QlR9mBOlJWf+Bz1B/eJylJW ZSdYf8U5TvUXHAOoa1rUxatW2bpvPGevl/a4kDMTpZQjNKRexEUEWmdwOAGrE/ASjbO39ly00rI+ nt3EyY3AwdQjRs/VyfspotRnJQRaWmqsg3PsB8sEBgUMb+wYsLNlHeQa1nxoVPQsf/pPXUMQrRoS zldWlltDR4dVQm260sltnIiEMo24dKhMZOsjgiCmU+MhuMWouL9psNVBeLPEwFUiuJVJAEYdCYak kyoKqSLPWj9j6i7eoS/DwKnAz5FBEbYwY7ltXLbNjh/70t57cyeMfqf5mPOcnHQcXVbRP1nkeLM0 393R/M3Vq/DGYRibvBuvYPontSYdHgs3pr9t3n5xbWhW5qfIOQ3lgqMNLUjUfv3qK1Yb6LOsbY+R IhKZE+syaLDHYuNi3D2aN4VmudGuioEIC9ZBWWYvw/beu2/bSnanvPAoVJSKJSiVnxwOAiyKlJPq qWz/9u/bZw14kippgdZZINKscOz9JEnr5npdRak1VVe6YMMR2LeGhEVbdR1xRYHVVTI/wzW3WsQV dffbyJ6TNrLzc7NWNCyOMxqrZlaDOGIpYd0wXrO6eWr4GE8IrPd33ZnT3MKcM/edmAB1oaZV0QEh nP4oQ0wEnjvyrJYNZwT7kjy5/X/SzAifNL+S4NUTuub1N163xRmrbV3xFoQPpD7DMTEqPBrnSBxU 0ESkkl0mg/lKZa587IHDzTB/VZVWfemi1ZReJvlAlcvfLDiEDwEgkd6nK/rtxjF0ulqnua5p0fhe tzAejIn2KTGxDJ37c3a39Gb6/ni8mKt++puu2/qcGEAtchVtsK7438e+ztebqlXQUbn4y1VdSK6g oAJ2fpukNlfh/NY65TiMNaFTqlQRPdhWKDL6lcEce4rB7eWHOuz+lF4vHAnbMGL3UFaQY6o0+BPA nYhi0DyLRMa+pSjBvlacarkYPOtUtxBJ2TeXptniVIyf+a6UcBmEdlkUMWhffPqJY5rUuuZXQVsf f/Ibtui+x+2Vcx12qanHI6y029A7ZDXY41VCQMMTMi0ucwHG4Gts92eVMGOL7b6t9zpJp3di9SAb hCmrunzRlhLGRfGt/GtCji0ZMHFBo+023N9MSJGFqKD9C1Qd9BBcIRHik2MtnliEQ0EEKoUJHIXY BGGQqPHQwgnzIRHs7HLxr/zMFpfdqVQbC1VMMc7q8TyUCQS4i3zOsjvqG2WDwcbzfNUJO1tLWAMC s/rhmocW57kKxplxrGzB8LweqUm/UvQRoHXRJiuIX2YrcrbY1/KTLKmzyooz0mwLdkJSz9264kfu iZh9a1rzt3RraqdWdYFGZuwJv/vh8L/PBZ4Z655LRRPuVZ3ektEaxHb4yOd26myJLd+yw0J9BKB3 0m0Oo7GpeG82Yg/qMV/a5G+kD2qaJc16lfQv2M6XlFjtiWO2gzBPat/fR9GOJuLipaICDmZRnzxz ys4e3GPpYTheIU0TU6pwJmImEriWy2EsHQIQONJjbc01Vo/tm4/4of1DwdbQhB0x998wwAL6Rgt7 22hdi42+ud9GX/7ERi9VX+29Mot6RXZyI1qIXTgxgessHrzBW7T7hsjs5vhBK4KTi0K9rqLtKET0 GIRRbvse4jWKqQyFkwnHfCeCP/cOcyjVrx4QLRStDB+NtFxiiorNcfajkk5qsjGPCh3stdj+DksY wg6d51Kx987lLwcBQxbPx8H8t9VUWVVFhcBwRdW7+r2v17z68YibrvltPi94fZhdjXLWdnsUIAkq 9yzv+uz2LTayK6Kw2dU5l7tofg5FQDL4Gkg3mFdGdA6VzHyrNm6JkqNgkqKw1dCpIhLMiWCUwgjW CQ/hBkcDBCg3N5WqRPV4b7fsVXCK1mjUpLZQrKwW0us0dZP8WsYLriMeFEr4XdU1ZOGoK5IJkim7 lmBUns29ZPogtsIAjJMfSaYCWCccTYtrkxvVrgjzd1al2t1IB2VErCLGaW2mzw4d+szqEauLMVUR MyAD3Kfw4E3d9Ij9/lKvnSM3Zie6nTfONNrrJb22twUm874dhKJptQswd7mRo9Zcet7KLl7wxPI0 7j+7SIInm8eIWGw8dF2AUcQkxkQG273rs5xtmQybJx6C3U28yP4vOimKsAWhFpPos9hkH8xgHCdR 6gFW9UbEZiRgiHAlDTBbikGGJyJ/MjAWkVeL3ubkte1GgBeHy2Pw+Nub6/uYpY4b8EtsXH2c7EMC Q+1k2WE7UXnQLlQdtyPn9qDp6Rof47m2cSvv14gIJy9XX7R3D75iX5bttQoygAQFhtmaonssIyrF 7koOtReWxNmZzw/aPiQuA6QC02TJmPsmh++arqk+b5a812tumKcLfvycp+qurcbhF8NEh0TT1Bv9 ya7uymdwly/CzVD+hP9Sp825jA/aDTw7VWNU49YqgCt1V2dNrW2FgVp79ICF1lWxWTN6ABuVtxDz iwqiBlQ6HBJtvhGJ1LitIe31EU/w/XffsWKYzOxwPM0nwDfC2LQPBVpK/gJypXfY+7973dYP99u6 pEQ819vQqPZbBXarQ9CldKTxGNmYDxVpajzMA8Gdo8IGrLO1HvpGwHmiDDS29jIXmo3bXHRSJwxN 4MIsC1iSg0cf6ed0bQ5FipLo4EEC9RP26zb0YRimNaGq3J7e/bY9eumsBWEj7FFW4W2gyw61+6Pd 9vY779nZk+ecxFUZpOrr6wi9g+MgSQOEpgMw6i2YypyGeY/xJVpMGGkE6YOKRsBpUmD+ogbaYDih M1z1/9M6UlaYKMKWpaLOisc+UIykGE+/cMrRee5xUjU3u5phb5ZBT/Bz7DfeNfOC6ZaV69QtCLSN qTjpNvuVVNtSj2t/1E/6Xf2+tuh3ftBvc0Odq6pCUDv74tqiMb3P58CpLtE9ccNi/pwXGJuSVE3K DxjID+EYguoEEcw12Z0r1ICIg0wgZAcxkVDMvkf+kdO7enXrisupCJBiiGKIxp6eU2ANleU20D1o yfL0YhH1I/lr6uMUFBlDYOFsJ00LgBnLyCH9Wl21VUMcR7AFzI4OcbaAfqSfCmqG56oSIfk7ffQ/ I8ngkpQoCy+ps10ffWzfIdK8558vppEgqRhdf/ePvm9vx0bb7/bussz6NqsaibYNDz7FKdpnm+/d bq++/Etr+nKf/ejuLNtdesle/se/t3/9H/6jZeUVOAQWAAotkp6RaRfKzljx0i5CpXiMoODQ/G7Z kG9vvXfaPtx3ye57IQWbZJxPJk8FsArJg2H0YpL8+TnHOkg9oegbEtPjrb2+y9kEKRyLxlOLKS42 znmXidnjEnBp2fCP77DSWL3dZHHIC3iA00KGlgg2nso2Epx3Vtp3vv2cU3X8+Mc/xuM7zlYv2ESb N4apNwnltI+LuGqjjAuNszAkJrXt5PduKLMFaUstO2mhZUNRg0N6LD8hwrak9dg7v/wnW7YAuy/i sWn+kEs7qfG0DdzQD5OQ94bquN5DakNbwq0rAYHBznhdjhR+Ii0aJ3RW0WdtSDqMqWg8ZUOHL4X/ dnd9phf/UvGOQjPdObffxGBojTpHi/xcGy09a4MXTtnF2kes9r4nLSEjDw1ArtWRn/zQwYOYB2Q7 pjGEQ8EwEQu0LGY7iyxr96w27UOff25n931qP0pPZXZgQCeBPcQ9vsQkK8EjuPPkEXsILckZmIHh 7g4Yi1YOuNBTSaiQJHq0jkGGeQlDdZlGbt/IyAGrqu8mzqnPGnFsi4nG7AETEv+cTGru1nzlkB+Q Gmf2/P3EWWXC0/jMgXVOhcEVDUPbjT3mnJ68oZtH8drzke4yH8Qov1xuladO26KCQsZY9orDRAr4 yN77/Qc42MTaycNkf8pLZEyHkQ6PQPMjLIdA+Tl5Odj1NdqFC+ftzLkLlpqcwf7tx2CP7IcN9VjI QDuaoWvp5BV8IvIAuBHKHIfCNNVWVRF9IYmkAZHOcxgUdMVv7qQvoyNKH6pYuQT+xq5eqe9UhmC0 VJer+0oD7rcbfZnQpWmrUOuwOK6oWfkFtKPi7idDDVIP4iGmWFw8wbypTORBNGGsW95DetWDYoBu osx5/xsnNDc7WMDtmD7e1UERAWcfoF2aotQ/ZRcrUAdw2sBYdSNhKaKJ/xSB6DkETjAE4iQQFAZg kIrkjTgO0sQx4eL4dVfz1S8Oz3TDxGeuvuWmvvmrhadyuRNFlDSpiYmJbA6EVqissmGygrCMDGWr BcckWXZWJpux4uF5i0BMjE4+tXX11tWMlAuvYMdxzAEyjxheeUAHTonnH8+LtNd3v2dbNm10RFyM tYpOJEr/8/VnvmWHYOhO7PvYHly5xraR51Mjf/Tzw3Z87257sSDesgjV8nRxmnUcqLA3X3/VvveD vzCfD+9gBldEXblBf/uLKnvtzVO2alW6LS1KhXCFYMOjnMStbBj9JLXupPczzZQf9mvv0WYVDmPZ 2d5jPQOdqAZaGb8w8CbA2ivaxuLzyYsMXNOiowqt/yA2aMHIEvNXPvd36nJDRj1bt2+ngVHnQfvg iudtAymN/oA0I54o+ueqjlpx/hpgUJiFa/sw94bn7wkdpQqyFlnXcKuV1JyyDDIPhCYN2OnaA9Yz Emar8gYQWATao8VJdnzXRTt1qcwKFfSXMVQqLuKTM4bzUzQ0t2N4NAPCYx0GbkWRVCsS8d5oSITD Lv+6d3MvdIMGqGWt8Q7sWiMJJB4CzkaQoUJSeh0Yldf72m1wCmjdgM1jP6gKHsWGx8xu0hYtsuGH H7eTnx8imHyDNR/40CIxEYlMz7P4Javtk4Of2Y4HHyRBfSwpwhR4GRjHUFwmJf7PU0CuYUD6yVjw UC+5wT98/WW7F445m4PUmLLiqsfCsPXrQapUe+m8ZSMJSmZ8Q+GkU9AgtDbUsB+i3kUlHR8yzB6B fF59YE9xuwUwxWL60kYQ+WEIARlyrYPPPhhDbze5qqlb+0Xjk0p2I02b6PzYeM2pUW1eN/LcnBrx bta81ucU2smHn7azF89a55cnLGbtWkcrLl68aB++/wF0YqPlZy+2cg6QTXU1dE1mSyHWWd9sl09X sxb2EkO2nxBmSZYSVUhg6yXg+FioLOZQ0Szi+hqsXcbg16HJmq9YGCWCY1hjU4NVE1c3jniP8QmJ zplRc6591iGY64LGCrtVoBI/4TFW7LesHYXeUeBy4ep80B7/lGhqpysOtLEf5axUU1EG49ttCfAE bZhaVSIxVazVMOjCxHuv1OffLWltpoauPDDlpzkxgOOD4+/hlFVe/6LbfAFa4loBL9swqRx0YlCw UcVuOgyDcezASQsYDrT6tho8SS9ZUeFCW7iogLRlCQT2DPeIJhKyUPe85DlUx8sQgPpBdAyyOISx 4vow9tUhgbiCmxlBf8Vj76rN37a6FwgBkgv7EKckta2wSuo330ipFGfZeRAk1BfaCFJQ9cbEwOxx YnX2bWN1DuHZVoc4faS7zfJiQl2cKG1dXkteZ7zXsQdm+aY21qEWPltfa2/+5p/tuT/+M0tC7exn PPUud/97Nm4ievxqFhaBAHmmD8/hl//xJ7Y+utdWpKdYH50SEX9mRbr9588+tqMr1tq9O3Y4KFRH UVGh3U9swr/7r39lJ85U2A9/sI2YeSkQiXYYpFPuFFhIeBrZJl6v+Ht91X3AFISpQCpOJRqXXgJE h+PprNNp1fk6U0BY5bCU9NWbauaE+6N94S5/rdBDc3MjRTmBBbcWaWZ6uj0Lw6x8x27OsZVbWrzc vv3Ci/bBu+/Z5brTVpS+ChjneNq/EcBm+YzWgNQNnXhTK89qFBkCQjG/SGCNFRUusJO73rXPcdB5 qBinGxA3Pdrn0jdJbePh3JQzMsvWp77NEe6pf5rHq8DtdWBe6vRXJTTSZ6UVk6NXX+8AdpX9LrOO TBIqKyvd4URmIIqHWc0B8MOPduEhv9qWLVvmnpY3vnK1Cq8kEZyKEboa6PllYwU/K8W1Haa4nClp FvS//Htr/sNOS8NOqxdpf93Zk5afmm3xuQsILv+xnTlz3jbfvdFpLcjj4/4JRjGS2lynG2u3jbH5 B4N7F8+fs4FLp+3hgiVuPU5ekpIIpuDIVnEOmpGUaR2cQJSJR/+SOTAHY2vbONTv4O6jTZfaDdHJ KOGvAoi5qqJ1HsLaR9yK9I80k211NgwD6J8/d9PtehE9utECwP1IteAVrsMq3WgDVz8XyP7VSUio AzCAPXe32eUP37TgV39rDz5wv31Imr7Q0WgryFnKwTrUCtMXW8Fo0VgF0BdwRrjf0F1rYTDoybEZ SL05JTAXOoCraK6TO8uttbfR2kIjvYlyv0z/ojmLYk+KBHdaCZHWWF1NzNh2MlDFOuGFTFu0B/tL P/hx8vRJTFewT8SrPB5b0mgEFSHwD+JJ+sAVsaOzxQV3Hy8T9w53Tf2iHv1NV7RfqOie6qoqImwQ GQSTt37hczD5lhlHt105vmiamtS2v5Kx+vR1LmVODKBX8RjneYMNaqClEnFMIFy6mBAxOO14+SjG mE4Tx4+dQD3aZEWZK60oa4mdrTpmp498afWXmu3ooUOWlpHhMkwkp8Tb6rXrsKkjSjwVauPQwOJM 5iZRgyPvWH/RJ212knLphD4MegRwQnGTwXMTJ9L/zGzfNRyqZ5wvhzGQVFPq7ACMkgeHBqWJIBip FoQWrcgW7vxw+foTbKpDRTC6X11/iMDPaaCnrcUSEfeHsHC6+lk0/KaDtpxjJEaXQ4kYGVeRKplF UX/D2ISeKk62vzu01373apQ99a3vkk0kwZM8cINCEcg5QxJJFUkwNKYhnLgLkLpJMqnx1GaVEhdm 2zMi7bN3fmdr1q6xaE5jjolkntvbOywtLMDuWr0AFXIEYwDTGBlqD21fTMDhVdaBdLeS3U54MW0B XpEL8ewar4nFjb0GnF+i8Q7WYPa097lxb2hqdARBzgtSEQUj+VMzyp8ciO2g0phJxD65zon1z/QZ h20L02CC1wpeCptMmroqq6ioQPUbY9u2bEX1UWuHD+2xPE69Icbi9kZ4pmpvy28yr6hvrbWjlz61 5QT3DokNIKPMKSu5cNH+03/6z1aY/a/spb/+K9TBHdh6Rtiy0FH7fD/hg577FnaZqNrZSP24PB8A ax5vS6Gd+WGbPJozDrcQlLol+RbuX4CeXcJOdtPGu+3cufP2/od/wPYp1rbftx01T4LtfO8D+3D3 B1bCPdJ6KKVgLrHrpCEQTdOJtgfklHf89Pg5/S83M5aSQqpE6MSanmFrv/m0LUVV9d7771rJiQvW fPY4GhjSRoIXLThhSZ2to400OU6/zZrw1jMbq8ZliqINmrudSq6qrcN8rEn9jfEFVz2h+xZwADle VW871m2xfay3ZuzFglDnqpYkVMHRSFCHwdEw8NqtaPowgkNdYJSorTeGg+4UTsDpkFCYSLAXOFX3 v5QiO9G+oRA73U1IrBGlAb018z95PGSfN8wcR8QlW972x+3Y/g+t/KVfWyf27Ks2PsR+JKYFYgg4 V9aW9lrshbG7zA1DZax/mlzmRf+8wmFpqNfSO0qsxe1qk1ue/rvqELolwjT5yMnegjStn0QLvew5 gDXegoMIJrZ8326LRGsRGJdiSXkFtn7lMitYtsoCWXeiyvJvu14UAuGK1rvadfvhGF4JSvEVKmFs 9nJiFWL58c79cBVE3vNqdBSJdxc5qbG3gR/wWXpMjFtX4gUm9sKr48rrzR6W58YAqucq/nfv26xf 9VgYgy96okrkMdmIA0JtXa2dPn3GKi9XW0dzt2XE5tq2FZsglDIQHbFFGassP2kJhCWItEBl1l7W QmaMOtvXtt8ulZbaY4895mAKw0tIUqpwkl1LcuWIC4jgGENNAzPmPItBSNcFJikMNahULkiBPSaA H7SXT1f0nH52z+smPggRZGJHU3znxU0ac6kf+N+PBMBTNUra6Z9OfqA4lZD75L+ud4gWjbhNhffQ SIU7Sbc+DG/lPUxL7h4l+xZJC+CEZQRoTYeRTocJmwn+sabG38S4JXA6/t7yFPvVZ7vtTer82lPP WGoaKYEAQIyKmFbnja3+UKJg1lZuf9j2vP0LW0eIGXnvaUxkMH5/UZId3VdmZ44eto0PkklCNQBQ NN6D4SD2UqSEYajwKyo7bIQ5WrE8C0mJ2ble8lEyD+qzFow2UI2diveGZA/7wBEkEuExyl98Zby8 u3gd6zij5y6FYVsZDpPZA0Gorqm23v4e5nkIJpqTFpJmjbM2K8kGxMTOZdzG2+SDWhMDLnWEkEFB ad984w3ikx2y7LQ8S01PQkIZhpQNQ/XBLlR9id5DEyv5ij4r+Ou5ii9xrom24jXF9rd/8zcwsYG2 FBs/xf3LXLTY8u95wN4++K6txGN72dmLhH1g02HdIi50c6Nuz1txlc1rjVODpsnWn1tkU99y/asc wljuY8vCux281ElMKigZc+/ds9cuVpzBHpUcuocPWlRmCFlxPseD9aRlZKZbO4GU1z+40s5+fs7+ sPtNx/jkgjNPPvGUZWZmcqZAmswGL/yU/aqH2VdD5qcTV1+98W9jy44KwGVJ8GgVeTqhOXyWwNp/ 6IEH+QXpevV5xwAWEjpq+eqVDu81nv1Ie2rrGyyNjDIRbKwK76IsHNpYNbPa/wXzxFlWfZIpj4CP ompXYLjSD2lNckkHt4t81AkxSG6wk6ojHElAbPJ4ZeEiDK5odVNoaBS6IvtKRZaQuq8H8WCSAtJz KA9lbB3dnmpgvYruuNe+oVD7ojvNDnRnocqWonXiSN5acF3YNOzQo7DDXPDQ162nutwd9IciE62n vMsiiA4jQcTY6HvAjIE37FS718KnfSaahAARikCAZm+uxasekyXmPoMwVtrT9E/uMdIGCpc0vQpX s5z1OjjQZ82VFXYOKfZvD+yyb/3Fv7OitRvATx1Y/LuHoNBnnp6IGzwvDNOepXfh63hmGW4VPVV7 wdgZKi2o7pm4V2kNi+w4xtHdH4DpVY4NcC0CQZC820U7HN7qRtcH3qYtXu+n/fk6P8yNAaQtdW6M yb1O1Vf/LDDFJOlEqA42NjXbRx/ttpLz5wkkjIfkaKhlJRXaKhiC6Ih4Bki2MLDjlCDExhHKZcZg LEwr5jSqQRy1qoZ82/fZTmttbnNOIpGKGB4SbjFxsabP8iBVDshw4kaFBfmQYsEcIrWKQJolBlHh WGKiY3hGca1gAnhxRqFMkk6y6ufE4RWhV//17scJmoChAEY3adxPHQEeh+sYzpGBQfts1wcWgGpX Rc/rb6Yi8ucIJH3UezDeThmZWdaDLWAvQUwHaWMUJmMEsXcfCcEHcHbYX9Fhwb4+ew5v32FOwVcB PlNj/KZ+56ZE2J8gofv10V32u442e/T5FwjsXDjG3MnYXzB5kAcCT0FOlp1G3YK5DTk61W/GhL9o 4sUVRQfakRMnbcMDj9BZxpKT1+o1K5nrbfbR3iPkkiW5eIcynIzYvRtTLD+NgM7DpIEDOTR2AcSk 6+7ooU7ak4RTeMdLWx2xAiHm2pRiEiOp+ioyc3UveSaYBRgTT7q61j744w48kbE7pN1upM1HYFA1 t3n5+cwnziAiDBq2iRN+dY3TftOoiBFwhT6VEpxWG3xvZ48FJYRa/eUW6xzstPT4AsaRJXcDbYzV Pu9vwlcx210dXfYeWRdiYqMsLzfP8vOLyAt93i6cL3G2oZ3Vy6ylvZvA3bW2HAY8BC9MLQTNzXwW VeeR7Pmsdb7rYtNl0qH1zKdXvIOc1oj3XSqvJphkSfPKq8rstd+/Ysu3LrGlGxZYY3kzuBlkLT38 XpxhxVsKLK1AMTIDMAfpsoO7DlhGao5lPZ1FfRxQQE5tMoOsBUmr5YV7dZmfSRDsqtlj07x5YEk4 6d0oC114EgITlZmVbS989wUXJFyHnVjMBaJhDnXQEx2sIS/5X//kJ/bsww/ZlnvvpQ+BSBG1br0I BsOsc42X148rsMtRw23dEBOxNZOL7gwe5fDW1cMGHGgxKdnWyCYeNw6xYL5S3/jzwKTg0pKiDtGP QcZZ6sEO7MZ8xFcVbfMMiMafuCM/aG4Gsf8+3p1hB7uyUBeKwdAM3f6iPOAh7LWxhUuEkNaNEKIj hmgdZK66kRLX2wCp134/GbdnX5t/7p0Emno8Pc+V533QuoUReFzzW0BMgG1MSrSfnj9pH3z8sRWs XMt6JtQNeye/OnzQXuDWtSfGHq8omGgkin8oTAsU/WRNuCXJOGgNDLNByT5av/vXlDYWrWUeG8PQ K/2MZF9H9ueKv00nJeUK253/Ae+GeX6dGwPoh+UK7LMGR2MIn+WIiIjGzp0f2Afv7bWVeSusIG81 +m+MNxHJOxWtxMgTiptYjQxlyCGJG1oSe+fbfWseJwtFo42QF7GrecBah3Ae6a/jTjzqUO+FhHEO YIICBkNQyaIagBkMhX0PQF0YnxhjK1etsFw4cHncSH3HrY5QOUbQDb7HDIoc4UDkmAVJIh0B45qk fIKvj9AYbeSubGyot4ysNGzOyFHL7021tfbOz39qA4R1WbVxq8Ui2hVWKFyJwq0420f6NnEDEaLo 5DC+EfK7EKETW7ZeiJby7sr1K0TqNxBQEqxlyVG2OMqDha9zLpLeSXr47RXJ9rND++2fewfthz/6 9y4VmENiXvpoX8xiLOOUnJpGROhMO1PbY0vSfYTr8bYNjVsrfz6YcNaRx0QDfxjM2DNPPYWHWKZV tndZztJYCy6vsvf3nYABDLF2or83BQ1xmkSdA35Unam3pLgMV4EcfRTtSqf45KQUUr+1WRebYUR0 BMyx1+5UHZaa2QcDqI0njlAy2rGba9qdyn33/o/tHIeP//nf/q+YExAgFgIm4aqHZVPVNvM1HQRk y9rDGP3+9dettbHNkjOSbDS633zYx0SaD9UWc++clb4aoj1VDyThXbf4Hjtbfcw++2KPJSbEE8pm xM4dL7fAgTIbCRyyvsA+7CuT7cE//XOL+3yzaBlByPLdfEhNKDy9AZIwFTgOZ+avsqmb8K7eCMRe P8X4+fcEhy8cVPuQ8MmJI4jDkdZvJer/T3CSgt0gi2KrFa7NtJVbyb/Fs5seW22xKbHOPEFSKeFl UjYONp+ewbmhEclZFvRIKRNHXFgU0QaphmVnK5mE7AIFvebBw1e+3Uh3JgyP1rikHzJZcbsWlat+ /LRcG71wniMc+GKIozdKWkt5OKeiFlZfXT5e8EBMsXa4TsKw7P/0U+vCtji/sJA0gpmQ42FUrtDd MZiH+K7N0klEeEyfw9HeQBkdsztdfwKw94ogbqgPWOQU2BuAUwG0YNru0x7VOrh0eJR9tY+DbisO Jz0wkuFxYjr1tDeSfLgji+ZHTkEXOhLsAMxfNzZiZDf+SmF1TIrTSAEG8PWRlWAkGDmu/9osodP4 h5DjPRAcmo9ypZarP4nJ9xymuQ6+RTCGG1lr7184bZ0tjTiRsN/Ao/hxyT2tF/8FAcd3zYXMOxT2 qxNhQkEeHvFaqzhIXerusy4k/yCx1WHb14FZR4ikeuB+SBD7PQcXHaQmUkytb//+LxjVJJdcW2ry Vpa5MYBjAyHYZlM0UOqNCIOYJ6lfJf07dfKE7fpgl61fdL8VZy1zhFCEzS/xu37dHiBCwOSYLEuN zXaPiAvXL2IwXcBjxzT0EzsPKRnXhnUd5OxB1NzNRl2CWvD0l2etYFG+3bVhvRUWFLhAoaEQcW3m mJI4Iix8loTIb2fYywRrEmW43MWEd7TUo8I+ZccOHbWTp76w++/fYrFRqRBqvHlKLtqKRMK2xPTY Kex8RpAIyCawBXvHNE4gIRDUQWBR4GB2D077IAobiXIg6kSi4lcn1VVWGtuGJbLQJN0MFtfh/gfZ 0qRYW0fqNxfhfrYT5Gr3XojcQFzCQStr7be02AT76NRxqwSBk7Djk8RRDOgnn+zGW7fLHnn0axD2 Itvw5Lfs/T/8xqpxINiWF0NMpyBrxyX0Ipk9vs2YDqP6VrohFTH24fR1/X0P2Hq+SyqwnHE8cWoZ tnH7be/+/ajJugjpQhDXGCLAp2Sh8iYHAHOsoty0CfGJlo6jhQ+bnyqCgPbDpComoOwgp+wyF5Ul JCkDGQEb2yCxFHVjP17HiRnRduzzo26jLi4uBkfVzpS1uPav96InZWLQjY3U5dISK0wuto7eFrzk iKO3cbOdPPGFvfXm29Ze0GZ3L3sIvLr6kHO9+m/V7465CPHZ8uwNZI1Z5A4k8v4OQs0bguRd1K6k 5rwdO/WR9X7rOQt+7rsuMLm8KAcRmQ6xKWnNzVcRg+Blg5mvGqerx83YdD9ec931keWoFSl65ooI N5KQIRy0+rD57EtJtVCcqPrxdLxceska+qpszQPLbf3apZaQFuNUkJAkSyrAxpaxG+gPwk6VkBQw U4FkdRjsH7Xas0329DPbnPT65IkvCZlxwWHlw4886pwWQrUzUIfUoeqBNk8xYe7LGFhzfVN3FH4r nDUiuuY2I6e38lgjGcfrGl21Pja6YAit4xOZe7WrlaODX4ToO3ZYWXn59gxxRI/t22NfnL1gvahp ZQaTgNG97J2jcL5QxiDHPLqdjjl3deAsIJs8YJn428T+CD5fH5J1tB9BHKaHYEZnnEnRBg7+wisV 0fC05EiklO0w1wPEDwyCDqNNuAaLvb57O7H37Ff1qrEZxOGjoifZ9nfmWS9cSjDjfCcVDW9vOOw7 nu/h6DOVzm62RfK2rrAkbPYuzfaReblPwqRUUgv21VaSyarS1qQSlgbhSkdnO/g66KTZAeB0GH1x smkxAaw1ke6ejhb7+d//rV1kj3z+icftSRw5W4/usz2s62G0U5Jm9kVl2FAoZjLgn+GtHoLmMRQz tcgovHv57N/jNVLCd/G/0gJ4qOq9zktHZ6hkTgygf0rdYroOfKJJIhIaM/Ex8rTR89V46rz51lsY OWajzi0iTpBssW68yMPo6oODiAdePWxQ+hcQFEacJxFJtcGL3kV0eB/AZq6GBOOXyTv52uVXbXFe hhWtXI2TSbalpqbCaMCIQajkVOJ/TvkIz8DsKY6UDxuoqvJLVnbqmB364ghBL9sJ1kxMpHc/sO0p UlEG2MKoIHt4WQr5FoOssWbYmqsrGBA2Tzm99HXDAJLqCBWu7FFGuR7IXxgBUH1xcXgqRYEwku9B dBnE2CikY7iKa+kH00eNrTzdHCmAUZLtgwcob5OL6zeEWoScvxBgk6hcQ6G1WtbUZ29darf20HjL X3+P7UBKmpLMooT5EwNaernU3n75JRvtbna2DY898YQ9+vDDlhYTZq/95rc2dKnFvrEEL1wWRxxj Vnr4iAXiorZkFc4gSO20gWiuaG1ss5KnbIht3LDOaltLLeDokC1aVMiG2IMBd7QLqVJaetkNextS zy7CxMjZR4bb8UipJDm5zO9dLd1IDVlw/mon91vYRf/Uvphmqf2HUM+Vn6mxuOhY+oJ1E31U0WIY C0rgvs/1RZKQSOZzxfIVVoEEMyYswU5+eca+9/0/tQULFthnBN0ubyyxTSM75lr1Lb1f8yIP4JS4 VNeOMzxmkeuU29ndbvUt5bZk6RJLIdaWJDVD4Gg/eC7HmWnx7QYhdlXeFEWYfcN0ZYwuzPyMmAO6 7Jg//53Cp04Ym2EObyFlpRaFVLsJc48qDgA6zEYkB9nG5astqyjdLbBh4r05hzStQzwiulpHrLkJ 6XR4FhIqJIetFbZgZa71NvfaiYsn7SgHR207Z06dtCA8BFewjmJiitxadLHfNA/8aa6GOGQ5FafD cz+E07yrfYre1H8VnSNdUG8IQQfwyysxLj7O5X+WgFLrYnBAB04OxdzjSTDEFKor0BMxglyXzRX8 liXGxti/+d4Ldm7jBiutbbC//x8/sxBsgBNg/NJJHVlUVGRphOxITEp0Bu9agyqScnZyGDnNQbAw 1EegY5nljwHp7vBgEaMqe0IfzzViE5wKIHJUc13j9que0BcWtdYmJJPfFAsuxLLTsUlu7sGLmLUv +N3DY43ojfutlawWPgZgkJzo0KrxAZtw263+qLFtG4qwqr54+6Ij0+rRJQST/eNOKxo+2SMSwI9P kwfz+tC2RXBwCvbxpEeLr//Ezd+hUUwPJfUlaU33fvyhhcsrnDV9+cQRYvI14yQYYsMcWJLYC6OH kR1GY5/IGuggiHgL0r6Ki6eti2CDZYTE6T/7pY2cOWGP37vUfAvRJrIrH+nDyx/JinCsf6jTBnrh D+hhRwuMoNLesU4ULk34HyQpIcMmOiO4Rp2m6CpMnrLD179jysfGL86JAdSCv16D+l3TL65ZKlcx D7omlWcdzh5vvPGmNZS12X3rvs5V/TbfyCwO+gqgrv5pgBaTmAcTmpVaYBdRgTUfOWgNxLoaQcpU RM7TpYUFlowtVBTxrRSnSzkxX3vpZ9Z19guLJf2YZit0tIf0NAF2vBdVH0xeNAjzaK6PuHgp7qQ8 yghLtaI8mRk4W/gg/voXGhGJxA0JGXGoYiFIIZEyfiamIceLThw6GpB4haLikH2A0heFgyTpuXnW 3tRkLTCP7MB4ng5aFJ4HPojTdEtOjK+6P8hu3YKEr56/NhjjZGBOiQ7CjZ74S6jDz9X02u6aAVu3 MtUefXAHgarzXJ2y3wvhnk8/fd+KQzrt7pWJ9ovXfulUhfdsu882bnkQr7s4e+m//B+2NSfGkqJD 7Y9XJ9uxS/vtF3s+tn/z539pqx7+ujXXV7K5tMBcFyHdUPRSbwNRf5vbGy01P9HueWatdZAX84sP ThIaY6fl5xaggsYRiAWUnZvj4vk1szAVCzKeDcrX4EPt38kGiucg6msZKKtMOd1clBQwAoa1rb4f FS1xoxLjrH0sBI8YSAUKHeNqXD2zfVF7+hNz5MP29Lnnvm2vvPKynT1x1pYsWcQPIy6syto1G2w3 9l19eLxFBJPlQJvPHVLE0EgCr0OLiiSUNS3Vdqb0sMVkRth3vvN9Z6TsZVhRGkP/oeoO6cCcwaCf XldnfFK3SBimd42RPsirUeNQUVbmUo9lwCWNYKM8TGabUVRgEXi5ZxQnWvLCaLQR0De/sJdnxUx2 d/Zhtxxn/b7F1g8uC3eigvNtsKveCtfnE3uRzBaWg8nFkOUnZ1nrsb326b49FsLhJc7HYYeNKYI1 JE2FbGZDOBhKSs9/T8VFharzqkLbGK5Ai9QT4Sr3iMmHkVIqLzF3ktJ99NFH9vGeT60ov9Be/KPv EUidQxIVD2PoHIKBfQi0QhuVGwvqkeCcs4A77HuUXswZjmXQre33brFzP/3vVotEKG/z3VbXQOqu 6lo7VFLhUrUV5SIEKMizIuIMJnG4KF6y2FY99KT9/uhntqyt2Z5ITOGgyuBP6I3sdXuBuRN6VpiW Yh/DqMUSJaGXsZejiiihzGrGC59HuwAwEFobzfxAK/Sz7MEzM2IcnzfxdvcctMDQYlh5E1wpNxfD /OVxOJIa5DaX8v54O9yeBSMRY32MRXAQfbn9YMyi10iQiU4RCMPD9MypiG73hMZaL1lBRodab1v/ NIxigB4n6Phrx4/a76rKCRnUa5mjrD7CrUmqXQd+NYPjnUj2RsbS9Ugo4mO95LPnZGQste1Pft1C C3JRz7eSOjPVEnA8VCDrCNyQI6AVnquc8Ng7MPUi7OnuabY2pIhtOHhGY37mfBHQ/IlfchjPiztY MTYzTveMP7omZ3yZEwPI2nLFtTlhkvVxTGDubkHr5giliF0Pka0bCGBcVlqGBORzayhvsc1LH2QA fQywnzJ69d7uV7fpIbIKQNWVEV9oK/J7LbLljJ2or7Hyd0rsQxw3Ihctsdwlq2zZ4kVshmV2dv8e +4/3ZFksyCAVWERUvFNZRUIoOmDudFJ+gphp8naWpE0nYkdsXefwhpXHCEVjmAGzpOKhhj4xkiBW LHFyupEYdPS0WVtXu3Xi+abYRmIEI3FaiSIek3Jfdne1WiNBZHtAqMEwapwwJzTt6JUisTeTWq4S InihK9AGIpOtFxVvIOl4YltbLBs9dxpOG8H0J4aj8uXThNupqbGcokWk7cGWgUoHkGxUYGy9OSnC 7sqJJ4VSn7350j9Z7oJFOAzkWn5eLrcFWmVHHx7FweSQZQOMz7C9tZdsgBN9J0zWe2/93s6XnrOn n/4TW7Zy5RWkZnGFjUY5aWo4GU5CcAC656n1dmpfiZVXlLv4afH0V8GwpXpXjEhlSVH/fHgVy6an DXu7UKRtYvAUD9DDR43ntUXerv2dgxYGoy6D9YbGBgeLnpkwfNc+OMMVPSdbKR09JDHRZvbc889b 6YbLlp9f4LymdY+kKs0wVa0dnOMTFnCFzt8BxWP6vI1b8Sr7Ccha3VxhF5tPW+6idHv+ueeJ5J+N xHwQJlEhPW4d83fNZnyrxocJEX2aqYBinPG8u0QrFE9SjyikhcZpEA1CO+svjFzV0UkxFhAXTjy6 YGdq0NVK3lTMKcLkZDCm/RCiDXT14/QWan3RC6wfI3rnwU+lsnHtbYOxjCpALFFoUcORFk1bCZmZ Fovq9OCxI2grXuGwmmRhsfE4FMVbZkoSmoqUMUc25cYGXjYslrxHc9QBisZU3q6S+Avn9V3SSNEn CbrEGGrjaaxvtHff32mDZCI6cvyE3V8Jo5awilis0DkYJj0v4/8q1qAkxulpqU4LoXOTpIIqkhqP YGozCtcsm93MggILOnbcknIKbDQjB4YYc5zODmtnsz1YVWkXOXTncs8GMgstXFhk333xe8QRXWX/ 42//L8tD+rwhOmH8TKY5UIgYmdZUM+7rVq+ymo1b7HITTAPjF0J74fRLAYKljh4vGphWbAsxGRlh Yw/0wdAJaMYdcutoyfi9+qBxk+oYR50AbIzp+FU/344voiXNAz7b05FnlYME2AYeiQgcbLcDgDm2 oVUSzv4X3M+DHirMvgb2Dh92nWFESKCT3vNjuDv7Sm7sTthpbEjD7XnMN063t1gch6qiogyLTGRN QutkGy++3zG1Y8MvdAhlvaxK6bZXSy7b2S8Om+/uLfbRlyctcbTPkmD+JAxQF3i7iiGWBD0MBikG 3OoHX1uQ7rdXd1kPe1kM5laKDSwtlYZQ7ThHKdfu5AEZ+36TBHNODKB/Xv3vE4d8AED6OaGI4XGA M5NKzbNv7177EgLQWtcJoUq1LSsftejQGIgUwTnnjCkTW5zPz1KfigQjFUMkvCMVuwC+lyIOPsHJ 4KhsxXLSrS4w0lKQAqcloL/X/dr0QQSpHx5cmAjCMGH8BWGX4qljr12vzOV48Y/jxGv6UdejOWnr LxEE7CJ8SWcTUsEmpbHhhEDMoKDIaIsHWYai462OXJ2Xm9stG7sYeSSp7b6+UWvAjqGaPausG+/X xBzL37DM8mBIgpE6dBC3q5Kcjl+i7jnV3WmBEaO2dtNiyy1cYIWEABlCwugVSQ0CrSA9z06erbHc 2m5blxdvB/eX2ieffGTfh2Dr5D9EDKOPy3tsGapviQjECCUi8bxMFPgyvEvPfnHAQmJC7A/vvWP5 hWxwSDe1ONiJdNQhT2c4anBsyrBwD+W55ZsW2qGXzzrJcQRSNTEpUtVK/atnVWQPqCjwzXiUt9Xh SQ4/LceQCKL9i4BOXjJ6RjinTWyQk97TL37Xtm7dqstuotwiZ/ARMkz5rHfj1K9qS/EAPXkOmQhg WBPWrnMwyya1Hjux48e+sMU5yy0qIhZcE+m5vQXZiOucNlKVidK+QYzqu3q7rLW7wRq7qpHq9tpD j2yzbVu3O2N72dAqT3U3QXVDwD9/HbekB/6FcUsq9yoVfriFNkMbAoMRc+Ok0CaXL1+GsSGAMOmu UpJTGRfoGLlofek4NGG7Kq5riMPSENKpwL4I7IRgFDmoRXLAGg1mvntRGzeOWkdQtvXLNkjEYqz+ YcX6DCE8UGwxh0go0ejY+mPtxS1YYWHxhIw5fwpJejP2ho02RGijaBx0VrKWVi1fZoWoVeOwiZPH cDA7Vh9/ql1TrfXpBctHQgjTKkZe+XBDYKZEq91a4UY5xkXTrx4C5i5ctpRYhDgxsea0x0hK0w9N OIe5zFus53UbNllOViaaBZCeNdxDcHhl81G8T+Vn1eEsPSPDUogp2guzNoiNs9aVcC6cg3X4iiQL Hlpj+Ufftcp9H9lrZ07b+nvvsVUb7rYVS0hBWFBgX547aZtgADUPwljRySi0HfF8KL9candvvtse //6f2xvv/YEcwJWAMWRd3NnFmGcyFz40NBNp6yjjTydgBOlTstR5DnRqnVTUGLENJfUb9TFA6QmO Rk2669Z+pdOXCPVSPRADk+ryqdza9m6idg2X5igE+i2nRIV1mUsRLclsO49tZzPjjvPgbS6yp/Vh f78pIc3BDifDljQAviIdpy9jMhuPGPhhA+bCJJ+9wJp558TH9jYBzONHO/BJiHFrbroR0FjxqCvh LL7MqEBLYMxaiarQWtNj7VGdmEYkO5rrpIFUNMJe6oWPGXtwDAa1MV07Y7dc921ODKBqc9uqWp0A i772wvz1uwjWnghek7pv3x577ZU3cPRYbZuXbMaDjIUEsZDk785h/tQrf5FKRMwb6g7I5lKC+C7y xXB47LWLqF4DRnstKx87NwjocEWjjda3mBXiCUdA6iF5ilCgOdoHbrr4qwiHwYwgtEoCDJpyBffB vPT2dxAKod1qgDEpK9cyUI+Wl3TZH0AgH5LALuL29Q8Rdy442oKTs23R1uW2nE3iwplT9g4n/ADs Lhflptii4mW2/cHH2TAUzBebPKQKzttQp3fGwV+UD3Trk0/b/3nitF3YX2bFaXjUwrD1t9WzAQ5j Yxluy5YWW9Xpz5y2S4frIBbPfbkxtnPX6xD6AXtqc4YlrVlgf/uzU0j2Kq24eKlbCQ3NTVZ9+bzl 5HkSDIfRNN3V0c9YioB7cAif/EGz/egnI1ofInTlGm7HM3iU02cPDh5aFhFIE6cqYvICkXaGo8Jv I/BsQ0MTEsUst/Bl6BsGvdeJT3Ooheqfh6nqmnxN94oJVFhvaa4Up1Eb4/kLF+yDD3Za2YVKe27H n6HOj2FBe/5ok+u4Nd/Z4oGla6AFBsHn7CjVTm9/N0wf9pU97dbUS8aUAUIJRY5a0YoFhO/Y5sLB aPcfhPHTeHQTh1GqYTGAt6q4MZ/LoN8gIF47zNMsNivdM8ya78ZWt5f5bAsiBA7XujhExeJ8pdAo o9iiac1I6hVObuqA0AEOM/GodVFt4bQwFIyXYx9rZjjFhqMzmQ+/zkTYCuNIYN++8BTMMbhOHeMF QJX/Oxw1UcSmrSAmISb4fQCa1FpeageqSuz4xd/byuJi27p+LSF7clmahLqC25JqFl4S1S3UlkOZ QtN88cUXSPDqLREbvFwkeBmsnRByQOtQlEJcvW8//xwZFaps7coVlkAw6raWNmvGY1YRAGow4Xmd +JblpaX27LPfdBL5Fhi+Bq6Xog6/RI7Y+k3bE3EAAEAASURBVLZ2Z5so2+QC6JK8JH3JaZwJGSPZ ANMf9w9GVGxN19LN9kjngNVfOGKHXn/ZLmFPlYtKeKS1yTIwu/FLUvzjIbqcFx6Fs8yX2FQ9ZQ14 b1ZcumyB2A0OQy9i0jIJqIvWqZUQO+HYTPuLiAZ/YkJd7kLGW053065wEbEYDrOkQES86REDf123 4V1gtg9AE3mHlNzxRcOrtGpukOcA7SgHnEjSd8b0oG5nbr+aglAAxJC9aaAPkyf++Kj/Xhn/4L/g vUtFnBkbYS+uS8eGnjRuGT7sqLWPUY8G5DpF1eovAvwKwzQpBvV5TXuD1YLLvazF2LhE9mPUwtzD MLEvUSlteuBANfwVzKKt6UCZEwPoGpxYkxr2oHFXJSny25joQlVlGXn/Emztoi0AK8aK3fFfSNHC G6DD6mI8qppNSem2OQOHlWgkYtjuDZ9EGlBSB0HhNKmcjiqMxTVj5P1yw69X5himhtNGBDQrAWQg nJWda2EzQr2aj1dhwb07nDSyp7+VSOcy4E7FGDsaFVGay9FZj9rmADk793y6x7JGWm1xa4btPnLA Fmz/um3afj/MVZQLpClPbaHYxI1RjFgTp3sfjKeMfPeUkrsUZvFbm+5xcbX27vnEOisu2LcWo/qG cGoMtAjWZ8VYIpFBo4IiCRvjswE2yhR82PrYEPvYwOrZiASPtVXa8iUb7bJOkIyUVLlVl+qwu8TR BkmCmD+HZnqZgOx+BxWFl5BNTywwDSL1rCdXaDB2iaF4S0+eD0XNT0yPt2Xxi+zDfe/ZxQsX7Yc/ /Eunth2lXTGALuYaCKDN083pXGYP+BysApXPZcQE/MXPf0bImQvkfE8b64BkM7evSD3XBZE9dPEj 1P25lpNcBOPeh0PKBWypmp1XWmxmlG0u3mqLFi5GspqBah0zZphGec1LVSGbP6n3XKduC+j+Ubwt jU3fCGCo3/KMXrCgwMrKyhkC8nW2N5OKC0kvh0TZAwrfNfHKMyocjY7DHCC6xbpbMkhTVcABGfs0 Fm8g8UiVvkxM35UCc8Z4I/qjjonXr9yhNJneLzBzrNFwjMgzlq02W0x8xuoK233sILh8wR7acret W38X8Ryx3eMJbUTiZWQX142U8dev/MbqBkmDCNzpMKoP3LfdNt613tnlUq1tWLHMRpYtIUB/E8zi MTt38TKBrMsIZ4HJCTB0EOA2PTOL3WjI9u/bZ8dLq8jedNZ6EVNEJmZYSEExmSLiyevbQgrBC/BO QVaw7ZEri2KsS4AEA0gsV+KylRSutPs5TC5GMniiqRFm8rLlIum7h01QS3BikdOLDyezZrQzAxDB Qzvfto6KUluTk2/NSBkbG+tIZ5kKY8iYMpah9PuaEcVT1el+J1Y8+bMecnPKh2nmZPIj8/ldzfcC 5+igRupfRmEnBFD+9DbLMdNKiOprwja+xQVVvq09Fag6EbAnKOBBYCTBwmPQTJJH+iq97QxAiUZq z1iSGuXwzDnQzXD/VD/5cdyHuUF+XIR1oGVpqKkkFm6nJZMAQuGOtB9jVWZD2lSEkq4ivfqfnqrm 61+j23MrAkTN6k/zPLH4r7trUJ677tpkZ06cs5LaU5aXssgRTn9Yj4nP3cmf1ScFdZRaNWhAoWGw b6FvAcSXG01hYggs7UZilgh/M30VLK5wEujA6AwZmcXCICnTBV4RVpifwx6STkgJYh3ipSymTl7M UvnE4Ezx1NPPWndTva0YqLJnV2fZBeXi3fmy1UJAM1OTLR1v3cTFK0gFl+jsELxFHIDzS5t9sPND W+frtW9uWWyHytvsn840Y/PXb+1fHLfdv/kneyY/zFZnYK8zJr0QrDoRFhOfUEGrZYctZJVYO5AQ IzVNFfbzn//SBlrr7E8eL7IgEH+EE5AYQJ0EB1gEvjA8pPD6FQMohHMnK/2sRUBREu2KqgokHah1 kHrGYCfZi2o3FM/vrhbsETHyvmaBUI/sHYvXF1pcTrgdee+0vf771+2Rh76Gk0O4hTN2UjHLZioA UaBirqkv3os+zFx0WpetlNZJHaF+9nz6qclzPB4JTlMHSexbKqwgDennTS7cmaG4+ldMx3EAarSy +rPS01h/QzeSSqTFSSH2tXsetsWLi5HORznJkRgFSXUl9ZO9n065nrcvwy5ugrlw83F1E/P2TVPr za73Om8V30BFmnd3GAIieem5QxLmCAoVoX8KLyR6FoB0K5TDmSt0QFJAMWlxqWE20l/LgSfG+gkJ IRoyjBRscs/URhAer1JgKnSSYglOX4DK/ecpMYy0l5hbaLFk7qn+8rD9+q13rbq23h54YAeHwDRU WA573bxFIrkNQ+oVt2C5ZS9aZuU4W/zjr1/GGSLDFhQWsAET6xM725OnThFg/5CVVNZYFwxfZEau xWEXFYcHb8jJozil7LdfvfGO1eOoNqKUWkvWWUpWPmGetN68/SEmJdOSFyzhO2taqlhwanLxxmHE ypLTrSE62TJI67YtMdk2I/kQ56oRnfyUJCENxFyNSGI8+XIObUISNlUYH1ky3tQdMIFNaGtEQ5yU VQfSiQ3TaKBsr5lP4fKdWjQ2wpQ7F8IrIycYJTZQvuBgDvZD4O9ooFiL60EPU4OqNaEHQQpr45qF caWJG/jkX2XTwMD0B4bB8EWBYXwOwBY+kJjBDgZJ2uZQhEayp73ZohrE5CVyMIsMIY4gNv7VFdgU pqazf5AaEgGKbFalbJQzlLeXYqfKczfa+pwYQBFn6N0YWtLkpFZlJ6Jx0Mahz2vWrLXKBytIFr3L qS3yUhdiG+aJ3W/lJnKzEzHl80KKfkmUUN3J63btIgtanItlP2qGeZj8Kduc5qLGVogSDgHsR9XR 19Zo7SUn7MIf2txxfwjGbzA8jkDXaZYnm77FSy0L1ZDzoG0qs6/dlQXOj9rS9BhL84XbJ+VHrbFi 2OoHcKg4mE9cxOUwjAkwj0iBcH+vqiy35jP77VtLkpAujtoO3NxP1zWSTeOoDZA1ZHtaoG1ENT4w xvz5wRZ66Jo8BQVzEHZSw1i2t2C319iGWv3sEXvxiXUwIJl2lnydbiXqYTbJxNRYa6ztdDZGIRh1 SzwPWjneT0yimMGqWmzVCPadlJWAc1Gzs2uUTWAmaq1WgtHKHksZFyZPj3BPUpv85bkY3kbbwXeO WGNzI57NiZYUn2Tbtm+zZOK5oY2jVTFBHrum/kyuS+BOLLIXgcd10rMPd35gv/rlP/MMpJxNUCkK 1a6Yw9tVJK3qGey2i2VnbO3qu+yb33yO2GcymjdbUFDkmH2pdUV/5bEqw2ed5L3Yj2xA4L3AFcT6 04nd0QENxgzF38Pr3DZ1DX6mZepf5+2qYPPDOVWl/v7qNxHbZqRiHdizxSbhjAUjGKJ4nNwU6Jg/ f0+9d+GJ5jwqicDIqEeDUQcPYXc3Zde4ORCv3iA5l2AUHhQKA3Q9RPMDzH3DMIKBrJGcu+617tRM 27lnpzXh5PW9F15wOYWdYwb3RWOfVJCXY0fqyi34ri2WuW6DHTt/HE/4Zp4vwmaxw744ecJ+/vJv bTA509I33MfBMBOJCGotcISeWmLBIiIW4H3PQSlzXRaagERwAgMSflcoq6nKVMzf+H3A1Yl0VbnA U5voCwOkg4ZGcTLzJ+1SG2m8zmCvev+69RwAu7GNbrMlZK/xTFaw4ebAewbGVIewYTyz/bPi2tMX Dn+jUaHM+1W/jINzp3wQdKy0OwWcmeGA3oUy9UmVZZZx4qR1phVYc+6SqXF9vCb1jegI2BsndZQ7 6R982PwUBi9AhyPKqCTrOrhOKsEJQ0jowelQiLtwQQOuPV7vX2FxYNB+OJxeTmyYNfT0Wx3OkINI u1Mx23ApbqFFWgsROJwFBShmqxjQGwN9TgygUFIbogZquk1MHXD599hRFLvusSeeBLgR++SjPXgE d1peehHhUvBq4tSsneRfjkRQJ27ghSq55NuEeiDvmTgRxkO9vn1FKKugy4WcYvtlE8R8pEcMYBvT 7RZSF1HVW5A2tVSfsAOHPrDTRats2+NP2RHi0K2PJwQMdgr9eBmrxHMa/vqyZLfh9/eN2GE2h6q9 F6yO9aMNKQiiHh06ZN8ujLV8vHsH4IYimLclZDJ4r67GBmtL8epVOAWgmm4cGB4nKmfDLMhLsKMH dsPADtmz2xfZ/ZtznYRQzjQuADB1aDR98ZFWTUgAF6NPWMrF8WUsvKE9eSmHxYZad1sPuBZiaelp bHLEV/JFwQC2uUUjBnCq4kBl4aTmp9i2Z++yY59iYN9Aful9Tain++3Zb36LFIEE5oZ4hHCzDjUK 5aNk6NN1U+2IhohwjzBuETB8a9ets/LyUmvAwzIjKsXS8BqXOu92FK3REQ4sRy9/hunCAMzfHxFr cZE3pgCgOVGQdMf80Td5nEni52GzN9pU4YquiXH2/nTRu8v79cqrfvE/M36VW6e+e/yO8Q/uYDjb m8efmv8Prh/MvRg8lX7CWHUT0UAS0jik2kPY44rJUGT/6XonCVQIISF8McT/6mlBypDh6pruJQTv 257mOgub7oYZrrt5YdPz5RTagse/ZZ+//RtLfPNN+/YLL7qYmUJaDWsKUsHgkks2TAzSqoMf2cai QisoWIB3PeYYez+13QcP2wBp6BZtfxQ6x8GLAyARq8daHkZqnG5RYgq54sx65ARyE0UwBbMeWqNw aIOJZXVNgSuyK5dJxrB90lBjEfkFtn7dWju0b69FE1oqHg/Odp7SsxHUEQsz3YQjSC1/KTCqPuik n/HWQdTNlxbqHVzwp4Wuazzu/BKEeUg4Htb5h/da7mfvWMOSe6w1CzoDTZ9ubYi9T4L5W9BwGKVE HxmHoNMzEdbZDoMGDJwMxNNc9Q0rI5W8AydglW4Jihxj/rSZ3oGjLCwVzqdGyWxkEEfPckd7Ulm/ Glb9FkF8QqWx1Tr0tDXe9TEMV8euW+bEAF4zPxpJtTaxcM3xFpL8IA4JhQN/6htPI2lIQo2407qr 2oi+nYN6j1N0eDQ8FDkwr6lkYoV3yGf6hQ+IDbfCcceLIHoE56uCTvRL6ZGBBtVRoGURPHpFRCLM tyehEZIoqngNato9F47ZSz+t4r4Q24rnkttkxwD3eyuL1ARHBNmOBck2ujAImx5PyqaTRiTzKB9p IZlKP3Uvyk60w8cv4enLqTsuCq9R2puMC2NtwGmAC9pMRu3BbYss9tNzeBvG2pqVSISpS96//aQf G5SIG6RW6e0g3j24M9VBQ/BLIpOEukg2kMrIkpWRhpd5tItbJq9boaZ3gtanaQDj8iCejdGJEXbv 03e5ej556ZDt+vAjy8AO7u6773YwCB4FMpfYXZlWxHBPU6NjoGQHEsrGc/+OHaikB+wYtlRpSBa/ m7bAss4dteaiQOtKSB/3AlX981/U+yC7UHXC6jov2v/0lz+0hXiKKh6nGD5ns0ajEtpqveqa1uFU 4+3GkhedPoNgGjUO6r9/vvW7K7qHDwpZ4Rgnxkl2WJIo+u/X+51RxqGeGhzw3s/86YbWlhb3F02U /wHsApSFZybmb7xSBjYmPpy4nqglh1Oh0IwbTbvWrxkM0ZSpC+C4Mbzq12ueZx5xGIlAhVp0/+P2 we9/bg8SrD0DFa9UVDo0KQuBpLv98jo8f8bu+u7zMLZ99sZbb9inp85ZBlLEBflFjkaMUtfkImn2 KJLi+SgCX0GbEsm8EIczyVR9V7/lMd+JR8uRrhbbxxMvPvUMWYD67MCunXY/EQMikPrhjufhHu/Z SGdDkXx3A2cdhjI5HMQ4yjLu4KLOqcRXDJIUcIrxm49+3WwdAahMOgc4xA4C9Z0K5FgnNYQxrIe0 RnLURyZYV0qe9cQne79qQqcYYzl+xPS2WkHjMYtAO6GsQvNWtP85AucRNWmfJoMgrcYwm1hwOD/e wcXBzUsqtsNCg9rqSucUIkdNHS4riakZgVYtivBwYdIgcE3SQDGHU62lqbo6JwZQQ+ltqhATCMp0 jegXDa1UD5LsBHMC27HjAeLrLLSPP/wYY+USa61EDTUcYtvWPoprP2ExpFu+w4tAHG5BhTDMwtQJ Am8hZ0T6FcHtR2zNhZgOSXScp5DgGaPRmcS9enh5mn36YRm2MzAx6aiXpiiuLpibPiSLowXpLsOI f+X0+xsae05Vp4Blf7E4D0yjTkQWE5nKydWL2QiGCIuYhSEFvP+R5Q53uMzjBHUlIv/hT8qtkVhq OYvTYDQJwXOi0jLjCVkD0+GvW2BobQvvtDHIgzEBta28gf33Cee68Dwcwss2CNWcx6pMhsj77pgd 8FPwSTKgEB8pqLIrL9XYT/773zm7ryiC7KruJUuWuojt8koW0zRdkRRNcKruRpxR3kcNnJVVaIUw 5ytP7beE5nraCbGOlBxsSudnI50Mi9aoc1TAs+5U6ef22NMP2VK8rjWugr0Phltj78ZTsGpEvf+T q3LjDE2BAcbxm8w4wnc962LNjd2tuVDRfRK4SvLvHtQ1GtRwqV3ZEroNmO/TFTcn/gqnu2mernu0 7NrK1B0n2ONd+NSGZ2szzgmhSPPk9atxVADmWRXwIQgr8YhAJIAcTAYYyChUrSNQ6h4I98T93Y/n V9ULMCM4PHS1NDlJXjBhqgKJYRmMbazsDLX+BK/m0l8UDiWEdIoKHNzDWvCH5VB/B7Adlko2mNii qQtX2K5Dx+zTo19aBSkeC3d8nfTeuTCR2DnfBnqstHZJmJBsOnnEsusvMxbg5YS5Fy40YNNXSlzK 4y2dVob99cPf/WNLyF9gr7/0S0sjHeTGzCw7PqHz+hjJmOQTaB/ZNhER1BcujuGo7HoDOqHdkZye tVNOeNY/fl/1u0CtGcIEZsjHmpqB2HzVgNK+7LyTiHcZ3jNiNcX3WnvqAutNSHX47UlbpwISSe1g p4USEF92nPNdpPYdQQukyVU8ymsKMI90sq+gAp6Abtfcdqdc0J6XBL4OEOGiBnOsEKKtBGE72Vxy Gk1ZkhUsJQzUwkWWjCRc8TkVutKP79frw5wYQA3WVRvqVIuHa5hZUNBTs8D0jNQnnaQYUiDVBx56 wB56+CHCkbxtP/3Jjy2ZaO+bFz8EUbr2tHk94G/77+o/63G4lWXZQxwtRZf3QUymGofbDtzUDeq0 r3hDKzNj7A9nGjktg/gz0JRAHCEU2mYilyN8mqrI+0l9dwR2qhvGrul5sWLi3pyXlDCa0s9mpMNC Q2OH7fr4jA37Yq2rDiPiAGz3+nCpLySFHgikZ2QDqOIRczEhHlSKESgGzr956r0R54swROeKc+a/ 7h6e9NKPdG6ULAVS0wlPlZ91wZocS8tLtqO7v7BX3/w1TjVDRIKIsP/tP/zvlkm4GKk7pptw/SLb TC0+wSTpZBNBxbdtfIqUgCk20NaFFyXe0D6Ch4sTmqeiJidSMoVZ6iGmn7KxLFq5AIeAh9zAyb5P zN/4IUGPzQCDxkRSMM4EEBaP0XBNMRfBzInUxXpemTHUviSDmi/RCNnKiRApcLlIsJMK0uU+N1cz NOp+8ub6enfd3O/Tt6F+q6gvrQSHraquxoMX0wnCPalvnvH1GPJ7t077qvvFjCtxUBd2crFdbbbq kz9YL6nRTpJFpwfHCT8uuGYnLU7ZEQ5UVNpZnLWysrLIDpRkQxx6wokBGhKFKQ0bXRCnf3nvq2hp ScrbcOyALcvJJPNOJhc5iNMXHbZayaQTwHMhrJusrQ9bY/lFQgH1WOHmJTC4mHKM2U5N26F5+EEj HwETmotUdMXpo5ZDwHiFcJnI/KkZWertw5v4dzWVSMRGbfvmTZZOuq5f/eNPLRhHlRezCXnDc37a 4AfNm1nWNc/H41yj9ap/rjDIoz0cvMhZTvBR7hi77n/4DngfIbBsCyFgFCl3JnegrxpUOQ3FQcMj STSg0EUDOB725y1h7yCs2CQ8ngxre0SKdYcnWkw3B+Kx9Tb5nhv7znyC56PYqXpF8zvFHDP9o3jD B+AIMtXPN9b2fD6lQbkCtw6KSTic1jd04u3eZqtx4FveUWXnKgdtz+cf24nFywnV9jyCiiXQJ/Fd YI5jrq/UMRV0c2IAtV14JF8NXD1r/mbchkGtw7jOKudqU3OTXbp0iZyWZ638UhUhOGLt+3/8fbt3 y1bbtesDjNPP2obFO6h5YnenAvUOuTbW7VECLQ+3oKKMuLNPEey3Tpr3zKJ4yyYrQTKqj8kEc+LI qntuQ5oNgzLGw1yNCRNrm/6zpBcnjtVYRV23y8uZkkWAmGGfpYYr5ZvPVu9YYxcunHcMnOAVPfG3 I0mS84KievXPX4ST7e3tbNqtlpJLvEY9MOF3/31612Z48UgpuVeHLXMJjCZeV+GR5I0mOXgsLv33 fXuLVZyqs1P7L1uSj7R+Cu+h3XXGguUO/VK2hS4OPB+golKquZKLx4nrlGvxdz9t4crskpIFwYQC zUNRnxVSZxCmL5yToTb/mrbLVtVRgVdmsD337HN4NctmDc9extClF/IP5HXaF+PmmD8RVCQp1cR7 68O2JouNNzwGT2mGQ1U56TPMzRCT1N3TZ51s7B9/tNuSCYheuH4LwbtxrklJRqrmqYZnGkbHsF9v mK8D96x/FvJMomPqz0TaplBFwcSCS8hAS8GaGCLdVbAGZTrEmtw4FQofQmMDwLUuW1BJHM3dMICo aSuWrLZOAoYH+9eaYJksERHe430LVlkxXv5phIUor6ywlvIa6yEPaR/J5RFNWwzSWXVHKuBupHlJ hPl58bsvOG/ui6Wl/EB8M5ilkkslFpa9mAVEHzDtSMUbWEW5cmW3equL1mQ0oZrySA25uvQLSwan ZPs3VZHt+CIcVzYOpJAVg3ij9bW2C8l8Hk5492fnkLUhmEPIGBGaogIPjbzXiT9LRTjSjoYAbYQT 9V57y8Tbb/tnedRGBXMIFt2jdeHknVlYz/DSwURv0DqSxC9gGhxSH/x9EZ4OkFawNSKd+H91/HIr eqjWpinAOgqT7d3hh2qae2/rZeL3sg4HwU85gTglw1g39BYO/czk0FLOl8jwUFufk2hrGP/G9n57 9czn9so/tdmL//ovHQMYjkmYImhcj05NvfKm6bQm7qrin1UuSsKjQ6jHfZICjoCpp06etD179lrp hQryzmaS+myhHfvygP32lddsAcbHq1esgQk4b724/4cTuuOq3fyqhu7AL/R1pBfbuBbEsdgETqbb dxLEkkbFQ+weX5yIvZdUmJMn8tZCK6LvyUtEJBytwKB71D7+stoaOiLIVkKYjNFwmKYOe+yxxyy/ IN9akFScP38OwOTIcDV8qkMEx725O7zfJWmRp3M4ji0huNI7B5KrH3XfNFfdbf12fBcBqJPzrWGk 02pqyvEYG7GitUVWtCbb7Y9tZFfpa+q17/3ZiziYZGBbjKcj+80kcCa0QP/GvimchmwwU9JT7GLl GVuxYJ0NEmm+l7AZgWzG06tHJlR3nY9iVEao62zpMYzeWy0rPss6+xqJkdZgm7duIBfr/Rj9p2Jj KebPs1+czPBM1wRVY78r5kVtjNi506ft1VdfskHG6cGnnrPNjzxuAwqMjIS0q4NA0qhI+7s7rQpp VXP1aWs8fcraiGO2Z8+ntmD9RvvTH/ylGzcx7jMVb/z8ozjTnTf7G21M0wxddkWBk/t7B8hMI/tV CDN9danhrtOHccg0iIy7HKdCCLidW3+GDTLMKlass27SuXUTmikQqezEoqrlJCTTGQ2YZN9hhHhJ XbYO04Ye27LlXnuMOHutBGduIzf5papqwg01kBmkw2X/iMImKHvJKlt9113ku26yV99+z0rKSlzI GNlvNpILXOnZ3GTAYCnO4+0qGlYfYW5Wl5yzRaWnkP60OsnfdO2jW7GVEdFWlI3XMXOhANhBeB2n wvC6NF3QtTltYP6GACSwl50T+2gi7Puv3jnvIEFmaJfFB/VbM2ZSOm7cqUUh0hS9FSoxJYgKmabi QqnxWfjtlg+4FzLS5zKHDAvXb2cBbwRvAJKEUWiUB+HtBGCKtgBC+3IN67NrKNDSOdclI7AZl1zz iEY4kTSGIXCGCvSu5BPaG5NxhPyT9Zn280Nn7Z23Xye71X1EnAji8C7aPUVbEy7Ncf148j89r5O6 f+C0wYcDXhhSCF2TFOKDne9j77fHogIS7e4lD1lKTDp2AXI0CLdTR47ZyS9KCOgZZhsXb0XUP0cw JnTgq/wIDsMAsjyD6EE8Kmwm404tYgL7JTq73YVNsLGhw9q6hywGJlTSE0Cx8vpO7A2jbcO2e6ya TaywkBhiIM8pGIc8GECFSxG0znidD35c03sQeOT/7lfx6l1419VF5oFUiLoamaYos8mpAxeQiITa D/78BxafTO7TIyQD/83vCEBda4vvyrNa3ks+L7MNCpeRTeYG4NFi0hiqau3tk4sHL/BxYyL5gH/0 735k/+1v/8a+PHSOHK6FSMfaMT1SnpDpYZtc51TfPcZP6YNaraW93i6RvzoMHWMLntW5i3PsEUwq 1m5Ygw1k4Ljdnzf3UwA9RQO6SyuSYXaMSGVFhf3s7/+bDddcsC3ZSfb+ay8heYqw/toqQvo0Wg9G /K311S714+rYUcsmfMGza9OcyuL9sw226/Ah6/v+D1yMxaAA2c3OMD36UQDo75aXaxvxS/8Uu66N 8CgKMxSdgCehJp3/ThI8m/mjH/1IQ5tqkPhy2Ei+WGWb95+yPmJAHnvoGWtKz7R+4vLpMDBesNkL QLo1SCaAUFS8TuxNu8L21A332Mmdr9lP/uGnBC7/oWVkZrsMOIuWFrMzaCPwsErwS9J3qqTE/uGX L1n7YLAlkcfcxSkEf/NTsi0I5vN2eaL7+0b8eIvFBGh56Rlbde4wkiMOU8B5vTLIWEtRGy5pxpg+ dGAS03y9Oqb8XdOp4KTRMAJO1DLlXV/JRc14PNlmkoI7rWE4CQbwOrv4VwKlt0T7sGkdCCMkibj1 CWUE+48hCEgfWawGoEMDjHE/f5K+hjJ/YTDzTX3xltYqVaUYQ/WRSbkdBX5zhJi+w40Ib9JQtIeD B7ep6em6pzXeQdiyjtEwnBLJGU80AMz3nUbJ8dAiVcAomhwfTkgx0kBK89KFaUQnEvVONJLJmJWU dZKda4C4wOPqr2tp3EQY5sR5iTZfNU58cdd470bVG0SKsWBOZ1J7vfXOG1aUvNrWL7wPQAkqq/gp IElBcoHl4imk4L2hhN8OwkV7CHWYfyOfCNwd/1njAd6OdiKNivcI9R0P820GMADP3pOna+y9z6qM Lc0iU8jugeSjnkj967Zut4aKFvvF//sP9s3nvmNPPv20deENqEC72si8Q8YVBNYnP/On3ySR60Oi MAjjJylXLwbjgyP92P6JyZq+6LzZjT1eSnaCU5klxqXa4488Qd7WUdt5+F1rq2+3A28eteKCtfbs M884JxOdzlxicBaqcH7qoiDK2B6xYrVo2Vqstq4BccOoHT6zB6/ldFueuwacmQm6qWv2XxWh0PO1 jWV2su44abyGCVnzDVu9dgNtjlgKsaKk3pb0SsGctVnKe/vKcc1f0/Tvgk6HcifN58snn3xipaWl 9vyKbFsaT/o9VJk/+7u/ts2xwbYhLdIlN0/ICbaG5HjblEuOW3Z7jYMcCbbmxdmuA83k0b1ky4qX sd4ZFQfP9O3fnl/omDo6YS710S+MGEKV1UIsPR+hj0Ijg8kdPewY6kkUcEpQhR9DSAvPHK6y5nMd SI/zLLMzypLJmtEBMzj64JPWhQNIKHg7XsToMW9BqHSHCGYeQLxMgaeicQxHVbz4iW/b8V/91PZ+ use+AV4OYn/lrRPRYRpVHbxL+/Kbf/6FtfsSSAP5MIyTgqmP1aWDlWjxbSpqVmxeSkerFWNvWHzx qNvsZ8P8+UG8JeyPJht1/kjHgAUlIm7xD7a/0a/wXfbNwayhEEwonK2zYL0DiyR5vTB6HXHBFqGw ESCZ7DgHkap1xQdbN1qYLgzFxQAK4/w2nk5VzMIbCii0JNJxBuMJHN3fDBPJ2lBfb8dc0M4wGrzR JoQ3yeT9DWXPuZ1jPEU/23uwEU5Mcl77pThv1XT3IjBQaCMYbIzLx/c+4NQ6l2f8+xe7rLI/yJoD wghPtRCtzw7SL7LGJa3gQHm9wZwTAyhq6eYG4AUA//kLxD25ynZ/9L5l5+S5jBMK/bKE4MN1pbXE myMzgwxxxybVnwc4DIBVn9LDuU3Nf8N8TAKAhRJzMKyDdE04Fgz4xHrcujKCMenoAPaASiHz/6ci BPDvLNP0O4AN567VOY55+mDvRTvyZSPhVR6wbz7/hC1cuND+7//6V/bw5kJO+S124uDHVlS82tpR KfpZFm2KOukIfRzO8S7mT05Fsi/t49Ahr8ZRF216xGKI0RaMFGUmuCQ6X373Yjv95QVSY/2aECn/ lqDZibZq9Sr77PBBO/T2CdK2Zdm/+rM/dSm1FCBZDI2cdrVuZypysBCzKOYpDDjuvvse+/GP/x+Y 1QHLSMpyzhkRpLi7kQOP+t8Pkawji8qp8s9szZZVZDB5xGV8gHUBLDHFXloyQHCMn0tnd12or+2R t+ky9ox1ZmambdzxsB2srrBPjpyzH23Ktsc7B+3egngrSIngcOct7lyqUVzKiQKLGGxOs4L77fwZ 1OArVjpPWJGlaTd11aXqvCqvBWxer6gRb0b1Klxz74xzBweRts5Wy8ARSWWYfoUKr2ZRlDWkuqSe 5O4d9tQTz7lwQkGobM/T608ullsnuXFDCOw6XdE8Ty6SQAeR/i1xxXo7dvSIPfq1rxGGJtg5GrXj pZwQH+cCPStsUwsha05fLLEVL/4FsdiQuN8Gx47J8Oq7NvMQ1k0GfS++/IUVVZTA/IlJEK7eGSWw C+FDPDJG5v724Nzs+j38/7H33kFyX9e95+lJPTnnQRgMcgYYQIAgxRxEgkGixCCJlkTJlu3187r8 vLVVr15tbe0frq2t2nL5vXWUtZIlURIlkZJIiknMESBAEDlnTM45dc/Mfr73179J6JnpnhmAoN9e oKe7f/373XDuueeeeyI2anpdigmxPX8l7+pCVZmDpC8VJrA3J8Ga8oNodxKsD5swt4z5o3FMNHsR g5Jqx0uuA0f6LZdc5FkDXdY70ACzSI4rPL6dqvhyDgQ0HO4WIxpEg9ePzQsd5bAeZfnNey9GWBcu XA0wEu7J3rUHqWgxsXcV5mXhkkpram61dkyJ2rHxTidcWT4wzkDiqnBGMkWpbu+31+rDdv1dd9v2 9ett48aN1lBXaz/69x/a0mXLic5BuJgIbZ5qAHExgF5ddJx/WsLy/qvDFf+XP/t3kqT3sWF+z3KI xabcsQ8SAPq//f1/s5rGM1ZWvJj7Sdcjw2OKkCKMG7MCQytNWW5WPiceorbP0Fn3cAx/RuB8i0ku vmgP6YpWbrezWx9A/Szi7dAxhhriuEV0gzRkw/1ABQRywYzjePxqu9VBiHmYkfA4DgOjcUKwTHez mLccgjo/eM862751mb1CkGmloFu0EATHw7Kn46J985HryciRbkc/PWFvvbDXThzfams3Xg8TxeJQ R7RAoBei0fo+wGI4e+4s3rsJlklcNjmUaEEIfRSoV/Ps/Y0OXZ2OSpcWWsW6Ynv+/3nNXnrlZfKn Xm9VS6rsu9/+rr3xxh+QqF3rUsJJFe3Zz/m1Rq/Tvyr4iVFM5AQvRuDWW28hwO7blmMl9C/BPj70 ll2z5ibyzOfBXE3JBvnVTXjXejvXcMoOnHvX7rznDpfVQyFwFCV+mLA3GrXPgEJfHJMlOMRbNAYd IGVnJYnYfcSSW4gH6tM//alTDWeh8nnqBlSY9F9Gy9GKD/8GJF4D9LuA3LSjy1uU3R31L31SbV/p or6KCINCrgwgVW5CtZ1OoHfFpfTVpbHAUveEQICWC5324H0P2a23fME5w40UFtmxrdvt7V7yhuKh qJhd8RbhbdHiKjvz6XvkvG10DiG/f/F5O3DsnG1ct9JuvWk7eXCLyLFdbyEcK8Qw0vl4m5m3+8X8 LW2otmuP4OzRdpE9ADp5JXbXOEag80oAyQs763RkLI4a536rQi0NhFOtN4wpC5+FKbHg3txbjr8G LeUeTHta8jl8Y+bTWkBMRiR/KvotWr+19JMAeZ4ccZiAMFrAxkzsvokp29iNT0B/I9LAPkzKsBEU /o4Sjvj7N+MT9GW4mzXbn0qKQA5ZiuqBVkUMzryjKhXKjrWLU3kaESiSFQUjC8c9mLoeeeglkXYR zYBsrjOIDqCXaPsAXvr18Fk1vV1Wlo4HPap0gaWWw4vMk775xOOWBX09hGf80z/5qaWR1vPLjz0B TcN2WYR8mhIXA6gtUJtQMJji0pCcv3DWfoqqQfr7p/7kz6ykfAGbpYthbpWVVXbj9u1kffjUmgYa LY/0RhmpWWyKdB5AdPe127mmY9bQ0GB3Xv+wleQsYPOaBy806obMWFpbHRJAiHhrjSXIeJ9goULI y1KEo4orRGBJeZN+notTT06xcMfGBbN1qtpG6kghtXYJ+h1spKbb0KhPhvAZhFvZur7Mdu0/ZG1I +RSuJYSkpbR8rRUVZtriigLbcKrenn35Lfvd6dO2nLzEys3rzpGcHTxigl0JG/QAKaHyKgpBchgV FskQthC9IiioH4IQ8yQWlXInTjXlUtGlod677oubbffe923Pvt322COP27ZtN+Kl/h1ojkLWeDH/ WKdT1jMGE++T+ihTS/hG1gpBgLNy7LEv3m8/+bu/swM4FNRg+J5KuITtG+526ufJz0/3XSFBztWc trWb1tqT3/gjlyZPavBBGuvp6oZ+EPogcshSPR68pqsx+m96TgykXjqyKVXcudMn7DjS0f9UlWV5 fO8b1i/RW5AESyFizhEf7A8nOiy4drtt2rLVhRgRmjhP5OhNX8Gr9N37P4H5kx3pxYsXrRc7msIF 0hygzga3pH6ZYrgT+ixGsqOl05YsWmJbtzJm5kcOHcoH/dGu3ZZZuRzvPhFwkCpKmW6vEyOaVlxq oYwC++Ddd+2LHLKPYDN7vosD0Ycf2/mai7Z+5Srbf+CAZZcQsgiJ5VzMDaJ0L+ZLw8ChhJSDN+99 J+LswWYU89NX6EZNqZCcvOH8JTwOh1l9uAoKXbPshH7DwMKdlbzQTbp69RU5eLRlE9sUZ6mQTozA cKaeigdwEbUYjvSKiZL4QcyHEd4Mkn86nIRmIdRLrMBuMjGFnLPI5Ry5WA/Z8w93klU6E7eWHPaS NIj4POJDAou7k33wfGuvVfQNWA5MX/dQgjVnkWoRLWnp4jIOnVmje48gk8gelokn/OK0KuhSNVK/ ViskfV0i9OPT861WcuNNpKVMd2v+h//vv1lhYYl950//AiaQkE7Q6ZlKXAygJjVIkL8UGqy+eMF+ 8dMfO+P4P/vz/8mK8FTrw4hRTJaYxFTyO37lK1+1xeSe3I3TR0PTKRskXlAykWLDwwm4MSfZxi0r 7fU3q62nn/yXuXDHM/U2lt+1cdN+48ptTv3RtmgtOThT6dc8zuTkfogJ6eYPUsZAST/TNhP6T67g 6vmunjsV1FTwYuHCzdnIr96xkWPnbeQrt1rgkZthAL3ZE5Q9KZw3Jn1v7+qzlrY+a+gcsn2Haqxy +TWWjx3gm28QJLkiw3ILyF0MIQ5gNF/66XH7hnXZT9vOkJ6qFEkhaadoE+iOljRwKwsE727tcwsU 2uE2WZYL8RkxjKU9Bd/NLiVGGhtR1JlnGMpAsnhVmVUsK7Z3n9tpP/v5z23t2vWWkZHumD8dnvrh 5rRxxTujsr0TL5ZC+zej/k1pumi/7Oy13soV1E1AZhanxhWP1HuIevrxJi0qXAkT5W2naHyRFiib B0R0njFPHuMuqDMAvBHPspGmJgv/0/9tfU1plr59LTlV5UE5Bl2hTJhnOrCXO9sashcbw7Zo5Rb7 Bgx1DifUMGNWnbKNnKo43NPPU98y1aNxXpe81FO/+JI/2U1WY87SQay+4oV55PiFUWNMLnCywgDN UNTlEES9r7Pftty0yp3KxQAqJuJzz/3GqjHWXrFpy7SHJaeKFJc8xYFKOL4Yx6RX3nnVUovLiKl6 n/34mWcsoWKFXUhItzMff4pzRbJV3nQnvXHs+wy9vjw/y3YtBZvcvM5mG0StddUWTRq2v9aGPaYY wKugCHZpiT22Neuc5QUKrWkk3WpDedYJxzSeDl4FXXVd0J4/CJ1zInQ+z7R0dT/KEOtFg5MmR5xJ D3gUm7BJ2HIPEh1EAaMzwl0wgTMzNLOGSaQP2kuG2ljr2s7FAM5jYdiWjgCsgFAuOpj14MgRwqu9 gEw9GTjxBVkn2g+c8MG1yx7CfbJOTMJhViZ2zfBeLXj/K9lBxzD5uHlm74H99otf/NwWVFbZE1/7 VszMn5qYmaq5jnh/6LvLjXru3Dn7wb99n4sB+5Pvfc/ZCElaIkNF7UvSbysmWBDpzS0332o3bf+C s1VpYgPphygoM4iyOGRmZNjhI0dtAKNnp2uaJ3jLs669bIm1lS910snLyvz58GF2hzux21CC5hxv c/d/+ly9ayFrhU5XdIvy0BEzD5/00TtDMFQ19V2WSeqaTIipammE8ftoF/mFcfqw9FKQ+Ba7h2Dg CvlyEInSg7eWOE8nDkLWi/PF4K/ftyAHifVbrrXf4wmVlhokoX2+U6eqIS0OpVmrrKx0Mf+UUzod PFLQZ6lcpXJWCJZz589aZyvGxXmo2/wdfrSnLDIxaDBgskFNRKR+/Z3r7eV/e8/ef/dtu/Pue5z6 WXYZ3DaZPo3WMt0HSQFDEOwA+UiHPtltm2B7TgPXwk332foV272FPo55mq4u/SbGqAcVQENXNbYe 3x1lHiVxF5Myu17quamLpA5iLLHzthwY9vuR4rX9U7J1k6Wlr6LEUlaUOzsWzQlnAmuHG22EAT/Q zudAlt368A678Y67OOxxoof5g/dDZUxln3FRD9yhAlz3UUN4U1NLSJXaOsuvyIX4I9EHnxXPNAHC hzZl2uJGxRx1NnfhsZpm+diUyh6vlzy6v33+RXv36Elb9kUcitJR8Ux1MgeOSdj/hAmvM4STXIKz nXaTO9q2pIA5y1azKYTt6Zf/YOtKCi2TmGBNZArZ9MR3iVPIIZx2hRS+6nr04Sv4QfBIBXdcjtcr 2O6smnIIMRHOs6pnXh8KWGmw03J5XSRMVm9HKvmOvewW89rMPFXm8D8OEIoMyEmkgKD/0xWlietJ yYYfIw/1IPl9L3dxAxET4z7Ma2sCTxIEZxHuvYMZSdbUGbJ2HGAXIKkPIqSSs5douY72jo/SOy8F 0dd3xZgtRdAm2iLV8Mobb8FpssN+/KMf2moyPX31iSdxCiQt61T0hbomlxnI2vjbOdGxSZ88fcp+ 9rOfI46sIbfoCjt67KhTyZWTpDgd2xZJPaT+CbMDIr3kIEtUcKrJy8tDclHIdzYLVHjd3aT2OX8e TzYIFqFBRLPms4jpC1xBbzdxCYr7NoRXUQA1ZAKp4uZ5SPMJninrciojkG3KvgtDYbYCT9xhVtdm gVULODIxx2ymss17+ZXjlpGFVxhi7QDeh2dqEHXnLbEHHt9hZWVevl4dDP7w+uvW1cqBYKjYahva sQUdtsOEDCmo2GgLYOjqCdEiI9kLF86T7zDVSZB8ewZJVVKDqZZR5kd79xhDf1Cqf+GiCmLS1VgH aaTyCewcYOFpAWpcfWQCqD/ZwuaUaxk5GMrCmOWgxl553WKH2zfcuN3ykFgJJ4W7WoSzKRpTMn1J RHrWN9Bvpz/ejRo8h3RpKahvlU869iKpct9AT8TeTwyM96zG5IrmZZ6LaiTNJ42xlgiHEiDVUPL9 D9mpvbvtRG+OZdVI4i/bQ/KuhlLsIhKoUFqhrbh5sz2M+UcF+ZnlECNvZMeYx3CAFzPpJmr+h+Og IziiIMBTG1VPBIjCqzZO1VL96prMA6THD2OrI3vmJOW3m2JB+JclT+zr6LdBvEorCFKs3JyS0u78 4AN75d33rPKeRwgwTk7eGRwyAgmsG9Row0gjHQMYZU5FQ/NXbkQdXG51hw5ad+Eiq1yzifym9Duy iUR57IpeElxcaA8fQFe09fgbS7gKTXdCMCEnQjgUJaKOTGrGcSiLvLnCtM9/0RjCLKtYBiPKLfXp FSvQh0BKDMRqlh3SfqLc8mU4y/QhpKhHtZu+fJkTOsjiU8yeij/POjgHmHdvIyKgO+ZsBfmFVlJS bD9+8y1bvW4NQd+/hRo5zZkD+c95tUz/NyYGUCdKVXry1En78Q++TyaACtvw0IP2z9//J9t/8FMn Hdh6wzZ74MEHrRgj5ESI0ADM1xDOEUGkgk6twfPtcKvV2MKcOXvWzp45a7UXqi1xIN0WLVkKAzAu JML0fb56fwVIIxxthrElSEgFgcQ9/EcsWowLsL/j5W3WUpOOWAa2offfUmUnSO32i98dQEaRaU99 78/shq3bnFpVDhUqUrUtqii3m+7ZYUfPn7ULJ08SDBx45S605f/1j7FjyLclBIFuOHTELYoUNlPH GERgKQ/gECenogIv6bgjDepTBE8V5iI/t9DNxRG8TzNyU7ALxNNPN3LPIIzqnucPWuHSLFtz00or WVyEui6ZM+aQtbW2OYbF3eoqjjQ6izc9LuYocMutlrjpGhvGG/jYyd22pGwFQTonjmm66uU8NRju t93H3rHlK5cTVqQCntsLAjrMoSMyCdNVMevfNAZNjfI4J3KAS/3P/6vlnSM7CuFtWptbLJHwHiPE nyooKbHVvJYsWYIjWLY7zcp5xmMASRPl+jlzN+IhXjPX5t3h1+lJ/UABd9n7q5O0HCqaOIxk5mTw CqJCIb0gMycnnWSdYv0KJjWoy26OIdD9Pf3W2dRrRUUlHB5y3fVzaEqeff73Vrx5u+UvWDwj8+dV D5yxEQ0TCzCJ9+iFvukQlF1g5dtv83pBR65keJfo/Rq7qj0gOABujF26qj858nEV9VBbRwdqkeoR 7OqIcJAZ7CWI9iBSQA7fV1E/Z9sVjSGDMDwz4YdsBaXRS0IiLkbwsrO/dEhOOAHt35exaNzaj8oz Uuw4NHQQOiRtlxMBRmmX5YS3MiyF9jg4xPPnz9mLL72AydI6+8aT3yTnsYQKEjrFhx0zMoAe8zdi Z08et5/86PtWghHyt576LlzqMDlcm+zo8SN4Atfab37zLBLB5XClJUiEODnTURWpWGTc2cK9b7/z tu3+6BMLdaH7x9ixNGOpVS5eRZDSoCO2Ucb9+bvEeId6YQB7UElmI96+DKLkqwIobO4TihYOqtSl a0tsWTLOQJ19dvBsgm1DEiRHDiGnvEqFFrLLq1q6zKqqqqyJUC5n33/bEtMzbeX2m/kt2Q7C/PUh eSkFl6TWFfPnM4DeJo5CADszFX3XopF34Xh+W/dn4g2Vi+pSWT+gIdiuMic4h2TlpJMtJNlaznbZ scGL1r6yzxbR7/bmTrvm+ussJ9ML06IRRg5jrq3Z/JGKNhFCno4E/FFsYv/+7//e9p3eaTes+IJb rCJp0xWNL0Se7FMXD2MT02H/5a/+q5UWEb+QeqWeVf8EAq2xy1UEabUlipWIlH/Zhs3YsiHthpFH 1I9uArjy0jyEYfLlmKJR6RnFIIwrwpYbDA/r3RGz6eHDTTEVSaj5P1oUCkjevq2oTptamiyvlLh8 OA9J3auiDBmOmI57ZvRhPugyU0D2kxAByPHUwxFDB5Jy7Hlk4xlC9fv7F1+0JuyYNm66HsFc7JiU hF3PIOkMZypSGc2APjNVcVl+11rMwBO6tJUYmA5Sl6WZ+a10PHLMb82zqk1Y34yNl9aenBoTgt2W ltJunf3srwke7ZtVxfPxEMgvRmwuplWEA8UTljUmFJ6OdEFTgoSJSSZqyGVn/sbBRr4sQl23/JmM +aFC4xpwFfMHvBOLMNM+oCcVYUSH0g6cq86dO+vy/u7Y8SWC1Sc5e/ZIb8c1MvPHaRlAj4kbsVPH DtlPfvgDl1bqm9/5YzbWLAAzYk99+ymkeadxCLnoTvqrV69C6qIMDt5UpcAQyOtXeVGffe7Xtnfn frtm6a22cPmSCKEVFLyT9sxd/RzdAbYMyZsog61Potv/QYqYlUEI/4mzzfbBiU7bfMPdmAHILk+2 VHjpRiRJSqWqBaYwL0WFxVb08GNOSqyQQL/EoP25Z5+xazZusJVrNo4yf2LoVL/es/GK0sstGi1O Xo6GaCHpS6RIcli1tMoa8TbuUlq3lEELkiYuiP3i1vs3237iEq5RLlQ2+4OvniajRdjuuu9GPIhl DA7jMlaVX2V87zBMA2KSoHCp9G316nX20Jcetn/57/9sG5dcA0HH42syIz2pBRn9Hzq7y/af2WlP fvsJW1K5BFjKng7magJPMdfOTmp40lfFEwz3k5+UE11KBMZuz4Tx0xDC2G2qB4K/TEDk6evBT2s8 jqK6+S/1oU7iLhCuqzmOOsbdqtalgVBffdyQjWhbW6u1EOg5BLNWUIFaXg4AGsg4/BlXzaUfqbAf Z4+Oxl4ODFlWjLo7j1h8wlG9lN1m7/HjVr71LswPgNEUOVIvrdgNf1RrEu33q/2aYJ7MPrCgsZ7N Lc75/ywGRxeHg1dXyjUt7Q6y5oShHU7mx+ecxGZrHcH+S1qFOayJOYOYZSKp3DB7O0t01iWWR3HD wgmk1433ijGAkTUsLUsLQZVT2KdyIOC+JnPWA9aDkfUguj/AvlhPPNVgZo4F3Z4zdc06jMp9rh26 pYgCCxcssh0PfAlypb1VtFKQir9MyQC6wUIMTxw9ZD/90Q/IYlBoj33tm6hHcjBGJ0YP6r5kjBfX rFlra3mpSMXn7P8g/m6D19rn9dFOguu+/4ndsRkVscK9gDweMZ5Nl11TV/cfxjzSk2hDkgJmEWVc QPgPXhzzhxh7/9F6e+X9Wqsi1t3d996PRA9pHcguBkKzLceCPtmHwhgngrTCE3hE91nI/cZbb6BG K7Q777rFLtYQEDqyISs8h1THGdgHqkjKJAmOfhcj6V2TrZk8zQlTRDJsHT7kIr940SLr6elxgaM7 CdHRn4y3cVmeVW4qs90ffGR/9Rd/bTcFbnaq4XUb17sNXAwr6DzHAhPE4uzDvEE2YZIMbVi7gdRz eVbTdN6WlsF8TlOEN2KC9h/72NZuWW53332vq0MgUWo3LzSEx7O4lRSB1TRVzvonYXA/saskc0zH gFmzKUmuIK8MKWpfzJp7nwO+O4YBZilANiGMii3AS2p0D3t4i7dAcKWFUJGapQ2mr7mZAOKo1DOy 0ywnGwei9Ajz590W018R3B68zTOzMq2ycskESbWk1mfPnLFeDLKXLF7qDsUxVRq5aai/1xIwCv88 l3zCPCXFwfR+pmMV/ZFT21VUBtEaDLCeIvyCW1spqT2W19dvDQSH+ax2FLpkxRfPWTbBvRsWLbVO NBvyVI23yCKkJ4NIDW16NvpoxPClIP0Lslbnm/lzB7VIpz3aNTaGgJxZITmHGvrs7YswaLT/2IYi vHclgYt3pJHh8ZyYepdT3AlDhq2TBBKhYDr26gsd/ZBtr+6ZXLQPyJdC5kl1BHoWzVmwuBJbe3gx IgzMpURlAKUuUeiDE0cO2s+e/ncrX1BhT3z9W5aTX8TGG3KN5pBPMkhAWC+zh9cFdV7OH+x5cLSe hEe5Wd/GUHFl6UYryVvEJn75bP1GYATciQSu+LMu2ouHWmTQzUaZIU+n6Ej+WfdzvtqXk8V7H120 tz9usRtuf9juvusud6rxmD9PWuVDQIsZ/whOssAGJgv/JxewQk5ET2LPsGTRYlS3OXah+g/uZKPF 2g5D0EcuUal1xfxV19RYTx8RPMUeRBhAJ33mXuFAQV6hFZIWTRJIFT0n5lHu861EWG841AmB7XXi 9P3799u3v/1td4BR7mFnt8ZKn7MVCP3QmKX9U50sKytCrX3/jh324q9fxq4nx8qLFjsPWdfJSX8k 4UxEepQk8e5WAABAAElEQVQGkVhG+BgFfZb0zx2yRInHF9q6nEXVq0W9+4ynxyD7v8xD65o7dEJJ jY2WhL1xYn6+hauWIk4ayyQUTyvqr7+BOhzigKGUdMls9vkcADJywTxNzmwYZ54Jw1BmZ2c5HBPe CDhqT59bYIDSC4odIzeMOjjWMoxtaxgGMJidH+sjV9V9QstMDmprzx1BxYc3c2T9XVWdHN8ZN2cc YMA7gm3wi/D5sy2iE21QxDa4kIRRDRIHGTJNpaW1Ey6LQ/BcRG+zHN4IHUsE57e88msrP3HYdt// uO29/T5qi/+kLDzpw7lqiFBLScTZnEzO1EUdJ5Mxf2ETZVribyPaMEUHNMeKnaqQVSJqKeCoBBWi A2K2lFSgtr3PXjjTbe35i6z52D77imHzrme1zuMorjWa6aOtQXgjYmVbjwYbSLYc/CXyEawlEyVB zJ9QbzLrov7ItrcFU6naugbuz7OSomL2BWIHOm7U6098vRobwCUMoMf8he3Qvk/sV888bUuqltlX Hv0a4TQwqo88J7FjSD1lQOr3mDgaiQf3CDedsSKfZR/Y1tphG1beRod55jIUb2LYOLraMYZE5ciG 6URL9Mwvzl7G/zKXd39HmQkRhCvQ/XAT3qy0NzLPMYXmMoT5flbS4sa2Xnv5vfP2yDf+k91IAFwh hhgV2YE5T9IpGpWaUMygCF060p7bb7vNwauRAOE+vulRSfpSsI3SXMuJo40TaG5ZNupab+G6lQyg hb/9vQNW21SL+nWQxVKCyhfj2kjJQl2XRqiN5QTM7UAatKJ8jW3atMkxle4ERl/kvKBsHvNRRFL0 EiwkiVJcvYcUwPfoYdt16B17+NY/Yq144nuHJzQ6hqtcYbxpaXh39bJJRXBOMBtfHErqYR83x/84 n5/VHWewM6kD89WGqgX+ATymR2B0R6Q+F80QQZllk4K5iswLOgg6rklQDuhkQhXFY5fn1TL2V8RX 0t1EPPJcGdc/HUTCHFbSlWM21o7TT/dcT5clQb8SHNM7rtKxpq/KT9rT1FvZ/i0nWPmSmqNIUSLA vyp7HOmUgzs0ZIBVyjnjaigDiMfqwa2whAcTOkROaOskQ0aZ9bNzj/KGE+65jF+YZDkgJGFCEZCm hXXqiLXozkz74YRuSa1LSKyOQZI0TL9C+pMyIAmJZAZhXSha8xyXRB8CrHq0SefQHvVBd1nGVgiQ r0WqFsSWTqksL3YP2Ht456YSRm5xYNBuW1VkZTgJKsxZzEWoz2uABjrZAAcInD9ILKkAQgg5iWWr PbRCotk+XwRIJhQxf5L8tcL81ZHdJzc338pKyyBhwgrdPOmBCU/H9mUCA+iYPwCwnzAPP//pj8nd uckeeuRRIlHnuc3HY7S8ip1B4mgXNNqxInxwV9jsFPdPgk2FU/A3sLE75/5JqhhJklLqz1rZ3hex LM2x+m2P2gBc9SBtJxNAkVvg8InrFReSTtE3x8QCeFU6UwEIjglsxOOzUFJAig+quc+dV99n/Fc0 Xird3754iPyDm23LddczaI/5k5pyxjXD82K2lDUDk1EkZZ7cbRApnxgyB2Xe85EGJSjGEEUx5XA1 t1TyzEazy8gkyLjME9obWskV3GfFBSWO6VN4GBXhQRku9Ndde41j/HTNncB4F7umMelAKOLArbMv kbmWJE9MrtS5sgVMgmm484677R8O/aMdPrvHVizaQDtYeNCgDk5JSP3UrNZjR0+TtfU32eKVC901 9WcuXZrtYNxQIuOJm97H3CgjA/ChCsa6uNKGUHGMwPRH1YvEUKf6qSK61UXcyTZSD+YXYaenRQgg dX22sBRP6tWt2fWK3tWk6hUee8G6I52I3BP1Td1hww91dzD+JEvCq3puiBe1lctyUSp7OQOkstCD A722Bnvwlef3WRIM91Uv/fMhAsM13B8mFdjVwAFymA4HrQZkmsw/y8QiKaUPZzsYL4JDz3ph+OOO 8112uWGYlo/vf9Rym+qsesU6L5NKHERSLFSQP0WdxIhox0ZeRHaaJaI4gH0pGYS/wQ5voJVbVUN8 xVUPnvYgXX+LIO+HST2XsnCJLVy2AkHWkO185w8WJO/3srRsO0Cmpr1kIsnEhGnrdVvtxX/5O3t4 DUyo+hljoSnndNiJl3Mdga77cXItJ+pFBgKORIQPovGqzdUpuu8+T6zcZ/6aGxtctrQitFnFOOBK 2zUmIOCZCOz0FnsPx9oaZQC12Si+2v69H9uvfv60rVq52r781cdJTZLLRjgGdEfuaGmM7I1Vpk86 cSezOYtBEmEoJnaYsoK0tDVYXlYBg54n0QptSXIySHaEky0nLX/P87bu8Pt0INUa191qp0nv00qe 2cwc1NbYLq2oWE3AVDYU/18UpNXETVn0I/BJbKzjHeJGDC4GNjOh5jEcmFAHYwOWzeQJNpEybXv+ TVf5u2KWHTpSa8dO99p/+d++6tKvaeMLwfyJ6Ym1uGwWOigID2Hwurv7wRWAxzFXEPOYNw92UgVL zeYWUpR51KUU3OvzSeWlwLwXay+QhpAQH4QnKcgvcF2S1Zp/IPDf9YO8QCXTSWLBKwuIY9vHpsw9 G98fGA33PJJL6ksSo4u66ZpNm+2b333Snv3Zc+CEt45dWjcCRy8je012Rp56Y0cv7MNWLWgb128U xXCMqqd6HdcL1a9BR4HFuLvm9NENwTWhT1oo7sqc6oz2sCM12I+Ey8rBJcjTHJoR+klKonWmuJEp qNB7OomliDNLXgmObGkAfrb1Yyek/skOVdBQG3p3hS/p4FtrN4l/dWDUjwzMc4jw7vI3dzUvSWc/ HrOKm5mK6YM7eUSqulretGUpDEnyuBOdRpLABiqHgLLWBqtoOmdVNRcsJUTw86tB9asOjp8YD/QT QSr8QBWZAL24Goqkf9UweqJPl4oYpAbuR+vBhjIgNfDUPfbReppbpn54hl9qq1Zb7dLVIK5oWxxE nnrVn1Q2hoKmAdTJ0OBLBxm19RAx7kKhZGwCYzen8CuScr8PolnDJjNcXml33v+grV61ChpLkgDW 8PPpqfbSs7+wxTiyteVk201ffZLc8Nvs4OHD7N29VppD/MVJtNVDKw+63g6lsXnz1sFh4nzLoB0c xH45t8gqKyrQbhHEmzqkdfCFDZojp83xJyvSYR0gFSy+ubnRGnCkKiT8lsJLuQgFE+6l/Qnf/RHH /u4YQF/yt/fjD+3ZX/2CTAOb7YGHH3EOH+OZP1etj1H++7i2dElx/5KgbjLG74bQ5mTn2rr16+zA rk+tvJQAqSQ81obrwXP2vZfkT/k6j184SJT912wDi3j1wmUElc6zNjbYPaffQCK12ELprXb45H5U 0yFbVr7e0mlfkiQZavtFAFfxJU5CGH9S/XvE0Cagnkk8shepHiqqzVtseMFyZjAi2Ru9McoHqpf0 ergfkTMMoGsNxA+kMH5flBDlsc/DJUngPth52lZdf7OVVC6FN8ZZA6yW00c8RZigcCHDIn48q+DM wu4wBBGejGveRqqpEk7qcKFUbongW1Qs4ncF8M0vzSHYOLlre5Xm6yK4yTWYwIbmOssiFFFGBgvT L1QuRxPZg4ixTVXdEClPJunfFMe7ple3uz/eWvUlgXJUuRspYAIUcPee3fQ1yXIgErt2HrDWUItd t/xmsu6k2N6TH9oXv3g3fc5zkk8xxdocLilqI9LOJb/N44XL3wRjAwfcEKMMM66h6HlVBS4EHQNI rCwbtPRcTuESN0epX0Rca1/SFp8uRGtT6Bkk649iUsr5TfjiFz23CMPu6sMnrauOQ2hJGRtdoiXD 3Kd34Y2OrWsfzN4QGopwd6d1Q+hDtWctd+ONHGqUMzcGmuI3dgXedQ5L5/CyquaMlTa1odqVyQLr EhqfMUgweNZjVlerZWFfKzsxSWs+0+KkEKxh8fepvBO4XvuN9rmoBTOSgLIcRMGHqPdfpovSgnSg 7myhH5Et6ZKWdD0xBmmUP1INyf98SWWzuCC6K0o9G1jpySSezyHaQjIq91iZP+FaMoxf0qyER2hR sCOsQ3iTX7XEHn/scRerWEIKDzYjdit0uJ3DGuTeHth2g5UuW+ny7u567SVbkjrMwRFEAuY+2DUH SvUp6aHAwfHBzZecWxu6UB/XDdhFK7AcwuJJ0ySNjtu/uFfbop5xYIwCf5/5a2pqsCZsoSX1K4D5 k0PjdDDXWGZTktRgiBPbp7t32m9+/YytX7fBHn7kMUvLyI660YhAev8vRatkEFjMn8SUilPz1ptv wYQts7vuvtuOE9tt35n3be3CraRKIjev7uPfJYxWDKNQ/d09nXbo3Md2suEAp6FBmLHr7OCa2y0n TfYRnPRxPnkAW6sVK1bYa6++au/v3GU9Nb2WS/aHNPLuZQXzLYMYXTKyT4Ep1KT2kXi6UwwdLvep nAyk5h4tzJiYzuEU8p8K2o66xAl2zTrRHL2ntJHDyIgJnKKoT59FcRvfVBg6vkP0Lwxzda622558 8AbHmKHJglGZFlfH1xDlcwQe42Dv27zptCKYFKAObm5psr5unEJI9TblatIYuF/2XkoV14fXZj+4 kkRw3492fwD0h+zadTDyzIg28E4cTXZ9vMtWYh+4ePFit2jdnjH1FEXpf7RLmkivEqm7fQwQObjl lltsM6po4ZbiJW7ZsoXgwc/aXmIFpoJjQ5wcbsCmUnOi4QyKEdagxhe+al26tTn++nx/dgipccwZ IFP2zOHepOFNeXOMP3iw02rDhoqsMkkQ9ATy201G8URwOUFSApxE+GSJHCCmKjosZhBPsqW20zph AnNd8GcPLtKkrFq9xvDltX2737HijTdYSn6xLebwuGbvLju1cLF9VFFJrL9WS+xowFyB4NMcKhs+ ec8Stt+FFUuu23CmavtKX/fwKmBlSCMW1Z0jKK/PoHIAcyYbUHHw96qQ+on5y8M0hJiOQteANk63 PmaA2uVD6RkaHvezO/jAWNPhYZ0wovRJlzIhIh36fVLRFV1OJmtPWoRZCjN8XIom3Xnlv7q+0bk0 TsCZigfmaHNsC113pYZ7sPqRsdfYM+4TfyavY390wtuu4ZDVsCFlcwirWlLlpGkhpGth9mHhh+K8 Z5P16YnHv+YOhSEk+rt377H3Xv6tBc8fsIdWFnHAgzHvC1ktsT6llcmFLtRhJ1gHcMPgfRbjSuIQ BF9rpxD6BxZusC/d/4hzMKyrrXX7iMbv9jF9mKKITukw2YTat5Hg9LJfL0SDKvO5Ue5zwrNUNgaO Cb/E+iVJhse7P3zPfkucvuuv32L3P/QlS52C+XOVagD+a1wrmoQEWGgNQoA9fOiQ/eu//avdcdsd 9rd/+7d4dz5pT//857br9Hu2JLeSTThIKtlsy0UtPF4FN67KqB+1Ufb0dhNj613LXJBi11dtsYOf nLStq27H2LLbTraeIt5chzO0zGVilZXgQRjBTZs32YlTp+zU8bPW0lFrtY3nEEGzEbDp5qYUWHZq pp3q67TDHahiGMw1eOFVpmSOrUEmeAhpUcK6zfCHGKgj2iW4V9Q+TntxdMIgmgrtDUJFLfwUUHqi 0fuj3jW/F9UmNQon3EY8Q+1yaKhuIkl3ciYM0yL3nDZZ30t0hsdj/xncEsqpc8IVBQ5P4RDh7AVd h6evSmL3juYe60etnF7Gc4xv+cJVLrRRpGYn9ftkzyf2g3//vt120+32zW8/5SKzpyCxRfgRff1N 36z71fV7DIvcNTnFyI4jCSmUYCjmQUX3XscaTMdj+V/+8V+srr3L7rvvi7Ye9a+cGLTGvMwf7vZJ f7yWJl2c56+04RjzGIA+l5Y1UMr4VvR5fIl1tDpgqjqpa4sKS1x4lqEwBtgZqFrHzYs2zjRiRaZj MtBTQO7V/BwXNHx8mxM+Cw8JH5OChKkBhyV5mftaBUkXMpEuP/mNb1jaM7+wD3e+gRMdhuQfvWHL D31iiavXW+PdDyBpWGxlxZusbFGlOzX9wz/+g516/QXb+JVvsYpmQVsmdHD+voge9kHb9y/faJ2Z ebb+1CeognuBHgeUcZqU+WtxFjUJIYQk+SmWQDaX0aLren0OirQe2fQ1A5FrK5/FCE4uuqL5GJH4 LFGHwUjhuQSiK2cFui07udUyk+FEeD7EfbW9i6xXNoPUeWmNfgWX9132z2loUzKJqxfs5sgtJmFy 4ZKYNvfLpN8HyK8tj2AFhHaFmySRg4wSSUJrhS+ynY48pzr6kdDVoNbNIU1tRcUCJwGWlK4fFe0Q fERQh4MIRJIQELTX19j7b7xpH3/0pm1N6rJtGwoI1TJin9TBV7SH7cJILnvHoOVweMxIK7VUQjz1 BbOtv7kak6eQJecU2Db4jGs2bLBsMlG9/c470GtgzqHEndtdx6P/8Zm/xvo6PH6brFSSP+z+ZOYW y+aj8QKBuEtSK6ERXnj+N27j2fHlr1gqTNl03nGOoLrGLm1OkyFqK/XJ6rXr7PHHH7dVK1bS/xG3 if0xqo8/vPGGNdWcs9bGVhvpRw127ZedFM57zqtdTJ6+q+iKXwQk5UP99OR7FsgP2Xf/5M/t+NHj tuvDPXbk4j68elott4icrmWVdv/Se20hOTmVmUAcdNWSpVZVWWXdN/a5wNSKB3b+5EU7W3vaWhG3 dg3W2UXFNqxcYwcPHbSLoVb748VpqDhwXlE/gHCIzTohr5gTlqQH7OJzLVQ8QiygqEXGS5+BWcpw T58ZkrLEPJhfifOmKVK/1jRzvswsYkEop65OrxAiYOVL7aZ5fIqfhMoqY/Oub7qqta135dUd6O8j BeE4Bl03TVGET1rgkvzIflBBpCXprlhQ4VS+kijLSeCtd96yZdcvsU8OHbDrDx22a8kKorAkEir4 4v8pmpj+shuKej42JqVGC0NcpInULyr6HOLfUnD1e3/+py7o5/JlmBlE1sIgnYg6I1Trr0u/Lq/G ef4baWeea51QnTdUbxtwDj4RkPlzr5vdJQeI8dRhQjWjXyKPO61EKt7gqicjT7EFJxcIdQ9xDpEq j3DASCr01DqT7xr/PRFJTAn40YaqZoA81xnZOY7Wab6k8inGnu/Rrz5mxQvet94L52wRakZ5/pVt 2WZ373jAgmlBt4H1EqPyImGN0rA/ChAnwlNOjW/ps//M/m3nCousIzPHSjCfWNB4GnOWy4ptcQ96 OFNxV2XBS7l0gr3rV/Vf8J4sHzJRirBBl/RWw0ogdlbyCI4g7BGBYS8Qu2TWmUmtVphWT7QE7FKV aoObtYUUh9KsMVRqA1g3y7zpShT1U2tNKzSFzSANm6CcPoJZYxuXyHd3jhzXEe3tw1wPI11WXFEx udKUeHQXkyJS4g1j358RyaGuentgOBLY3/M6u5wzyRBZnxLYw/Ucq9ea+gYsDM9RUQbz53WGgzQZ gGDW0hH8KKi9zAJ6iK149sRJ+/TlZ60aKf0XKzNsc0m+7antswNd5LjPhBlbv9Ye2rbdujua6PWQ La1cxf6DlhSnrXAf4Y4AdyrrOZiOAxdM5gCM51CIuLQaR1SiPTZ4jV2ZsprxL2htaSHhRhmSymKn lfJp/9jdEz+JXmpGBe/ZlCQZMW8hj+99Ox7iNMuGOhOr6rcyCY8EX9l9JfFCUWpLq6rsL//iLz0s 4JkhJkvq4EUE5e0gRtbuTz62H/3waewEu1AJwzzwu5Ici+MNMckBFoECBY8vyol6tvqoNQycs//9 z/8PKy0tJ9ZcKsnXcY3O67eH7ngARnMDCyDFSXQEd8VfUzoqTbQYEzEqGRnpVl5WZqtWraZfQzgc dFsDbtYBGEXF2Pnhj39kpz7aY5+AjNewkBLYrKtxNhnEGylpIGT5IEAREkyHxJqBOZW5Pj+nxic+ zCQmsmgCXZzu80HkGYoYftlHBIBhM4hbkVruYKi4fvIMni3TJFyaXNwC5qKg1UnwS4T4LrXbTAvE q2fEsgoInsou1kRWkIICpM780yatxScG8NDBQ3ax4azd/5V77dX6I/b+e+8THmYjUm0YR8YHrzb7 VRZlPOqX4COVsF+x7OsJrekIk0wX9Jj6KANkERgyjk1Tpmhkmieuxp+0TuXBnYTk1fEXUw2Lk0aY vNs+7KYai2DsDE2AYXISdIH51Nz7T/rVC76NEPPkYAYZYxJtRp8AaEViS7fl1LRY+iABax3dpDba UZsiC5IEZmem2wP3ftEGT56wgVdfsn4ClB8khNHet96wnjakjRB+SaQ7UFOllC62lTfiWUkFPH7V Fa3zTjzsz5UvsAVNp6+a/ok55VRuCdmKCsCecTUCbyZouT6PmPxcCYHu8DP6I4SFymy0sqEuftYi yIWpGSLgPVK/9A5omdIwgvGSEEZKdlYDsfZ6rLOn2FqHiK3JGvPx3r9nvt79tcXyJRA4LxZWLirf rG7odR9aD9n+TWpcB3QxfrUt56y9v47YgDoEiTBSCZuM7MIFnkE+d7NW1AbL1UKpKZYRSLNc8nBL steCKVsaUj0JaFS6iFkoyf9oekcqkZ15GkxiEJtrLVJlifoEs5/dr/zWqkIN9tSmIisBj9481Wav dhfY1ltvt6UV8ArXy3QNBpo+qHa4glFeKaiQTbQp7VQYTY1SIQ7AJ/QTbkaUZtJwXd/8P9p/9EwD 0kcFei7DWzifeMve4Vejnr5MV/f0T3q/Jsm9+L77I8yfA/MMj03ToiZFnpOyp5VmQEycirhgvZza CyCWlJTawopFTv11uvEwKlWAx2mmMKMUIp2E6quaKNeFloXnT2nuQmqIAIK3nsFuy0QVW0QQxUGM qjMJxPo3f/032PWlE1vHC58Av+cYPy+gL2uEjgXEBEIptMGoV4mctHw7xBxO7r4aTkvv4R0P2q8R E7988gi2Fl2I0xPst/Vttjx/BcKxXiscbLCvF+PZAxM4rIEytv84hQmOLKCZxqRAmlULc21h2hn7 3a9+bvc+8DCp15YCW05DrK8+CMBsQDP5GR+66pZE6q1tbZgpcFhgXhRZPZYioiH8E+lQkHOd0rT4 lGGko73DXn3tVStdBc7lp1vpghw7BkMo1V4FHlzCF/YXp5Sb3LcZ2/Y7P+ON4Cz3DnBCVfy0hAQS PkEYRXCk9nVq4+nqiKOd6aqZ9rfL3IZgmwzXlwFhHw9nEVYxSc5Bh/WmgNge4x5Z29N22qMeqkMH vzQ890PYgaZFODxhj/L+dhH3axhb4PTlFdbUVGPp/CDyFXXIbEjyJA4hMUSOYGmoi2VKIhwTjork uyUEA9jaRQ5X2qxHSrEHSUPJ8nX2MdmQ6oYwYygusmGkBjIlKS8swzkl3417BNy8GgtDQwuSaB2o uoYnHc6vTH/VgygFqUMgF3MeEZ2oExblmavkUhhcGQA3JSXqH0mxGtb6EF8kwYpeAkiOuy040u3w bGSkBRohXJVdpif7uuQ5uLEMmMO0JGyg21OIJJjNLfMLKNUWhBYnaZ8FfVNhSrNh+lJh+JJh/JQt RIx6NOZvCObvdOMhO1W/zxYsrMAmXwkUUOVDC6CEjoETLxHkYcQwMHEJlsYvspVNwYgvEQc5iIN1 EeezlVBEQQ4Bgt5IVoYL/i+4+ONNldkNquJ+tEjnz1+013//grXvf99uI8XyDUvKcFJNsEbs+35f 3W+3fv0h6EIzTqTHbd2WG92BzuNjoNWonaOtUtkLKouINI+iOdMVj/kLk92jxtmfS02dR2Docd2d 7vHR36ZvZfS2qB9gkDGQT/NOxVHvmHTRQ8voyKmrspfS/prMhMsmQcgpDl74pqwYWqMBbshOz7fF GEJ3JzSSCmUBG3HILpDwfhAv0gT8LNqxxWutabWHtj/pVMQCljbDfBjD02f3AzTFx2m05cuqrKy8 zG3qCswqfkCBfAV7baj8d0Xvrh+SooCJiSw0MQEjIyApEgc654i2pA6VS5bYU9/5FurqN23vB2+6 HKinOwjomIz4t7vHCs6ftE4MoocqV1om0f79NlxD/wP9ETOWlZ5kj963wp5/54Q988sf23ee+gvS rOG1hLSAqZbPy9gk8HmGNeGgp0emK+53cEr5FMdXP90zmqRBcVE80EdgzdCBA9YC83eAuGV79uy2 utaLtu2OjezFA7bm2kJ7Yd9he+fdd+3RRx8F/3DQgHEUQyv0iauMDiY2LJH9pIiIiKgOLG79OAwb rejS5vWT4zgu/Wk+r0jFL9XM5SoKBg5Pz1A8Y+gB5kexs6SlkGqku6Pd0lDfL4BQusK4tUWMIViU ntFd12PdS70Kqt3X02v9QVI08oOkdP0wcsP9AfJrLnRplppam8gL3Y/dHnZTk8ar9gYRxbbVdlhq IgfA5cuxOcOekPhe/r0SQqktScV/8cprtnHNamuuvmi/rVhm1z7wuA1jD1gqKQzMrNK+DeIJHGQz cweTKEO4Gi6JudVBKMjGPtPGNv/91eQxWRIraTLFtatwOSEFxocwSaTVccyFbvu8FEn2q4cSrYE4 UPKkHkCdi8bRrfvpxyAE8/HaywzMU9M+MhRGEhYIWVoyksBBbI5xdJy/Ar2issIOJH14QiSwCaeg Mkkkw4dfHAtAn8cXL4zbgJ2oQfvSecR2PPQgksw0q8VxQva0bm1PesZ/Xpe92tkHECjhzWrl+d2Y 8sAYs5cnw8gV4VylVKD85JamUlfK6aMTT/w9uz+x91970TKajtuTK/NsUWGGw2st96M4duWVVdlm bPl++YufkYLzbjQHklLCX7AByBRHc+ftPn6P/Hcag7cQK+4myb886V13KGJGPandOqBrCxYuRKXs 2YJHBjbpiSm+anBzKNqj4y5SpU1V/O44lZnDMUARgYXMEjQ4SWJKy4uxc/oTVC6Jlks+QUlyFKaj va0d9fFSO3hwv/3gX38kCTCBLyXSJnFyywU7Vr3Pbty+3T7df8Ce+fnP7H/5m/9sBcTJEWeuiZGa TM1Fmry0m66DMJOaANQvYdI0DRN6QWMSEgcR9STSlkKFfOXLX7a1q1fb62+8gWVWtuWQPiql/oLd fZpz28kztpfFu4bULEWwOj5NurTBz9cVD27+LM7cd0lPCom3941Hr7X//uNd9uZbr9sTT+BRJVE8 m+sIzIwWv1+cAJ3vDif8i1He1Y+JRUw9ywaEL0SFe6H2PBk/QtiswrzPVJmrCAPrggwbCPTa8Jmz 1v/GK3Zo1Up7KWXICkoy7YYH1lt+iWfkm11QZMUrN5GX+C1bvXqVrVu3nvEkYk/jEYCYmot03hEx 91lAuHRUkdsmvQk/vQPM2POTbpn8NZ5OTX42xu/xjCDGKifcJmIkIi2K3d7ehp1nvyVjqqG0fwmD nTZEqIbBSDYYPaj1qnNcrEMX4yLtQz2G1n3YIuk5mRZkEH6nsLyIwwwaBCot4lBX10zOTbx8IRMT C7+HUGmFCfK6YHWlkzBITa/DiOt75G6ZFSjywfNP/8Tyv/UtL5sLznV9haVIe5SzGqkI7YcUUopn tWmxrUxs6yr5JueEVE72mdhwZfEqJQiwJOnM1pXpIYBKzEJinwrAJGHgvyvsC8lkWFJ4kBG8twOi BZdMWOTez/hNXR6PSmIgLsKUHYf56wfp9E8IIZyOr8zwBI0O0057d4kTvIyECYPG/jaeJsfX3sS7 NS6t22zwIr950FL6hcM0yv/p2pBkT0H6D5/ZY7U9p+1rTz5uN3/hVvvg/fdHGxCLNVUlHgoICz2Y CRulGcwk05NPEBzMgbN3LzSVddZYV23vvvm67XvrVbs2c9Bu31hK5JAkdxBUw5ADO4W374JVCzEH K7RvfuspF4LLFy71sZ9RjduHRjs6+QN1eI16LV/6M7yHVN61SP4wh9PBM5vUug5ok2+e6buI2BxK 3AygmtNGHFvx7hNQVfSspHPaxJOJoVVZtdi7DjEU5FevWuPeBzDUP3L0iFUWrSTWchpGm/0wf+ft 4NldtmxTpXPu+NWvfu3y4im3qtRDggP8nCNLai6WHqofXgfoGx9FW2TspVOCzGUVD249m385Eoe3 fv+u/fqFZ2ywpdbWEqk/kwb34GFciz3PgziGpFOBHp+v8ploWOj8CIxbmJfiNcVaFI9PNhUP3LHC vv/sB7YVY9mqqkrn5SopsD8bWoqqFiGCB2u1F6URXfOnRj+LCRqPcvkwgF3YbXY2dFjKIpKRQwOj 1TO56iTEz0FsAdOa2iEG3ajvG239nVutYnGhYwS0yNVuCPvqsjXX2aH6JvvRT562v/6f/9IWY7uq PmjByA8tgjmTm7jk+1ykJbG2MdZoLFAYuzv+T9Qff6dibmb8nEvql4xtTXNzK8xWpy0qz7YabHrS CNqq9S7pgUw4QFWI6fRNCAMTHD4HnLfukiVV1tvLQQC6k6Lgy4SGEQbJk0+SB2Wdqa0nlSChH1KR cF8CVdEHtAaSVggcbS2t1OHZFvs9kQqoG23BpnVrbQMOce149gXb622AFIXJmZz0UfvKHmmEA6js TB3h8h++it41dtlA5yD+LmwMWZCNvpKNS8I4Z4I5U1/9SXVAvASSMz3NtLD6U7APVyYlGZhPoEv8 Ji6alOAB0j966qXLiKAz9/aSO8QsECcBBwxUt8AxFWZa/2oB3imYP/RdjqZc8uA8XdCuNDiQZQ39 Fe7AoQPTMDCbNyhRUTIbZ3ErHro4ASgO5PQF1g+c6O5ttyPnP7XWcI09+e1v2LatN9IxnuclmI2V CV/GLvNJqOBeNKnjk4RA44u+qTfa54WGPR1t9ruf/si6j++xxxZl2NqyIp7ztAD+c7q/MDPVDtY3 kDmoAz+DUmejx9YAHyJ206vLvz/qu99wlB95GjozaA11ddaNLbtj/jD9mH1Rj2dfZjg+XFqxmpsL qyMtnDIiOPs8KLcIpSbOnaJ574Mwv/TqK7b3owO2YdkWdPW9dqJ6vx2s+9BWbK6CsVhmv/3d7+xC dS3SmdW2CNGpng3xipw9Lu30lFcmzpSQBB7S2VsNwAhKFSfj0jxEsyvWL7HVa1aSYi7dPt6y1Xbf 86DZtttsT/ugnSHuklfmNhl+N52kSyFgrnCRei/ExjaIXVK8qr4h5nIpjFRV2Yi9hF1FXfVF68de UnOj7C+ya5KYPpkdWwGWZQrgaMXENetGLCiOP2SIGeaR0SJpXBmSIXlZ9WMAPIFbHL0rygcoyxDc fX9FvjXsuNHSvnaHLViCCl/XtcIpajcltc0ySlJs+QNfs7PksT588AD7kBY+nYCAj+tKlEYmXnKP TLx0eb5doYYY/mUpqnYU48HDAmxh5BnX0FBvxflpZNZIxO4zaJ0Q5fqaC9j/atcXOY1h+qmcpUzx DiAyDJcneC7rOh27QNGgpqZmq0H1JJtQZS7Kxtu1u63n0g2NBqWqVUBxFdklNhBFYFCMnE4iFDGR FzEteGfnTuvEGH/Prl3W+dEHtpL1kILEL0QkgzDvQ31dmJf0WRKHXMkyrsYi+MqfINiL9K+109Jb 6om2QGqsyPin7jNPMo8JHOYDvT18hjoLR+MtqoND5IhCnrg5VB3+i4+6JjzQ6R+77bgWZ7x9ifN+ UYrmcIodDiXZp4QcOxwK2snBZDsRSrGTw8kwhU7uF2etcdwuMAGfUH+BhYDRADRXQSdmMQvTNEoO dzb1ZPBjRm9XWhYt7+rtsH0nd1pPUpN950+/Y9twQtWakslHP6ZgYgCl+dOL7WPKl8bmhsi7yLcE OP5L610vn1rrvgtnz1r7vo/s66sLbQN55IWf4kMmFL5+YVGOJdceszffftOp5tXOIA3EHN4sAvcJ 9fJF+8cAjip1NdWoqjuc2jc7V5K/uZRJ/Y+zKgk04ipqbk5NAhzmyk2Y4CQmwElwAM6pUyfttVde tTOHa2zryjutuavBzje8a2VLC+1Pv/6n2AKF7f/6P//WSQDuuP0Wu/eeex2D4U2kaou/6DQ2vvi1 KGODsAlBpSNAa3ADX7lmlf3b9//ZOjnZX7fpBvsNjGg3idvfx+4hEOizDYTQcaf6SXWOr/9q/ixI KGp+QDaRcRbWkjthPvbAOnvlvXP22nP/jL1WGcfDTLJcYFyPuiaL2EhLSTFYUlriDHWTOIlKGih1 CIcrJ2FTPd6MeH+FH84blP6ImXRMGO8pqAIVDzAM8dG1mCVt1DeQm2H16xeQ5pBxThYfUZfaEZKm kAaxdEGl7d93wO6+9z7wAAaWl/rr7EljgJEYSm8kMdw821vUgAMcg/MReLZ1TfPc5R7HEOIJt+5o SEyYnD1ko5vGaSEBOJZDtLt7B+38xUakZuTXdPFKI5vANP3WTwKPNgeZeojh973KZXN87tw5Dn4D BI/vczaHshMsIYL/8VPHyNaBJyHSbeGXwz3wtbu914rzvLycYgDlVa6sMj4Oagp2Eky2NbPA8m+5 1U7v+dA2vvC0fRubwQ9QbZ9YhKMUzwmegZ5OCxFGIsgamXUR/qsuDXKei2rMQt2d3TNsiz/+vRWc 2mWDC6uwfy5AMugffKM0KlQkXmvip7uId8qmTjDs4XwM3OPtI/UM92FiQ07VxMyp2wtItAUDMZKu MCBXoKgRiZ8FINGLSaDXz3LLOAr33ME7d1orhr2tvKvod127fIUOwWh29+dbC2njsHK6pI/z0baO YOkwf8n900v/HI0GSBcaTtrJpiO2/vrl0NR7yA5WDglGgMO6kufsoOgx+OyXsU/+lWnex82BPqoa 7R/yDO8mzFc/IVy+vKaA1G7JtMecRSkSRuUj9b+hNMle+3S39T2ww5JJ6yh5jEzMYu7PpBs1ftke 1mPOoqQEiyur0GZgYhJ7jVF6q0veIXjc0Ke4L/rluBnASeOKXusUVzUhkuQoXZzqcUSYGdLnY0eO 2G9+81trJ1tHRX6lNRCseTClw9bfsMpuv/0OJ+lram62x5943HnxrFm7FrXcYtaeUrJA3B0nr5ri KV7bUeeAqlSvbGWTQQoxqYrhtQXp31tvvWkH9u3jOzaA229ACtVrr0DkF2KDoOApCYj2JSz+3BWN l/lQfL/ZdF92nHlIae7/whI7f6GFdGs1GLjit4XERbaZB08k2qfM85ZrrydTwmrLQgoThAnUWkyi bc2lO7nxXbjiXpHJkdpP3r85GNynMg9ysQ8RlDOD0EWTRf8zwp35DIiZpM1oszSCG5cLPcA9GdiX Nl48hYSI4Jwwrolwo8kwI76jUbTnJ7bv3+G/T/x1Xr4J7QWsz3FR78UbSOquf2LUlAOzq6vdunpI oUZ2DuFIKoxTSiDZMmTrQ3HPuU+x/RGZcJDijyR2zc1NxAHrshKk1wpVpdRualfEORWv4H5Un5kw gI75o4NdbVhssZsqNZ+KmNQi4uOpLp9J7CGuXw+SjKI1myyNaAHZG7dY4tH9FiIR/YDuQxquojqT 0rBLxelkGIlgAkygN544cQU8FTPhB8F1lc/TH6FVMgs0UTG+CMKbgN2Wk7bNWD8PamGj0Qlg74Qe bXY4SjWyIx7q5hCQqcMesJkSPIJeLEUVxHpvlPr0KCeVkTP1IBHOCgthbHVKjdKvkDx6YQLn0FqU Dsx0iY4gYezoKreOUL51yqs2WudmqibG34cie3iU4bsanH0ra+tk7QE733bMttx4nd2D8EYSeGle JF0bxFtQEjapcuerq5HdnfqIHNHeaVnYLVTmpzqGc8qhMVGiER2SauaiCdP8amCaQP99yoe9H9xc 616K+qB13g3zV1dd42LRKnxdKrxC3Ichr8qJf2ks0tTE6zF+i5sBVL0aoBtkjI3oXh2WxFco+KKM pSVlURDqMHY9baTgeuaXP7eaM6Q/yV9g7aFGyypJs9tuvMs2bthkWQRIDcEAyFlkx/0POEIruxlP vSjkERDi6ZHfcR90Uz8riYSYEp3P1d7qNWtgkBJt3959TgJVBlNQWl5q/7DzA9udmGbLA4OWjSFs FhoiHNTpl9+G3+bV/S711Qjj86UZcfUWMApG2Rhjr11VZquZsz7sqMIswOoBMrg09Fn1qVp79d1X 7BjSlY1rNxEbsgpDeqSELBIxgGLmwqRAC0akkGK8tYCkHmhrbXWqO90nhoywbS4bw7wsJH+gTJc2 mUStetRKWcvXEuy6wZ777W/sK4884vJIpmCLlIANj/BCcJJkibfoZWrUin7/VXxVxMzL0Tz/nYQk RGgDK8bhgg5cpEgDNzq7mqwwn0wbSOiGz7VYQSCFkBZjtnmiJ5IgTz0JY/3VdIyfEjmdpWVjGA9x kpZSjFw/9of94Fou8z/YheqHkDEyceiHEe3vDJO9AwKOlNBn+Hzmz2vFI/bYETAgwvO2N1s7eYg/ +sI9ljLYb7U4GA3h9aewMQlIsF3cVZjaQRjdpMxs+kF4I8JUxFIEJ6mUl5BdJIn1cXrj9TaAQ0ss cIilft0jtO5Fet+dnWgHvnCb5axcYqXwcpV956evQvo7VNtDK9c6hnEkC09paMPsCpgHPXUbsSpw E+jPorf43PITrYipAe7yb5xq3U5Xj4hSY7ON/PR1AsvCJHz9bsMFVaeXsaeof0CHGZiaK15ocmgg 01r6i63XEdDZDDLWXmMzL45pFKATn5Otrg7vR6oPkj7tmG2/5Qa766573eFfKRO1v2r/dstXu6UD 19z7O75Har8H05GFmJEobMyUsY7VNh04UkdGsJ5U23THVnwV0pyD6iWq4onDnPDN7QWsTRXt/52s d3n7ym5YpkupHPrmc41OaDzOL7FRmnGVanCapCk3vHH36qPAAP2wFMf4eQRWE6DAux9iF9PDCbGu ptaOHkMsvHKz5ZbCRK1cSuq2zc7ZQ+JbeeuKdgim7iTOhzAEWevNSf/okwfuSY3P+NVV6A0mMmGT HxEi+XYFkhrJrXwTTGlFaYXt++SQvfPh63Z/6Q4LYsj5zLHTdiNhIYYJkvpgYb6VEOBaz36uCiBx ktlYJzjK4MSgAVRXTxYEUnlVB9jwipHe5S0osLozDXby1EE7X33OVhxfacuWegHClZNRQbyT2QDT ydqQOG5ONL86MSpOpA4OLa2NllmcycbAL/MM4wCipgxySHYhqUktKLXCa2+yjz543TLIKf31xx5j IROjCsmlGAAJOQJMMuGuouPgaN80gtEvUaA2h0uu2stU94RuacwTLszLFzF/QU7nigEo9YgCwGud SxqtcA6tZMfo7eNghVQtiLF/gEwIbThpZJSXIwH2HDFEY6RGEpRjLW7+oCPKENLZ0uVSBWaVZrkw FCk4OhTCCHYNJFuLDpsw/JLjFBeUOJWvNjY9r+K/67NQtg9VlgJOJxF4mkFgdxqwWg4S4mCGtSGD NKEBJGnUL1qYxCYD4iNgIyIBDF0AJlCSQUfrVOkURXVlE9LoOjIYpKJKboMxrVmxxhKgl/NWGOIg wK0rCNpA6UpLXLPC1mHfuHBfted9Ow3ERxQgd0EV8JENHxxcDMjjzR+HQdaKu532E5JhMrIkQYwg n96kKgSUTvLG2wgB6UeU6SXWgbuFy83MT9yFSR4hreTIqYswgGSVIb7jOFLlqlNXG9EkhOhRzH2K uyPRH5C0L4zn76A0UdhO+mCLfvdcr6INIXZTOAXBjsK+jBusJH8DeNQdJ6du3QDRM+693W697XZy nhNUi3gqWFe4g5vYZh24k8CRJDj9cVXMunOuDv5oDTkTI9ZbWrpwUKxm9KKZasWO9Pfn+q1s+w67 5eabHc4q/Jw0jDOtx/G1qi7RL3n5Kr2b9rWy8goLQq/mtURAriUxmxI3A+gamaE1EXS9VPQm5k+S P9nLDEDgzp+/YD8m28aZc2ch+CmWQzDnW2+9lXAbG2zZsmXklV0MoDxvP528lS3BZwBHLU3hQn1b rMmLzzUc0x8RmakRYnwV2lxEkJJZUJI4FJP66YabUu3wif126vQp23ztdfZL8n6GLxJotqfDVuNI UZorHf8MwBrfyFXwWbB0iB4DsY6lu9ocewFBKxMoSAdxua9cu8Dyy3Kt9nS9HavfbycvHMOmqtiK CYa7aOEiW7ZqmWME/HlVHbIJk7dmL/ZStQ11FsxKIWcuEpQ595POjVJIBq+vfE9LICUeJ3g5sORV LLbBa26ydz542RYx78tXrHR4rfBDwlNJJ7RhOSnUJKD4Y5h0+f//CgQEmyTWkjQDYv607dfXXHRp 0eSl68UBJPsO2TlaO/oI+k4mjzIMtFEnDIaJ+UVIh9KiCtTBxPqiPh0YWNEe4xADhB2e034IAtPV isMS8y1pQTdt58NspsKIBYKZSMCQUKOCVqD5jIwM5+QxFd4N49QRxkNdh8VMjj4jaVkwAUgrI4iQ 1t1FKqwhsj3IO7PHUrEzTUDKKaZvGHvEIV7D0MkQDF0KjijTlQA0cBiJRohNJYENdRimc76L4KoD fy/hulwBXkNs+BzvPNKmG6YpzitUBmgxrFNhwAD0eIj1l4jnbyf2n6L7+Wk4jfHdFdofaWwz4xCJ vYlZValDpOEgTDOHBzo2fVF/mVtr6gRhGEMhzgBiTuMpYh5JFRZ46CaJqYkbxDzpWqSIfgwSIqxx CMkxn6+0AlgTlpCI6j2ReAUjsueeCSh+z2f33p6RZKm5ZPwgDIxzBAHGmss+snwdOb/XBlLIab7j doQ617DGInEkhbtuR/DWvw5wwUiGDu2vWptxm/ZM0X0dslRXSmQNTnGbo0Gnm3qsPqPMvn7f/VaA xlHCJ/Efsk92RGaqh8ddl634IGYPLTiW1RPkOY31WVpG1rL5Zv5cm6J4XtdmM8txUwzBUGsoGiwZ t/tNk6m1hZjE7a1JLIIQKop333+X3L3H+Ez06+p6W7t2jW3eiKQPhq8Sez6peINIimQX0E+WDy2p IU4xnqrNq3siLgtRuGm2BSQUook4T1eNfgMHHDGScCtZ0gquSCL1wIMP2enTp+2mm262XDaIc+fP k14m1/bVn7MbcXr4vBWdWuYE00kDFuykNpRMQp996WB2AfaS+Uuxqeq2lup2a22tsbpz1dgJ7rXK 01V2zbrr3dz41WmeFLS3npR9lohqtjAPVJgNyvs1eu9KmRTu84xxE4iUH4DBHxnCQ29ESn8KTUhV UbBoiXWdrbLfvfSyLTx6FMP2IduwerXdcsstliLCJVyCyHg46z0aeTxCf+fe17FaJ30CsGJ9BN/P S1FfU8E17b0imPLMPXfmuP3hpWetg8DMClyrjTSTAMnFxSXk664hVRv2f1npBExNs0IWYn1Tt9XV V6Mp4MAI3RDNCYtQz4AX42cilawjPZ2kPkQXJc9geZiXY9aRkCnDecIGwZxVwPQJ/9RHMX7+S3RK GQFUFFA/QQwcDiUZqAdLluRadsJpTFzyrCt5qZMEpfV02UbMH9I7223PdTdaUyk5SlH7eoSF0DYc hvUSIzjQ0WJDqJHlQDUVnrvUbHmF9tGOJ0i7NWBtaCUUZH82xYOaDxnRRHAq8lVvDreBbzq7YWXt KfK7kjM5VoybxPypLREZwdFt8nwexthaHqoDxOXs4zOpyFHXsRZpnOyUwBZhW6qwnJsuNNrwx8ct AW3CSEWBqyugyee/W4Cqf6pCWwEciayehGscOkZyYCKx43RzMNUzk6/TqYCeu3+b13YkrZh/G8oB 6wKAnbwLb6540dwRmcLlA77MjWs/DLOG4XXdPqqjAZfogNnx6gO2+9i79sjXvmI3bf+C7dq109Kx rd26bZsLrRIE/n4+aT4yDUgAWWPOBIe5lGxmEurMcjRUTqf8Q9gllfCztF7NZC7ZfbHL1t94q5UR L1T7jTR4g2JAYpxHx0/w3Ce7P7ajRw5xOM10kj85LV6WEumXg/ksGoibAXQz6xoCauOKd5L3gqEq hUsCDN8IhJAZR3eXR/7fTnvzjTftzJlztuO+B+xbf/RtK6+qsBXLljPxSv0CMgDoQWwCBe9eUi2J wCTJDVefRpsb/TCu9Vl+jFQlsjI2ruh1+a0KIRRTTGa1kg4tIJ1TLgbphWwa5XD5DU2NeAr/i43U IdJmTNJUSDp02csYgObWlMRYOs1qwPPQbVWRwp9MCGK7v6NwTQ4jYruz87Ism7zDsgXtae+zprpm 27t/Jyq+duC5cMJYepCsdGDLUbgIqYkIxBz7F2Cj6e/Ns7becuYIZoSTaoISWJKmq2eYtFzAwOEG 7cgUoXzLzdZ+bL9VwyS0EhC8lnBF11yz2YrTyCOEWlJib1CCiP7a2MZ1fb7mZlyVl34U6Z0Jiy99 Kq4rDh56Yvzg4qph9GYdEiWwEWPRi2dsdVObvfHqCxboPGrlBWXW0I10F+aqqXHAFheV2gh2tX0c HFvYbJMyRywHO9Oyokw7X9fNoaABJhBmijnSRqI1OqGM9pv2mAvxCSpiQPLw4G0/RSaOdGzyEEX2 E7YkTyd/7PMIAgNOwNy7TQlM4P4QzFlPTx+2rb0ubmCYPgqPE6FhqUj/cojvlceizypKt+R81Mod 3Ef+1cHUIsvo6baVu96xjJY6O4cncNvSNZbdRA5ydrpOGDm/iAlMJNzUQHuLJTB2qdKiFcEuTLvn 12ygB4yNjUfX4ircnwLA0mSMFYETn6wfyaLyGyeCyP1I/GToH1LA/JGQFbbSZxB9ODG+aAHqow6D fdTpGCNUux2YWqhdtLcEeh4iV7vMATC1ISB/riaT/x09I9bWx5rSfZhnJHFTQBwiTJhj/DRm1O5h +iy64OV+5eZohVulLg6oIQn+GNfsCAljSBPXQx3iVMYV7VtdqH9JLuOaGPfT5f8IfNWdbg4egziC jCL7ZWpZIFQQ6MwODjC062gma0zSvWSYnoqCJXbxdI3t2bvbzaXWiWZGjL8yLDn5pOaPZ3qJrtEJ LfC3CUlOkRfOueciv+IvwuCz68SkOrV+q1v77M2LpMorX207btruDqVh9kLZJ8qOU3XMVJwtMOvi 410f2ssv/d7y83IvL/PnOjQ3+MTNAGquNIPuPQIRLTrl/5WaV0DQ5jf4yW4bfv45S96w2ZIeedQx eTff/AXbftMtdt111xNtXwF8uZfJEKetg7R4D9WrUCpy+tDvl7dEBqMBxViECEkQZPcE7/t3fmhn 2IBuvO4aW7h8lQsYnENU717i/RzrarM8HEMKoW6enCC2RlS3Q7pJiBr1aQFb+mkFHQj644l658wX 1TCb20grKiypRiYRtpkruPQO9YiEWVZACIS2Sd5wOisqJIdKIt5WuUVZVlCei3TN7PAbh8j3XIzq ByNc+qENoxvvSkVNDUJ45Wwy5wKydUAoW4aVGok2BjmsYFQaoJ9erlOvb64d7k0nAHja5q3W1dxo NcePWgu2iK0k8M7NUyBPDitiAOmfomMoIP4Y0fDnZVx9c+78uApctZep7nHNjC18h6ETfonni9Z4 ZG93ErQ//O45O0fmjeBQk+24fbV196XYzuMDGE/3QFOQwuGZmwFjNoCE/QKeuS1tqIMJDaMUjqWk cKqtb7a2NrJ5ELlfkhzBXW2o6LN6K/zx50PfVcTQZZP9Q84mSUiXkoIBa8FpQ3lCh/EIEX7CUqL6 zfYyeWCz14kKtx97Ik6BIgTQKK8uZTUI80yQXNKiDoF01LLgdHJyyJJDF22kJ0i84hE7s3SVZZRV WNfCJZaPlO+6l3/NxjlsH9/3VWsrwss8IsGTDaDSxIUxeUgm3M3ogLzmRv+K4fOfGb0Yx4dsvB3z W1B3S88VAYwYmAGYKRf9gD73wa0nj/QS/Lkbu79+8r1iuyi7h3gKdQ9w4BrkoNSbDPPIWskB3ikp HmXEMgQpLi+ue16j3pDFDGQxN7qrBVuS7CTmBboQuD7FsgjqngizHIIsDCnUDExsAn1NlemNP8mT +yjEUP7lhTrgcZOczXxkmXzvTN+noEGCH1prSxezSx2MaMruzNREvL+PEHewi8DPjSHyTMuDFdob WxkPsMjimeFB1ZyFdiS/Hfzp1jfvOYFTI15Rvt4WFSyzQxc+sWef+41t37oNs50M+/DDD3Hs6mZt JNmCBRWYfFUyDcl2aP+ntvOD92w1PIMr6lJsXfHuj/bX9QV6Q1sDIwrhUjor2gAAQABJREFUHykR YiDtw0Xoye9O91jCsuuwU9xhi1es9ngS9ibxJD7d8B+N9i76IrvGvbt32Yu//R0H0kpbUkmKWwQb l68AoAh8ZguquBlA16JrFPLIO/AjJ6Y2P68vdXi7DMA2N/3iaVsIA5jPqXf4i/cj6cknbt89o9AU 8Q2zsSvsgxM68V3rSYtHIuArsmQ0DtrVmwAYS9GY1csRmD+RwIa2Dnvmpz+29toL9tRf/BW0JdU2 btpkP3vzRXu6scnWc5J/CGN12evEXmgkhMSBNqSSnLZIP9LJy7CLUXRlHaW9Tk77WNQfhemcpAcI +JpSgDos6k3xX9TIixLCJDpPsj6Yq2j1aha8ECBk4agsthPpF4gg0cdwOKkDDvc7xEZhWGJakTF0 U/3CXB9mD3zjxVbq2tKj4yUpI+zy+Q21Vnl0n9XTh6O49A8T0iOxqMxeeeN1W3z0sOVmFNqWm7Y4 hwIEDC5MTIS3jaEnc7/Fx8u51xS9BsFq1ng1qUrRDL00j/3g22tvvW03Xp9vt29fagtLsuzoGZgN 0sAlkemluHwhjBmqUew/U7EVzsEJq6mxBi2BJOxIluEcJImXhqGwEHUgReocrO/c+hSBd313v2gI 0BwmRrZ+XZ1daBrgHsTM8UwmzJseGkS6F4ABEk4oGHUjYVqQfbmAyApInJyJdIw+JTLRnrQJ3IGO iTQMhNPpjw4LyTA3SYSSQIrR0k9M0y7rSs+wT+9+mJSCMDNlC2zRqeNWdeBj1LbDdmT7XThxlPEL jBhjkydwKiYkA3gHJyRGgkXPdl1Hxj75TTiezuExp4sYewrzEgGUJJJljact2N1mbeQvTkdNvbj5 iOX2VmPTRtYfGOQp1WmTG3HfYSjJQzuQjjVkOkxcqqcTyYSBzpMBaKTok2A4fpj6riWfJwadd01V N1LZofISx1yl9KA6jvCuydhOhgfBKTb7FOAvR52ohbkekQRQDV6GRSpMyEsMWRXIdH5ENI/23Mii 9mbsog+AsSuxfwJXh9HFDnSUWjPaiz5MWCRemb6IaQF4SGETmR+VIfobIMamk9BO/7BbM/DjeKAz Ok0M/+kGxfucTD2pKem2oWqLHTjzse398JCdPHmaAwup13ppG1OeZJbcti9st5u2brX3XnrBjhw7 PsoAChyzLX431CFJGlMw9QgNdI/i+AiHuQBeKGGECa+fbbO+Jdvsia/9EZk5FoASog/kZtaaphMT KcilPXKCLOD40Qdv21uvv2YrVq6xO++6w86fOUk+8NbYYHlptVfkyjQMYHRsZO04ILp3fQTSIsQi umcvnEf0+ZKtWrPWOmCEFn7hdkskyjfWj07S49t/aXI81SgIxwJ0MdcEZgdsVapGKG4WvY+X5a9r x2809hZ0WE4E4WXgfC32DO+9/Dvbd+ykdcGMpWeN2DpCxWy99yFsHnbZS3UXbAPMVFVKlk9fZ26I Lo3gdagDSyKEL7Kqoj8nwk2sshHS5Rl5HrFanxPcJCofakf5JZGs7GrmYQ60iPLYODPoam/0UYxe 1UaaTg7WXIz9W5tanRRYhvfJ2FgF5T3WDtzni2gz/xlsIySGi7QffbBDqHwXHztgN7zwCzvPxn/g zi9Z2bVbQfpkO3vkU2vE1qUPD850Akxv2XKdkx5p6/Fq1WSq+uh1Rxqe2xtNjK6ZudU05dN+77Xx 6/A2l8IMusfVbYVUyiA/bjp4XlrkSZ0TtIF39ll+V7+lIPkjACPqWCTAhFHp7evE8VKJ7Xk4srEi 8wMnvIxCuqzfJPvQu767Qp8HYBDakNoOQ3wGmK9esgwxhZaWm0y4BwWdxvs7C8YAFbNPjAJwFwpl 1Eve6TSCDAdhHJQYXvPpgSEyFrgUtRWWMwc4LElUkPuFq8P99KYT5ofDYGe2pM0c7GCyOogccOKG W53qthO1s1S4o0WVI8ERqLy4garda2v0njl8UE2iXwPEMh1KCjkbOw1ghDZTcIJZ+Omrlll/xs5s e8S6l621stbTlkZKPsFF0vF4GECZzDRy1CrMhdlMFyMn+NGWxuY+eX/Gfx532d2jucxDrKalnwJ8 tW90wXjIYcBpn4gjl0zfFCuyHw/dQSoP4iQ2JSMzufHxDc7DZzTYtggGJxVV8AUygbSgAZmu+IyG VOQeEzXd3ZN+07wx9vBAtjX3FSFhJRi288aYdN+kr0PgfyLOVMHETuxxu3gGdX84zXpCONbAmSWC y5rvqYrYWkmHm/IJy0SMxkyY8bA3EOJ14t1OAPERGKl0HKmuXbbdWjoakU62W1Ya8V/R7ODqZGfI uPHCcy9YEUHCjx34lKxbxU77J7OLqfBhqv5Mvq7n9RKDFiRe7EB3i3dBF49eMKtps5OFuXYkgNMH 4eWW4IsgGhECv5xQCpuDaYbvmtMBU5K/3Tvft1d+/7ytW7vR7n/4EQtCw85wwLu8hYFEpkdDmk2J ygDK3smNnEVyacwcHyG8d/+b7u8gnl8mp9wqAGnf+Z7logsLlJbhno9nLByygKoi9aYWsCftowbv v/fjZ/DXLbjRgUzfAQEa/HASCFldLcRr9aa7v2h//8//answ/Lzv/h1WTH7ih7/6mPVh3/PCxQv2 PuqtjpwSC6NCjL3QCERteBCJWVCAU8tRihKg81MgkY2Fk7WjkFFui+dSCqq3BE2WGMB5KFpE2ts0 ipnALKwQU1C+qNjO72zAALzHli7FThRilIYUSBvqEBx4IlR/rozIMNLI7LQW6woVYLAttZEH40Q2 ZxWMELwOg6/9RIPvysm34YpFVrblFgvhnKBNXIGoA8Snq/nkdat77pc2sghDfFRUWkKKK+fGOxMV ca3Nx5+ZoDvHNqg+hn0ltkaAiaAs5v4aAoO//fav7bbtVXiDY4sH7LrAP3l9pxBmYxj1UL1sijnB Z+FxmJknr18PN3XwLMxLtU4OXw04CCmPr0IuSGrklxFMB8ItLcQXDVsz+sJkMT0gZCoZAZReTlLl 0dWl5zRfvBKREKQ1d1gG66A9Mw3bQw5XlOnwTurcJJxYkruoA2mgaJzW7wi2cwkErkyQxEWWTdTf xab3ye0PqEbrwWxE+DS+hPswxWAjVJgYrYu5FtUgmiVbrQTRX/Ba6zIcRMVLJgcV9ZcfLIm2k/rR BADzoq4L2An22FCM8QldRf4fqutEGjaEvV+aQoUwbpqeVfGfk8ZJklrZCSqbENo7eu1BSIxikMPA ICkina0f3tufRdEQFdu0HO8VhTKSFJBu+iRmrEv0VxLg7OpGSyTUUdfiUgshlZqZCaQFntWMKXB9 Itk4unuzrUMHECZ4uuf12ADp+bIDdZaT1QsN64d5RoDAD+HhPmuDkevqzySLSC7RFvBwnqKojQHG NphDPmOkehnpwmvoPOP+/9h77+/IjizP72YmMhMJ74ECyqC8L5JVRVbR+/bNbvZM7/ieWensavSD jrT6H/SL9INWP+jo6GjPWUm7Z3ame5btRj3sYZNNV0PviqxieQegUPAukQmk1ecbLx+QABJAwnFm dzaqEvnyvRcRNyJuRNy4VsZCHXdniXijnkDPNFxpXa27uN7FLyXwEDWCKCodr3z81/bKr1+1ZvC/ pQ6rewIrRNGfczqtlCdafX3Jw/EQC0qMw1eSg18corQGFnzmKpLKq0OWfLDdHsVI5eD+fY5GEZNK Rh/a45c9PBSAEWGZQSf4rddfdZ/77jtpX//295zhWgor/q8krbtvPOiWEoA0KogPrODNa5br3ms5 fNcst+Axzm5w9Fxs051Y8u7u3k20BgaPcrTUiZOU4jQgNr1O6nOJzEW/5m7PXahhK2Hx3IsbvFhj HYJZS6WUQ2XdnGcxOnL6Ydu//3Ubg9hzYNN2EYHPf+d7NslJqqfvul2CFXywrhWDATmQLRNmlU89 OqkT/IBUIqMs0HRSq+RZBSzuEq+UWZt7TRtTGLGXB6Rau8ECKUGiphEWqThFrTjmBUCl89eyo8Hu fDTgvLbLObWwxYnd2EQznNJCm2JVxQbC4tea7rN8YjtB2xEzsnk0RgcRARDCKdNiKTgiIVixPUeP 2yxEgDbqrJTQ0YNyuIARQbClwh5+M26H3nvNsgcOWOAP/xj8l9DwP7MkVNiERmmTFuGmohR5Ywji rIKNRC4XJsczdvPmuA0Fo7Z9r0dMax2ZQsTbgTi1Fb0v5dOa48DhRysEYTg06zgMedwvbOvaPgeo 3svgZzR7pwcxMo6l9zQ7bp/KCMfg+okQ4npx4mxgwZmUVQ2gWgEOTO3E7j8HYSngl03gE34KY/2j 1jw+a5GuCovjLmRu/dTEL2T3VQymmgpiawhD/56Kd+snotYgeJ6GUyO9uBCE4Gqb0rKg8aASoroG hf0oUoPwDLDwP0y93ibt5QxyaskQ3rLnFI6rJx+0PBbY2yavOcJxwfq9UkWFZ2oqCkAWx4ffNriq ItzUBetKrt/4Uxj3uTJKlKcxikLZpuEESkzvOLYl3psrYysvwKPm/CzOs4N2TaaD4L2HwF6l0qWM TsZt90/fsOhE3G787jM2dGIfFIqwvlTyGiLvBTniC8/maqzm7rBte/8C+By3Ow+1gkdQxysl9qc0 FultnTg7F0Na3WpwvkkSOFVWcdCKJ6xvEL3bFAckOTVfJmn7dBBxkYiFHH5FJCJjXumZV7aGDdUL D/S5ksTtjEKYCcfffP3X9t9iF9DDIWM8PuEMKBa9PpevnAua4Q4amq6iTWpZs8cQb/cRxvFQe419 FIxZw6lH7OCf/gs78szzwIHbOfrcgV4W548+ZH6++dvf2FtvvGb3nzxlX8O4tRp1CemnbwT2ctq3 We8sJAC1KNNZ4dd+bcFf/dxy3/iuzf7+j1glxGXymqQvXRV+6iwLMcTmjMl+YwGbFFw9x2lb73G4 cd6+3cmyXKhVuMMe75Rfbra1v6fFX6giSPVdXtKbsjRUhAv1157d3fbf/ff/g9UAszNO4J4IqWNn H7NYS7u998EH9lf/77+1vRAX0gUsveUsUzf957iAiBBYK5YmzTCdiPW9SUmwq/s3IwkqvEPZHU6I Cn5eqglL6qHuCJzNhrYGIiTgBBiRlNwDiBAMiQAUd4iChSYbTRqPqppRQ60cq8dqi0Fx11cPQngj NsCQZ6ZAyOWpcAo3G1pVWvL9TryYQjQoDkoKEV9l7x1rxRVHYHCAd6SMTh/CLvPGWoCqJzYB4FIN dsVv3viXqmKudOE8+DFH1JR6eYV7Xg94/DuJT/rv9tuH77xpJw7U2vvnhy0O97lvrAI3P9st2tbG oQZ9IcTAzCw4v3TtMJba8kkHMe76lL6uwI1LCwUncX2RkMjYJfqf8mfh/o1gtNOC66ZoTQWRRQgF xWk0yMFpRVUCEYZwotPUIx1QxcfOg3c4NS2Uv/RL8ybIyTAC4VGFnmgAToYFPAJP/ZXLwMWc68hC fk/1ynFNFAXEwxO1FUMUcQuxLA4g0hMe5cDHilgNuOVOg0sBWOaO+lwWvW2jONMmkkkFi5ckko7g 5OECmLR2wfEc3XXMReTpHDpvsfFem4EIiHBfql70QllJTZ1CzBdB96OxBoKl3IyLS1dBjIezFAQf yklO95OxyIkIrAdXtD6qI77ipLkygSX4KLqJiSAqBOBdgHWsQnJrzSMdNDjQVt8dsMj4lIXBZaf7 7dgni4HV/hJCzxF/qOk61sEw7maarf7CHdv9yzdZLy/bl0cfsim8bogTvVzSHkUpHKjpEOaI96rX OVpTxaVtqBeHLm430WPPhbqcHl2p7tO9EJka4BpGkjmrx2m7HEILtxyXeTkgdJ/MYaztc+Dz3ds3 7Ej3oxz84JSi++3Gi1dEASxHCquI1RP4TD2SJuBI1N7pQVVrNmWvb9tn3//Rv7Ra1NTkP9Mj/jzR r1/3cmVrTFMQf2+9/oq99ptX7PEnnrRnv/5tDpbyXcwxiedfTVI9Xl36W2p8VoNj4WyipwR7QKbY A5j669sVXFw01+6nf4/O0GIJERiSbIGkdVJK2hIx6C19PDD1tNy09hzllrzgPbB/ffCx8WsRZTkU i/nYsWNu49eirbVKC5B8hO2HI6SA83/1f6M8DZeDXpmrvqx63QCQiwUkoIOYT5lpoGRhBBGCqSQr /Fyx5V8UI6pmSSHpSqzw5bc6/83Vv1XFEMQUDi3KLw9YVH91AyLfDJFiMCyK4wJGomFN1CDcofWh +1J4/VZXVY9iRC18l14ROAEB1xAZYGOez+Mu1SDwuv/GkN27MsBiCWFA5/89i3r09GP25Ne/6TZs 7+jiZfbrmC9pc69c+YvEh5tbw3xpG22LekSopvVBqFyLYcfJB06gOmI2nGqy+o5W29sVtiTEk6K+ KInwb0RfLjMCR7h3jKg7uIjphpsia042+MDdMYglOD5sJKFWOLJw7FKIjBVlaJSQgTMcvKp2NFsG 3VJtrnkIc6bsikmwZeAQTnVhWaxNEljyIshWSoyBlMoTWNCPNWI53Iz4TIuBGoxf00wUncNl6pV4 WNKSHFzQgIwcxOVmQ5EeljgwWleybDoZDFTc/TVwwLUhNcSx9h2lTCeScyjsrUQeii5sFeDO0meG zl/Vlfctf+dTS3TusEkOQHq9npksZx685lKpIvRA96uZ9zCTbALKsVamsWtNLgt13eFgNYhYbWeL BdqJw6z7PgDLlCkaK4NYdRb8iRDOzyX6olCk93uVMpYpuqzbWipmsLLuxb/cEFxVGQylMHqS6dkM RhDSKQ1hCZ1C7Hn7248jwEH8uq+0L8c8C1EyjRpKqh5dvxqbztQ4XJ5BiXWkrsMGd+yyeFMb+pye m5WVAMxCGNdVTqEqwVsl6ETXJdyvq4Vwnxi1gUStBevoc+HxouRcfKGD3szhIgqOhcQ9K7znHyyU yxlB+nvXojKkeyh3PmFE+vXMsyTzNsthJ4CbIfVhqXoXFVHyp/JScmG8g9ZBH03BhvgQw6/D33vS dj7yxBzxxzA5RpWHWCWLczc1l4T5773zlr30k7+0hx993J5+/ptwTbHaZ45+dcSfD+PSMfGflPO9 kAAkhxR8M089Z0FOEdn7T7kOKp5o6lSNif74VauTRQRqkPVMa15xR7r3davMNNeJfgVl5lv7a8Dr MGytEHo1idAVrlfAXYC2Y59A7A1BKa4najWuL5IQLvIIXkl/DoliRCekCmQfQbzUjMVuJXnKSXlE kjkW76Bzm1DofHSNUNjgeMNMxjLRVVhun6nJ4tLiiBn2refY1AeEMtIsVCH0o5Yk5XMzi5fKqEvr yz1EEvKWVl5LVaM3HiKs61qrLT6WwNB5HKstFolqKfSi56KCFyc3luXBtSAr1WkYwoUFil52xIkA rmCA1UyH994fu3keH4Cfj9mubXusrqaR6DZx+xWcoWb8sT2NY3MdKeSSQrjhtUR/y+isBUCt4Yer xKtpDbnW9Ooc9DrUFRb4NRVQ9LJ61Bl+MYitra32B3/0pzY+Oe2IwVZUJ3pwpv4+BlR+PSIEY7hV SQ6KqwCRxQamj4jzXBy+MmJX4cM0Y1DPpjHNAj8EJzYOJyE6Nmat6CKr+2eQZOTg/sm1zNx4OJzR z7kWzkPKszT+ATX4IswczmlXW24jI2cWY5JEe4ONb8dYpB79UDJBf0D4kQ/Fd10vSaqaOrSB4CXf GsZGOISgO9faafkCoafQckF27FzBNYwXQg4jB4hdv5+WlKtiaVedNuiRFHq99PyqaALXNIcYO37P 2sZuWQfWmxU9N6wKOCbau2wWa365yGnKE7IR7J6FmC7QlKWqd9bTsvgc4QBbg5FzmctdUVkaZObS lzcsj85WMLPXUBR1/TU3hkVvL7jUULEZ5dEHTNG3zipYltsyJy6Mu4gycYrLnZ6FbAuq0Y+S6MP9 ialZGyI+c7guhisdDDWEtxD6SThl8fEZi0FkReBK9z92H8iD9zxwdIExkACD65eebrXBVCNqNOAU UUa45UCWlKEPHenUi39qs1jIz+B3d2H+xaCCZ4kxa29FFxaCy+H04lfUHj70CjG4icHewwELjqMM m4qT5l8VlFMLboRik05jmnwLcUy0QRTDrbr+GzZb3WBTbd0UXJhrwnnwPRhE1YKD4DBqNdWRenR9 kzaNT8A69kzPQ0Pp/i2GpdS1qBENrZLUS9qaW+1hrI3jiRk7dPAAhmdetDERf9qahROF112eUn/c XOOgNzY8xGPEwBw03zn3Bq5s9lgrxmo1+ATWnFy1oFKFr/leoR/JN3+1tkKWEIDCiPSRYxbYfwAl 2lJsJbrI9dLirgKZ/HFdGwzLvK3CFtexzKv/gLel16D9JcsJVycD6RtIv8klCJjJkSH7y7/6Dxbm pTin/CTuLWrYBYb4rmTDqgqxqJcDP+U6fUDyeq5hqFgTyR8L/7ucsvQOK3EesUP+w2s46mbRePw4 G5Qn6heSpyEOJWZdgFn6rQCObNZ4v4ZiKqxCKm+FJG05jeZakxYTxfqtaa4GLVE2oKMICoVivGvs kuJCLK5CwqxzHr7k8ZIbjvhnTZuFgIijG5JmUVbS/RAudRgupz+kED4zLBpTxIudhBgduTZlZ44/ iqn/c477+3P8Po1AaOw/ftzbTFjItdFKQR1jbm+IltS+eTdK98bmlV9cklBby6TGZr1JkgHpBAfB X+lrdWzfaZ0UrLmjtgj3/KSxiKP/N3T3LsQTuqSI83LMgRwipxyERSAXtQhqFuKgNbD5SZewr7cX he8kIpmINYGjjQk2XETLU01wT9h8KyTGpVwp30fBZY1Vqg7uoNhzwFCcxHmTi5TKKULTwYHOiIIh e8iJ+Ev0PLey1JkXkami+ARQjwlwSJMO33IcQH+i1RM79JFXfu7ok4+e/4H179qNyLaAl/ROCP+A KjbLJpnD953EwRVwCl2GYsC51gZdja7ftnspi2EksFxyLdb6Qp+kcQkSHb9uByZvWUtyzCJswoHM Douhv4xTG3eQm2bFGmUxwj80+I4lKOCRdUlSuTy2OtQ/ghzectMQw3XA4Spc8nrpG248KFyRWRoR DUqUp7oWjVPpzCK8WdbY07LTrELkU+i8rNa+QoaQVAH4VFR6esbLlaO8zmMFB7sMQQr8JH+fqL4h mmevBJcFmnNVxbcsYJPoXKZwL6Q1VbMm7NYm1FlgnSXhXqcYnwzcrmAYXISjnZflGEkliTDVv3iq zsYT29CnZK8QReP2Gq8b1JA049+397BqBKeVn+8SAyIYMnJWXjFE1BuIzVU2Hu3nMdz2tDdNWP/U KK5z4K5Trt93gjPEBlgNh1PCP4mzFyeB0XT7S9v17ks2idj1+pN/CKEKkUQ79SyemORAFrB2fGOO EIc3TGfGUOWQw/86bAmU1AdrXW9Utj/XJA0YJkBDbNdOO0T0JpWotUYHLhF+aRpaqr9c5SX+aJ6c efQJa8VtU2/vbbt25TJRjG4gZib8a8d26967z5qIa6+kcvVxhGOJsv6hby0lAB1EACzFzxKTTLcc AvCHPl6ADPq9GWmuszarwGWB8hohFrTXmmVfXPGBcrMuFBKK4FypDXJ/UEkoqRosGe9iBFK/Zw+O h3GIjDJfDdaPo3IdwmYUBVPniEa/mMXf6guQVe5h5nQBJQITprMJ4MVYlfJSmZ3GQpJnU8v3cpJJ IH8TOxNxhMrQdMOviYe4xSPM7fy7Fy3/xU0LPHTYAmeYTG7BWQzswt9lQrQwU9EvNVFiwGVlyLwQ hDCVwr6sLOMdTZbVguz6o6igokuVqab1XOm3e9eH4SwgJspzSqcvB+8hagzDiUEp2eO0IIrWyR1W R02swZ5++Kw9/tjjhCRrsKuXL9sv/uYXzl/c3t3dLDpwgYEhTP+K65OXby7E1upVV2ERDJt2qWEX FbOFyYNemAGebLAp6nvp0EorHONQiEFvQ9UthWJL4qPLHzpVNcPvWT71ddVE1MAlEFySCERWBRaE iizgLEvZzfKIWUfhnmVsxupbatwzBKccvDjUImMOs3FWjCedymwW7nYFOF7Ti2sIKhnfC3Gj+VRI WrSzzAn5pqyCS15L/FkZAY2DV54eFmJk4R2blw4pxV3iicDUmkJyezq/1Si/Yf6zou88bY9B2O28 +Kmbe1cefNLu7tkn9kXhLeVnuktxnncz9Ek2JUIwRVvFDWQdKTq0a6OqEPwQwCtUy2YIUQNXKIKl ch6isnvyhm2bGYHYAJd3UT+bGpQA0w+CHe4THvZwncTmCS4gHHS/BddyiQAfcNIpawxCOMYY4wh6 pfeXlKO5dHwPFvZERcGl1lqSxkXcVFYPl+QCCDLIVe/GjMNGdkaiWVrFoa9C0hAhaCG5d+i8DNaj E7gCCnMQFcGipCanQGTs1tFTTtkE1GAlBGYt+svaU2ahLoZ5jv2bww+XpzAQKqOmrhJVBXATNR4R lVmdilQoHy13giWXrbSheItN4t7LEYQ6BRclBytl5uScXHMzhe4p8GTCEFk6rACHDlx6FkhNW03F qHW2T7s+WWHI5mvgpfZmrJOnB22ckJkR9jN3Ei+8gWBKJbv2zmcqXNGPwsEQOBpNjFs4OcXL9D8w acvVrOmfuMu8roOfgIHd0C1rAOdqwajJ0WHLdu3w2uwGYUnpq95QNvWPovvMyh8x/SDVIofvzAtt eSL+5kdn1SILL4hg3U583+1EBYrjfeAuUotb1td3xy58/qlduXQBYxA8fjAuMQ6lziuBkzroVlm9 XiYgHh7q5XV2kaNVSle2LKA0wLVhMxtSCgRvUS31ZFPvqZ1qynxfrqv44uzSb0pBqHGes1ocYP+L /+bP7d+H/o2bpM2IiFKamIhzUrN5oh6g60TlecTBcvmAQGLF+kUAuqO9jtbiwGFer6NXADa6Sytn n3+FDTMEoZQ/xQIP9yPgTqYe5wqpglWOy2mmwlB5xbpu0ob43iXLv/MFem6cYs8c0qHXpeXQZQE4 /HBEkbrcTTwv72b8DbKwx+DQ6QScJLScIwBXLDhg1z6+bT1fDNmhXUdtb/ceiHKIBhbwt8+9Yx/j oLcq22AHDx62WiJBVDOR69HrasetUWdbp7NInsGVwq9ffRW3DXW2m8gCr/76FXxeVRL+Z5trZ1gb Mv2qNmvLEZptRfLKXbgxbEU9bqJsYiMUt1dcFR9HdKXQY2k2Qn9aqroq4mnu3L0bBXrEjnBjJRLW wj6NgUeSxV1cvTQ6cwlcBmXhtim8YISDFdhs6aZq3C9F4Nzh8xEuryx0pUM1FZO1JPioA4yQnGt/ Y1LfaaH2OJIQUcy1MPil8uTSI8snx1zQc2cYokMZZUhEpqIEvPILdv2enkRPNIA2nN9QVVAiiXCc amy2889+x+HxMBtMaI74m8/gjFLgJoYrIEYRoUlfKgMB4IgBvsNwCQMFDmQW1ysZ4Cp29DxfkuDj OX1ehauX7iQHH9amjpRilohLBsDiLlKXGxC1iFtaoxohqbKsOxVQAK7NxYUuuqZZbsmChcpBiv6W GstaDiwqoAGCBpG66ncdu6iOcn8yJUnzAyHrVHGCM+IopzAGkF4eRL4TC1ORCIZZuIeq0xFlrHuV OlwWEr1Df+i8jJ9HiD0dCOKo94gz1osxxCC468SYfobCt8MO172KFsMYYCWclgSDe4LOhUXlgJLG 8jyNSkMGKjJAKL4guoRunHlHsOdkIQ43LRacgDAlRno1c4C+jaenwAsdnoKIJT18rMG6t6F2lnVO uL0IoGV+6jX1WXszMIwO4qIFUa/TZ4RjCqAZkFpcSR0OliTGTbv42M7Ddv3RH9oMXOQ0BzgxRrwE AThyyw6e3G2T/X02i9sY9Us9h7ohdIBnYJDEENO6PqGuuWxLKlp6Q+/qIxhFgLUR2zdCqBnNyxRj laY/dcDxentp/tXu+JGoYuwZe/cfsm4OavGpSbvb02N37ty02zdvENpO0U5Ys5CsVaEj6BGDcnPl kNDBslo9W/1czKo1JXUo/90ffxjXVEAZL/sIXgqnysi+hlfUEv+zhmyrvipRCguG22HytnfPfvu9 P/vnOLz8qWUxcQ9hhRSHeJBosRr/ZQF0lSbYxMKEuqoqIEepKrRmijhT1HR3ii4MhBCd7N6njEGR zo6isAQgbPLH97uVzTmC5zSqUExaHTKcSgMSdRTkBEJ4nVRndmzDyhGODMr6NROcOlkVJVLTxqhV UrD4SeDJqSb/HRGUY/GfZBOWV/YqRHlawDaFEKTSHMTwTBMWkqqvIMr24Sj+dpsVbbzxWa8NXBux p84+Z2cfOcsiiZ4OhIXcATQSl7Vze4fd679nBw4cxkjhAReqSHip06Mvqrx2/Zp98Nl5e+TMt6xh MmdfXP7Y/t1f/8QOwemtr22w06fuR4xRj5NVuIAgBEwEtyAVw7Mp1+po17BNKa1kIRpWVaMT/WbO S20RRSjjiDBVJDQXLmlDUAD5KjjmuuGvDbIM7+3rRZyH1aEjvDDFwcq3EjdLMcS6ITbhWcWYZrPO a0OH7pDT2wiEYp5n8iU5C3Ee397i6sqK86NKi5LE02kIvRnEj7adTZpyhGeCIYQlsiMcUCCSUr0W ebQ8gBbilXJS2rzR/5qBu9Q3QajA6iaICgovbmxRXbqUfmMSS8VPnvqW2yRn2DQ8v4HzL4pIrJoY tzQ6eWlw1RmEQKTl2CzdvIXbkooT2xh3RapuBuIiGYOrAv6Vqlr9n0nh+Dk1bt0zA6iyaCsHz318 0iAsyumVI0mHN3alyp2HuOjKlSUsWkdyeclXdmXl1eHGEpDQLoCYxqqfkGZJcCNXRZ8yHpzX3XhX MN6VECbCTfcRPEWwVME9RtADiiLaRZQZIm8NeaJI0lZyfq/3RWzKxZXWRT9JipDh0FEBcdcRHrLY 9AQHHThjM/XA4xEQQcTwdSEsh4lf3lBD5Bw4q5VIcQTaDHgwOZywXGWtNSDuFTJQBct1+cSfD4uI xVrK6AwMEypxBgK3ni2IvcNJCfVWUUf4mfxvJkOikagtdVjDC7fc+gGhzD43C94NjfTaP7vvBTuH pT4BaaxdpQGuDK5mCbuoua95sWhq+qWv+C2o1L8ivHKsC+o36QIm2HODHGq0PW80SULkxRhGSwGf iYeONdqBI0dteKDf3jv3NnHK+zmcpggZiqsrxNphiFBxB0XYSpLhjaVHoK8dlvkGzF+trRSPACwM SnlZmQFuDrs/5WVZ11ta+re6DgBTFVtQjSaNCyUj1KWX9+4hzNXu3SinD9oMJ4UwrOMI/V6LmHEG JJ3mFFpLiyUMU8uXS9oACjSaXnRJdYmRAZ55orXlMnNfTVUw9oQyKQVYFeDE5EFKcTAUgF3lT3Hi rsPIRAQPWApHAaJTxN5TJyx0cp9VoAMotEnq1AqhGCsoVsu3mu6rniwXdwj/liDvzETKbnx8y5Jj mINwv6YjZm276on/W0+5cBt8eBxQa/+jjXl6Gxst5WgzL5VUr070cQxnhnpHrb2lE12cCnvjDXw4 SkSP1ea3vvUt272n27Zta7frN647wkOhhGTco4lO99A/lEMFH334Ib7VauxQdTdc1BCuM5qIC33Z pj+5ZCP9vYiFJu3bL3zPbeYS+chQaiuS+vqrSRrYrWmDD784Bq49/BGhraTfwnu3ucLxE9dvcmIS 0XrC6ttq0YHzOILCoxDcw5p7o068K11BEW1K0suedTFixYWAWKNUbfAJiRRVj6vUvTr3Rxuzxj7J 41QT77GJKjJIBOJO8XfTbCh5CD9xz0MoxKkY9ms3LyUWnhoL2uBItU3XtsFEE6de9XgVqS1up6MM 4aXmsj/vRfgpLXbloc2z4851O/zeGzbcucsunn0KbiS4TlnypaYU4Tsx1EfREAo0WpzPaXBTelqL CVxXJ1VHpm5b6+yI041Tv5SbAHmNiRZCDeWJBlJ+LWusYr2vA5C4dyn6a1KcaUfM4yKK03IEHNLa 6NYozWFctTjDOzmZnusE4adXeRVroNJOPiEKuowaCB4dV2yzG3u/LMHC2MXgPEtnMVqZwWE6hk94 2qiF6+3vi9Khra1CFYEoS0ID9anmjNbvGITgbAS3LK3osIL7bqwp34eRO2tKskKuw51PLIIe9FQS R9F8T1dZ5WQdviQ9LrAPvldw0S8qdTqxelAAQF+X+7904RcPHThk5869ZWNsfuOwLe/RVzGYE1ER 3Mq7DrhVu9Z6zVm/TvXNDOMpVy3qks1OmtPOkIuCm1ta0RFso9u5ByGfIKa31i3FGZdIWutKJURg jLkuIlfW/ho/ty5sNmArlIeRIyDSIdIfKSe5wdCL9K0DuJxMa3xnrhNUwZYmoYn/2fzKxIqXV/G8 Yw0weRjwDiyFZtAdi2PllMLEfoTqM80QLhNjBv+q0NrlYdETbWbFG7H2D0l8pAq4WlL+GHVWMKGV zzWfhSS1s9GiuFfAKxP3INDg6kn0RcmuyCALkT5VDXDuuhoJ6ybUBgwIwDT6LxJZsFxZhmOcilXZ Wrzk/mUCJdyLb1+z0ETUTh0/6zy937p706709lh1+6B1H96O3zeU2yljI8kp36vuEoVok02jJzg5 mrCpoUl3uk7h/f6d87+1O9f7bOD2kJ197Ix941vfcLkjjNWxY8fdhBSh4AhA4JMBiiMAWdj7cZVU nUM/kLlzr50JXLvTjrcy8W+N2Cs3/9LeeO0Ve+bEfVZFmK8QHEaNrgjHTU+u2zbWd6vB5KOKW0zn fqyWax3P1YzCR2uN+ss7W+BHDa55T08vm4nYedDcrbXo2MLh85vOBWiNuxWIPu7lwWFtlj6PMYNF bxYuiwgpJMUo4IOr+EITZ31p4qbui+Bl/POOw021EH8uagORMzIQfVPbmhEzs4DDWchhiML2CwwU Tp7JVAj9wxa49egXYvTlNaxQE7pQaRTyK5ACOKtBJrX0GdWYxYTfPGxElrhx1Y6/+ku7e+CEXT35 sKXJ40RqhU7QQc3133wm4HQNma+/0F957suhcDg9ZInsuFVLQW8rE/VmJ4EP1yWhBghSt75sZYXl l60emoUYH0NcKDxxep3AO8Y4XSWW88EWjM/o2/y1fsv99hMLbEeF4NlTqOAs7W9//9LKuR2OcD/I Ki6gt5KuDpPws/7WXWv56JLFu7fZ0P0HHTxR+qsyCmValHzc13dhWN23iNUgIuMM4s4sFGGYg67D c/+lojLKvVTWMEq7zU1pq81OWKxvwqJD0rLFcnfBykbdbEjO8t0v3AeU3xXMk95hjCcGztsLL37H Glgfu+jG23AwbsDJjmzvtkZJTlgzHX3il7GGb42n4IW0KexzQMgNqTs4XjjX2qP0zlYkEYIiQMXh i3BAlGSpvj6H2tes0xucYT2QCkscR/gSTVeyDtQgARRRyMQAsHIgUyu95LfX/13ud4WsKzNs0BGU fH3EXTkzgDnYygFw5ZJWfvoVnRI1K9SU+b5cGaw1PuV8ZtNQ/UE4aUIIsb5F8Usv4eYg7GH6Xq4K 6uCihQOIVCVHEGYum3imcqQ9XwBa66jod+l/LznllyhHohsO4V4ir0rK4hkeKJy4TKGydB7R/bmk HyClh5ce8adncmwaYXMEJHdClt8tver0HLgYxknppzdQPg4123e++4IdO3GcjXfGbt+6bZeuXLGL Vz+zz1+9Ykee3GeNHbWOkFS5601+s4rzqztnIVLH701hUZpgkkWtblfMajsiVpNrtJvX+pzuX1UU IpRTqIhFuVLwT3MqS/ekcqlv1z4m6ZEjx6z36qv291fe4FTX6sKadWQh5qdZIFvxH3flI8v+H//a 8oexsP7+D3Bh04AoWCyizU2CZxkqZnMrUsu9yja53Pni5jFr/p5/Jd2diclx4kTXWa3j5jmU9B+7 bxHj8c4mOIFEIMK9xuLwaoqq4yVmJqoYMdQvZDU+K0eEzCGvfUwxdg5xDHQ4lrhX3CFNsjBuUCoQ EYbAJ+mLJjGaMCzDK8GrVC1uOOrRv6MYHahhYmDoxQaJcYrW9PnEG/yXmEuHwIoqdBbZ+ORyKN0E YaHJXDLlbbR9m906dtKGdu3H2phZSh4RkMJKiaPSSBakn+tXKFhSEC5pdAFd9A9uxGsrLE17snCJ YoBfOb3P+jIjVo3fvxhW1W6IC/Urv78SlxYilwS09E21GfWV3DSHqHodFItrKp1lq++qfUqalVMQ LSlEuRUQdXP3OVVfVDjO0Rnb18oeeRXu6q/fNzuAgYLznODrR7piFvxR+2ZwgTUjHW2/wAVvLP2h 7Uhnjpbz12zPX79qI6cP2/ih3c4AyanMlNllwrcweDuLuoPcs6X1DZ5EMX5ysJRZzmII/WwR9h+M 7y2NhX4yzprPJiSOpJtA+KipmKrCryqGEIvaLVc849Njdv7GO3b6zAl75uln3YG6kUgdn4jtihV6 F0ySGPujKw2c1t6ykaQ9y/9spJyN5BVtpb1DKioiBuVdQNzAhNNjxs0ZjuMnUe3Yjq9CPd9gk8sG FQLQW+jKzSHkcWPKn60CUh3l0lZVMNfYQj2LsXTu+cYvNPDyISadQOccm/4WcSTCexq2cAenoSBI UM1mFGBDyWOJKme1y/auEEmrlWOLLITPIfnCW8v+0rtziR+hgXFOJ5gqsGnmuwkGjtNcd3yae6n0 hTs0MF5uX+VPqFa6FmRl43z/40G7eJEQXq377fiJExBIVZjjD1kj8VqPHjtq+w8dtKPXDtvPfvZT u/D2ZTvz3QdYfMs9J5eGZ/Fd4ZIidozdm3RK1nXoCVZh9NJ5cLsFcWw7PBax1hOEBTo4Y9dR3r1+ /QZ6HNXo+yDWI6/ap66qYBMVtogTqNVEhMSjjzzKdc6u3u7FbxUK0hCYn/dD7DN8fVjj3cfmn//x X1j2sact9MzzFqxVWDA2Ph/tFgO73t8qb7PLXASL+kBVgH3LouaiLOv66fqmqD3CU7/uasQlLfjy SqDjlkL8FkVh3+FfcU3kVSxVF0+1+L5/TQVyFxQZnrQgOqzVuPdJw0Wc7sBoBCtQ6f2pPo2xLpxY Wdy/wqDJuGgK46kgBGAAQiFdi3L3EDHQsUBPghtpxSkGVypw75QPMof4DnG69zZHHwi+2YxlrJEY H4Ewm7b7Pn7HolgTXnr8eZvYjxsuNkNHeLl6wTfBQ+rde4SY1PieRFcwQ7niPCbHh5m7GMOgXlIB N6Wqtd1tNi4D2eIQAv1tHHoQAwtvh4mBnFKbmGoxFqb68D43f+8MvWfdiThRJdGZpB/1SbPYJDi0 kI2YyIiZ2Y03SggGY0ic1BzK9GEsXH21X9SPFzqn7zjDmpuEE6PD7xyCA6OIfMKY2EXURiKTadvR 1WyBU4cIacsaKULbG5Zl4EacDAGIOZ07Wyzz0oLbnsNkDqyoHEzv2maJjmZiMLP2FMZ/wcsr/aBt lTVwniHwhTvy6yq3QWJCVNWIy7RS5tWfSTMoRDG2nwOU425TJESgPFRkxyE4L8IY4LGkJT7uihs2 k03aB1det3ZCMr744g+sCoJINEgedZyW0THbPoZ9OURlvoUDNHBTjb4WJDclCncWP1vw4qIfDuVo tzevVhm6RXk366ffF1KnqsaARMYh0ktMIt24cf0aBiqzjkj031u53vmOmb9aOcfip8SrpjuKe3Tx G0t+ux7k7gYxaEm5i29o493qOhbXuUW/1b+seMUnmZA2AJRowyiZy02Mloi8E0+J+Fs5KepKjpkW jG4SNwn4nLuT0UkzWdJChOWrOOGK67GWGebA5iTIonn7xoj95G8+t/a9x+wQBhXXrn1un37+ISe7 KnTvOmxbRydxKOudO5yTJx+0f/cXX9goER26DnRgvYZfKdVd7vDrveIZoP4uwK2JJPF0GG3uOixC vdigWDAikRsfjFm8qtnaTrGoQ7Vd+uVP7J13P7RPvrxsJ/bvsf0HD3ncWrgAvb3o9KG7sXf3Ht5V f2Gthpji60T+ODs+YeNjo9aDSPvTTz6zpiacqN+8DRcRz/7NDVb75DMWwNGp+ngrktdN5XbWRiDQ WuERxBspZeW8S9vhxpDxlaL8ts5OIsOghjU4hX9IFLxrPcu+4jKXljD/VGgRQIeprm/EbapObQAF Knc4Yy46SgdkEuGna4eHygNOavjSEE5J3NGE4PQ5sRrv5RK480AnVq5lRP3LXdD4eBR/Z1iD4yg8 KAWtZVJFXYNV9tyyYx+8bXX3+my0c6eNHb4PETVK8Dh9TqEIX4ED6ahUCMDrNH0w3NUNRxtu9tUv LQ3eRWenbBpOYu/Fi7b/Wy/C3d6LdbInKlRfpMk3WoeD6iqIXK5ndXgspDQbUZrfscRuG4QYDNt5 68DnWx+H0xGIhjFixkE28DaOztEXvg8xVY0TdRdPOL+0hd8VbPg6y6rPfUV5rYOExsWiFL26KmDE KCEYhSCUFYbS6sV6723wr/aWBGtwAi5qTtxQxigvce4SANABhNBLYYH8ydiUNXZ3Wu0fPoPONGt2 QWRfChT1sFbnYdzmyHHD6qu6X4o6IGCDJ/ajKlRrSfSSpbbgr2f+W+V8IwG2KES703ljnBNTM5ac TDq1CecUu5xCVnhH4xqECAwRh95BrUbT0NkBDllpxPyVzAVRii6xZ3GouXDjQwxsEva7v/sja0VP TmFjHTGEAcUxDCZqiGZynYOMiQAkqY4FCfzl/9zWoMe+rvCC95b74eTgyz38au/7RF4F1vw1hEp0 jKElDd5amJZfmZapV/C5MeGPxttdL/Puem/7HTM3yustaNV8IK7fmC2qTMS1Nz1Uka6F1HDcWHAi 1bUs4FgHYcWXd5sEs0edulKvFp5jAMbM40fFJo2AJpaqFrR9OP1EnhzobqUOYCq3Cq8AV4q4Izu3 11ojLgdSg+eJ0ID7AU7SA8kJ+/jGTYteh3OCJZYXlQHil7xj9xJW14LlGhtxCqfMedwqBNBTcn3o DZQre8EfwQ0x5kBkw9Y1q8qczpbeDcPZqY/gjoFnmmRaQEK4S6iY6YUwbEAcJv3GsLVDiH765q+t 9/ol+6Cr07p377VHHnnEzp45az996a/t5p279j/+q39l27s6XFkqTxt+EzqcLYh8u3fvRsR9glNt lT1w7ZqN3rtnMRSBQ93dloVjUyxSXtCGjf5wjfcX2o0WVjq/N7SqiDERTi83HqWzl3/XVcEf1yYv G8xk0NA7QIlj0LlNRGC/xYcn3HhGq3GzUiY8whRZpqc5EOTY2Gcaq4n2Uen09FQEqEAqbNfcAJUs ApewGrdIGR7OQuSF4Cin4aJkpH9HWQm45RIdZjg4ZfidJDZ0thIntlH0/8DJwiJTog9k/RmzFOKu nu4Dzg3RVOcOdtCUDV4+b7OEvqtIExMYgitSV291+45bFLny+GVCs2FlWJlP2Q7kcPt37bKXfvqR xThUxeCQLj5oeGOHwZYjcFhiivpWl3JZoigVVrfHPp8YtE/Gb9oIhG4MvI7hwaChHmtqOuIcQe8j U+P2cEPLitE/mGEQmnnrx8XVVDppMXwUtjMnpKqiBS4bp5O1rCTYfiA+8zGIgCo44xxonY/TIvhK dNqGb6k/kozlOBy/PD775CdP46TltFQSbkXgok5BiF3m8HAGCYncFy0/rl4p4uEOUeYyxZaqyrtH fWkOGcPH97lDymr1LCmoUGGW2LwzEF0KKwhSuIGP1YLra4doSRVzN9QNhR9CobSsqHvC1kTcUrlV 8h+qf7+89bn1TV63H/3zP7K9+/Y74k9tE3czBhPkCyjWHbiJQT+KbJIq6a9XhNZsJW1HhUv3W3Xq fKLhWC25svjjdgu9X1zQapm39Lkg8hqwNpDm39ZVGV2wpBVrJgBdNa6m9VS3pP4Vbsw3boWXNv6I atSSra4NHHd1OESlMrHDpfCZlEhQT8o8VbsGC1ghPRrvkE4b74PiEjTTUFQN3LjLJoc+TAeRAAT8 akkwiYNCUos6u+rtD75/wqZG4bbgnqOlrQbXAXAv4F5eIqbnx18MWA+RSJJwGmYJJTCJVdnNL/os OQxrTpNcx+Y04nH2CqdEK+6K6ihOwBqCSxEdJzYBBPQMemER4mlGWKRnOLFrk3YLDHkc8412uDBQ fEfqKlB6H7dpRLX5WCMnY5xIQ3AOj49aiuef37hl73/0EQfRFnvwwYcwPuixN19/w77/wgu2a0cX 5bGw8h6MITYORbSQaD9E6KQWRiRvR4kKkj96lLZgQQyc2kBFHIh42uzkjQ7lljFMG62bJm9xKl1B MREYgwjc3rUdNzDobY1OoaOHJbBTnyidtxhg7Uki/kbbccuCuE+h3jT/NCqO6QcVoFI0TLJ8nEHU WzEMt3EMwyF0BWNxNGjBuTiK78mCqxBtU2l0YcUZzsJFk6PoIDA6EWGBE1cMg66l6K95pc04iRjo 3VNnLcK8i+/cayMfvGXh8Xt2Ei50W3Oz3QL3fvPaK9Zd12KVREfo++Q92w1uf+vb37a9B4/Y3dvX ED8H7NDXf2CxViwPl+E0q+1LEu2UOvEMhNqN2xdtZPqedZ04acdRz+je1mFNhLiSH8xZiLmrly9a 361bFmxU5ywsTO3g2OX+jRPS693xSRtApy7S1GzTd+/YixCfbaGYe8d1Ntlz+KgjNKvlkzg8TsAB qUIE34Bo3ecGLgF24ze8ccX3PeutxPkVItDLSCICRTzd6kcKgM5bSzUwk29RN8yVpN5RyRWiUEp2 /NyrpS8ouNx1t3hNcbqr4KBiDucSiIADsxyAdapB9xwCVtIZB1jpWtd3V01kKHN4oZi5hf5fHFfO 6Fn7hzI58e8dumlf9n9iz3/nWTv94Bmv47QZkld9VY0z6EuE0ux49HGL4DtXs3Cub3lH3G+NHf9d uVLFqaBc/RZxKYnM3PsrtkK1eXUq7z+mVDyOXxVcayYAvUHwBmPLgFQlSt5Yeddb8tdb+Dd/RswD q0ngtUZ/aVChTWqiWN8iNvSv7KT5qwWSBd/rJuUt9FfZhazyIgUHME6xWwPYsxPSRiKjlUDUzokS fP6t87zLpHz4qNMF7EJpOtCGYYXaSP4oPtu02XzeO4wD2Spra8KZLVyYKxeu2vjoBKtH0I7tOuEc KSv02l1cqSgCxDQe+BWRoVq+A4sAEUhhnLTW3h22DO44UizoUTbrqpEJdyKc5bf0S1zlrFAS/6rP dBiWiK+qOWNj579EfIapPjpU1akZmx0bYnGvta6Du+320D2I1D7nZPh7GHG0t7Vj3t/kiRyoHOmF C2kGTYvlJrDgjoGztkviJkisLCOCDISxjIF8TCi8snlf1LXVSX3tkhZbDeYWJDVDRJTPpfXw26tI NWq/EFdA3xIHazwuXx23GTbkGqzTy0muTIi1FERgOALRoV2ckZFITJuYkuAQjsQ5WMzK2hcDrSrm agiCL8LGWsHARxjbFIOck4I//SEL8wi4XwneRglDN5udwgOA3H+70ly583/guKFXJ46h2lWBKsio uFEYgCS//Nwq7l6xFzloPHDyJMRXrf0Gx+R/8/LLiO6kX4hFITGCh+5cgmjL4qC3yf7t//UKnLrD 6P61ebg5X9GqV1oBp1hTegYuQIzdstPEpD179jHcIMmZuUR4HIqGh+38559ZgjB12zBgm5PqzZWO ayUJPDGtnuIQ9f8NDNhv+gfs+7//h3bk9MP2l//r/8T9GeuoqHKHprlsBbwVOuUhACUaZmQtRPxZ LzrT3Jsbv1BdjCm0kevzWea/2uf9Kq94xSYPIpb9bDJlRzkANhC2LFo4MKiExdNCwpkmHA6Py2p9 ixI2E6xDrNWFyZLGB+EsOBpmzQ5D8IXhpukA7bj2WwGDiFuI3Bn8oKZ7WGN7G6027Pm8VH94Rh8j 9unNc3b/Q8fsm9/4hnOB4tZEXkAHzc2QcdxwxTFwSnTtwG/q/Bojwo+f7h2BLynKGGE39d1O3PC1 JMBx5QgVCt21luxfybuCsfzkt2gtWLyw9DUTgK4L3YmmMHsXlvef3q8CAm4t4CLWikkXrza3/LhV Y34gV4JDb4W0qsiHhX5sYZIhSoj4qa1k4ewAAEAASURBVChuUMsqaMLmaBiR5F96S5SVBfZux4gE wg+u1wJigTKH0KN559079sy3/wRjkAb77PPzTMrrdurpYzaDIyhFe/jG176ODtW4/eynP8O6dsY5 7Z3Ej6CcR7uZS595pyU2YKCTaE4RDGTiL+6ORHoZOII6DWvGixBz8Tk11nx0KFdc35HhERs4P25H tu+zepSuh4exVmYz/jpcwAfw2/YKm0Qv+n3SY3n44YftxPETjvDQ6dPVq7FTecAAfYroWtV54yxj AucomDBdim0bJnzXViU3E4HDrW5bVUmhXFfXJtehMrXIq8+icIrEGffuLa2tuJlplNolZvL09Mqf EO598d4cEeA3xjuk6JdwRJFF4sNJxM1d6MxV2z1CU4XArQbwupLxn4bDkYPYEXfHRWQA4iiHldqh Ufx+yb/gAL4v+y1RjUi24J9JEIog3HbzqnVev2j3dh8ghushF9+3qmWbDffctFl0ZX/nhy/inPwR jwCjLoXKEhzjt6/b2CBiYebYJFEGegcJlwVuTnGdi3IwoT+CiFula1VuUgzl4cHbWMhfsj958QU7 A3cmAvfSuT5ik7126ZK98crLlrhxxY4xF4/CgUQbcq54jRAt5iCLLjM/5F7qYw5z6ZoGe+DUg8Sc rXGK7fVhOONurZvLuvCCvPKhmB2H0FYY1VWWnIWZV/+lc6AMPma1ViDezjOW3swtkVdIVhJWwr5h eDQCUfcZkSpaIbTqwNdmxMNVrMtRytWS4ycd+WpDEGfUu+mTExCz4F8Sp/zivSoJb52+MweLariV Wvdk+esO4O6NTf4DDDkkNelepC+DrLFj1bgywwIffFedIv4SRCr56NLb1o6P1B+8+AOcIKMrC1dc 7mPVzdJKEJH34aef2GSk1q7cumNdGOnVovJQwRrurfMe3CpzEP1AhV+rQ3d2LnG/5HDNvVB04WTG Rb//EV2uOD+2CM5NnmZbBOV/psW6LatcYprJIqVeEX+aOMz6Qpq78G9s0jdcMRTbZf3qKCZH5ixT NIt/Xs5Pd29jF4cY1HWJGcl6QEzJWUvgH+3kydM2iB7Tletf2u5T2+zo4/sRAd+yC+cuOK6DfCON QIhNz8TRD8FhJpnDBE+Xyw4Fb1fYJPlxm8DlyjjOb2twKM1x3GZasY7EHUcaGMRhdYd8v6fouBTc nBkWzdGxWSwow/YY4q5nMNJ46+237WrfPaskwPeB65dtX891Sz79nM2++KILA6eFSH6aXCQQVnlF U5Gfx+Lkb/C6V5CGw/2TEUrRrlCcYTOvS/T3Zha/VWWJU8q+6Yg/xU8Ow0WLML4iBkUUlkpuowPn hiHKKioxYEBVwc2lUi9zz80Xvr13UBvgIhwnhBZ4OIOuq+6H4JiIK+w2S/rS8SWoPwoetuDbcQTu 29j4mA2Cd3XoDWZ4R+71wqgcVChUGISBZMgBDj0wgrHkyxA3ut+GUbyPRztcyCyBJ3dQe99/3U78 /W/syiPP2UA37lwgeOWKa+rSF/bcww/ao48/4TY+uYrIgfeHdu+yH37vO1ib98D1m0YsixHVg39m R47dLzLWvo0o+KWXX7G777xq9Qfvs5o2LFRpVDkbigy9JnFH1cKh6aEzDzuOkerVpjxFtJWXfvYf LYmF8g8oc2d9s1Vy38dmDY/jEMLZ7wyELQYrvBZ4H8K5/acQlp+8c86CzOFOYHS+EJk0WgO85B+V /N98U6AjAtENrKiX3lrRs3Iv5wZ7YeYEQCdZRzJyAg5iOX+JasDiRP4gnNWwJBpc51EvEFxzsLBe R1FpmUrHWMeIloSDv8bpvDVE0tYGR7kNy1uBoOmo/FmsgF3+xfVs8LfGPU7EG6mdhOGGu0S9clgt wskfe/97g9Utye4OXmBfpg991xtNVpnGKTQ4IN121SniL8dgnr/2LoZQafvhD//YGXDJ4hXnCDzT cs04sEDLF96XV69a++kniJ4zYnch8mrj0xbjEF4BMSkuuKJmqGP1flNzCwcxnRLUz+xTC4d6CawL bsyN+VoyLSjhH9cPRz+sH6Q1E4BCbCX/2/u1yX/9wucGa5PLnytuDSeHuTxrvHBtUKfx0cpQlNxE cafDopulLpVV+E+on0VFlHp7c+5phrZzymJCww5YuUzkKoG2RrM/eMYjAEWMLTMrtalHOX1n4Fb8 9vXXiNOatMOPHSMMUgVRUeo44V221159DS/quPvAPU4dYuQom1PNOKLdXhzWcj2EzyjpDWYJwzU9 lcC4JIazZZTMKVs9LX0spfm9hge0Z5owdPJZVYGt48G9R+0ofvx279njwrW99NOX3MmyA05L8Kln LID45P7vfN8icP4k+pElnbpEzRJ6igBcNbnh9l/UD/961Zxre8EVu0VlFyBxTdEfOkEE2GZsLOpH qSRFIL7kcieBO4m7fQqsftsmCJsUQtwpDpt0fOAvsPjzzVhog0uz+U6xcdThQNyJKkvhKPDKrYYj wNU9mjyUF56esdo7wzhRxkk5TtnTAgIHmhEODdLz0jsK/SW8utt/17ZTZxvi5iq4uPcG79n4CKHm oP4qWkJWhw5iBAORIBzk2a4motEQWo6GVTZh2deZsYlLfVicEzoLVQf5JAwKDxGjTmD1OMHmluKA k0P14O7H79kuLJq//o1vuoOLogdIXCnjl0qMxJ568ik7TXtnIRSrCU0Xk2sZ+kcHkofg2sm57qvo qF599zWr33/EmsBvOZaWPqA2TSVWuyUoqDGI1tTbFIRtHK5Wc4EgdjqKdJdzZM87XRhxVLOpp5Wh KOmXdP+qJQrnn85EX2trsW1YKac//8jaaMOJ1g5ExESykJ4s7ykP0lOLoCupa3pmvkQKcK5Q5u+s cEU+jbtgUhFMzjxuNJxjbQ6KfhKupqkrJR94Ijr8ByW+HTyI8et6R3A4DnGMmopXuJ54SdKcqEL/ MabiAg8idh3muwejiyOIAXYReUVzROe+8bxwuHyOrF/Hct+aA0rSTdUBuKENV0A6dLue1DPtafOw 6t2tSJpK2SnmFsZ8rYOoRUTiRNpB/xSCVDCkiE99qecTG0712B//0Z8QUvOgM/pQn+hw7OY8aCmC 8cKFCzbBunxg3xHUH67CfZ+xcVRyJvFdmGefaIMb34lKgrjSrRzGtB67QyBzSWtyuc31egfwXBe6 P1vRNRsqc21Q8XZhqJVvPaM+P0vKBls9rpfXU125laytG8ottdR7ruP4s6U1qqvcwrYUAp20V028 E4CtMH96XjXHhl+QhaPh6sAnqlYukAayCAX2dHqvuc24NH64CUtDptlsrhLVYN+z3YhV5a8qh9ii yrYdbbO33/k7dKoiVsviW93ABk8XRSRGxRdXJp62SdxHyJ2FCIFqDD8a2vC4u2w30nesOlP4fEsR paShrslZWz7y8KOO+JMbghyb7XPPPW/7Dh5Ecl1j+zu7CNFDnFVOmu4UT372Rydo0WJTumUr99BX 83TrIHMlb3LbRdyE4ZqJ+BsYHLI33nyd0Gl3MQyagSMGvhfGVESFyAsNsoynwhA+KVk2kr+Cg4NE Su4NNhS9JVj9DSIBJyfjgjB798TbqyZGbzPlh/DRVxursxQbyiyEQ3ICDjPcnxoOE0K6atwGTWSm rO+upwfajEHG9sgOG8KX5Ricrck8piDgehQCUpw/GflMS/UBfAlDkOnQFg1MW/edGxaH0BzetoMN MmjXzjyNu5ddNtyMzh4tG730mQX7r9t3/vD30DFtoT0Qf5QlTkkU0SKRtuDsYMmO/0y/fdrks6hn 6LcI4FOnTrnN8Y0337ArPdfsLnp79Z3brbJju9VJTwxCMcPBSQc6GSUpSXdRzqgbu3balQ/fsM8+ +sCeZR5A3zjCsRqi7wc/+B37xey0vdxzw15o7kBnS0SbwwZXhv+n+E5XRaW11RFRg8leCWyysp3C w3qSfIqSojmEP2ibBiYtFTWINpjlPGV8CVPk3MMUF+iA9WpSXge9yuVQmCeKT75hn+WbsR7FTVNg FLUVSSCIA+1Yy8pA4g4cf+a6xPGFe+7B4j9+vXSC4HbEqH+v6F31gbqxQgcB1FayuHuJz+TtovOJ l4WYx+UOODSBGx0fj4uyl7eIeMM0l01jnkIfWt/TIwnnPUJ+CucJvhKAzuXexAvg0l6UwZq7ujdu u86/xjhm7dJ9z9koMdCnE2M2nED9gegyX//W83YaaY8OIjpEC6cj9AvMUncwuXP7lv3qlVes7uBx LxgFBUcIS5on9ncaB+rT+MZU9AzNZyURf2qvDllrIf7mW08fuW76ivpqvuJVr0riyaq5NvbCmglA H0j/e2PVL5PbR/ytHiPtLJrIIFPpWboMfGu5XWiD16R1Ngj45PtPm9KC8Elb1E/OrQqn5XwNRhea ZWUl3lvlXZVUxcyPcDrsRdcjlWEjbq9zBJgsakV0faO71sZf+9TeGCawefdjbN440WbVmNGGzeYz C2euik2W/cJZt1VixSluTckEkoYTWMERqWEK/1etO3a7GI2sICzcYTZ9OUbFmoxF5fDhw5xSD3in S4hZNUW+yyTC1YmV/XjtaS6Ph2drL6DMHA4PfGQoM896X3PVzDVsvaW4fBL9gtKOuDl37m17/f3f 2J6T24iYAhcOZ7JujeG5h4Ms+IyHxEqzuD/JEJGjtlmEGuPEGMGj9QqjZF+Um4CgUwzqGox6xDlx oQYpL8qhIlDTZGHwrbmhCZHTANw99JeqamxwuN9tMLVw/6Ru29BaY5PDcRvAIEh6geIEduGLUHqK fXd7rY+am6tiRNDIWdXQBIQe7oYgUIPiCiaxCoejeeRvX7Xxrl127sU/tnhdo8VRM4jjCxOEtiyc zpErX9iLj5yx+zD6cI7GC33sGJNsiK4ftAbos6DHPU6sIwDA4W642a0QkBcuXrDXMRy5/vE5q95/ 2HZFdzrfhKl6nF4jLkR6STxkxNgFPbgoOoY13Qft71591U7c/4ATeYsw1OHnKJbsmd/7I/vJ//m/ WyfhKh/FBQykeREU8xDprn4N59LEOScSiny6FNbYWmKCV82/6ggCvz2T+LSqgAisjHIYaEasGmbC KbmG88Wl1ofpWdZqcY8YS4U3y90YsJq3L1r+vgbLNXQSG1rGNbwgHWlNWA4IKkLYIcF1EAKkULIr vtQfepT+iRJNhnaSOVvsGLpEBtckYBMRXk14pdlwlV1AxWQG3V9xEMeoM49eZoWQvWj05I3AJ2pK FOtw3bn60kNwS076RfRkOYmKixkFxmhNQfRbqoCtukd/5nDUkEiFOQRlLXb9Azt59e8hgomFTiz2 W9ntrKdpa9xRZU+eOGunOZhoPupQQxNcD1QwsXSQG2Le/fgnP7Gb9Ffnoycg+FDLkFuFguuaNB4i qpmjTVgFa+6rr+V6S990xZqTsgiXvDR/5d/5x/C9tmbxdqEZa8s339I1E4CuRlfpVnegN3nnQd2C KzXhq2gLdZQcIBYYTWrv6Qr9qfwiABGfOAUmdQWKTC6H1pXi5BZNyixZYfGLy18rq4vIIVHqemZa qaIBljlsLQPD9vjNS9b/sx9z0sOKDktdByoLQgWisH3nPrbYh19Ytnu/fYG/tTjGGmlEHXkWhUpO 9bXo+NXXetFGyDI3AeaqdCu+13hFPZCLmOq7iHPYYGobGp3rAHGPUlB1U4h6pLAsLovTOUN8ARnh uEAqgTXLEYJeaXM1rOnCjdFGBqPM2rRxLe2MMjOX/Zo4In49G+mVQoWFIrQ93+3ptUp8sh0+u88m 787Y0GUidSxD1wsEmEdsut6GoHbLEEODpVmRg7BPo+uZgNPX2oTlNpw7dY97h+dOuVwgUECKcEx3 EDl3bd9uu3budIANjRJRA2fI1Wzes+IsEXM4garByATW5nAbZX3YhihKYzsCATdDGKeGiSlCqiVt WpboYFHbtRvWgKPxgYkqqxsZshzctAo2NxEVIW1mbOLBUNhmiASSi0/asVOnXXhIGQypXFkUO+kA PxyBV5iH6jI3xdUO8FtJf11XUm4NxNyZM2chUrvs1Vd/a+98et4qutGZijTbzCgxu/M4Ah79Eggz du/AETiWjZaD099x4rRd/8Ule/21V+1FuH4SK3prk9l9x47b9dOn7E0i9hxE+V66j6qvCkD0Twla i7ZhEBJIYWhB6RnWDlRWIujZRiHAGB3Ru/MJQ4oGRxwSBh1ifiKEpXUzBGA17EolNVJsd/ohwVyd SOC6CUICuskljXQeB7oBDAYC0gtW/3A4NLi2itmY512tNzrIaa6Ly5vXfd4rBsMrbeFfvZckYhAv z/XxwjdK/xJMEdQKZiHOLsN11kE6DV5qmGbgMOfhkvmjFYYTqw5RPyr5agrCaYnsJZWQMRFdx0M+ +gbyyoIYWzishrh269FWJeqYhxLCL0F896Eqm8412PUv3scqPGGh3/9dDk+1dmDPPuvEpVYzqjyd O7qco2fpYYv4E+cP+twUz9jpBzI4b731lr39+UV0VrH+vXEJcTlqF7jlismYiYNeLWPY2tWJ7nUh JjDjofFcb/LG3fu73jK2Ot9XDR1YtLakeeZ/1pZzDW8XBlks+K1NcxWB5VtZF/W44ounkua/fmt2 l5HodJ0I8/KPp4WX2SRnqwGxKTSKgl/N4eTudkatOhqodSanJK0Ve12sr1KVUhazN/rFTQjAa3Zu aMqO/dffddEUtPhpQ9SJeAzdvpGRpI3Uxy0xwYmQxUOny1hjrdPPkp6Wmlo6FeCl7a47gF3bSYLv LKJCLax+j0i3SYRgBMJwlmxy6OuSwGRI9Mt/13uwvr/zZQjo+V/rK22ZXBSrklXDf0opV5jfOtu3 bm+zG/1fWg49zbTEXBoPNoAFfVYYeM0a5zCYp55FL2/pcKQ9lcNCxb1xfLjMWhMOo1vh2IXZhJT8 3vdHwn2Dk+KqV8HFk1PyVhx3yzVFzYWLEHQzuCZJufi+NXCdgzgzn8AFRbo3bR3EKxW3TQRXehDL Ww4TYXzlVWMQIo5l880+a5vM2uWTL9gHT33Lkmxykxgr5dCNcyQIuCdyQAeP2pY2u/reu3YQAiEI 4ZYFliT6rzOIvian4rijGcWaMunWC22mYXQCg5U1Vgc1VE2EmQjlShSozVaNlF5gDD3DI3C1z71x jrLi1lbVAfGOC5lk3Pa886ZV4pft4pM/sAt7DxPlgrjYODLfeeQ0/gZ/ax1wOB9CRULieYnupIt5 qKPNPuQQNsEiFKV/HAEGJZhP69CUZw7hEJtNW6Ldljz6cZzOUui+jfN+PXM7AgdQxKLHx9Fo0Pve f6sHrnvBlCVCcHW5KW5aVlGJbhLyhXYM4f8wjk/Q7jZimHuuPSFCgWBPG5xcxO+VjJk4avRBIApB SLk6D6ShSFOMxQzEUh4jnZyeq+pyknux7LfnSnREoCJg4OBb+CYNQmcp6xYZxkewiSBFl9OF/Cys 0RlUD4Q34pa5WMRCf3QMHcB8RTBe0foo4smVsYG1fQ5Yv3n+xJh7wAXP9DibCtg4/gTVn7ozMV1j U8FOi2M4FMco6fT3XrDGh7FYZ0KexlBKne+c+5NZB4g07RJTVh9V43QY3QDlUaUYwZp9Gvy4Zw/d dwydP0Kige8BmB2aj1WIgZ1HAN53nhccDIJj/UkwbDlZsX7wvE5aS/5CYzRWpYZxtaJEOqwx+dX4 32vMXu7rDLrwZEuTOo9mqCVbWtUyXSV9hgwwlFV/MYBMLG9CwjuRuIPFUMRVvmfA8jhZth0sjO0Y ZayW/A4utZhwbyURxWpFl3xOGwKtjVZ5bJcdhtvS/kCX9WoI+IgAy7LI9Tz/kMXRvRsixlAtzm7D nO4jMT4oXUv0oQW2VJK4qgKuTxTLuBQL5wQL5Sy/pWgeJTRbZSPh3tggXTeqba4Qryy6bo4MV1d4 z0rV8o/7nlqztbAv1/tr7xfBqo+S0DcEkV8fydueQBqckFI9xBAEho+ialeA8dSNHO8uTjIU0Thm IBwaBsetlk0/gOhIxJ+4JNqM5saWwjzuGhsL9VRibRiFeyTCSXOyCcIugE+9QGjMEhARcXRPq+rQ R8VAJMQGLZGw9AI7OtqxUKy3yq4uVBUgFm/csJqpaQw8qm10R7sFt8Vspq3JPm4/hl5bNSKwFG5O 8HfJIS3L+zG4kzEIw/rdB236L/4fy3309zZ++ox91tVtg/29NjZFKEHgS6ILJXWJarhL0lHMBtFj Q4RbjbJ8jI2ykrbWQNwoWoXo5lmMoxLUMcFmmsUR80QsaEQqps30AVbE0RTROeT3cipllfrArYri jLm1ssuuxHbYL3/2K2vmgHn4vhOWr69zc666DVtexMcVePttDFa7w6eIw0lmThbCcBQunkK/NUH8 VRbWNHH/coolXMEHQ+lKiPQY/avkj72+xT2sy+BeZUwuUyCC8Pkevj5swfevQLjVWORUG4ZgUYgP DEl4XhsVKcl7xHAO7MHzwDRcvxRcfMZVOCADrRzjlGTNSMNGzuEIOc+aoHXmq0mCxWun6tMhPQS3 ci4JRok6+XYJuKQ3ypsevpNVRLBzbj73ige8m4F+vsKzUl9aDyUBEcfeRUcqeskzhME5PbikhS+E Ws4CVR9VBa6k0ZkeHquzoWwTv1l/NYcidfj8i9vw5+/bkydP2JNPPWMhdPakA+jXk2EeiQ+hJkl0 7x/0VKzGx3FhaZ9cHb1+7m0OOGN2+vRJnJ632kfooQ7gR1JeILT/eGofhXxFbVj/Jf1RRv+tv/wN 5vSGeQ2FeHvZepu0ZgLQX5C3dKehE1w/aMXeylTAhE0ndErCrBbNt0eTQOb7GU5OmhRavNaU/PfV Bg2KFpQv71juyj2IKa7ZeFwnLteHys/m4nZFNo/iJCgzwMZ+XF7yYVnpfcEBnIGzhy2/o4W4vO02 xOaF5rSzuNWs1EKRv2+PhQ91284xNr+rCefWwMc5t/gtgYhTMRtREIuxGErhscEJTqiIcODMKNZy FeKDKiyJ5X9KeieOGCiU4W0jPjHo3fSbsqSaDd9YqXM2WLgDeusgn4NOTdikalSMjEBUoLgCd2/e tUPtMTvWBpEFN+0iikYeRwScAAFCUBDV8jXJ5jjd0ezcATncLQCnd+PoeganIeKIxiInuAHYRdpW XQK3fJGmOwYAgH4PDg3yDvpluIVpQD/PbU46KHTvtHw7FodSF5gcZcOOY5QER0JEB/Cqrp6+O7az a5fnswyiMd7by84dwsq3xq43n7C+HZ0QIdsQP6LQjgXv6LULVoVDZOFzEu7eBGEgoy3tNnbjmjVh EJW4fc2+7L1rPz/1mDsQpQlfGAB/W9hJw+FKm8USUkTMrOMW4VIJIjILYZjDwCmWxssdXDStJbmc fGESO7im1VrO7LWZqnobQLwWZL43wk3MwCUb7zxkg+3bcWZMuDeMYQgYQS/k7NSBJ6zn/Z/b1P/2 v1j6uy9Y6J/9gUHlWuPufZbDFcxd2rG7Catm9SzWKc6yGROLMHOrljoi6mcNLinERQPrWwqOzhjv T+MTrymLiFzjycefEXo/xkFtNkk4PQgJmH1WM4sBWqjaknIeDWs3koGIHQlicZu2ox24PuEdb0nx StGBGGaVzSArTUH45dBvlDeAvDiDhboKYHnAbfHf0mtVoVIAkeHbiolmFZdRfL1iPj2k/BBqEFUc hBQNaRa9VNfZ3Bfuyg3WwJ0RfKEmwZ+MdR/FUKhFnFOpJbBGcoqYwX3RxGDYBrNY31Y3cB8imvwT vbcs/sUHdqS92b77nReIYVuDuD/t9Pvm55pH+HkrK5mKkohCjZs499sR7yoe/I2BjF384nM7+sPf 45BVa6ERVHZ4ySMW9f6aWl9U29JLQeMgEtosBG3py/8p3KEN3gxYH7BrJgBdNV9Bx2nQwdb1tars XDQEpJ+bHWXnW+OLWoDc7PA6ziE07atEL0gK4zoxycBh3ckhM2WjexJAPw4fBRTFTfVhqaQ2I9rK QzDq2w7ssABuLNg5vLc5neXkAsYDulQJ8/dUlghJFg43oZap0mUQPHjSD7bgMmMwZeFff2C75ALj iZOWhGMpa11x6SK1WAWyK0yG0Db2umy+vrkrHhSeheGUiDgIJOGUIEYI43y2o3kbXJtaFMuJLEAf +6dJB97cSqXhX7aCuZo2dLFSf2yo4H+AzOryTWyPiAD1v7ghQ8ND9uADMedMV6jrrLx5pur0CaEP VjkaZ+dApK/oNG4D9YBRGQk2tSQGH9uIhxuGaEqDk4qIEEPPTtwUt5SApkpy46E8GeqdRH8vilqB XMp4NWnasOHowEA5DexCARwjDwLfxAAOaFurHTdK7w7cHLYElqcKlRbkwDEBt20aojYfrrVU8w6b bD1oCRxDD3xxDsV5/FkmJu3hMw8h2os6n4Lvf/iR9X/4NoYqk3b9vgfxd1lrl/ccsuCeY4RPZJ7w u3Fi1B795Y9xORKxd3HvMt7ajm5ioSFA7Jw+s4nnIFRhD6p5dBZ+FCPoyUIIKak92MZCrxGf+/xb Vt93yRKtu+G41zhr5coKRNO0R9MzAmxnK+ut/YN3iFQCF+rbL1ieTbkG/dntxx+wC6+8bI9KpZJ3 dYCCTLOqIGuONxRzxJ+r101R9HCxkG3SGNHvU3B3MY+xRtz6wFPys/F6wBoRE+eSECCQfCMNrRY5 dgzn21F06nQv6XxEAp5encs3jch/Bpaf4nmnOMgmwYusdJcxuqBKveqS/134+Q/+5fa3LYJCouWG qz2282/PEVqw026+8ARh7+ht1tSeS3dt4PoIxjIx29a6w85f/Iz18Z7d98Q+DOUSNjYUJyxmnH7f js/EPeiHNjtiXaCOXP3CElcv2Jm9O+3Zp5+ydg4kGZgNYiRKxCuCze9w4caSxC3ZwmhchEDvo/YQ r6yzPWeO2Qdcf5sDh+6rGEcoFka5qNglRa79hiovAdvaC9qCHMBVmEdlFy6qfANpfQTgBiosOytY srGmlVnTWju8zGIXvFZUhxZO7yNfUohUWOAmEcm04TbCQ/0FOcv8QaEoLgeO7bYAoqdACxukOq+o 3gUFaQZKv+njaxyZIbJkFdkKwQcBKDZ/Gu5JuNFTgl6Qb/EPNhTD8jH/8RUU5esscHwvm48I2eUq 1iO2GvnGGhyxjlffQQQ1bZP7dlgCqzsRgK5zWFDcJkw5y2FBEIKgAuI1KwIPrkDFGAsX7UqinN+4 cxfuYSQC9zpB0DjrMS50PQfdgh88+C/pq+sB+l76b9LLjCMWDY+OWFNVG1t/wPDt7QgJcSs0Wvor B+BOMZ8f8r9WNIoQQXD/MPZpwKChBR2+ACLRUcRIY6OjtmfvXlDSEwP7jdP8ExKICAxJREj+HD7q vE25QHSymzn/g7zT2Njo9Oz6+nqd+LepE7dFcFgqIbJqcBukfEGMiQIYm4zjIqaWuRyMoA+Fi5mp qRs2deED4kmftvuffMQefuRRKkY8iZPl+PCgvfHuXet+7Fkb3LvfPozV2CxuilpZFzQPFOGmumfC uj97j804Zucfxc0GXDhxvP0knbAAOoBBuN3qJyWtIyLUJaJV8npRBCBRMJgXk8SxjeOeRgR4EjHy LDG681IwhpuoMblBTLbYsRPW9chjyG0rXfskSj924gH7m9+8jGscLKshrKX75+3mrpqSf9TVAoAo tBbNRWyKXPhOhiNI6Dzu1fOhBeInurUnicg4g8hYOp0hLKVrEHdnKmZtDMMSiX5rEHPDIHbGIBNk GkUEPxiqselAjHCQjKX0/FyDXc2q/Z9cEse8um/IWj+8iEpMwu5842H0SiMQf/12/YM+27f9kJ06 c9p5Pei51mP9t+9ZzadhG+gdZ4xq8DFIOMPkLTvSBtHXOcNnJ/5Tie38wZv2vSces689/zWrRzVA utsi/nDQIExYFhXcM/5wnsCQR/M+aP24d3n5tdes+fijRIRqtVsX3ifqU8LNSTcPfWRWuZs6gt4u 62Da1HI3ozCg2tzGrgrUmglAdZwb7VWL3tgLrh+2vDOEDLRoy7HB28TUI1qctNgxF5weUj0L8mjf lLUQJFcLoYeeenMdCeurQLM4d2qTG6llCqEWCEbn6BmumURl/vsepAVlY4eNK5QDGz9/GbHzX75q trvTQt2dWOFBOKqByySVNpYO2zCbXeW+nTabwD9fPZtl0aa2TNb525x6KnGzUT08adNYAU6wOSVw 6xKFAIjt6bYKHNsqqS89MYJqLXAbFjVH72wtmql0/7OocgG5GUnFrjjea6xESOp3ijvWe/m3BHrV delLe+SL89aMOHXmwDYbxKGudO3mEm3LciiJd3qsJ6cD6LeX/CLGsuRpQbVA1pGe3pDEpnD/eO4R dsIHr1k6NOta7yqqwDBi4Pq2euampyIg/FWzg6qD/CIUJerqQtfv5s2bjticZd7UgGfVKKqrfNUp QlEhDGfQaYo1z0DgKDttobYHDh21h84+7IwzNFYxiLwARFTzA4/Yrseed+HiplUfB6RAgcOnw9gU uqsXeJ4D1in8AEqMuzh57Vu4cqh9i1MFnMI7h++3wNPftoaxSRtGby+YHLVoOmGNmWliHCftymyz fTwzYvv/5Z9b+PGnLUu7NTfFkd3b3W0ZCNBbGJXcj/ucbBFuLKjLddvCtUzw6FODpIPZbmO0LQmV mkHnsxrRcRUf4dwM3g1yxFJuu9UPwQBnsnM7lqNwtIgdHtXBEOpRfM48nNbbMUTLJ7ttagz3K4SR DIi95PqQF/4JJ+HNJD5Z7z6DPjUMgTyWw1Mjcbt07qY99eBz9uhjj1lrexuW5hXWtWO7Td1CQ7Qn aHsaDtpBuMxjcMNH/vX/bA8nf2t3Tj5qb/3OjxDjo39JLOiTD5y0xuYmuPZY2kMApuAqLocGGgKN udvr+KMtxxn4gN9/93ev2CAc36P7DlsWVQitwv6BZWuHDiRztW1tLV9l6V6L1lfjmgnA9VWzvlxC nq1O6rytTo7EKFGRFu4mFvUJog2k0eeJIuZhhqwfHLf4rUB9+SXzXkD6d2cOc+pn4RTRKO5bIYWY 7G4h9W8s960BQtwSkINZEZFu014ZHfV0DGWdnhY2s+8/gacIuDdd4v4t3dhKV6sNGaVqxHshRL8S +Q4ioguj87Qbzl8NjkgFu0BTk9yVQ6TS2LQch7F03Wu/K1gFxZanEvi1rjopJ8BJPNTXg4NdNnkI JD+5kd3EerRxSHev8vZNe6C/x8LvMJ7ffchGsZL0CMD5fnO9CBfQJeE5CZrEdW0CPAgjxozCCfOJ vWYMQJo4XHlREvQeByy1TR9lJulduXOJQCjW46jZzyv2mXRyRfgpabOT+xd9qnCZMoXrF3GU6ztR myhKIgY7saDtu3fPJm8R0QAutfI0I1LLvPRjS9ejLP/Qw07/aQJH6Df6+q32Piwo4e7JKMSHyy9S BOh0fZN9+LXvu2cJCM6gcyXiv7G2b+nrTRHL98qRU/ZQP8YfEFi1Y1/aLjh/csky0bDTJqdxcp2e tFpCJAY6tmGRiUU21cgvYAcW1d17Dtj5D962E+CGU+EUCPSX1jgRHkZ4Pnzm4JgZ9hEibPV7cdIv tbMJ6/sUz0bh+I0DV5bCqpAM1AQg9EcHLIovwzzjGeBQV0kc4QgRNkLp+R5SKLIGuLbT46iy5CEp IWYX11Vc7z+la43zJIfx67/7jPP7SAfa2JcDOG42++a3vgkOw7WGqJeBxnPPPmsHevbja6/Zdu7Y YQ0YzF2+ccM+RDUnhdpDEGIwBuFXzeQJcmj//PIlx1XXSHBUWZH4U5/LZZBUzPnvOM4iAC9evGhv v/eJdT72NXR1K216csxq2UPCHIp8bPHxRGX800nz+F1+mxce/MrP5725ZgJQIG71pinQhAAbIIVU RJlpPZ1eZtGF11RD8Tqoa21+0myJMQHaZfE0MITOER7QRZhtNUiucxlFiX2VBJAPIN9ZJqPnXkMv rpBYRAKHdpr98dcIiAmnQA58WXxWSw0ogzezEIzsbGfxp7HkmdtMVstceC7F5llEFWNJlJrxMBpG 91ELm98OudDyr5crUlVveVqlCzev/k1qDOMSOv+pRV76K8seOGTZH/0Zqzg4OYcfmwOxukWRM+QU tmLPPps9+5h9OXnbjtGMDARXQJauc9tBoU4fBj2hgAzWrlJoT8P9a0M3Thw9n4hzsUOVzXWLt2LJ vYtXJr8L3aVYv/Lr5xUN0kikqh+8IAIwgXPaIaKUZCFAZohQovKa0U8Tt7AOMZjqmxtirqXULhH0 vf5++/C1X1rbofvsaxBRu/72F5bfucNyREUIECkjzT2FwUr23zM7ohJ82AQ0SQB6QMHlbnBPA8w3 L/HMvT5Xs/d+4emyX5QX4pPCgjgJMXloasg6kkNw4LI22HjQRut22778DdzV5O3cK3/L/Irb/v0H 3RolUX0lhPIDRw7Y35171SayGJwAhOOrM39zGFuEcOFUc/OyhXCanT9w1LL7jgGKExSXBEnGIC0Y rGDKgt9vfH7Svm3ZGEYzhMjD6jcCUT+FIUwcC9rqXAIOIEEcEQ17oxmwXdNEhfnwrvVhrJPHlY0b t5I1/RO7CVrk4YYmW7zDcIUOWcTLhsVL2LWLDkdnpT6D/l4NetJnzz4C8SWNTG92NKLPOvPIE/ar 8xetBaf9J371Yxvetc+Gdx6wd9FbffbJJ/HQUANBt8yhvYDOivYhrp/8VQp/9BlFReLnv/iFBbfv tdY9+5318xgW9Xu3E32Jg5Bw3p8NWzdqauk/xlQ0n8sGb2NtWTMBKBCLlryywVzri2KcfCUbtNBt Y324atN0WtV6XpwcAcg9iaha8HWV5oSdxZIvEICIWhWgRYW5ggvt0ACVm+Y2lEIG8ip8URaOXNg3 s1upLDWC8G2BM4fmCyij/uYKFPoZ3FEWoH70gkQEpjXgZSUP+9K45Ehi6ZwYTBKJAWe7EM/OOSpl uGYVNs+VinQ4xgulenOlfGt6tqWFFyBxdZTbfytAX0DSUG+PBT5+zznmlq/EvPTZXH+qok2oh1JU Ep5GHCcicIIoAP/Vn9ubP/43NvJRrw2MQPxV1FmMSAfQWV4SbOCbOG9pCP4UxEYG7i/kqrU2trkQ anrR59rl0bEjyjz4CZEGkecINW0urh369kSU7j5lhuDAhZWHzS9QdJBIJKbt3r1+t4HO4pi8Fq7W tnY4Y+KIsKEpCSYl6QyKMKynzhoMsi5++QWityEIvYB1Hz/hXMu4HMBQh8+0bzz1uP37X7xsw9e7 rWnnboAXn8RL4tBow1QHOFE0t2UgxV8qLGy8PHftUbuYS6WGRv2Rg3hVOTnWFznDlk/57PQt6x6+ js5XzvoaD9idxsMWxUL5/uSAdWGA8pvPb9jPhybtxNFrtnP3HnS+4JBCqI2hsjFK3w1bCgfPWO5W xHAzQ/g6WKZNmUGseXHfQ10T/E5BINRDs4qbuhhrvOlOG2nzZKTVJtAJTOfuwembgUvJmnDyKQ6h 6PY1bcfCeciQ9lpftNHqEBXXpbEGZ70USlRgAR2sgrWFHjM3C733X77U4U6nmq4Qp6+5q946jjTb y2/+jcVkWQ3HNK9DzWTafv/3fmQH9mPlLZzj0wg3/OE/+JF9fOqqNb70H+zQ375sI4QvvPK9P7Iv Xv8FjqBRmWCeBBlfMTGy4IPGgv9urLmp/56+H1IhrSGDcMXTEJNvvvWWfTkyad3PP4MYH7dG+LuM 37hs973wdef6RXgiHkLRVODOZqfF2LjZ5a+3PPXgWtPG2rJmAlAgeiewtQK6tve1zZcfFHxtZc+/ vZ4On89d7pX6y+07CzK4FjJx2EjwOZYiisD49IS1M5nEqdDT0gmYNVHhIGjW+f6t8rhJyMMNc76f 0CdcX2IyN+I+paPRTeAlpbhZXugzYHBJDfO7cUmG5aGoYQeowodhPYvQXZxb32BhX0N25xokUofi +zi+0MRFhYvjJ59P4v9e9lv7qw/7si9t7MHWOzPfGHxLcjOe2aPHLPD9H1quey9HeDgHc8i7lhFa UvKSG8JxoVEOzlIT1rEHx4YsMTlkLfVBu8uGkcG1T4MsUSGsErAS5P4kC9dPtE4YLlFdVQOEP8QW 1roixkQMpRG5ZtlwKnp7rWJ4xGZasMxtrHei2CwcR7YcF9pPhJA2KRd6jYumsQkLSVTL+5HDRxys Kq+ysspFEskhEpMLmHbEonK6rKTeEO2nb3WRNi5pQSjiwzacUD/z9HN27vOLNnHqIYs8+ihcsYMQ 04i5aLTEzo8//oR9fvW6ffjmy5Z+6EmrkbidAuUkeJYIIQFUQiIQnJWVSAhoXxq2dgb/fSkU8lVf Q9dO5+pIBF5ObqAWK99qfdBagUg2WEs4LSB10ShQmZjN9BMtZdCGW+63nqYjjvjrHvnMGuN9qITs t8M1B+zW6G0bfA1dLQ55s0070b3DWppoKEfgcsrly//P3ntGx3mdeZ5PJeQciQwwgDlTVKAkKydb 0ZbbqdU97unZM9uzPb1f9vvO7tk9u2dm5+yc3t3Z8fR2u93tcZBl2bJlSVawJJoSlUwxkxIDSABE KOQMVNjf/75VAEgCRBWAUqunfUlUeOt9b3zuvf/7RH+oyPoc5xBXOOgNFqAbaOu3Wo+v1NobNlhO DFg32kmc30Ss38RkcwcvdCPxiGid+XUWLm61kvEuq5jqxaF0AMfP+EWs2+xc29SOXLRKDFXGCput s2SzhdFZLO4HVMemnDh8JIRYXNh3AnCbkDVmeEpT639kCVoJoqqz5db11nWROYaz9ZwidEpZO4+8 fdQeefjx2SWcKeJA3MZNG62Bv1OnjtiZE8cs2txqIQ4+E4jpr3ReQQy83qlUeP40cWnm9gZx+zym hg5Izs8t8/HdQ+/Ybz/80BlKXcDFS/XNdxGOkbjW/BY+e9LKMOzZtWePA6DuQJbx7v0cUwj9n15a WVvSBoCq3OLgJL2q3+huASPBoP8qEqu1x5mYa48WcClRu3BOxcUWXNdiQ598gnk+4auk+0LD5+6+ uhd88vmFbgYKTpy8JYbCIm8qiM4RStM56E9VSIR29TNLfqMwWY8Z3L+AwrMlAd7sg/yG3l28sx+d P0BBpWdo4X5erKKzz17/QY9ohEtZvaOIdS7gU4ytyrX7+rsXuEIHSr9LJ8VRHN76Eaclk+OKJL8s 9p7oYNGyPmYseawOsl9GJ2WsUotkLKLkABLdsMniuFOJ4yA5Lr1UXSepp1Zz7svvo6wI/cj/CwBG D97/MKHZpq29/ZIdPHjIJgjJltMVtmzKH8a58kxuPrGk8etIjOpcXCjlAmS00ciNzCTuWBRuK4J/ vTjcvJKBsOURS3R6DKtiwow5cEQz5CGER6BvwnbxQS6YFBc6S47wokTeINJHGeW5jY2n8nHg3IB+ 1CTh4gKUp+gESuoRTRH1R6J7ePcAreaOXMM89tijTiewCd3U6ZYWysLyn9/kU03clhw411958kkL /vhHdvH8SRu5rIgLWMfi80/RM4QmR9uJkAEI9tGuSQ5K2ehBlhIJZADF+Y7Oi9aw74CrR4Bxil/L NqGSM2ODtBnxHhz9EO+adeK89GBwc2wMiQOK/yHEuS1hgb/L1g8gu1i+0/XzfZGw5WIZ2v3pKfuk Mc/6alptVxQDEPwsFsJFulK6xYYBgMUzI9Y8fNmKyaev6Sa7ULGdWM1Bq+5+F6DuR7wLGKAuyAqY 44TX468fceSV/HXWX7YTzuG0NQL+CnzZdqUEdQAAKbxfqx07YTWA1DGimLRxXzy72GJjnTZJrOFi 8pUVcT4LXRhPVuN946jPBJ2xUFympprU+vt9cj0ges8m1GLz1jq3titCx3svHbGbcDy+trmFEfHo eRK2fBYcawG5Imiqu3mtvbn9Fqu//T6Lol/tZ28awtBJtK49LUuRqJjHAejV+Xbk2gwHmBkA+RTv 8u/305dfttGyOuZEpZU1b7US/E/WnT5mud2XrePCBTvwpYesigN8DK6uc9ie0THTzNXf5zFRr3Rp dnZ/WV575nbNFJ9PLnYp3r6820RTPOmBpuVlkdJTSTpwhaX0xApuWriQ5Ikrhw2jCgXynvbLOD1l gdOiTWleFec+eReZrkwWl5jY7BnEPwVA4UMrSiwmXyEgMF8X06YmnOji/2yhQWZRiB/vsPgLhyxe xULwrfvm/A2uoFfk9gNI6VU1OR4p5helD6ZxAVPAxux2QTaFZC8vmRU3uHtZvD6bNG8MV7vAJRub ToEAGh0sMKJwPQR9JdPqwj9vrSOAA5wAT1eoAP3XIHp1g4CbsvJSAs5jGNF+xXN7wkbvx2dYNiG2 CgBlEvePIbId528KoCc3JsTV0ZkIAAWoq8K1UQVAEV2yAKBJgI6Z4TYqProkOo/AVVOYLcmr4qgV DPRNWTGciYA4dZoHlJvNRpYDd0ti1jhgM07ZzsBogXmijVSX1WsSFT/4wAPu8xmU50+e+tQqykqs GSfT9fX1Dgg24wz369/4pp05c4oQiFhDQtOl+BNcg5Wm6LsLnanhs2dwtXSIiBpZNnnzbXbnfffZ x8eO2vMvvW6BW+8FQAfg8ADUkw1T6/gcBRALIAfxiUkzvEq5n4hm0rDZLkaKrKm3z1rgspWOXbYB wF9b5S6bROezru+U1WIgkos+X11nj1VV4RgYMWtjH6JyQPjlkk3WXgqXD4ORpt4jVgwHr7ew0S6V b+dQmmUNxBuuGA/bZG6NdQHchkfbrJFO8/tnrA/R7pWiJhst3mxVHHibw0fgIPZbF+Cvs2ybc/HS GD5u1YPnbCS/EkC508bwTZhHfapGz1lpPMtyGGiBlCBgsD2GX8VJ+JuM00Q26gFSPkMEj6yTflBn /D6pBwQC9U/Onk8ePGnRvoA99cdfZq7BHeZAogOK/PkpzGgwi9nO4Si7otLOoxJRgB5qTFzpqXF3 f7JbdU4R913c5c7esPWiz9eB/qus4YfQmb1wud2mqput6aY73EFrBuaFtX1qW372d1Z68Yzl3Pew 7b3jDjdpZFUsLrebQBkaMs1Ll5INSH7/x/quJYq6z7YrzXakDQBnZ1SmN06IMcO8GZqS6L00Oy3t 2xcZIW//oJ0s1qpKBaJgKef2dF9xg1qImwhtXEA8RphMHNFyv077TEqd5JFHsdbrNEYGzEbFCo4N 6hoTM1uzOUXSUPY8r81kwaQdpKsfEHiBMHMoF4t1I3XFFLNfKE81RwtHGHESWy4LP5m5/FLJFLEg Igwfz66pWeO4gdqw1aepPK36uO5UR/1XkNSKVWuJ68QFetHR6QLXV9J/ZDfFhuPolXygWPc3CYd7 ECfN+YVZhDkjygSga3R6xKYAIP1DivAAx9vNC0K5AfhyAHG5zIsgomJNC+UnFRJZIYqbJKqYrTkf 9PsUVrpiB+pXAyhGeXYcq9Ko0B1J9zu9KDhuPnTgMDN2IcYcJvYmr7vvqhceks6VDFwkXlbeOshK LN2LPmBHxyW4nJPOYbU42LpXYK+ysgLRL9xLns8CzMmIReU3Iga/+PERKz1xAhCUbUdvvcu279yF I+lhrCsBxaobc1ab9ezGqcZRyQj6i3I67eJ6U5dk0nqiaCAR1D1KT71tlfgh7cuvtYuVOwF/+Vbf f9rqBk9hjJFjw0Wt+N/DVct4jxX2HMGOYMouwaGT3mAOYeVaAH8S3/YVNFobnMMI4K+x77jVDhHZ JKvQLgLeBqjfzOhFG0Fs60PRv694m00UbrDSqSFr6fnICibD1l2yztrgHKrRzX3HrLodkSHudPrW r6fdWHSTX7D/mFUBzrPhLqo1GlHpLEfgIIubHGDcsjgQ+nEMLZH4tB/dVYH736fZHtCBYBiXMJc+ 6rFnvvnPbNOGzc6fX4S+m3Zx5qFf7hYdaj1du3atlWFt3YnD8igGUdvWtdja9Rtc/2sSCfwpqs3H R49iIPIRh5iwDZKB9FXjxeWWvX6n1cJtnsHPZ393B4ZFw1bdh1oAroeqOeTV3C1xMNbxctyOOydn ACb6zVjSfvp5TbQ77cp57VGPpf0oz6QNADU2yb+MdaNa4/6W06R0aqVCSBklOFeAK2ahIdJE09qs sFiaNAoy3yWrPERRU5yOS/k9i4kRx0pLyuxulLkvhvjIpUQT1GHSCxSGio6yQBJbM5AXtUBhBEex c4t/oiLXv7FhzBDvVIHIPT7aNbeg1+RrrTP/I/tBqmyGbmFd2fjo6Yj8SLFgF7d3WojFfRjL4Bgb 7Y1SlFPixPA04YqmrRZdq+KiYrdYKT9xVFNKs/2W6gMp5XrdTV4xes1gOYm2qITZZl1Xk9W4kJk2 gGM85XFVHs5B9Pw5mz5/kegfI5ZXkguIUeQIfPExUWYwVJiCbTgewWVISQ7cQEKLOdDHw/Orl/zM +zzoN9sJ+pliXXKfeXwMFQcflqdBxKWO+5d8Fh3DWFOL0zGT7z5v90s8vMCb5rQYGQK2KkParevQ mSqGqyrOiKwd/WJfcWOEe6JssOzLcF10otJl5iIARtecHpUOfIC1gpoGW78Ry2w4ggXvvG0No4h3 4X5OoSfIrV5yaxnPY8EbmRwjBnalt8AkftZhUxb3ikGeHR0CxA3A+WuxC47zJ/Anzt9pomrkAt52 4Jh6lzXC/SkNDNMmuG1lmxPgb9QDf2NdFobz1+Y4fyE4f8etZuhTxNZFcO52YSBSZSVDJ60BP4NZ wRI4f9tstGi9lUwOwDn8neWL81e8nufRO6XdTeGjVjHWYQFcYxnco6LYGqJR5Flo5IQV4q4G22B0 PoZduMs4xiqT2YoRohEWGNSyRPvY1SJ4Jx4amiSaCYdhsal+n1wPCLCFu4aspKDC9t20X+cE95f0 56ee0jXRrxyO19U32qMP3meftnUQBafKbrnpJlyX4WSfm8StljrDhQsX7a/+6j/bMP2dg6ujadQz xMHPyseQC9+YvWeOWaC73arw2VqOgUl9yy4ru2Wv5VCY76ZbPO4j+U1RaNKgKlPDpfZlfLtfduXp +HRJNcHg4cllpbQB4LJKWc5DalG6nbGcclRIxstSQxYfIhejVCdY7pEvpOraeutnkxgb6LfccNhC GIiwaziP/9zmpflUzGenF9h2zlkMxmobyKmIDUDbD0r0FbivWLx4Lz8W3zgh1MRZ0cZ0XRKyaiTK whOw61W2/lxlFrj3uocXvqAspmAjBvuGrP4nrxLZI2Lnv3q/DWxqIm9EBdcmypsgJuzUMArg6D1W ESmgghisTgRBnR2TY6G6X5tP4nuC9zPvVyqkLtMKuEpp9XJapQqtIBv1lyzaVzPp/CqdI2dYgcho 6tkf2AxK42z5WNMSAxZwB5OXbxIT64P05/AdCec7C13UbIluVaVlVIvRvmqNkTqBrIolKpMc0h2E ZAUtrjgg0BWkwm5AY8rTgTnoSJzIOAAvDgDJ5cDWBNe+uanJbXieyE1RFLSRes/Mb4Twofolh/fm xx+3YOta5nGVVW/ZaTPf+Uur/OHf2ePUq+/dN+3kgXsRtaJhp7w4REURnUcmJ9BZzMdQY+4wFaNC 5Vfareb8aettXAfQjdtQ/hpC2O121rwS29bC/ZsO5cEN3GX9eTVWbh2WW0mUDbhDHej8dSKmzQWY i/NXjMVwL6LcNuIeRwHGDXD+HPjLKnZ6hMO51VY5cgHfgMcx5inl+W02ULwOjh9iZ7iJDvzB+btU thXwFwP8Hbeq4Qs2WFRn01yrwMK/cOKKTcH5y/IRq1kRSxDzBs4eNx8RjAY3womqxY8jQ5JFH4fk TB9CieMv0E/4uewxLMU5ABvGOzcaM5HBP5Wkw4UOXDOAefmozOawTfc5lYb5fTAN3ToahBN9/733 201E1ckDcBegqqR50Y1l/EdHjrizkAyx6vAROY2Yv7v9kjNEbC3dTf+H7crhs1YEHd+8fYtt2rwZ TneVi8vu9FFZsCPQpMD6DLSraac9IaMp0/mvpPK0X2PxWaZlAMBkLT+Dqs6inQx1iZqgxZwJkdFE GUtUgS5sAABAAElEQVTtm5qYMqfX5JT4p7p6Dfov+Fpio5vu6kZ8Qigk7slCFMsyP1tdz1IaqsZ5 r//cGYARuwlOkaOKhsEkxqtCilTFhMcayzngXSDagCtQs5PJHD98xuXp299KWXAt1IfLSnAqcAgb x51HIeGIQojkskapMH1w7TyNTEdx+orHsKmY5eOQtBw9KUVnkHhNfSfw54B0qvVIVjn5znM+6Uyx scRwKZP5lSjViqZ2HxTGjfMak9pjad2lfvbKWL1ysrVxU3X5xLty+rhN/n//EREeoryb8E0m8Jdo llei9yoyzGXrUSB7p/CfVisWvllty0MMnDUybp2dnVZSWmL55B+CE0+ID4vjsF11cT2gdz647piX nbQktJQE4GqHmMjZcJ+wz52lUWdxnHhI+SiUlihd7dGn+flJohvQHxmWNjRy+Goic75Qp0vnzlu8 o8O2o+fWe+g1u7jjJhtDFByHGxjlT4r6WQVF6DEiMUgkp2ZCQa2/e8e2v/aCnb/pC/bxw4/ZJaxt S3Bvs3bgotUB/qYQAV9AFNyXVwsnrt2aAXohxL7tEvuWbLA8wN9aOHdFEz3WW9AE0NuBWDzkxL41 gxL7FsP5223DeRVWDZirh6P3aXTc2iv3AR7X8lyvrUXnT+CvGzDZVrHNcSSbe49ZJfePEA7wYtl2 DJA2YojC+hDswwgIox4cRAuSS/fZJytgfIBONtSAZNYAYmSRTPcAAKUPHUcfWuut29wS4vxkP/yT f4ewymtK7NDwUQw0iOt7y830K2E16Vrp/yUTuwgiYRgSmp9wpqtqkP5A/aLVXqzrf/Tcc3YKAy2w mx3Y0GR/+K1v2Xe+85/scleHbWhttS8++KCz0D954rg1Na9FbWEHoRMxUoTIBfR0iEM2hciXd00G Elm7lCndf1eMJlmivERxn5+3ZAd8hjVKGwAmF6nke0bq6gaI3sh4h3iUoLaIsDOSEvk60HaDQhxd atVi89A6r8cKBUSymhDDoBjf3YMO1KRVwSFMWijO8JDshSVoiopzhzWxO8rhFkVXXZmabUsl8okB NOO4e7jh7MDNQvxKv8V+/Ab3ISoWR3A94d9YlJeb/CzQU2VFdvFLd2ABLREweSIK8LC/wB3YFme/ k4gXFBqqFIvMMkRpWTq58qNaJ/DnfUqvFh6g4RmNSxTXIW+9bv6L5yx69/0WwQGuW6nSy/Lqu5M0 pUa4EdV7BpKyVRkZyn5+jT23NmrYygrT0yHoXUBJSunduJb41c9/anty0DdrgqZKc1F5gPPm5sy1 ZUHxTmfp2uvza7rEZx6VaxUZWshCVTnlY/1eURazK8PDNhVmrhGnurhvAFAFB74AwxM2MHGbRTfS XdWQuumlh/mMTTq/y6ApahM8c6W93UYxUsmHe5+L9XAexkoy1tDz8remdmcz113p5CGx29VJsN47 4Oi6RHLDiKl/zU69oXkd4ttp66zkoIhxShRXLygXYn05ZgVED5ELGTcxEhk6wy7KddxMHSKp73Bu sY02Zlnhx29Z1UA7nD/mIeBvIL8Gzt1lOHLHLITeXkfpJsBfq+VP47+t92MP/BV6nD8P/J2wNYh9 x7JKnM7fkMDfSJs18Lwf45wBrH2HigX+4PxhbTwL/uDy+enAJnT+KofREQT8SRQt8XHd+Dlc8mTZ DFE+KhH3B5DvOgDO4TjWssFxAgsKqywMJyuaCygEwfDRgT/d6HOusOB2kf913Xp1J/+T+iZ6LcCJ ftP2anvptZdt6y4svlEtCsE4EP2JlJMJj0t85wq/RVEvykUHVeHj+gYG7fD775sPZ86FzcSwPvKu PQLg+9JjjxMveqet37DBdhMyTrHuW9auczqtAnXOyIM8ZQkel+oPBbn5w7t+z/Q4Xb1qzW9pssX/ 0O+a7ekk7k404+q2pZ5H2gDQrXSululVNfUq6c7PaHAS7chkS1y7VUAqhdBsbSwxgUDudycunebh BpYjEr4MOPGhF1ilkxQZDjEpc9iQtIlMogs1smUzMRvZMNCJy0GVF2adMrxxUpkCduWAR8US5tS3 eO+zISGG8yniBxPWKZen0q4b1EAb4QxcxM679rJZwAXNxvo5sSpo7xf4G0XxvxiORiV+0vLh+ilp E5VU2t3K52Un1V9tQRE+9OLz5jt+FOvRKots3EwhWhFXkHeyUivso2Q2S76rwzKUkjkn31dajOhb Ik4BJjlBf/mlF23g/BGrv2uLDeEEGosLTYCr+1/jLYDFBh9BLxB29YqqIdcVqNdiSQqgVL7k5ke3 tRAL/Ah1msQzTHZOEGtG9OyuELYNEZhEuYoekgwx58SuAFltYDqYSaw2NESc3f7f2ZFTH2HURQQL uHMFcMZqUe1oaWnEyrcU3cUiNkYJtkk8J6gXcrSW7GHRHZ+9/3C0+M5c78WtRvaRD62S63L70oHf vVGJ5ZAQSH3DGZawRmhezXIAEzSsHD/ZfTPWt2UWrmsE8KFXXEyYsDUVdnmsz2YKtzpjkIpROH8A tVB0Es7fVjh3GHwQR6wlPMf5S4p9ZfAxy/kDvA3nVdsaOHmNcP4kjbhUutUGGc8WxL6NPC/xbw9g 8KJ0/qhPE+VUD13gOVn77gJEllnVEGJDQOEkLmdK4C4GGG8PiPAAB9UYPulkkZ2H1XQx7me6C/Hb GCAaiEzK+S/wJ73nEGMb4FDp9MpU2O+T6x9tChv3rbWD/9cb1guQa7n5ZjiAspRXeLirOwnBC8sg BiJwXMXR1l5RgdXwFx9+yN56/wMbu3LJSrM42HD9wG232b59+yxHuuokGZa48G7kOUMeMoySzrdo fbGk4mcP5ovdtKLrlO2KX7wOK8p+BQ9ntt0LVyxtAJjcY5LvC2e7wqvJzK8hxhXmusDjIoYMF+Ky TxBbqmCC+/SYNjptlOqOMpRnJ6trrfdym5UxkbLYDAbYvXhDURrQyKl+Cs7YKCIQlRb144sJ59Da 3EphYCAss1GeyyXDcd6LkLvJ1iII1yPaUGV+uXbBXYbTf1qgp9wlHRFxEu371v18pZQaKQMvgTBV ef5Up+SwurzmbUpqbJSynR9AIbrEmMQobwT/XsX5KA7X1XuWkbN9k1goXP+6HNN78arlPaO6aGPZ uAXMgcWmIj0kykkv02vudnVzLeeH5Vb0mjwX+npd5y5008quzdaeQVzpQiXqzoYO5fBcgOXYyRN2 7uCr9pW1hfgDK8SlBweMMeqboBF1ncqXk/NpQI42ITm2DXJYWEm3aiMSR28akCArYvlAG0HXLZQb QNUCcMS1UUKMSTl9HIvXiYFxCw1lwQnJg5vHH9E85NBZeShNoj7Q2xu2EayXfYU4kS4n/2LynBix 8ECXtQ9dtBMX8GMYKrCyogorAlAWYgFZAHfR+Tckv4Dz1afDDQ6h4fBNE3ljGivLMTiKEwC77pdf ti/0dloVh5OxMrjlONSNA5Kk+ydjh1AB7jo4GOKMDddQUxbg4OiDtgVQBQoHqmptoBLRqb6rf1k3 elt224f+EnwnZlkzvgBliOE4fzL4wE+gwF8zOnsS34Zl7YtxiHT+GvuSnD90/gBvw3DwJMZNcv4u AfK60PkrGmyzyqHjPD/g/PxdcmJfz+DDgb8cgb/dNppdYnlDuJ7pPwmQHrEC5Lp56PJdeySN4w5H dffjRqRssNsC5bUWq8dBN9xGgT8/4E9NC7D++ScAxsgpfVKmFBGtOGmyrUpGK67JcjNQ3wQ5fO3v vGjZf/MdN5+QBUMS/MCec31KHLoAg0FAnfaiJx97zCbRTX/9o6N2O66OZOAkjnoO0icBP63l8nOr vtJrVN4p3C5wfe66ojXFLWML/7wqV1WPTG/3K62o6ph64u7EcKX33FwJaQNAR/yutOUWOVf45+IT zVBLFiL71atf+n2lSaqpoyddZBAuyFXE+OiodeOPqQG9DA3eBBN2lE3oMm4htnKCK2HRlKK+wOME 7z4Wwegk7iZyUIgW252GStdwEkXpEY53QTa7UsS44oB47LQbtFqVYuP17Vzn3QSQlHNoPMwu/BCb jMlDP5vYIM6ee0dQTke/MATyLEacUIaSv/RLxMdR/8s60UOJWgxYQNiQoyzepfVYlCFOkOK8itRi oaqsWlKenGJnvvw188FViDU2e0B4FQpRu1azqgu1eS7/uU8L3bca1zyKXFlOome5ahPNjQNsXvvl z21L1qhtJaar04tzG0eiDJqkPSmKuDQijhWgL4jhR0j0ugopREUm8SE3xVwYYXL4xFkkOZCLDmKk NB8jA/RjodsZjERkKDI8PmBDI7LmzUO8yx8ATiHgurvR1Z0cJmwchlwbSm3NNs9aUm5lpsenMV6d xM9nr13CzVPXBCLXT+T0WS5fMGiBZ5+Hf0OP5DiooYsYHxrEICKPkGrgOTheCHotZ2LY1t3xsIWH +21o43braVnPHBth6gKq84ngo4MM9wr8yfVMbGwEK2rURiS+FrhM0nTiXcYXU7iK6WpBxDv0ntX0 nEHnLuLp/BGhIwcg1gwgLMMYo4doHElr30ZA2hp0/iayJDbebQNw/qTzJ/AoIHYZ8CeDkYLJQasb 5b4J/MMVb7UOrIUF3iReXjN83lkJu+eZf4WAvzLylYuQXHT+FC5yYXrToVPSAg4CWG0bImIdXOeD v9gU4I/b0Iy0CH0ZRWs0zniKq7xsytF65h7mZT6NOopZ5ReVJVLUgpeBJI7fnvEhKzp8yGK33W4E BHZr7kJFuSbTjzJY8lMfGdzIEfu99z1oa9a22v5d2zzOM79Lb1Bdo/njWANuDBfKdfFrOqxkLDmQ m7HcV5TxstqtxVEksswuW2TnXrwdWjdUXmL9WPzGlfySzHyZjUq96OTysoIeXKowiNnrL16XQdjq CvYPzziEBXxNbY1dwL/XAIv7GljtnZz88+ACnAv32DE2pjs5DbsTGLNQXBYfm1qQSZlNME3Za6hL JUSVnUeYyE3dvYhXh+AUSOfqKkpSrRdIuqwKqV0nL1j8Qpf5t681f8uaq2lQbQWwxQ6ftJnfXYBD UGXHyptZz7RY4y4gxgk/OGb5lSXWgdXhAFyYLMBlVVO55RZ6ojHn39Dbj11FVPSqgT8yc5v8bM7i /K0xYn15BL4UZ9M9t8QLXeD1qWquntd7BpLrGPLNUPaqsWrv8qcMLVRzfacfUkuaCYoWALPXqQ/4 AXSH3j5onccO21e3lXCNfOa1QRuJLFdjgD+DU+3jwSypIKRWXEp36aAh8dUIsYWnOZgE2dxmq+AW O++brJQDBViWEggkgnLUNPLhyakxYqmO29DoEFw3QF58ygrLc9FPRWwJh12RDRR+TlMhC1BYCTcx F4vU8bpJ5myejfSOAAwBlVi2zsxMwH1U9ASsdxG31f3mXctH79f/4G3Wv6eVKBk5Tu/VN1lt7w6U 2gxcxOkaxLjU2c+BUH0ln38K9SYuooBgIAu9LkLHiSMY5y+qNhDX2alxqFKJdVYGIq7rJ7vtZM85 Gy9utPBMyOonBm394Ekrwi1LOKHzJyfPEvuuGTzrDD7E+RuC8zcf/InzdwXXLoW4ehF4zJnosvOI eKexIg4CDuv7Tlr58Kd4Oqiyc3AYBxmDsr4PsADutEp0ccV9FSc+uTpfO5BaEqZYK8Y3tlr5CL4T cXXjC6AHiD9INUngT7ZwoqdcOIIBJCUT/Rx65bqK7zFAvsLGiWOlbkgpcWPW8Bj+GM/ZDIB/cEsz tHkNwaaU0VI3wTWGbooudBLiDnWCdfUWlapAYqyWejql30UrHKgP56Mq1NJim7btcI8JH0cgJB2/ k0n944AcF7QkOteZ7seY1Tes4Q9piX6jfnJpJEMSb8Ykc0jt3a0p7snlPJ1iGdym3F0JeplrZmoZ fAZ3pVcl3U1DeEt8SruG1wNAjbhy04qyYEr8nvHe++xGSM3NVErmnfJCs0BFNCWjADn5CizAMrgC kNJ7qc2aWOjzyXgGx7J1GzfZO+8ftJZhuIPoIEVZ/XyIMuPcExtHFAyjTpZyycRlqyzw42IGDsCx Npve2mC5ZQQJx/Gsi+O4GFdPGYj7Agj0vXEEi+BTNgqS7MdFwyQLlzYgcUPc4gpXpeyVjyz49ikr fvIp2/rgwyzKOXAxx2wcMdnQQLd1yMKZ+mvRGZgatd72AWu9pdGyA+JYyLqPhRvRWjKpP7UgJfs1 eX157/Ny0QLLZp2JNK+UTGTv+sKJb1ZCZCnWbLlFgKscuELyBLcAegTIXT531t74xfN2e2XQakpw xMwYiERlaDItGuJmn3RCoUXPwXNmejJEOdrA5D9uMQqYD3hDOXAg4f6JWxlhR5wCxEUJZ1IIty5b KhWAQZGTkqsxn+PQVhRUonzkazMPFzZ5ck9ChyZP/lKMj7DLZg2P2M1vHrIi1DjO1hfb+X3rADHo doB8BrqG7UR7vxVs3IiBA5N6jLmBWDwotJM4tCTrKqCnWMJS4I8xx2IcGiVadSJhfpOLGMcx5PeW Yx9Y85tvWjv++i40brThyTYbu/yBbc0FhJRJZy/h6qWf8GyO84fY13H+BP4uOl2+gHT+BP6wFs4H /LXIYGSy104CVgezqqwAEXDh+HkLEm+4n7p34xomTpzfRvKrnLqEn0dAFnINdd2NwN8Mko4BP9xQ fNn5dFjEWbg/JGU1umCS/qT/xcn1yT8MFj5ZSEBA2I4jmsvtMxwkxml7DA5iDOORQArcZB1CSs+0 2fof/hp/qfl25L//hjNeoyrzEqPtOEwadbUi/RRjouT1DNq6594wP6L/T7/5sPVtaHSgMP3cFnuC 1RZaartzjz07ELRvVwHkmHPqBumxXr0Mem3x1AW09rIecwOUi96gjk+eFa+Ao6x5l9fqefWkuCT9 zru6ih/Vns9nymy7F27zdQDQ39NlgSGCeDc0eY6Hr3lOG4DrQg3UNb+t1tfkgpixAmYrKgJWO7z3 2cur+EGDmsx9uQPsNhMWFuWknaUS33ejoyPWi3f1CrgoFxFbbth4u3MEffjFn1h9Tw+bTAjjijyM O1COlgh4QqIzNozEoCnPbMBVdbGP6AqD1nOEBbW1Bj9PCE0oZmo8aiUsrAJysw8l+kULhfw2XRiA s9A/RWSfMRtcM2jjMaILcGoNsKj6WWEigMnWgnW26QtN1vTFp20dTj/V3zFAoriUk3BROjs6bIy2 SCw8OjyKN/l37MTbn9q2WzaTjzZarhPrN1ad0CDRhuk6ZIWDREVEyxlN9LErwhWUqdlCC1whGqfM JVd7rzFpL9CSqio8qzZaOY6VUvmJkyfttR9+z5rRi7t3O47FyVt75yTcjmEMQGbE8UJvyzkmF6cm c01zACxpWZ9KMcl57GezzgLwhcRZUgfRzuRvC+bDPbrNkS8vntNbXUkmQChtVQzm9tt3Wu6Vegs3 1jB34QwC9BTvOswBqe3wadvStAODFbj26OIFBeQ40S0EmlSfAPf4iZMbh+0fBXApSoaMKFSZKC5W pjFyqTj+oa09+oGV7NlrrQ8/bEOM0eFXXrafnrtgrfWNzMVcjDg+dmLfMfn5S3L+sPaVwYcH/rY6 zl8BLl7E+StEZ7C3uMW6CqqtYOAch9OPLC8yRLEabIwJxq8QYaTTCtAxRJhLJ8jsbX5/JPvFexfY mIaGBrCyDlH9Qo4L/mKcEQNSCeMCyCXb0XGkHoDBYkTDcEHjU2JrcZ0iswCoOjBH4faGxnE8DJCf 4C8iNzLQpQ6+C9IZz8RZ0/RrgP4U2NEepX+qrw4uPta9yChRZACfQdZQrVtaJ5VuSBPeLbOvyteP Wk3ulbD5OfgGGXdxaFczUV3qF7Ddj99iz/7lr+zTi1hstzS7+edR6Fx5Xt35Pts3nohXFsLi9qlq ukdnj8VHbunau3JcO+fKXvqp9O5Q/bTGuFHOXDHpVeqau+f3oQ9fnmLExZnns8R01f1zd899uuqG Jb/MAUA634coIuunPzLf+U/N0IeaufmAdutrMqEoV9pyi7wmu0W/umFa9NfV/CHztOD12UrK0aTV UEgaFmIjqCECxnnCZU2ykFewxl28cMG+cOAO+/jMcTtx8aJtwrWKNjU3eip+kqEuAgDOS8qT2YBo iVMnWjICdVkckXUCHCfKxvggFoyKDgIQS05v6W0NDEfs4IdtxO3cYFufvs3yt26x0roqRCKy3vQW R03oaU7d5TejL4J3+EBTixOJqUxXLAAxH6X3TZs2usVUu6LA5hqCgv/7v/x3drm4wwoChZZDPE9x GJ3uIDIK6QleS5HzmvT5/JjhCqs/b7RxrmanyDBadKwyl0q6R+AvGw6b0zFlfPt6e+3Y0SP24Zu/ toorZ+zB1lL89AIKpYsGKBirgCsUL7bsMNbtYhd+jpObP8meSKlTBBTolSidsmAvkglzUCHpOmQV DxCIFKMXSNjF91/GGTJ6fCPhKRvuCTsL32AeEUCY494mvXhHJWnDpwMV3DhxBJPrepQyBB67N+20 s+gmdmJlf3tDs+0lXvEanPZ+/3vfs87Lx+2pih6rx6nziMAfnL9BJ/YV+PsYUCSdP8CfXMWg8yff geL8ydpXOoN467SG6FHLjvRbMeHlsDf1ei0ySN2pv9qwYH/MtUk9NhGAG8kOHiLeeQli4lAJ4u4y +e7E58EUBjBIHPyEK2OxYNOERhFXi0nqJBpBOK+UMYUxgo97ORoTiYL9jrpMAhIdiONAPE3UEVXF 0avGlLoFJ4hAEh6y7vpqm3niHvPhLWEKfZpJDrjZ/BYcmLACdDwL+tmw48Q6rimw0Ur0WRVPl/HM YU1NGgrNtWiRTyzykxUlduGxO82P6Hq4cY2z8F7k7mVfVoSZiaExK8opxKoXXVWPmJPUfF2+iZ9n r+u7+mzVE1nOMoBWPXMyFAL8nKb57fbB/fW3tzumTgw/oDEs/ZNzdjWrPwcAlStgInDsiNmZk+bf f8B8t1y/0GvMXRdqoHgkE905u6CpgIymZO31npnC3KC6YnhhMVlJQoAE/Xq9XoBfsRzEweG+bltf WmDnsIj7pKbKdj3z39hxFsKLXW12M/eUU6wcbl6HmlQdBtP1NRtO6ZY6s6pSBzBFFKX43BsfGkfH icWtDMUn6q6SFT/1hTfO2+B0me380hdt42YcyWIBFgSZSfTr2phYGJR3TM9x3RlwgCyn3YFCp2k4 E5wi/X6O5ySdlqUf1ry2xXZv32uHj7xt2/fscByWaGzUJljYQ/gHWzWKo/2JarryM/JCmyhGHU17 1WL3bfWLUrYZbozG3qs9r4xTKuVp05bCuES+cUKgzfz2N3aC6AEfdl60db4Ru6WlzEoAfxMToEqy 7S3Ns0L8QBaPo7+GH77/2pL6zw/kyAKMXD8h57WWn2dwSm24W0q6RGo722kNZU12855bOZjFLNyG q5Wd+1iyvfkz7+kbftSclNhX4nX3GfAno5zOXTfDxW+w4+++ZcOvvmJ/9PWvW+uWLfb0N79hP/3e 39nhM29bAOvP8eZ9NpqHq5YxwF//UUBVxDoqd1h3kSJ8AP7kKobYvr2FLQ78xXH03tR3lHjDU3aZ mL4xHEmjsZegJa0XN6yu+1mkPcQ6MQMADEwHZsGfv4xoQYDB6BjcO4Cd0x8AbMWxmpEygd5Fqn50 A3141VaEkBn3G8ZkFC1DpFzAddYYFtOopUgRcry2FHCH5TQjJT+rWiOrf3vUik98al27N9lIa6P1 oT9X1DeMo2w8FHQTraRz3PLIuxQJS6iAWO7nx+3UpUmbqcAzA7qeU+VYNxfArVVDlkga7whj3/mF 3W5OOM4j11YzaT62Q08n375od918j7W2tnLuQF9b09DtL3OluQOGRou6qxZiKqTSjrkcUvvkynH9 s7ptnV+6SE1FuJbw7pax+Tf8Q39WnVQHKqawrv5htGOn4CojoofdvUByd7vrrm0L3LHUpTkAqJ5B lDCNd/jA1u0W3bGLNYpr1yWK8mp53S+re0HDNNfA1c17Xm6igkwX48pY+fY/e3hJ1LcYx8/dI8MY UERtY0HcTr35otU+82e25V/9a3vpv3zPBq+02wMV1VaBHzIpP88mTWZOgDFETe4sXgonATcwwm9u DnKjRG/5xXk2DgCcxHoxxMIqBfaPT/XYycsx+/afPG0bWze4xcCBO/R3NLW8v9mS3PcIHAJxjiQy kAVy8p4IDXKWv1xRPcTxkWPgA7cdsCPHPsS4cQKDEOoIQB2mncWF1BHxj5u485ozv7TP6+dMVteR gwYv44mSZolw6cLEOAb/OR216Lu/tbH/7d9YKQYLd9+701qbqwEP3qFW4Fh+wkaCOVaKflZ8FPp0 5biWLV3QP6Y7aGMwKB1BAbfF2+cBP6iGW4IglY27WswfLrAvffFLLvb19154ycrX1FsuIbgUkzXd NLuJa7Ph4ShAcLQZq1249r9991XbtmGD3YJf0S1EQAn9wdP2En4aX2nrtGi4w8rDn9ro0GXrmRqw sdwaGywIWYVdsS2jZwDvvdaN2FecP/kpbCSMWzVOokcICzdGzODJ8HtWCmiVzmIqc0L3DKHvN4Uu XyFiXuQRFizGibYDf9BNGC6fCwIMyBPHLQTQmhAAhLpomPwB+gDcMfyj+vGIAJMPi3Loi2tIa1EN RAeQDzlw80CR0B5xmrkm8bz6JYSF+JpD71vpR6ctB+bi0LREuzNWTwziimEkJl0xy0b07M9nLSvh A+tbQc+0VU11W3FJqQ1gNXRSC186iUbHJepRSqWTvDtTehUnsvti2I5ziN+9cb899vhjSIDQv2X+ zbCGL7ZLac39TBLlzNJmRgr8rBqSfuXnh9mMs2fHZJAoa00kZbMbc/rZ3vCJOQDIbXIkGrn3Idjp 6B3AclxoIByWUZYaqBtmvfwfZ1mhmSpgtmoiBhWSOaK4qg+T6Gq2/PQ/sHVQW3V+nIDb5ZxsAzbU 083iaLYDq9qDz//QHn/mT+3Rb/6Rvf38s/biuU/swYZCqy9Bj4DkuhRP8EQDt5iAHwuCrwBOA+/z iUxVDQAC8xABS/9ohPi7sOvswsUeqyN81GYs8CJwjGUQ7Jn+L96HOkcoP1f2vCbrWlLhWBp+QRYh hdFqamm222/9Av7hEC9haVeA7o5/YAgfhGyaqi/gYPZwoEyWk1Tdxau8nByvf4aquSLc6rnMel6f 6/VXXCEZzJ8SlftsW1IoSluJXLVIlCZVgPfeet1aOi7a5iZclTTCycUqXblqfXOiJMRyJQOjNn2+ 2/qn81EXgB5Bj+q65Q7x9R218BXlr5BXk7ONXPi+lV6VOHAmMmm56Jyl0IVeca5OhHDb02xvfu8j a0Nf65577rZzn3xi7x98xdY+9CRccsTEzJ0VJTohju/AivUbsU7utEM/e862H6pgmPzW+uSXLf+P /rkdP3LUui53wi3rtoGyOhuI16D3m2Xh8TYLswYVjHTjr3ObtZdvRiLgt2ZiAFcNnQf84eePCCNT cAOLmbsaU8kAkklN1Iye1XVLDLjumOZzGAObRsrJIii0v4i1oJy1CJAWCSNaBez5OPz6ZfBB3jHu I3NHrPIH6ANsxwB+4gbqYoDvIe51BjfQnB/AFsDZdwwDOB1SsQqxEDqCyovLloeyWy5i82B1E74R 862YKBhVKCDmD2OchN9EGZ3giBVfhFhzs3YNETlwhvqWtBLNZAseGQC6BnBMO6VMIKnnrH11lAP9 kddO297Nt9qTX34K/32ljousfcoT6c6Ni3L29i+u8ax+uWo/S73oJe90+Yow5tHFkg+leUNiKlGC 2iOa+/wlVyfNRXT4Y2uIiKTP4LKFF8G5Fsx9Sq9NmipzSYXhyDHGyWV2Ms79mvhEUV4tr/tldS94 BLe6eS6Qm9qy3N5bILsFL9GvKkPkvdIkMJVc62VJWQkIXFNfb5/OoAfDqbFp9IL98kfft+qaenvs j/+FxXfstef7h+w8/sAkZo1jURlZW2u+1joL4NTZvwauGhaJCxGYqi0QmIP4IghnZhrR8gyijsBM GDUbTsy0SAAOBqRTjHaWYFTw2ncHAJdouNZeLaA6ecuZ6P79+9koC2wcVxmlg7hfIBh5HOMkl7jH NzbGH35sVpSo/GeUVmPsF6vqZ9cK1ocUCxP4kwqfHD0fP3bC3mw7Zzl3bzf/bURtEMcBwhkHcQ1O xK0Ljh+eT6yMUIcFHTj2vYJbEwwfIuhAybXEZ5Fy4DIHQKMZK01zj86bmWQeom8rTlGqSc8VVxdb 1aZi++WLL8BBDNlXvvpVa+RMd+m3r9NPzEUd4JaR3DrPxptc7+Useg3i4GkcKPf94Ltmz//AZn74 91bbH7b777nbnvjKE/bA156x+57+pt2/bpPtRectEAlbxZ5N9iFhGn/BnHy/87j1f/KaTXUctUsY ZJwsWm+DqJT4+o9Y1vS4jSPe6o9OJP7GbRC3UNM47fPDeJDu0/wkB/biDufgR9RfjAi4gt/h5kX6 PO8G/lxUSfLoT0QJcUChSc2ZrnUWwOK0Ihp24I/+FhgUUHRhyND787PeYAvhjI38hXRmDrHXBQB5 Hikv6gtQA1lPNDTYyM5duEypsBIAaJGi1AD+ooA/fyFGH+WI6dCx6R30ii/YXGwVNzcAVrMtwtq1 Kgv//E5ZxmftpjKqO/3+OXQl8+0pgT/GIUKsXiP0ocChVAEWS6nO+8WeT/k6XT7LAEr5oXRuzNgM T6cSC957FeKhwwX8BAQzma5fNTTSSYSxQMn62XUhL4uTywIPpnFp9pSRqQJm66KWJP9mL67qh6uI +QYTLNVC1SWqsThvelcqgFu7dvc+Ox4vtXpEpoVXTtgLL/zMKmvr7Mlv/bFl77jbnjs3bmf7xwGB nJzZfEVcbvCXQGcabz87eQEWwUFWxk8uDbjYpq5d+pGUrIf7sswXtUtVmaZh8iBfQPzj2ro6KyUK SD7KOQixnS8zlz2bRKDtggXb2jwQuJx+dZXOMIGRvSvG9VMGy1IhibFw/ZOBF9V+ti1LNEViX84L bLhBGxnot5d++mPbWgaHb98GM1m1AlZGEJ8R5c+JiHOgLxm64aLO8uD2lsIlC2AhPoOPt5nxKSJh 4MJDxLFEuStpdgjazlEfZhhwStfKOd1Lp7JUixlrm29db5+0n7EPPvzIGpqa7JmvfcOKR/qs/b03 kV6CVNKcBwJ91Zcv2NaDv7bK9osOBEqdIxuOYuDW++yDmiY7i5umyHM/NB8cwRAWxOUVZVaHRWzD CRw5/+xZq//5T8x39qzVtWyw+575Y6vev8UK6kLWkxex3/ln7BX69I3wJTt34S07fukD+y0W/b/A b+LrxC4+GBm3t/Cl+CKH0w8wQJk6fcLs01MYPwAE+Sd6y6aO2YC3qXwsd8tAd47zB+dtDECI2DVQ gdsqRf6YhsuXAH8CeQJ7cTh/8gkosC0fgS5CCN3krqm7RKN6Vv9m0IvU0AAItec68BcJuOgwofKA TdXn2BScxgEOKsP4FIzDPQzA+QtSvlJXmGtBaHcTRk3bGiwEoIx09Fmkh6gwaY6Ly3AVX9SX0vm8 crHb2j7usIceeIiY6mU286Mf2NT//j9Z/K03nG6ffGBem7y6iwDVSyKx6++59pnlfFe+3hKmUjKT VHOV4VrCe2ZasoK6X1snV9kb9cdcC+Y+pVc+UyDdRFGutOUWmWp5GqZMl0FdpDuV6WI0aZzYMtW2 3/g+AWSRhU6yUhWRIvh2LHGLseD74IW/te3Ffjv8zmv2LpzBex9+xJ786tftxwCrnxx9w77K5tuY 24XrA5zqVhL/9wZgP1kL0aEmqAxALrSP2RNfuxfRM6cTOCYCk6uRlIsUrpWduIFKebm5lk8bfEQN ARkK6bpNSi4s/MNwAxk7P6fYqFibq1QPr+TVf12dXlq4Xh75Oji/8A2rdpWNBDq+UVJd5PJFKgVB xvP1l16yibMf2r37q6FVNmQodwAXHDrAFOfhRoXNVjSsXEVn3pynHABfHP96PsY9RrDrGDfGcbkS BHy4m29UiWX9xiEHbrfz64fYzsW5XlY+N35Im7Fbc25823W/SnxcVF5oDdur7Ze//IXt2L7NNmGk 8dWnn7Lv/PV3ra+4wsq2YTiQYucI/AWY+5sPv2kb33nVTt7xkPXX4nQYZ4hSQJ9pWW9HHvm69WPo gJ8nC549Y5GTpyzCOKx56QXLQScweumyBUvqLD+7zN549VV7BoORJ774iA21XbIwh7SpkX4rBLyv IQJQYHIUo4pG3D3h3xOgkcfhIAvdxhiAO4d1LIhleOwDYssihu4oLrL19S0OJ08CmAvRt7PSKe7F ZYs4fwJ/eR748wO6YkOI1AGA4gIK0KFLApBPiH0d+JOIGMqThEH38bP0An3Z+iBACMHOUAb1cjqD GIw4sTHSjiD3YfTL2kc4vvAYng5yrCcatLp8n+Uj9hW9D/ahi4heYCXRX0JbcYiPSk2ksw8w20ls Za7hJshbsa8b1oxeEK3JAlrqAR1ne+zEoTN2y+7b7bbbbydWddi6APbljGv27pvoB7VEs3Dh5H5e +KdVu6oaqENnGUCrlvP8jFwp8y98bj7/Q9BI2gBQhDA7UBnqutlTxuL0uEolO2qD4JgoGaKLOWL2 ylqlirtslHeMRU2bQwhA9sB999nPu9rt1In3LDDWbq88+/e2HoexTa2b7Mt/8HX7KTvts0fesKdY ENaykUb586MLmKpfvSlcHoRy4Ta2bnZlUmxKuCs5jNRUS9JsF+i6/nRdTkUlgpCFmr+3x+KnTwH6 ON0jDjZZQQkdACAEWP1sInFM43Up5vSfPNgwm3EqH6jG/Lqk8kja91A/11pHXGpphpIKWQKYrbRk 1V7FOFGhOn6RJMMPT/fPbxfPn7N3Xv65fbEF615CDope5WpIot/yIjhuiNncGC6SHVlhM8smzeYs /2q6eRoAEkBc6yJ2LPLcIlVb8rJoT36FfaBT8aBYFlxyLkHmPS01hWuvzft56Y+JfJe+8fo7NuIU +vVT79rBQ4fswQcftH1791mYEHQ/+dUrll1RaQU1DcxNDkupJPovgmuZKGHYopJ5qsGJPtXc8G/d Y93Q7hsfHiR+OOofr7yNaYXf7j/0kTW1d9lYyz67tP1uKy/G2GHgsj3345/al+srbWtf2Gq27jC7 /0GiuOBsmfpMY2QhP4ZBSR6Si61oVuVxT2T7TsZ5xkYRIX80iTPq7i7bXV1CrGSsawF7WTHukc4d Tu3nwB+OuPtZCwBwMupw4M1x/hg76fzNgj9E+wJ/4gbKDUwS/FG0A47i+gL+nM6gA3/kB/gTwcto YopnJ8+0W/4n7VaMp4W25lbE0dJaJpRhOGgDMXQnt5ZZDp4UfKjLRDr6zQ/4i6C/HCkrR6cef6mo 3ohmFtvkKYry3Kvrk8Xu020LJcdBg341x+SrUPVWCMJ+OJDtp6/YSMek7Wy9yZ546CkrJJLJj559 0T4I99u3HnjEqu682x3MWFqvS97+pb7wVkvv+3W3rfiCy9frhBXntVgGIjV1sWsJ7/r+eUvp1Wnu 7rlP6bUobQCYXvYruDs5GVaQRUqPJgg7pXuXfZM3PI6+l53Hwg8qgoHmrd5LsNh7+Omv2UFO8qcP vWoXPj5upz89a40bWq1mzRp7it++z8n8+RNv2jNspJW0Pb4B9y8Yg6TCCVQNglgnKYSXkgDg0oQH uFMf03gpfgvDJZO4QGLcqV+kiyMOEduF2cu/NHv3HfO1bjVfHYqw8x7SvXEBQMTbKt3HIuun7aqH /tLr46VrT5YrT59FMek1fJltoiH09WJJ25vCD/rZiBTe7Oc/fdY2BYZtfx0Radw/VKdGFLgBC3NI 6AZZuSLkONonrg7PalOLASKm4UJPgxxjigmsAwztXiqfxep73XXyggmIvzoAA6AgQjt0wIpJv0wE TEE6LImOpcOoDd23gNjsunyvvbDMsdJBrwC3IhtvWWe/+tWLtnfPHucU/oH777fLl9rg+r9q6x/5 Aw5IcoK3+DipOo7bTvtO7b/DwugL9zSuc2AteRgU1ygbrxDx3bdaV0ML3L8TljM8jRUurqdav2BZ a7bYUM1GDD5qrDSUY3sJ8/hJxxG7/NzPbG3bGQs++pT57kZSwFpB9xH1RJ73dGBNUgKjmkDYEl+H WlrM9y//3EpQAdhy4YK9+oPvW0dvl+3BU8HarHzLxjo3mhD7SuwqEW+kD0f1w4Ae9AD9cPOcq5d5 nD+sNuY4f9IPZCw98EeFNJwKGQfQ86Hr5ziHAn8zCfCncSY0XzAyYRP+Kfv4WJftAth14fh+oHKN lRcU2dhgjvVPRSyHMIa5O+ppJJy/9j4LfNqBFS/rUmu9tRYWWBzDub4IBjUV6DnMA1mUTI9QD/5m sBSOwP3UN4XEDAAYvTOd+mvxpDxEg1PoU+TgqzCI5Uo/oH64n6hKiKAn+iP4Xiy1u/bdYbccuNVK AOsjxJP+NR4jzmQX2jee+RNiu+9yluQzN5Ki3KgSi1fv9798zntgGQAQSnDEkDmKcIutiJGTvtbd 5AxQifpb5vq58FAw0Vc9zwVKWmI9XuCJ1C8pb4liZzhBl8AFeOChR6yBSC5la9+1asLBKWSVFvTq 6iqUx79hz/6nPnvl9HH7ah6bKAtSbEsjIZWIEerM4BYuV+MgUbOLiUpkAe/Epp5bPPlZwcSpkTGA xkwnf4l/nF9APrv4kYj4tIeK+zKNz6PTZ49b6IWfWPDTC9aP+GSSxqlMRTbJZmHLglMhLoL+XHLj 5xWg/NQXqaYbL62p5rL0fWlUaenMFrjD5Z/pQhLlenBsgUpwST7/BIpk+PG7w+/Z5Q/fsr/YVc5Y afTjNgLnb3oa63X0AVOp7vx79FkGCtn8zSBCjmB5FEWNIQQQFO2kNfDzq+9VzQETcUxEQ7JgLaIt 4qPhdAgOEIAQepURlKyFc6E9WadOcb9CNMZpswODyutGiUYIAEWnsRrV2qZ/eoa/RDVu9LT7LTIT sTXN5fbJ+232IiDwm9/8luXCJX/i8Sft4//lf7au00etfvctzun6UpkJ7PVX11kf7mQc8Ltm8rg5 DjjLKau2rN0FlgNnL28yyzpZazoB4qFJqYAQ/ziXAyTqGFvwEZg1PmqH4d6VcMDcIYNCxkvh7eIY cejEqGVdaf7cU9sDPB+oqXXrxX4AaRYSjV++8Jx9H3dQz6xtsBJgt3T+QohdZ/AJ6OvH6A3Rb4gF TIYgAnFxjEOS1r4+3F7NGnxI7CvDXjh//mzGkt6OocPnDEY4eMpgRODRgT/uU/Lz3XC0n8VfLKvL PoJLWnzr3RZY12RvXToOJzto5Yx9YUuOle9usAA+G2faid7xaTuGxKjHAP6CGO5UDo1aVn+v/QaO 5ATOs/NQY0imKfxf+tB3pWVWikKiHwMZtAqJCQ2tASwFIkMAupDUHkQrvIp+1KeiealZiB5GEbGP vnPGdhz8GKf7uXa0scWG4gXOyfPGxvW2d98+a0RnVH5WxY3VuArc74B73LxzJ2WSp2gzWbEF3hPD tsAvq3yJgmYlgKuctZed1xK9qj8/Tymz7V64pWkDQK0Rrgt5UQe6zwvnvcyrLMCnT6JYfMri23dY aP0GxwVQZsInUtUQ58gtnMssYe6x5DKkVmSGHBxr3hWoDstMGar9NOBsbGISnSpCUwGStu/eY+vw 5SXApAVDE1wxMhsb6u3Rp79u3/0P/9Y+bB+226nTZBvh/whu7tVPuV2ftGiEBMJmxiyMiLa2FmBJ pkFAnhymXt1/LLQ0NZvNUqJdb4Nm7Kjj8MiYRbA6K2NR9OflW1bLWlZ/Tyw0wmL7HnpAuWVVVrGZ +KEscsNEjhCwVdflYCmg6CGKiCBL4by8PMtFT1CcQyUnUaIuauv85L7yclUt9SXBgZh/76p+ps6u 7NmSvW+rWoYyc9nykqHsVcQs5dK/jqbdmOsXLwXo/Cy3KQUsfKXTXsAF0V3VIUINeha/o1NxG8Lo o5j40xITL5XUFFeEPswW7j0VYhPz459tBnASgabj+Kh00Wp0Xzp9wP0xntd6ojkimnXh6hxnEf1E 8nIu5tigVYdpiRQpQpHfwBwAQ0LXwSmc4i8GDepe6VzpZr1el7ioiDaTY1O4bsEVk3zhEXtXhEvx DkRe98y8C0nwKHLffnervf3ib2z7lm22e+8eq6uvQ7n/Qfver35t1Zt2wKmX42EyTSEluX6L3ap8 ZnCOPJNdY5Nwqvx02Djh48ov9sGxwy8eXPioxoT2zGy8004jwh2XXjKT1vUD7+ojfb52bibLnBH9 uMWdNQUCufmOO61jcMj+6t1DWAdjoV1ON5XO2HHCVh7tnbR78D9YgTudYDn6wDiIjgNM446BRikO /Al0Up4Df1xLiIhVCwcS4QhezfnTdWpDXQUcp9Eznp6MABTj9n54wsIYuUw99S3bfcs+O/GDv7VX 0Hl8YkcBxnc1FsTad+aywF+HW8skVQlWFVt0AE8FZxEbw9lbB8G0ES0Eo3dhZeiMSYBOYXVoGq5c jlWhOJsDW1zOFXqxhB9jTRzCRUsf4TEHcYnkLOLp9+KyAlxz5VvvlUF8MY7gAgzXSdM42/6k39Z+ fAGL6Czbue0+xPe7bH1jI4f+atZI4jwxPlK/0HqdE8qzpx//Bl4Wcogtjwsh8hX375op7YbG27+o ND/y6g7x7mCQHLhVep9bU1RKZpLoT7mrJXQDA5GZclaSa3pVmrs72bZ0y04bALpec+XOFZ5uoYve z8qmANghLMtCv/2N2R98w4Kt65iTTFYmZowFX6b7UxBjakvboiXN/QAlZKAlc/m7T1oIM0jY6ht2 kEnpmnCSjHHaVmSOPIxCNFl16pavPjFi/Ny3Dkffm++83w7+6nt2a0Mxp2ncqXCS5Fi4yAbq9VAJ jqHXVwftpVdesj/81h+yGBDXgJO3FvX5CzvVceBPumDi3oX7B+zMiZPWH+6yIaz/6jrb7aajH1tO Q7P5/uwvDDTpFphsRLu7iW6Qg1LyNNaCpadPWz6ixIkJXEeMT9gUtBEm7nEQEUkuoqEgvrjycvJY xAoAhvkOoC7Wy5r0+m3+Ipe8173zonpnImUo29mquvwFZjNdECUu1EcqdjbcG7G33njx5xZvO2E3 31RjQ3A5xuH6iTuTj+8/VKRSSuyRqGt5tMU54rokwCm3LYop7cLIEUs6hPxWh4HkuF73UOKC2iCr 4ihgxnGNuR5ickhvSuuMS2SifPRVvDqlHDbpKJwv7R7cablULJt5NsXcmuJu2SmpPpoL4B33sPCg ynCJNxmXSHStiD6iSHFwZBkc5YGA45R6ty70KoOJIHMkLx/fmERN6fq0x37ywrO2dtNaDGpK7J67 7rK3Dh60K3ABG+ECIk1dteTWW0CJ7CWchEaRSjoGrTBAaDnAhRLdYvGsHAvjToVgu67X3KzTdf3d qDb8KCNe6RkXkbe8FGwlytCmHTvt2NCgDWf3utBrZycK7fRMltVHBlg2yuAKzuCXECDtdP6oA+DN HxKXS1w+qEgcPcf583aMmO6DFmVhIi7hLOcvCf4QG0/jELoT7mZWWaVlN+bZZPE+u71pvW287TbL A5Q98tQ37dWXfm2T1QColkobS4I/xjW2scGCNfjW60fX4cxl88Gdi61dY5vqiq1gMGJdnf02gBuf 6aICW4duYxUdUwwXMy84jT9CuIMdl63oxUMWqyy3oy3N9l7biE3nVhihmG18dMLOT7ZZEcZ7E4QE zM3OI1hMua2tbrBta2+x0qpmB0Dveeqr5ltT49Z6tXoKMA5ZOrqUNbDm0223HXC0LtrUwYKpsMj4 aNTYv3gmOTW4kNGUCYA5V2Ea4tINqXHu9s/w0/LanWzP8iqaNgB0hEBZGSEGiFH7WIxVUyK+ABwn IIvN4B9qEvFgEZEvQrLVJ014K6z7vPwXCFuiicQCv/x8Fn9Sg+rAnzqMz5lIc4SD4q9EUvwT6HMy LN60IbkFgCoIGAqU3Xbn7fbd375oR8ditmNLFeIGEdIC9VO9AY3SPwoCEO+9a71991eH7DdvNdld X/gCGycrKQWpjGQS3HWcP/RYLl9ut5fxXRYbaLOyXMRFFbiY6PvE+t89aDU85MO6To/Kd6CUk/cj lpAOWTgctvNdXe7EGXGcnhkbwyJxdHTEhhEzTUWIAQp5DI8P2hjfc4ZyES2WWWFhIRRDvtQ72S/u s0aBMmLsUhpyiaOzqLukKzqRa2jcYsh92siS1q4avWUn5eOeX6Rvl53xNQ8q+xVU85rcFvyqMXJp Xr8mL2kGSc9TsChCJIhDb79m2+D0Aak4V2i++tjUAUyopqVaTbLjadEtG5aUyBZM0CQDF2NtiIG+ onACZaUaukZ1ZP6jyslxDbXh8UWAUW6OVNulkrOo5BnRkeP08Vl0lMvz2WQW5bNUFibhZAXh9kwS IzYGKM2GZaj7RIcS5+UUAHCYM6pLMAjnSnmy8CVpbrF66B4nOlbHkNe2OzbZGz86aK+/9ro98eiT Vkqotie++Jj9xx8/ZyU1jVaII9nlRAlZrHyVqfVZwxHiQJaLvl1QEobEA+IEdoXbrYcwcV99/Cuu bzX+jgQWzXTuB7VvGt+PM4B5Wfc3wMF68pv/zE69/56dGrzCYGXZ1j23WKCtw44dfM5uz8NB8yj9 N8qMV5848KcDAeBvkguzBh8CqNQ9wQ10eqUAPem/xOAEyn2MxkaAcAwYGh6nzgWlVk4khoLycjtw 111WAAc0BHCLAKZKAFf7b7/V3m7vsOrj7dYS7nMGdRL7SkUgevyixQeGcVKNn70WIt40eMHvigcH LAT3t7aacHPMhSZca8XGsSCenLHJhM/LPPT2Au+fsgHa+un+PKvZdpvVNbVYbkmWTSLh+eVPf2nd 4QG79wv3Wn19A/5ea62spNhyOBjYnr2uM+P4Y4xKRYJvWle1F2j9d4l9MweXR+outz5CfBHtGY5b fP0cEG265BbJxDOJS6v55q3VKv/6OqxWOWqKW9uVIeO9rKSOU1Jmyb5xF1bnJb0s5yqR3nNzdU0b ALpWu9KWW+Rc4dd9ErVpkn3pSfNz8gvs4o9N+tChw/bxx8dwefAHVllVBYefU5rmd5Kor8sonQvu jJpBsqMu6qoMdNdVrdTKTCEKJ6Nwa96h3Cs0WTRrgQNqEuE01tXbrvsetRcPv2ZZvmzbim6KOCJe byRy1iRhI4sfPgEHB22oW7faunVVdvdNY/ZrrDulp7Pvpn2O++a4HIyf+0c50gPr7em153/0X1ig z9j9OEZtrCWwOS4SXryEyPnOB6zu0cfN0FlUGCIp1bNeo+eFOIdT+ziLnas3dUjq/GUjslD4uwIc Qvf0drNoefNYAHAAZ9figgoAKg0iZpYhQoiDhHQHRUcSjaNa7eITZ7FpF6C07RYCaE6ZSTwnXUow QWLDdtjXcXPUd5//lPlKLlgC4ybyE/D2+7OsCbFk10cHAUlwN7LZbMRtSbfzGHfRssDWUsnPPbjc tSjcxmn066YAXCHEg6JBr1xoi3uc/pSyY6ylixpMSBaWyn/2d56Vwr0skhWebX7y9FsBRvSCIFEF OmTF6Hf1z4RsIsFdj0j3D8AnmlO9XN04JKWVXP3VhLjlAwq2CwS+8bptad1imzZvsptuudmO4tz3 fYzA1j/wJCJBuHFuc0+rlKtv1jqgScFBLATYzkH8G+weQU8yT3YVLkmkOYlfv6MX37Hd+3bYrXDL dHBz4EMTNQUKUDHSVZYv0BBWv9JZu+mm/bYeNaDecK+bx031gKyf/wyduqhNDBGpaAiJB13ow1VM YD7nT+gnIfZVfzs/gWLe0gzH+XPgT5xDvvN7jPEaQf7ayz2hwnKrw8hMupXiuJbgk9RxyaiXdD11 IP7iV75mP3vxVXv2hTfsT/dUWNGudRaQMd3f/drs2AXzb2y06H17LVBXhtSDuo7gg5U+jOF1obo0 x/KLEkYemJ1H4FTGAGzDgxOWU1tpk7fvtN980GOFu+6xA088boWoC6FEtwAAQABJREFUutAzduH8 Bfogxybwjblu/Xrbvp1we6Jr/cp7vFxrqUCfQLD6nCHjLfHRrafus65p3NThXBVTIMYFcQEXSrrL y8R9WuiWVb2m8chYEgJ0KfmeYknUyTeJO6OPP3DjH91zE8aIsGWTnZtiNje6bVntXmFXpbn6zLV3 Fdt9VZ9oWKK4GYmub0VPRts1Tjb7r9hzz/0EsHELJx7PqEHLryd4uOrx9L4kGuGdvFfYk4uVTLYe qfGaIcL2CMcDX66w2TKvrxTrDAuRuIBZnGwfsp7+MXvhzZMArinbsrYCkSp+tlhF3ALCYhcPD1rs J29KydBijdVm25rt1r2NNjT4qf3ujeetu7vDmtGPKeeknIOuSQ6nd4lyhwBgL/7y5wTPPI3rgQ3W 1KiwdT47ebTdftfts6/+iz9zAD8CQJuBYyL1H/ES1UUyNhEAdM5/E03Quqt2CgyWlZe5zX2E+MAC CdlBLAxREJc+oJJ0DfsuX+YEjt8uTu7IzCyHlb+cBT2E02xZJkrXKwtuURSxsp39xInAA+vWc/6A +0Aeqgf/4UYDFlgY0cl2C62upZy4WaPiUYCe9Cgh5edTvdFly0uGslc1ZtvNnNE4JDcY/aZ9gy4H bAOMMNy56/5H7a/ffI0NHMAAwNHmuZyk6ZnOkwHoNgvLzRlOP9MRoBi0LBChyutoI9glOvLDhUuF 47dQnQUAND9ulERbFYhpt1WE8IcXsD5AUxsKkMP4sSsqy/c6M9mw5PuNMlzkNx14GlprrVOi4Oee sz//7/6cA1CBfeXJxy38//4/1v7h29Z0+4OUR6PTWbB1vxLPCCjEJifY/KYsDwCbR1zwQiQyoWn0 cAPEzWVeCdiMTg7bh+feRR8ual969FGMHfKc7q4k5uLIpZy4VYcwJLAc1linWBTKEbtWwN1X/HIf 7qFa337VxjpxFVXVhO4B5cP88sPR8zh/PMDwOGvfLDIRrcIt8Ny6QAPyE5gw+MB5H3VnaSPWcFh+ /nxZlguIEpNBHLWoACxjLY6uhkldGNILRTTgCubpp0vtOx2X7C3ivz1eVWbRnj7zvXPC/G1hiwMI /XD+pobH3YFcvgCLKws5DABwAXAFMoNnLVPGoVwAIMYe8QHE5vVVNvjQfvto4Lz9t3d+wUoFPimz s6PDfvyTH9nARNh6MMYJw3UUmo2iciEuK0cLvoubR13Jk//XJY2CVB3c8KpfaJ8MScS1hKrd/dIT JKPZZ3VvMi/1gg468+f+7I0r/ODWFPJIlrXC7BZ8XK2ay3+ujQvefO1F+inIWGf9zXfoN/RD4Q5H 1m9is1oxCplXktaodNLc4FzdttTzSBsAOuJwtUyvqqlXybtzhkU0xAInh7C7d++3Rx5pt7LSEndC 1HriEeEK66DHHYXzYYVZ3ah9Iu75pHeje1f2m463izdExB9hdcCIjsUHLgVA6oknnkChucBef/9D u9jWb/s3V1oVujXZWFi6PtYiVUG4OBZ/HyJgnTSz2EAfvmutHfu43U50vGdHuvDeHypl0c2Gy5Zt RXDhenuu2Gj4rD35UCsWaGVsyIhXcOz7yuEOW7dtP7FNcT0gbi+I1Fu0CO9EtdwGy7v2WC1kjrPI d7XK60fE/wKHbELVXPX5qVM59aOeAodatHsxUgl291gFrMRB5Du4D7Ngz7A7ZUdY3P3rWsiN/Li/ 453fWvF3v4MYL8sC/+pfW2AjocooOAaikWGNNgIxexRA3nOTsHj/ukz/gV5crW4w9qtRLfU/y/91 WWmcJqELGU5qw65GFLmjv8/iR9mUtzYRzBxOq25KK0Gn3J8OdlD28HSgb083cJp3IT45kRZH0HHp VthHMcchprdv1Bx+U0/l4duoBi7UmjzCLwKg+tiwdagVl2tVksrhgLLt9lZ78+8/sLfffssefvhh F0HnK089bf/nX/+NXTnxO6vdvter7lJj4PpGABddYrjnMcB0nDr7EE/mdRHubSLLCnEEE8QVTBau XxSHfALL1St9HdbRd9aiOZP22Jced9wziUpnYA+6uZ1WY0XJcKPoZ0kE5P4HSbOjO0UiMgBgxYfv 2VZ82AXgrPqq8EyQw8oBp9Xp9wnACAvJgoex98CfR0cBuIRJnT8U/RxtjdDWQeo6hauZ4spqwKZ3 uNTaRw6Ogyb96WTSJ6kd0AlWCzPii19+2r7/t/+3HUAPsAxQGtvcZL5dGyx4YBvcaFRjAHzllQVO rYXqcEgO2uAIrmWIN5zT0Wnxrn6zjQ3mw+ehHzod5aQZZL2NoCzbh7Pm5mZ+o7gB6VGfOWM5pVjv bttlGzZscHQUBYxMaG1mTVbPzdU0WeO5d5UP/nOAvYfYze+9e9hJVPYq7CaHY3Gute5eS50uz1nO 2Vx+q/1J5bg2LEWnKypYJaSfXL3onLgOQ/S5cImrbPpZLf7EjQZv8adW9EvaANBbP1neltePKVd2 hlPzFGZ1infbXNtsf/In/xxGTgGLEpOKdZ2zS8p5LX4jeWSU2CjZDaqQfebKckCNAVloc7627aJb 1gtvZWOh1Gn3UUSx7x2usk9PfmS/PnzFSkr6bENjia2tL7EcFqasb9zHqYdTZm05z0nBmpMkAHHP viZrXD9qXb1j1sWpdByzyJhExaNBq2BRvn1HmVUjGproHLGp7gHrPHLeAr35ds8zD6CHgshZpycy Q+XP6RWpronugr7cJ1d9fZp/NpqEazdypcuK4DJmw/WLcTAAsbJQcrrmNDyBrmAxXL4cFuAsNiG2 fisA7IUQw8QJM5UcclHQOEAx+9gRy84vtMDwiCtPwGN0YsJ6cLDbsm4tizfiY/IW9zStNNsElTT7 Ja0sUrpZ2a/KfFi8NG8MvDZ4h6+r7/VoEE4GdFgAN+WA+nUMTgjWkFZY49Hb1Y/c+BtFiS6SB4HZ 9UYErKTdbJGkeSBOjR/gIoOFiHQ9Jea/dmdb5PkbXRZ4Ewc5lSQ60584giVweDhzkRL1TyWDFO7R gay4PN/WwZV/8Ve/sO1791odc3oLkUIef+B+e/6V16wfDnj5+s2sm+KDJmaSOjQ5EVQO3+VAWger GBucW2QFwcUBF2cf6/sAVq35RZXu3vGpEbvS3WlXcAAdCYxZ7fpKu/3AbbYVAzMd2jRuAk5pt3be sGqoVcUoL7os1yyB5hbz3f2QnXrjNdtTgI87LINtPMeFZpN6OIbIHvhj/XAWwPysZgSk8yfOH1xY GYGwi1g/9DFIu7NLKqymstLyMZpz6zSPCKMnaW9+G6TPKLE350Enqdi+YxftL7GOQ59YRRWKCPfv I2RdocWKC/AJiAcD+i2ITqoaoraINrMKs228bwx3V4fMh75g7Ik7bPKu3axBrIkY8mWzVm1pzkOX 9mXbtHE93g6KbM2aanscVz9ThOPbsWWH1QA+nbicNU46rdIkmF9PmnBdklsuHeLkUuvDDz6wF1/7 hePUan07cOB2R6eac/PPJ6qzl9Qz1H7uQvKHVXlXvvOGflXyvDYTNWXZZdApsboGi3zr23Q0QLm2 3iOQawtZyXcqN9vdKeXD3YkGpffcXOZpA0BXRUcEyy1yrvBFP0Gk8lck1wHZrALS5CkuKnELyzTf pauwKnSoJqjTRXyUmbFEORnsLa/ayQ7R+xJt0cLKuuHaHWJRLCzIs7vvvts2btxoJ44RwL3ttPUf 7UQyOkg84VxrqCm2csUYZmHys5k6fROVg+igqqLIKsuKbDOrpRZ+iaU0OD4sdYfeuWRTR9uc/l38 vROW98Yxu4+QU/VwHh1nj3rKRQzLo+sfjYMWewnopFOU7DONTPKzGitRb6ii3AWPl+sNl3iO/07k V4XrgyCLeXR01Cmpl3K6zcsvR0cHgIc4SbFolVTX2n03WfBP/qWrgzW1uLqrLCcaYVV1LjI49ZGR m2vz6+EySeFF9cp0mt3YM1kQ7XB94+bM1QV5s8dbxKfgGvXSX824gFFQYO+3q8fw6qcX/ibxrejB lalbVD4Ob306AaJLupQ/GXGPpiTulXdnZbLCpHGUmHGJ6bVAKTIOgVOdpNUF7lj0EoU50WdiXl17 n9atyXAELtNaYoH32cuv/8b+5GtPO27n/ffeY+OETHz53bcciAgSYk0cI5AUIIADE/NZdK6JE8Po IgKdx+GI+fnNj66Zp69IiQCESG2AvM6jMtJOPNwBGxjtsZnguFW2VNi2rXtt27ZtHCarHShxPkkZ Iq0zaSd18rWHv0Q+0hUObNpsvm//qR2+3GGNoRmrgT0YHZeagXRNJaXQzdCMHD8D/jRWjhvIb3GB P/z/TWMeHcY1yxiH0AK4fhWor8hdlpKKV71vBHT0u9rI8gdozLd61pszbRdt1y17LKsjbLFj5+wi urBB1E+i6xssezyC9bu2Wm+NyoZ24xh+eHTEegdbTkxGGTJJBWd8Kmq7N5XZL986Z7954027D/c+ ZUQUeeThR1z/Kpye1iXtg1OAP6+ummVkcoOUnIfihB8/fsIKG9CN5nByECnIbQc8q2CBxGuTe+76 y9fetvLviTK8fll5dtfm4LV/eQ1RH8fxNDFzzwNkSx46aYhY/pGntAGg2qxmZ7TtKgAqEEiQ7pV3 2Pc6W6eyeRz5FXZ/ojErzGWpx90W5qgvOQWXeiLN3xMzxuuh1J7VIuaANLcH+BIEiDU0NJjAU7h3 l7VfPA0Q7LBznVfsYvcw3uS70KHD4hFxRlFhPorJ8t2Heh2rYADuhjzXZwscxgXc+MfGO47FWwBH qLl56ODgsyoyOm21nGS1kMfw7edWWvKQ8MIBQU7K2udkBZ6XyyZE3dQmr9fYpNh8VWYuC6DV1Eme 4uhE3L/kgi19JGcIAgCMsbAXaYPjT3mhSOQ2P52cRUdywZGPCxrf09/geS7AKREo1AKZh8lqTl09 IelOW/zECUQ72424esol9eRVHFJOtiKdEUq9GNdJ3J4sJY0nU7tVfSga07u4tgtAYYbb9bEABZpQ 9hIb69a9tRj9lLBBxxCxe3hNXZLshUT3XFWHBCl71+g3pr/TwUTSL6d7RH7Ab54URsVV4ZDhaOiq HBJfuEU1jcD5y3YcmIVuSv2agNYEHKOAdv35jUghCzks6MVSIYgYOkmnKTzGLXBr0M3NHhyxyVLA WzJ2XuJh1WkGjvvwlZCN5LVY7d58O/z6q3bvrbeZRIc5gBqJhOW389jhN6zitrtwLJxvvpkpngPo 6UAHWHcHNwCRXNSE8E/oF7c04ZtTLmpmRodtuK8bLv8Fy+oZsGwMF+o31dr61nVwqDah/1tBv+Ai h0klDpnEt2rzstMizwr0CLRaY7ONY/naN9ZtsTCCSzh6vhzmrXT+6DNZ9l4N/liPBP7Q+ZvEyKxb Il9CSFaix6XoSbIEVx9oT3PvboBvXHu1j1WI9sZs27ome/3om7YuPG7rnj9kuYRe621ca0fXN9m9 W4I2xqGlQKGOEkkujPIrMBh5BFc9u1vNt7UZDxc5AOwJfLnOWA4O+qvKC2zXxnL73Tu/JhxemR24 7VZnxKZKOhdGNFX6eqqvUsokCc1I8tI/MGhVeys5GOTYud9c8TZ0fhOHUse45NzkUmK+6jpgVd+9 IhOtWZ030bL0uTOS+bwqqurLrj4Nl0qES5noBDJO9rtXSAqvicboueW0K20AqIJEFGlXNIW2XHWL 62BOd7QqaQywnAZelee1X1xjvPZc+9Nqfp+bTquZ67y81DHJAdHgpJgcCKSDWRfZZAGBvIcIBl8L KJKj5103ycv8mA0PD6B03Ga9l7vt3MXLuOQZxUhj3Kawvs0LIPLVBov8ZW1tgd25v5kFK8+6T+Po mVOunw1E4C6+db292IMOFCLY/L/7zzbIKZfVi3084MKHFdaUw4BrtbXN6zHyqOREzubEXHM6YLRP 5OA2KtWVNmqz8gHw1HTO/XAu+MRvWkh4c+/JkHXqDt0XVwQT3gVA5dB2ZGzCcQgDWbKyIx9WdZUB 08ptjG6u/+j7FkO05v8Soa3+4n+wuECn0GMqSYXNpqu+zF5dlQ+uwauS0wKZALrD3RbACjMCqPMl DG3m36jipRcq0ovjuPvdt9627DUV5mtYA1YDbOMHEH+2piAIhbiDkRsKgYQJgFwWO4o2Mm/UPBpU 9zJE6H7BreGDXAo5v3lCmfIRxw2O5uZ1qeqgpJERKYg7OAmIycblikDOSpM7IFBuEA6NI7RUMqQe 0mntwU9dFyoFuVVFHiGn8Kx6xA+nau3P3rKK352yK7futHNfvgf9RkHiuTQxOGrh0Hpcp5TZ7Z3v wX1CjePf/q/2xP/4b+BsVVghRgR//O1v27/79/+HXTlzwp7CMKqYeOEfH7jfLtc2wCkD+DHRQgAi PxwxASz11xT+Oke6rtjYuU9sYuCK1SK23LRho7Xec4s11jdaKcApi4OX9mzNpwmsPeRORP2/sr0x OZJzbdQnDWnSmAQtSislqtEnH523A/LxVwg3DgCoxSImR4UQgCcK5hoi7DiOknWSmAT4XMSSMw/g 11Jb5/yGar3QnJcXAvW5l1Ta4sm1j1t0ZoxyiLzl7vtsEv+rZ3rOImVotW1futt2E2P3pTdetv+f u/eMkuu67j13dVXnnAPQ3cg5E2ACQQIgSIJJJMUoiqas4KBn2bL1PPZ7M2u9NbPWrPngN7bHtmTJ VKJEkRIpSiIpkhIDmBMIIpIAkTPQDXTOsbrn9z+3bnd1o0N1KI48B+iqW/eee/YJ++yzzz47nK9p tpUprGM9SFTxI+k6xxXPx6IKC/Cne7KgzyCKR7im1YL0ZRFh465cXoJR0xl7+smfcEqTaatWLnd9 LV+Tik/s9bPqPHZ9o1siBk/jnQST34dBjzE/OukTH6dB14GNt/+eD8ebo/7d6f1W77vEeHjwprd8 v7SBNgicP9z+w1i+41k5VSj2ofRqK6I7hTRhBtDVkUq6hXkKgMd8lTZ5zfJ6Y6J9MmbZwx+6wqfW icOLvOQ3VFLByCc+upeUNMoNNSKC2kLQCSCFaz4f0DInWJGRiJSctV+VC5W8vByIfTYM4QzrXtxj Ha1N+ONrs9b2TiRoUhTHwzyLUg1uWY4c3mfHn95r6+fnWwG74cLzpy147Bxxe/MteUGFVayotLZu dAwPnrRsFBFDLE6SHPQQTL3+XJDwv2/Zm7lldu8DD2EtWeAYPSGCdtt+72nB8Xe9aic/3XGIvt0P LkRMRMz9d/TIyxm5ikzibqQg/RyHhZHqKK/6QIwGgiaKpiAIZXAJroiw7gvzLaMVgLvSYh1LFfOZ pHjAgRFI6Gy3pMd+aAl7dlnvHfda1823XdIc9Z2YfNu9yzp++XNL2v2R3X51BcdeOtKnp+jTFJTy NY7VzYwNClTpvMQ6xotmuKJ04yO0xasb+aSjxcLMy4ncVNEaUbcjwBm5+lRK73y5P1CQYz0ec9Qb hEHrBaf4D6OJJXBkbC+p9ERuUIdOjiKSKF91dEBjeF+RJhCA287aTgtkYWTEu6pzTElwoBkpNQ2W ceK8pS6svOQIWce57U3gblYprlk6bOHOd62opcaePnTYvv/II/Yn6E0XoQ+YnZWNjtcGe+xHP7G5 505ZYf0Fqymfa+fmL7FERdmhsxLY+PXiBqXt3AlrPHfGms6esnwqvHhmqS2+YjNW/JWurDSpX9Cv aofzz8nYaVw1xppWMbdvlE5w/es+Ls0gg5JE4Mil042brrdfbH/bjgbr0akj5Fw3ikL8OeYPfHHW vsIbMX8cNsjrYrU2n6iOlM7AlUxEj9Nrhw9r/NorhzbKinIkTkmqShlI6LZwPNvWfLklbW63RHT2 EjlJWdVSax+88bQtyVuMsjUSP42pdrVKQv4IHdJP+ZVUs2maY/LkCzWNqB4LF5TYhdaz9vzzz9q8 ObNdJCTn7NwninqXP7olhs6PjBFwN8I4d//qNeu+fb19RL9IIqzoSrLYT8Ufooz2NA/VXhXtEhMv qsr+3en5FiA1YgAYv8WNKjma611Ox2dkBKajqD+YMsbH3JGrOmEGcLKARgY/xl1mQzQujJFzCo8i EITVoxCdKRQ++Gq8O03NoA1TAaMu0PtaXLWY6peOhqV/qcVUDmtFNNM5Ji2EVRKhUDb9OR9ZKP6v XHkZPhvfsrc/es8y26psM+H8ygigHsYApAu/DmsSCeVWkW2h3cesr7rFQmvmmbHA9OCmoY2QS1WN Xfb8Jztt10dLbOOWLaoEyTXOu+TTVc3/FaFG0ff8XvC/fSSKZHUluFEXMRMN1h0+/DL8394D9GvQ +eijXX1IUzgb82ogXNGfxFTjJL/c4e0Y57WJPXaVntgrMeVWR7HABarOW8LpExgB4HpCSfcHGwad 5geMdN/OHRbG9c+VPa1WdA0ug2DnHPPG47QkbzGRRPB0Qx+GRkGkgfB/lMVaRJEqlGuIfhK+2ULE zHIOoME9NzV9eCqQpFNgMYgSJOMJhOogvWVFTkTMmMSxqKRY/azUYugnnXhVb8s/pI5udWTq1zOW MnsJ4XUAZ9BNWEGnS3KpfvLbMU4B6i3FGD57/TprLS+yuqVzXSjH6NeEvzVt4CWqGbLYPcmxYw84 2XPVRvu0oca++73v2J1EhVi2dKmtIx7ss0/+3A6yseqE+auZOZt5LfMoFnsd8Z4+bfWnj1k/Dpe1 2dtw+SpbBMNRhqPhrKxMtCxUf2rFvJcESlJbZxBBjwzOrejaTe7aOyK/tJPcOFCkNn+KZrRqxUr7 cP0me/HjN2xtPpJpPCuLDkniquNgMWf9SAOdk2euG2Fw2tBrnK84wxyNC47bnPDORJLGRT5Edegx uGYQdQnGOC0ViWoR5amf6NvF85fZjid/SvSidsuYiwpAQ6v17TlmVpJngQWosDgGh/rSODmD1kUb G+OwOznx2irXRpcjCTzx+2O2a/de27hpAwxit5tzwncl4X5MqKVMzAtZpF+ucH2fHLUjWalswHLs lVe32XXXbnDqMwF2VAg0nVW/5pmssQVD46xxiE9SzwJnAJn4hbNx0RUGbNpAunaotPg1ZAp1nUQH D/TX5MBqRZt4infnCROUNDPinAbF/nEG5NA7zu3x+20KTXFFuA/PLQvrq+c2Bp9uIjdhOVfmeDbo FkMPoPSiklCQVTi2G7Nutyr0go7s32HngrnW3vmhdV9stJkX9mPllmwnmmfbDPyWFeIKobOuxepZ YDLQG8xDeTuvLNE+OCtdHvy3Ub5KnxR+082ireptv8ej+QBnOOJVXZTNpRHh8CyckWX9/LmdO0fe Se+8aQGkLT0bNlofi2ksTOBgLTxY0/7pGuq3dBpLh8OQs9Pw5x9wTHD3GpyfqvhIn/mQdATvGEUs IhNxKZH99mvW9dJuq79qsWWVEYs0mRwgj/AnD31Qp/7JGq3wcep3bTJc4jrEcRTYNJDfh+F/S9rn SybEvCh6odZiSYbEmBhhDYP1zRQEaSMKg2ceGVVhLocLGlS2ckT3oBgdWc0qznUP0pA0lBg9gwll jipPL4+Q1N5zLf12Bt2zVBnDqPDxXxssKVKhhoXl1jSrzPrQS5A6hZ/k/qWhCWvSIFEmkMgzAPbR FdfaJ7h8aSkosiIk9Uf3brcffv8HTn/shhu32NorrrQXdu2zZTfdbY24auo8ecguHD+K/7kaXNWk 2BUzS2zhlqttJtaOxfm5nLZzfK5+JHUxaN1YqAZw8yTJpGMGqeNEmuQKiuVjtEIZOEmmgqibJKKK sfXuB+yRI/vtMJvJbE4T+qWOEkJPlNOJfnQuJd1XvwfCHHHiAaAIy81knCo75o/x1TCOBmq0agpX Q9A7HR3XE9lDPFUObo/8MsVPSkIolZjiAnAf47PznIbMZuPSt/1TC/z6LUuohGH9m/ugLSnW29HN OHYaZiGOxKQiAkwoxJ0WMFRmMqoqednpVlESsv0H9mOsdy20TZty4adqrz+NR+SSr9FSopM+suKh r12dzRH+omXWml1h7Wcv2ve+921779237d577rVVq1c7BlMbO9DM+WQUDNcsPmJA/9GqMPp9yh3Q lWbyJODjNXjyBMwfcZbnzmUewwSqqVNMaoMrx+u2KZb2h/C6Ny6T7ZoJM4AOCRwqxLHxPpK50Yoj nOnAqJiqJ4IRU8YpZZp2GGCVEEtMoCQpCqPWhaRPC3AiTFv0jEzEW7KIlsISZbM7nzFnjoXRM2o6 8oklfHLYkl54Fp2sBDtSON/2nu2yhb3VNl/HNg0tlohhSTISIlnW4TTf8opL3bGUozTAHK/r/Lms 9vuMnyNYuuH9d9IBp2gM9ZLRSRJ1TU1Bh8m9oH3h6FAgrxAgCP+pExZ64lHrx8ddHxaPfRs2Ii4d XJTpkEsTdRi95Euz/0Hdodn9jFnP6rUWWLaCcaeXxIENS+p/+X0LsXAkfu0b1rpvp/WeumDnS2ut MznfCgvocRYs8WeKn5tOX+IL1/HO/omYOL7+k9XWjwVlf9lss7m4HHKYNwhMek8yNKBK4B8bEvxK MpDoJcIF0skyPwq3YCXcgoQkhXpGGCa943zvUX8tXmqH4lRHJ0m0nK6hoEaGVMdx/uiFkQIGMQJx q7R8boyV1CGM+wX5q4SJUoxfMZQTTrzSjx5jOB14el2VJwmt2wh/dq6hwJJyi91irfvdmbk67eQ5 ofeycvE5mGYtB/bZ77a9bsdOnbT5S5bYhfY26z5ywLqxDs7sbHK6cIsXrrVlCxdYXkGBZcAYJiHp 93XjxIQIrHzaKVxZMiHKXCxgryoCG4c0dGyiAcDeeXhIpWbNqrSrt2y17UivlmZTN1llYDRjtZy7 S4SVSzuIP211HZZJTN4QY6jOc6cXSBEHFPqjAYxz7cLIUQeFwHtv2yuWA15fc9cDDtdUvCTS0nXV ZkfGcskz5lpz3zlrA74cz1fVNlsrjGlOXasVZ7K5QrVA/ZuMakNIOoKoNihSk3qgU31OeYXoBmag R1jV0OQMONQGWch7JzU0SXUeZzy0WfJInaylg7Yd/HiLwresXW9fvD7dXn3tZXv/3fesBP3IyspK 3GulQB857uc9GeW1C0Y8k6t/ZNxpm6JuBPDioOOAAOtCv3xAjtfImOpHOREwMWX/TDNNpmLjDPw4 9R+Hko38thA23gkccLur+MIReY9/Y+IPIb69pNJdG8QEspDpGEYWuX7SM04KIcx9LBAQMIwtstlh 9vOXiTShb+21lkgUlxR0qK5DN+bIydN27nv/ZnP37rWiuouWcN1yQlZl416iC4lGouXgrgLy7IqP BdfERIgdVQrASHiMnix9ObqD0Ou34pRKZ0rHXtJXS+IMJxNnq/KhJYLgG5F4pQz9HHCXkY0eD8dj 2pVyVgJ++rUcmn/oLzGXccYAb3BoRBzgUGQ/7e1ndQ3APPTBeA1PAtuLWDWIZDhMZIqqJXPtPNKR Zedr4c9wbps0i4UMRg0pb5DQcEEYuUbCtmEU6/Ta2iDwrHGWeR7G+vBZxgy/jvOAEmmOvhRRQi5h dPym8U7gaJVCOFuG+Uv2JLRa5AJYW3Zz5BrITUdlIWTdKOlrY5EiA5JIEuYO/vJu6khv4F7kWpFr 5PwnhE5UV3WTJdU1WwBfbf0V+MITdxipn19u9LdgSGdNREzXY2SNfu2Sa2f5Gnl/oAz64UINuJsI AyhmNDLuVHcgBTGbTitC4kVklpSZlVb3u9/Y4uOH7arCPKxna2zxgnn8LbAS8DkPvE6FWdS8cPWG yfes4cW4Y8DA72T1JQzgWBulAeBTvYhqx/Ci1NROpIDI0xDyBu06YuKePnbSzjfV2Sx87slrNIcV 8H/kkeSZcce5Dcfkyc4ti/pQentQhsHxHg5kjN/CEbc20VM7935iV1+xDsZKhkyUS+Eii87fIhnF QM1EenXuo33WhQ/FD0OptnvuOkuaOcO63jljxbjaWlORa5VLZzic7jtWBfPaZIElsyyMXmMTksE0 ORHHAenJkw1WtmS9o1/abAmnRetcGgfHnKRc84Z6Sootmrh2yw326fmzllRUYldccTnqO6vt3Onz VlJaYs8+94zV19Xje/dPoONZTuLp9A4Bpv6Lf0LFKBsagK6mo7UwztMLeAwEi3/jphnC1DiYCTOA HgJ8NmjgqNE0d9fQ4j6jdoC9ERo9FPx/xl/qMv6G95x+96IsIolBUMSJHDoali+xUA4M05VXcTQS sBKOlLIr5lojemV24IDVnq6zPBbpRIh5kyQsOHUuLsLnY0QMI2I7BFbkh770TLtab9nimx/dHFW1 thLSvaUJpgErZpxGS+dH+os9PEukPmkcVStUXTEK8iHiCrP6WUDxNocPkgDwTt/JUywgcCg4X7Wv /Tk6NBjAEAqqX8zjOAnaPKwB47wwmcdU03WS6huPpH7Rf75H0qlzTdQzMdvEay74xt9aR/6vLf03 T1gTC5qVF1s2/iKT05ASs2ZxOmY45HHXvXQQQhTioSJlyC20zCWVloAFsT8WapEccINSMH86XuOO OhVGXiu4pDhhHOxpKeQOBj1ILLPScZkC04o4RjiQikjGSXp5rqR8w1P0Pf/al/7JtZCiEklsCaiB ug0vY+C3Kg03UJ4ZslN13WxEwK+Bh7FfCLclVZIqVCIMDTr6pACW+QlW35GDw+FhOKuBGEhe7WVo ld6eZ1fXVtmSXQdt2f1/bIEHHsBpMY6PcayvOdGCpPIi1tvtbVj3I3VpqK/nGuMfmP75qHNUImmT 2kcaUUDGE3gPgJ/SxZCGXFKSYp3LH6wkZblI4ucinX7nzdcstwXH0MSFk2N4orqhSgJjBkmpksSt shSGuMThsPB4cL6MDWs4cJebjzA6hddcdx3xl3GwrfJAD/YobpzhT02BSMQ8zywpsSMXW/AT2GDv 7W+yq7/8FzZvyUI7V33SDuzfZb/Ytseuauu0q3Cknfzs29Z74LR137vJWq5Yjr/qAD5W0+yt7Ses oTfP7t5wNXRRGzAZSSkBxH1pTgz+9G56n5KKa94kwggrS9X585CyFJszZ7Z94y//2vZ/ss++851v 20233GibNm+yhsZGGM9me/vdN+xa2rdu7eVOei+jlAF40QDicc3YatPZN4PNNn3QL5Nuv61Thhfp symXE48CJlO3ybwzWPcJMYBa0AMc/XlSFE+SEqWWMljqFK4GXL6oXcLYOCfN3bjDAYmjI1tMe5Nc G+isqeFCbNVyC7CyjgCMKmgXLN5NCy4hNkmeqjLyIY7udE/SGEJk3XSzNaG79OvnfmnzsAxdUY8F 4tkm62Fh6w/CMELkneTO4cAgIugYWknjpgVSy5wYPxH1uro6a8BQIYy3/FS4CunqtHEkVMeClleY g/QpAWvODmtub7LfPv+8XYnEYO3ZU9YOkT6KlW8nTIUYVw8AMKjnInym5f/mKUIzZVji3/y9BRYv sgQ4kgSYXXck6uUe9dMdlw1Wf9R8U37wGcBQX48kzRRo9YXGJJicY4WXXWs5oSxLIRTfh3v22IXz TXbv7Gzn8kfj1I9iUUG6FhRhEZFDGFNJYFsKc/HVuNTCSQr56EES4yfpn3T9nBDPwYEBIOY0oisA SkJFOWQUfQpzZJqYhw6V3LXwIIkxFL1ylXMQIx/CYyVVeoykbPK1F+CITjFAA/inHE/6p+KYAlbA 0XQ+yvY1zcmWjp83gXJQI6AdWO75NRh45m7gOgdGr7Yx3Vq6OZZN6LC5ZY0gPXqFF3Pxr4geWXQ5 FOZwjW/nvNwVrpsUhvFSWk6uhU6YffzpATv75ptI2bOdJKiRBb+6VS6d8NNJeLJ2JH1hFlzNPW10 8t9/z/7kK1+12UiypEP2mTCAUacLfjOiv9VsbTYVp1sbgRzCt2XmF7loRBmp6NBlyp0N0vneEBvA HtqUbKVs9vqEM+oPVz7fk0hiPkXj5Iro6quvdr75JC3lIJebXoHeAS44wP1SnOSHCZG5/xiOsxPy bTU6srkwqCUlpTBhC2xX8Xz7cPf7du7gfrvpXIPlKEwcfgMVRjAVvdNX3z9lb++stZtu/yObVVmB VFknG4OwBpoQgT3wO3LhNk3MEc2B48eO2j//0z8TVvUW9zcTBms/KgJvvPaGXag7jzFeL3lO2CF8 n95421YrJDqKzyz7xavv/evhsKb3N7QGdQMvTSfEz64FE++PYRN6jALEzksqq5Mt54HBlwaP8Y4e OQiRNVS/Y2YARfpbccLazjFQZ2sjfojYgSHNcUOjj+i6R/8e7VrQo59FishhVyp/VO7hOIRARUwt Uenoek+tsFHf9piKzwTQqHWYtgfjNENDqj4VndXiLaaBEz9vqDEpk2WnU3jGs33mFx9m4WmzDz54 yRai31K8/4Qtt3R7+fkXbP3GTR4DCJIriRBJwqSzElXBweFTzJ+ORM5X4bOspcHyYCykdB9iIWvi XCZBkSMoIrMI9yEsamIseqSok9VjnTvfsvDL71hrYZF9sPGM1ePVPxCRPIq5bCfv2QNH7Ybt71rW goUWJExWP4up9NnkKsdtxl3tYvnwahxLzsnlUa98Bmk0MMxVuc9JFhNNU5MXLcFv4t9bxfEj9v7j P7XT7x+0eaWZ1o8CvKLJOAShusIThyVQotSsIEd5KVaF9aZ8+eqR6Iz0nRK08IJQAo/AGDwATpoY FS4Zzm6QTMYa/ekcfeKzTuUKZzyXQQ4IL0US73i6jOCDBnqMpDd70cVKQooYzs/mWBEGQ0CHFTm8 CPmHa65vszkcGbfAWHWl9nEKSUQN8Kuz3XtfxcgnonNyTQESgPeg2NUPc9PZmGTVffn0A9IspNOt uOO5WNtBs/usrR8/mUg4/T4UbElCk9DPlYFTL1LuASaQHXqQ47SPb33QTiy7zE5lZtvFThjl+nP0 HaE203CYnl4A01wKs0y0HwyeAljLyrF7d2OtnfrdL6wWp8HzNO8oW8eJPoMzvM3T8VtzVP0yXlL3 d4IPifSnjjVL2MSdRIJZizV0KQyf3ML0QW9q2QCmotso4w+/vxK0k3DS+3EGcYRKiLGXvmgidCwZ kaxwTExZF86o/dI8nPYYwFx8mhrH8CFC0WUmZ2ANLuoniVyiFdPnOsKePXe+vffq7+yp0Cl74KFV lnX5Ijtd02Tbd5y2o/UZuJj5gl2+bp2jpQ5/aLc3E1RBOitqQdcdP4W4Lwf/CqdahzPwf/3Xf7WP Ptxu9z/wBVeHHjY0y5au4Pf99utnfmWPfO97GIB4UV1WL1vjmFQHCRDy1wq1de/55U/vt9d7g2Pv 9+b0QvFKiwHB4gE2ljJjbHYnLtjqGpqtq63J+YSMadIAH8y3Uk5jNL+FuzExgJpg8v/2y188befO naWQLpSsiZsoRs3vSwobuFRDo35EXXKfieLndaMdeSp9KsTqy1BUvvn2Oz0iG0d0UxWVHHR1ul9J dzceHwIS4+hOFLzqHqeih1dFoDxSFxtQV61I3fSlHXQXBCyFsVe4tk03X2+/Of2JHUIBeR2Sus0z g/bomy/aL6vxfYbLGTmmllJ6BpI7RUUIaFcq/TuIm47m5KLj7Llz1g7zNwMmL1MSACRBjRD/MDv+ QGSH5MfjhJtwTGP+InSjshZbQ8sFa5lRYiWbKixPyu9+P9I86Qm1JrfYtuN5KHTn21oYymLwVAyA dMakDymJiEPj4R018DuqwHgNkgPhwxkAHJcLf3EbXrig6+hLzrR1NCcffP0zy232jJl2D3GBE//H 31oXgew7N8IQ4YtNYhQdBxfgEJBhdGtzKkd2km5Icqs1mi9LgUETj+ascsUE0t+K5pABM6XnjuqQ t0uME3VwDISbzD7zN6ymvOPiIFbVO+mhFaNrpMEcqfvI28FmQfgEaJgx/PI55nVYmfqpcilD9e9G QhyGIVCUhUyY2pbGXvu4iag4uWlWU59qF5uz2USwgyd/VrjZEtLgaEGitu4U2iZGhbLCieiBKcIG JFr4lp5l1RexdEWqmggBj66wrF1T2ZSvfOsVXg3Yvg03WIcYOR3PUFYAZqN+wRKrLZ9l3Z2tliPH 53rGoh6EhtPDbk44K2faqGP+BI7gWi+exzlxgRUxhtID1Ng7Z8xqa5yS1gY1fzwQyiPH08I5Jenb FWE8VnPmuGXjUioFTrgGmtHBMXZxZpadOX2CU4Biy5JVv2BoTCPveiXE+Mk7Th9V0kdqqk+FoRup KFc+iByEJlWw+dl3ihMOFu5E6dS6duJzDyZyAQxgLhLZn6KO8ou6k1b44Sk7Vi1juLl259032oKF 8zGSS/I2D2L+hIwueXg5wOxH7vpfSTB/olW9rKu//OVTtmP7dvsy0tyVK1Y46aTqUIJO9sZNm+zp Xz1t8+cvsq03brUKjEB2796N78Hn7fbbbqe+RNPhT0ZYIzbUBzilb79NDt2nVNJYL3sjRo5BcGNl /4yfgUXj1Esna92d3Xb0wCe2Y+deovq0soHMoJ7QsHEGR+uVDI2+/qd/bKU4UpdOdUwMoOKytjY3 gkBv2oYNmxC5w0FCVLQAD000QDNhSCP4oZng7vkP/HyDE0eI2sqR4Fuvv2r5SIcuR1Te47b6QyFM 6y/VlXRJlb3b0/cZgTOsY6avfFfSAJBpLndocT6BduM5CZBCBQlwFGJKhHPenMV2F5ajh4LZ9urL zxOUPceurUiy42n1BGvvdRE7OkHcZOmSYfVZX1tnzQW4qCAsVjqLYiMhJjraGm1GqZg/GDjK1l8X jGF/Up9lF6IPhhd+4WB0dWVU1ooX/sMFd1gvx3rpOKVLAwc9bPDKkPSye8tKq0dqtefDM7b90R/Y zVtvdUrTEr8nybcdK5AUsqPLVin//0zRrby0hRpbnfpzYIrPOsYMDke6lwtWrrJOJCHh06esa+dR C21mEeZsShIcAh9YPuqVIQZE1CATZfVOaJnIGfI9x/zpvozOJX9AOGYhGZxEOtlREDFIjon0pIQy zREj7wgeO11+RiXgoPNmuCaSFNFyIZ7KMzSTYyS1uXDHyOCVG2PgOGbUL88faHgpMX7ODQ1tEhpp 0UznPX7afKxR66vCtutY2NqSyzFcof3kkXSyrgtmThYESqg+SPpGs0kwiCzgLpFPt7BzxckwPuSi JKh6HoaRy0Ohf9W2Z1wzTi9cinuPHKxevXL1ro6HE9B9la5tL+6MxP8lwvjKIlS0XMeV7mXaIWBh IobU7N5uN61dbWXoC4oB7GI+Io8ln6sg33FKQqQYk0KF+tnzkfQ1NDVaFX+ZtKuGTi6eWYFUtcuq zp3HqrbXUuam0QeMN+0VHdK7E22N6ymfCeP90WorlZf2jmZwOwGfiiX23p6P7fTZKlu6NBfDjh6H M6IcoiXF6DJ+Drc2+/btcj28YfkMmzd/ARb0OMSnLb7kT8PkwxOeuQ2rbqgR/oNI3+m5Urf8CoJW X//m1+22rXdC6wh5qZMOMqgt5RWV9s2/+ib2bTMIjZfLEfAh+82zv7LqC1XUYT4RSFY6o7kwEmqf 4XYFj/aBqFglS2LoEG20fNH3I3XV+hL3pE5znTNCp00VuHgiig3QV/FI6tlu9No7W1ps8ZKlzjgr xPx1QMcBqGhGUgVIQTDi93JMDKD6ShaesqJcd9VVbtcgoG7HOA7QiTzWzkZHPU//8nF2RFk2dwEe 1OOZHCJEcCGucOhAv8fjAUfESCAEw5/18YDjyhQs/qbQIFkQaxetBT2Ifsz8Rast9y8L7NCiRfYy getzqpudK5h0LU7snjvR42nt67E0dtO9LKw1NbWWyzFfSxN+uCCyZUWpWJEicYr0sbojCSLUhRQw RQ54RYeG9YckSmEW/vZimSMoKcdgLu8XDAxHeIUrCOhelmeHPjpmP33icZftqvVXWxAinsKEx2+x R+fULSSno8OA+KV59fJ/eXmm9TMCN/I1rUUPKYxxdwvOkJsj/KCp4p00IMnyHzlvgaXc/Dnr/flj 1oyeZ311na1eUubGp6oZRr0byRoWwhmSBvKamCyv8zzGRxBc2/hw0ldlik7AkQuXbjFSbBoRELJo RphycYrRXU8D+lEoDOBbzXGRkv4NwIsUqlfE1MNAKSShWFMVo8VP7fL5MrlG8aoCLgFaR9sOLggo vNSRqTYICi24FCbwdE2SNcB0JmdI0qyll+dsfCKtc19Dpq9fb272wpBJNSYxg/w+orsSgAtX0J6d a9Wzlzhc78jMcaEdI4/dl5MSUV4Q6ZMASYetFwlZPz4tJQWUhNFPASy3L+zbbXm9HbbxOiz41be0 QwygC2fmZ/wD+BZD1K2x4p+OVeXG5ARGDO30UelMMTR5dvIE0j9oSQ+GX/V1NVZMHtEwHWrGxNCM 0M5hQ+ByCI2iUUlMVhbj1YVvqy4sj1fNy7TXXv6dzUbCJkMMx3SrIHChD2SZN2cujrdnuI2BXFRp 86RNQjd4qNCJOnr3UcKrkv9LCDu0kkngnk5JVHwi+H77rXcxvzLZlIj507G1N2fECCfCoHb3ddmL L76A+5dkjOsbrGgp6g753fbOB6/bkqWLmF/o1jJVesfrMNoRRNoa+vB9650928Krr/A6ZWj1Rvil Bmi+08ZhbRkh86RveeXTX+JmxTh5Vl2TLm/4iwkN9W5u97HZmlQar+1UXXgjx+xXr78GuknMeqk3 xJIiyJmBlwRvwzchHUAR3yDIArFAHB1MTHE7k1jgxppHxzcbb7jRjnBk9LPHf2rf+tbfwwiUsFvS Xi0eST2i5H97v+L3Od7oThayV+6QxWOyRcXwnuutKTRF72uDpEVIB1CJrKhF5ZWWcd+Dlr16nR3f v8/O1F60DhanAJsOLbPpJTMtk0UuH8ONC4cP41w4gDJ1KosxR21uRzNYIRGQDAw+ejkK6oApSECq JK5C+DWEUjpKQ+bBVy9pvXakQYhaZn4a7hoqcAhca089+0vLuVhti4mgYEuXW8qKVcwkjzj3wxC6 yaWVSeSsP0RbtTzFNznC5iDGF47HAY7fGrW+R5w4x6HJGGQkIN1Iwql0Nkd1T+7fYx1Ha2x5ZoYV ouwufRTpVZ2oI6wWzBLCXetHSOcGRg4DtVtIR0woP2n0pPyfDd/zarET09XHkW0/HGCA7wAbB1kv 9kcf8apiwpdKLI2VJP0DtktCDxbHroh+mLOcFO7wWOUEkVJ2oOgoBlCo5MoGP0KMudyNuIgo4Kq3 AfCK1Kd4vdz0Prt+TpeFztfYQcK3JWGdK6bM4aTgKqkakaq43/4H+RI4Cu7jKM9jA7x+8B8HaG8z RhDv3POwYxKacVAeGMFdj8tP+WL4cKQIM4deI0ZOXRhOhVJR6YFJkrSpDd2/C3vfs4dvvZGoIBz/ Ar8HZldHiUEWnngm4bHr3FiBaHgi/aa5Kj+GM2fPBhcScCgAE8MmLReJYIg+agMP6utrraCg0B2t M9SkkTo8VuBePg2fQsOJAkAqGG+uuRlm4LOJUrIC/b0Xt71nt66fbb99ZZ89i47znZ+7HSOPZDYU 7CiogvNTycsZqMUoSVrjGD9wM6yjV1e6ezTw4dqt9it/5K4wQ+juqVHwkIrIUKCksJQyxRB6zJ9U caRmIT3+4wdP2M9//gQRdTgun1tsS66bY2Xzi+z8oVzb/sxOu3jrBZsxoxw6KNm+aJnqM0Jy9DVs obffsOBP/8OCa660LlQPwoQiFKM5ZnINGKXcMV+M/aEDAX4n791tyR+8Y3YZ9duwiU6gIwZ6MPby huRk7EJITEM/+nfX1vBDX4mUOyTXuD9EMmNJWvfEhyVByxJhAh3ixfCiio82SIX6xZ409NqR6GhF u045iJxqv0VDF/5kZOTY/Z+/277/7X+0Xz31hH31698gy1CCF/3OlK4jM0dfMfb75MBF4MQNiCrv sFvfXLiJOLmqjveWK9phaTTQ8d4a4TnVFDnpYkcp33KJTKA0dsvLOC6cQ9D506dO2/btH/CiFskE mIhkxN2e42bFN+1oqSLWrNhHZfEbPwhHiI3KGc57RUgxEKDOsj517gxcF0VG/NJXBwuJXCmEVweB 01NgZJZumMeR2wmr/sG/2DycuvZv3mI2d54laEHHhUbCqZOWQCSGAP60dHyYwO47jBRJVouKKhGX RLEeixmn8v1KU38tIN5sGR+WshI7AmZOR2/zLPClr1g+TOAWLFEPff9frHz7TptRlm7BKxehK5dq TZJyQFu0MDkclkSvGR8oGFHIyCGQrCgOXmW03GoxUlKdGCJLRDemj7zCLMMAI8T7/dli9hgPmREr f+R9RHt6dSCJSeuUdTcslCQtyYhQnD5hhCI7bKdYOTsPqYLccFK+SAmiUF6/8OXDcPe8D9WvNLvb NifUWvKFsH3SBgOG70tJwf02RWV3l76jYkkLE9ymGz0w1GQSMeSIfklly/1NbXEZ70UYkRHqMLR8 GAMklmHi/yYgaVJ/uzZC108TynHpvDl2zYZrvXpQwS42a8IxwYp1kRoKL9Zfqvi4lR9SmHKLmdOc 13FqPlI/1x61qbnOcpmXPUQwqmW9CuJQ2WvpkCKm9EO+Kd3eRCWLmYgMqPBS6lPX33SH/Rrr3pe2 77GVa0ptz4G37WeNdXbj1lusvHyGa61OJLrFJGnzwUBI0CYVGf0YvTe8Z5ouUoEQaBl9aFl2jqLR N7xQhY5zdyOqrqWmI3LVSVJ0f870Q6Oykf7ecuOtbpNxGF+Rx/acpAJmB3ceszrCeHazAfM2z6rN WPXxnhsqXMaGpF+W18KtSH+M3cmD5fqwxs4/iaceglvog7ctxBF3f3OLJaBq1qdIT95uYBKFRl6h 0wMILYLvve02dsGbbhUyTrg8VTGWJJyQoMH745d8a8WQXBe4UfQyT4gB1PAquU+vJK+UafoUnvSx yyjDouuuu+6z73/3X+yVl160mxFfy7/b9CdvajmmZvoL90r0uoxrwRr4Mc3QvHK91kxz0cOK0xg5 ZmMaxt+NN30io1z5g0tm4RbBzIKZKikpdrthEVSBiiYK2YReqq+pdkdSqRwJu/qonq4bvL4Q0RER zEYSqCNnGZ5IktGJxXCHGEKIWkq/mIIYEm3uQhKViXNhp89z5WxLO3nUal58zw4Qu/jkzx+z9Jx8 W3PquM3esd26l6+w5oe+bFngcQaSmwBRF+SPTUc6jtGgLtM+Vipw2guNoW/GyaIxFkuGCYQlwxjL anv1lVdY+ScbLRml9JbqBtuZmoU/tRlWyHG9jsva9YIao7Fnx44yGwQaJGlud34Gk7mvfuzmo59x TGruZsEkf3u3hWBU+rpgBJFYBVlFxbhcDDZZGtFmpDbgFj+VzX8lzX2tux1a5KDXQZiiRG4qX3Ry OlPASOQ813sUxUa4G4NlRr/nX3ulBawos8u2JNVZek2f7cAauA8m0O3IVf9hKRnLX0Vi6ea0RUxg ItEbejD26EX1IZSF8YrfCK7EmHlp4MK/cem3qy9zoKMdXT/CG3JkrFsJHImd3bvDEs4dszv/+ptI 3LNhEDm+BF+dNTV1jKH0S+FN4E5syxgFarCikrpPa7iYnwHVJBrVj3QkAamgKh4ipnEhhiB6LgZo OtqiWui4VUlSvGq8EaSlJeEnXpa/SeBWGH6o2O6+5357+rke2378kK25bIF9uGOP/ccjp+3zd91t a1avckZBIeiU9J3VDsdoe8WO+im80emJ3PPImtz9Q98RnRk7ix/U51940apw79IXQnLbmWh33HaX rb5sNeWJcdBmi0vKKIJO3Xf/F1wf1WAt/M4H79qe1z/iOL3cNn3tZsvPz4/0l5i0sXpNz8Crq9Zb GPrdT1+zc+feWO/wmORQUvnGz+q9MIlPGTdJF7YPAUP/0mXWtxiVCalExIx0YwDVuJWVW/iOe+HF kJbPrDQ7emSMF6bh0VASNakCJ8gAaniVQAMm0DTAv6TSmsgi7vMWLrZbP/d5e+nF520mnbl8xWok OW5luOSdSd+gAeCEh3TxaIxfMZUtDI8Tcjvi72YQMLyZ5EOe5u9IA4AxHimIFbArkQ8RvU7GPURI OS3iXZGoA/5CHIFMH6LXJ6LOopS4WJoAAEAASURBVNhJHM00JDvCGSFjoIMjMhzYBtCv6SfusPpb 7KPbEUMg+9H3SAHjU4HRhvQuPY+jSSmEj5G8lsLAcJwYwgglkfNJSYcaP3eVtV82z46eabOTjZ0c m1Vb+p59VrJ3jx2ta7RnCLNUiA7S/Ugdi44fM3YxFsDlgwiuiFAHzInQYlqSP+xxHHtXV437wISJ veYaH3fkr+NgLVicUZVtut56q86gstdntTBd38P32FVZjVaOnpLl4I6H4mWpGZaz424YtyYkgfRz JxazDYyvkyzSl2kwenm4+pFFKzsHpECMMwuW6woWwhD6MSEY7wsca7YghSnJJzyXkwY6VHILoZg/ ucpIAkcEWGPu0gDS8YtbjrkAqcAo77k+aVwA63QKcIYtA3Nc5bg/rywttjJ8uojCaAtMV04CPva6 WuxcU4GlFs8WojqmUyAFIa/mvK16/UVrh9HbtfFW605JQ0LDsQ9S8t6LF62Xfgypr/wxd5NgsFqX XEXyiW7LO7KsgaXQGErLdMe6Ceh4dTQ3WDXOiR+48QZbMmeOY2h0jOlOxF2fqEGXlDytN1zfOxwb q1gqgU6kY/RwY6MkxkRSNK0Qksy6RFtD6GL148JJs7wEBlfGOUrqBv1NtTnwXg4vNA7tuIn6h3/8 v21GdtDmLFzOmrXO5ixYgMQYf5CFZbZ50532D//z/7L8RZ3EXF5kJ/dftMceexRh9J/asuXLwHfG gzq5ZS6GigldQxwjO/rGRx9Szr5fP2Xd0KA3eXasIGSLrpzJpiXBTh+4YI89/qitXLVioH+kO4li AfULuU232qDNd35+ga1deZnlIUnNw2JfjvS1EfDwwHXfyB/qUy1GRIAK877Ki51cDNJDh6MjQ5jS XeFIABzpuvIaS1i+0vpzUQNxvganhQPktCEbJ94eI92HBwCPw469yg4nY8xOL6uzwd8YEGWMMsde /S550YF1E8c9Emzv1iU5p3JDAyWkXr/hOmvENP7xn/zAvvW//K+WzxGHrNGmL029A8ety5D+GfJj 3FdjzaD+UnKooMup4YQra6wPN+zT3BQVp5FlfsL8YS0Jc+ekDtHDDWCdvsk6Uj64ellAo1M/vrMC F7EWhoGwuRzBRiXRJY02hrvu/bJMfM4hUUrBUevw7vKljZqQskTvaHUKaRBYrJKJ6ZmSlWTdhM/q yUqznsQOy7BVMBUpdrZ8rr2/cKVdIAh8O0zGCSKSnPv9U5Z54pB1sZBmXH0t9IZFiIJ7ACqmd/rS 8FZMX8kqyVVVHyLqk6i360t6Wr7ZUgK9loDlYejP/8pJaW9icZl5kGPh7S/bjj2fWEE+0QsK09yG T3Gn+zEBzmOpwqOKdaEG0INLnqS0VGcBl0YnJmAUlIAuX39ZGQwqRF5K0a6eXLNC44kNw9sMq7t4 wU5VIfGCgXeqAGw0Ehlf2cTllEkKhnGGVt9GJG/yoEusVj9J4KQTaS0gbs8Q6Qv8CJkhxWRXYn0Y Com5V+zh7q4EHJ3LdQbqA7h0OQmT2gUX2IGunVwH9RMqIrcYOPXVVtfMJgb9qzBOtOUeRhuYojMn bdkbv7OmolI7uvYaq6ZNAenE0p4AupO9zfW42yFKTaqkWyzi9Iuny+TX2P9W/xHaTT4sgd/boTkD C6sjZRhI6QGK+evBIOTQthdtzZwKGJVNTlIbpm/l305z0kvgmFb0+KLa2MXDqIfOnLAQ6kH90AD7 4h8zoekz6jhQzYEKYzzDiYI2AdpI+of+eizffaIHU006VdA8BjXdxrSyosKOvfk7XM/02FOf7rPy ymVE2bgFHboymztrni2av8IOfnrItlw215aU5NjOjo9xwfIUQg4MVjjZCMloSt08QsUEwyWeJ5FJ ex4Xv5o2nq+utl0vv2TLv/tvln3hrJXffpX1XH+zZYPrnW14T7hYi9cE4fhg4VKLEboH1XlAlI9W WYnn4Kg6C/1J5dU/rbliFtVObaijSXKkRoNf5HFMIPYCrhUjNWQw98CVR1OoG//jmgDUj7/XML5f pVrk1s4Y6zhmvdRuDRwO111xzLe4JoC4rppif02QAXRDSscBXB9xTFr8k1AYvwWfgCeOHbXHfvJj +4tv/lf82EBotZ2eriSEoKx4tsYhdzyBqPIDQOILiOUkAssBna5RiCpHC5aITcTvmCNO3mPoPMkb qTCUq98piw2+qsVTyCnJkcumrhgpkac0M9HOyYeEiovKJ9xqQ9rkdvZalGFOlKWghOgLlNtS12KJ WBw7JoAHvYFUpI2EOUM5vmnWfPu4rBK7h17LYlFWDOGTmOx3pb5qHxw9ZSvefcdu2LKF40qOn9Eb aocZigI9Uk1juqeh93bN01HaGCABNDhbJgGLVzRzEdSycHHUip4QvLzJHONqpA0LFs6zEws/sE8+ /dRaAvh/TA9aukIJ4hw+DWIt580ZMCyp/Emq5xYo6hTAYwCcEXGAddzkJb92GjstRfL/lgKT1Ibj 8Q5iq0mjLaWv21IvVllCZ4fVUbHCOYUWgPnDAomjZkjjPBTnxQiqMHAmkTGTs2nWSC+pcFxs9KMf yrqtKrgdSgIXXeg9XrjYbudRbLgYpMEwdXLfIiMLMVyarxg946AYf2891RiX4CoGpi7cgv+97kKr zSuyYwuWWktGpjUodm1TvcTQFu7uRHcQZ/kpbHJ4uZcIHmIAwwltNNSvWKR+YG4QIw8ZW8lVjCSX IRhGGawEsL4XM6m6tjXU2Im3XrXyhB77wudusxyOSjUPxLDKWMBNEvWz0zNyneEDiMO3h2OCOlLq l9HOkcMWfPX3+KHFPc/mG+FKhrbbH3sNnKqskGoaGk1kmuEYGkGRj1A3tiMBivEepTiGHlsmpz7w AE6Wf0hEotb283bn+ln2zp6P7EePHLcbbtiKB431tnXrVvvJv+61tGfessxls23VpkW27Wcf2Ec7 dpDnBkdjtEGUWozfB6q7b9jhV0u8hvQdu5H6vfvOG/bGu6+hk49kee1MTkGQRK1b4k5SGmva7P3n dtnM4gp76AtfdnNGa6sMS8QIC4b6REm/5TxahrHefTaq0D8l2ULpuFlZZRHO/9GTezZWhpFeFUQl 4Zl/7d2Zrk/XJrVARIjGOgPg6Spc5VD0VKSXHsMdW4X8HvLHLra3Ls3FbJpIYj8QPa7R1xMpZpy8 2kWrM/pZ5LOxaPvCQ1+y73//3+23zz5td9/3EOPnDeU4xcTw2G+Avv0ujeG1iWSJILMITrxgaJfm Jb89E6ngxPIKgmsJIKeKfGNB9lvk5xHB0z3hRSchqro4AkrjeHCgxVz0y0EuRyJwCF4l/ZeHf1Nx R2R4xw3PQCFk5LoDw4O0LEVDQGrAkW+AYwIxf4LvpJLKpB9QkKzUVhYZLJbDEF4IZ28qkisC0wfQ /UtEwnJ03TV2pHK2nT17yo4884zNnTOHEFBznKRJukM69lZRU0+ud6ZezCglDNQx0meTHXt1td5V LFdF2NAxlhY36UeWlZRb0c1FllE53/bu28dRO30vJkXcOEl1EMFy8YB1Q4kB7ON4VMmvk/sWIJLG V3/CH8W2leVcFlaJehyA8QteRJLGC+dg4lLhTLMB5Yi4gOmlSDn61tF1mE2D9Kck5dPxaD+SPyNC SDIW6ZJCCkv6cEGTnpGM818Y1Z4kq+9DOgn+qDg1Ql/6VNEyyFWUiLTULsvO6LKetpA149y1BhWG V2+9xwIZudYFwyfl/gAGNOHGGkvW0a+YFwpM5nhR9e2FMfRKdIVHPmBOYHhDbKST0UlTUn/KUj0J xjAIQ12DE/UzH75uq+dV2p233WYVM2e6jpTfQzladu9EiL7Xv9499+D/g4+AGBIMivqu3QwDnGp9 SEjtxFG/Uy+pkRs+Ki7mRsyacMFrh2sZHy7HJe/FfIPXVSVksVimJ+Bgt9ju/aOH7dFH/pUNQLPd d+si2/npRdv228fs8PETtvXW2+3h8jmW+sgjeA+YZd3/+1eseHGR7dm71zZu3uyYOjBoAEdUD/G8 yYy1b3SkGot+KWbz07/6le0/vNcq1pZZ6ZwZ1hRYRISIDhzYh4g6gtN1VFdqzjXaVx/8us2bN89J PtV+2ZNrS+DrETrWjjK1iXFrb6STpLOr3/rWLBT9S2DSdrB5FRM4XdjgxmWqY6HOGi+p8xyc6ar5 KABVvBo1bT00DA5Fu6YMuz3RnxNkAAeLF9GJVxfqGCYFZXo7ddwwobLKBYvtnnsesB9//7tWPmOm XX7NZueSYLA2k7+K94mGiLLwwGc4Jl/TMd4UJgghvNk7RsYpPnJEwTWGgsZGP9Y7t+BJb2TsnMPr 5PWXO2qKPFL/6QhHREh4V33hgqWyaKbD6EnvZyBJWqO/GBLLqSO2PSzoijTiGHTBwZwvJSMV10OU n0MuFkuNoZouXAkFUyyMsCWk9ZTfuXlYZp4/hYuObGtnMe7tarYwTtMDSK507NuNMnZiQYkVlM2y kw219txvnrZv/NXfuHLF1+hIcarJ4Zeoc7wT7XV4PMERHbFaNFsbcekGyrdYCCmX/M0lEf0lEz0k SVSlm6Tk95C+9Uc1Igs6v7kRHQnBz0sWL3HDLf5awCL1d7GB9RRYAY6icYxmfbW1SAe7nd/IYAXO dxVLWAOkAnnPSYJ1zV8zx7npiHzEEPbCqIX5DmDA4tXMyyNcTUHhtJgiirsTrNrfOfO+ivGTfy1Q 0kdPSpRxEke6Vm+ngyUWzJ+FJAfFQVd39CeTOb7ieEmWwM51CFJF9UdikCNiv1D3DRuBFWgPPv0S c5BswkAqsXxbEu9f/upzFjh9zLaB71s3X49kerMVYaQjHO+BuZWTbhlP+ckbd/1WjQfv+8+n73uc suUWqqzC+r/yZ46RDWJxGjgGAzhO8vpZsxyGhrxu9fI7f5x3x3ss/ELlF/ziAsK3AL2/O+572J79 2feIpJJpG9fNtIpiQly+8Y79+NELdgfHhGXFM+3TkxhAvXGQI9WQNcLMyT9fZJgGQMLmu02S5ngn KgCdGDhlogLQg470j3/yKPrGB23tLUstvzTH6fq1t4Wtg/1BBtbvws+sggwrX1huH+3aYevWXuFa L+m3rIZ1fCy6Kpci4vxczzOh1C3eegW28Ez3ZUUt5i+FeSlmkUA8zInpxIbBwXAbsIEemL4Lv10O kmvs9JU9vCSFFE1gU+ackjIHXacOzzTst9o92AvDHg776ecTXkwljbJaUqqIL4SIrW5U+YCNBqhr vyZRuaZ0KUTkWCPlyZ9a4Mghp3fQ9WffsOWr1tn1N57gKPhHVoxvqorZC6ialo+pJJDb1T+6UVMp 79J3tUANpiE/Bm9P8cpHG8dsUlZ8oHiV9BFuaLsGGyDikAQRlB8qJdyNuQWlJyJNGMw5+pWrf2TB FG0SkfLhXkQBvg0pSGU5unvAEIoOpvHHUT7aWtHlO1fLUR8sCI5b8DWJvksEsXtwI4LLMJIWTMqL mpQqPQXJTgfHhOEQR78Q7u7uNGsgdEV3uAZJFHViu55IpAdxG9IJSeboMYTzVflem3nFRvvo+Sfs QvV5K51R7o5b1F/+fl9Q1fbxW6Gcw1I8Bx1QA8VzMdrYD6tRTD89/hdmhXGURKEfQ5FO9PIU+cCp EQl21Bj79VAf+Xjv3xsJoP/MkTIyaI+kj36YPrepkMEI3Fcf8W41Fgqr1g4nloEDcC14nWwQUtlU CD+k2yQXMMkgY5DFVYtjWPdgFgM6I4uqp6sL78v1T7vOhx0+ubsjfgz0KfULUrdQu+fTrh1YfRxd B1GJUCeprlJ/GLBfjzRQ+kxDkiaOFmi+pYrgOpgMcoKdfv6ElYOHKfjHK/3rv7WiO+9Ako00jbLC 7Ni6aMdAffSOYPDhMYFDoHz2P1QXuKS+whIHW1bSE2YYPOTh/UjnTUMrFMRATKCogk7i1112mbU2 PmhPvfCkZedk2qK5hZaTFrJXPsLH7YEGW791s82ev8qS8GZQ/sbLtgLd4oSdO6z/iiuojV9Bryz5 8dOt7Z98YG//fhuRPAqcFPxk1VG75vaVlkUonTAMWltnP/HQey2H38JPtS6Rk4h1W5fbe89ut/ff e8euufo6h8fyWyhd6iC40Y5roWacZLfhLufMmTN2FIb6sjWX2QoigEgVQBuml9EvPH3ypD308JeQ VlM+VUqEYUUQ6GG2quwn7g2fCv6j0b49fKMQn9CPlnEa7kdXdRqKu7QIOicZX7bJb79pQU4wFRLT 6Y1MBt1UWc1tEbDo97mejnaMwABCMKRnsv+w9aOUGobZGinFjxhAhJHI9M2stAAGIH0lpSzIuHRg p3v9Tbc5BP35zx5FH/Bvnd84OcycalK/TkdnjlyPSMnC8HgBoVyPSKsGcWyNm5wq34eh7+jEDlHM H4uhLzGQ+4oAK7lixA53kBv9pn/t7cw9GNqTukWaRUx3aupq7eKFc1ai3a3uaV2dQJ+q+u0c87VB FKvRrUrOwfKxod2a62EDRWMB0okPErn6SCM03HBapDokpSH1IXJFbU2GNfbmQEwhtFh/oV3lHRNL vys6UYj+CU+TcQfRwSrbAqEt1X3mdTJ9JUVyL7HYczmutV10+Vzr9QkvgsPKiPWnB0ed7tc51jfH zqc2sJ44J8wdCtVGn+modbQ0+pOR33DMoqqNcVGgpRHdPs5eoW+S8vWz+KUTPUJHrD24BkqQeIS8 wmH5eOtmEywrYeGiEuhD0piyuWGwUmVaPgIZEj51kYkYHioupuSqyHF0U1eudWeUWN7Fs1aMEVFt xTyrwxm6KyiWwqI7KHItZ9It1VV24d1X7ap5s23mnHlWcuPNFsBStg+mUj45xYR7kr+hQDxhYHSh MTVnwpm0HfI6S/BHhqd+H3g2cpYx4Xqv8Dk6iDHfH+0hexbroHJplBtko7Dhug3Eb74IE/iK/cV9 y1FxyLHbrku3vSWp9tYHZ+xETZ1dueYqq8BqN/Podgu897bZKty0oJ/pI5T20ZA6a25ptX0vvmyL MRxqIypSQ32HrV0z09ag8tJRz6kDesWnOZ1Izc7AsCeyGaCJfShB5pWkWyoukN59+z0YwGsdXov5 ayBqxR5g7/94PzGqa6yupoZyG+1c9VnLISTnypXUhfGQruHOnR/ZtldfJbpKud1y8y1OOK7DFulY ihZHI7hUuKQrq+glsadIGfRfvHgLIEToJFeqmm5MNIlou4J4cQzeI4haQujkMfqJ9aEUHsadZozd H2r3kCrpB5vhBNSd+pIwSJOH/Ejy83lzwb878e8IKQMwwF1h6LQkohCc+NiPcORYYt1/9z8sUCyL GYHkL7oN0dcThz3KGxRKPMy2+x+yIB7qExYtQV8KjQUWg3QW7fseeNj+HSfRTz72qH3lz/+SKmkH OAL1HaX0obdZFoRwk8aGoaWN9Mt128ADf9gGbkzLxQDaTBUbYqiNA8EQqV2XgmNXKUkID7u62nHK i5Utvsvk2iDEItobkOPmscdKPaQRQfPLY8oEh3sK/1Zz7pTN6Ou0zA6ObCFoPYg4dIQqqU1QO1ox haO0QfXt4VgXJzFQZ6zfoF4Kx5QJcXOOTvUeVcskZJcsdaXzd0lhKpxVPTU72bIDSP46mNjUU8RU xV6SX2X6CTztYjFPY0edl5uPXk8ifuwkQ0RiGsmjoxn910Ii6RPCMGdx58D65Yz6rQrEL0U3T3pD l479NMFWF9BHavO0J8YgSASXAHFzFRfXYNzFcQdOHLdCNpv9GeBQAb4eHXJ7s0obzz6YvDCEOIj0 zE/K0oF00PGKWm9HqjCZQC8Xk7cL2OONkCB2yyClLp1jvEX0ccBWvvl7W/jeq3Z8zdW27aH/AiA2 WEhgRPO00PaJMZW0dCwaCOAEjqEuHtxnZ99/zTavWmoVf/pljobRY0AC6nz9IS30LK79Fg5+q61K n80mA2Aj9aVXhen5HChfDRv4MS1la8/SCfODIyrnqeC22261xzix+Mmvd9mfPbQOX5QpdtXyEpuB lG7HgZP20u9P2RqOc69ZvdaSV6xgY4KBGZNL0Yu0YRZpkc5mgOgV6156CfcxFRa8e5O1wFz1sfnM TUKXM0M6ysQz7021czCe2Hs7Jl6tE/N2ePcJazzTbnd/aYPb8MhdzCuvvGTPPvusHT50yNUzBQMq OQbPysyye++5z65cd6VKcX0iPMvEHVF9U4u9s2uPbcJYJZ0NlHCbgEyO7kqSKF1dRTbpY4OrsIUh ylNMdrATfUMSeX0KLdxWEgSNgEdTpncsVP5IyW0GeaAaTAwi87mx3tGPfk5w+oi3PSIhpNCepaus 5/QZ/HxCZ6D1EwTkVY76hfBcEKg6bwkYyfWiS+5Er2oUlffrPvF2qAAvgWt4IO/mOMwRMQ05RyMK nYOjW4Ue6mQhD6J70C3nqhxN+ED9Aqb9GwA6tgiX4vKFMHDJilHpLwgQuUIiLHzhwYftB9/7N3v1 9y/YjbcRYxTiNenkU7dJFxDDi3HvtEgdaMtnBWqkVgsR9SdJQ/XBPbb7jW229UvfsOTXXwWfTlno ljstPHueG8+R3vfusSBDSOR7ypVHm+rq6vFof9rKWaBzqpAOtUPicMHSJ3cv4EQXfjUUoiudHVJQ K/IoKQwe9VG2OxYjjwhBEEYwlfr6/cY6PQpzGymUjCJ0acSuTcfVR5tEh+KG/AJGga2eCfd24au4 237y08ds9pw5dtP6q5AepVozZWjTnowBiRgOGSXo6IVLpE9DC9R81cIgojo0jVuBodmn9Euw4wMv PqVGGqt+5XTBMXhSuAO3NP27JMGgr1PYVPRH+t/vHjFlSSyq3XDjwhf91juKpSrn0EkwhZ5vRP+N wW+hRSZ5i2GYT6thXI+VtCb2dHIk11dkXcmEZgtjFIJUUlGXupEAhKHHvTiHTk1XWC9gY8hRcvK4 NeUX8IeenwAOS06qgKj8zNsvW8fJI/bQzTfY+vXr0V3Ng4FgI0QbJK2R5C9OQzqsRuP9vLQN473x h/RctVdfSpoqx/Y5uFO5F/31xx/rtF88t88evncNxk0hm1OBj72cNDuDle6Lz1VZeME6u239tVhz 6yzBG4og3JFQU2UmE2ZsLgY76R+HLeW+TZZVhJNuhToUTjk8DtjsxLCVsi0+1oVLKnBOTGTzhVbb v+2wPXD3F+3ydZeDQ72EWf2ZPfnkL3BQXWA33LjVuagpKiomgko+x9XZzv+fvkWDlCQdvvaaa+zN Dz4gLvBS9K89wyOBlhpEExE19iFJrEffeRmW6rNQ3QrMm2+Jt9xuAYQ5skJ3G2rya/4oqU26cnGJ dYNfaLpOHAUpxPWB3qXQEaaACp960gYOXdykp35mCW9uszBW3V1f+wsnobukcOZb96xZ1rV8FUZb TW69iKVl6u8+MdD0l/gwiUGkxxviiL4fRrIfpcu+PiSK5FP/KXm96V1P5jPU2NBg3/n2t1lsIoug JClIWzIRJ/cQ/aD9ke+iGI9rgpZmFON7PIV5etmTnE0GZAzvqHUaSTeyflMjgwvhnb94md1+5732 zK+ftJn4XVqyfDWEbHJcoJNsTrUXx2wS9deKEWepiUB42B/HxrjZpbY4YCO22u2uQND03GJLr1yM n7MG63/uN2aHPrVQxRzrmzMf5B39fYYXqQrSOelVAUHxgKs4kijISbQc9O+shc0K9Qhw7Aat5Bqp Do6de8TY8UIPC7WUn1VFV91ILYVF2k1joOl2nZHbZNKDqInE7+j3BvJFXUiRPpTUaIVJ5y3cWWad SGHGY70VnzaVeJyVW++2AyjfH/zJo3YdftdamFNPF8zgSDrDSmbMtJUL5tlirPWKCgudxZ7cS6iK 6gslMX6iy+pDMYLQCvTQeODGxGWJ24eId5/6PI7Jm480yG/wdMLS2LLo9eKzUbpwdK3brDThuLYn 3G4z8jKc5DUapOoDTXa6Tr78T+MhqZn0XJ2eom6MkHQ7xBlZPrh5Fn96/Vz7C+Cl2TWuqLocOW9l qCQcKQlZF3Ng56KldpqTj7rSmRgbnQDvWQjAgn4kLPO2v2Vrtj1ntTMq7dUvfh1jFEkaIpXhS5E9 5Dbmk98+ZWUEV/7C/Xfb2svWOYmP5qni+3ajm+u/cmmdht+J07hEgRnsn1E6NSrvpC4pVqjlaFC8 QFCu4lX3wQylgmclCC3ueeBBe+Tb/2wvvHnC7rh+PnXADySeBnJzUq39hrn221cPWNmRoxzrrsbY o4UxwX+hxlOJAUpavcY6ieSxr2a/bcL4LQgREPPlJ63HSeiaSiI3A3p4XhCQEu7Ytpewfmts48bN +AFMtxdffNE+IM5z5fIy67jI8SJE8fiJY/jeLLBVq1byGwaDsqR+oW+n58r3wkUL7e++9S38Gs7y ZEUAlkpEa3u7fe9737ETbEQyK+cSZ3enlezbaelXrDe7dpMFi1Clwb+gIjxJjcLNb9ckNh1MrDB1 DQmWaHMCsW2do+7xB0Y5mFZuDg8QC9ZY7Zep7ohJtwfwa7DrRsx7yU3K1mlTAi5+Ei6ct36+3Rpz SUZuCJD4KbmlSsThegxJ9dJYnK86Z7V1NQNtSOAULZF+08YvTB+r/zpxcJ+WjrBAYxVD2WNlwUdm ul1+5dUUPJSyh7bcyA4RDhQgSkKGlOQk/BzmeoRKN72ZpKtpTepYl0YYSR8pr7rmOlxrnHaWwX// v/0PFPnLHOc8sYr4gPzvib0dS+6hTZjqcI0M0TFdesSMcEgZHzAOuMpXbw1tl3vk7rEuUoc+yymt sCu2FFmyuBWON/qzwRuJsIWyTKYxMVcTOyKKa25pYRfUZQUcm4pIWGWR967M0CjalQMXlJ4a4h12 kRzzduGbTYQscZg0UK/rZPcS06EY+0tHIX4KJISxxqt2zFhNN8QUeCLqoyYeBVm8c8pxCfPB6xY6 eth6D+1GazzDUu7+mnXMmmvHsRI++NI2y/ntM3bLAw/btWtWIt1mY+N3NvBDonokSTO1ExRLIQal D6mCrBDHqMGoVYvlgV+ug+7/iOXFP6g89I8WVRzdaoGTJNBJ0qBpVXVVlit9PvBKNMZPChnYxf0k NhUugQI6EhZaJ9Hno0n/hCnChw6482qu+1gExzoElpuYUFO3LXz+FcusarCMGx+yHRtut06MiM7O mI0bGSyAMXrrId5xN3Fk+3ANk4HEJf/scXz8qR5UaLDaTorew0Jx5sN3bGlBpt175wM2a/Ycx1RI wiDHvjLMohvGTX53+Iv3uC9MMoMHx+u5SRYxwddiaPwESxzITmPa0TeVYCUBJkfude578Mv25M++ a1npx23TlXMYL8aM/5ctKrJ2HNg/8/MfWlXVVjt95GMrKpttd9yFGyANquY6tDPzW39nO3AvU//G Ubv7piVOP1UbQPWbj7MirQ28JUJ35tNz1nS6y/7yv99lqagNNBGS8lWOfudfXm4z5xfZhVN1VnOo 1j7dewQfhDc7mumkUGJ0HHMJWxKheXJ0fxlGIdJp0ymF4OlP9FRuiRoQFjVU1+C7crVlNzRZI/qE VyC9KoBedXPEferMSTt29AjGJqhasGvKyc22ypnlVlE5y532iF4rnrLcGgm0yJzDzVGGSNUSxY1U z9VT/SCWSIIAp3440rs885nAkR4PjN/wC7UXNYpuQr0lEKUsrEgi0IExkwDoD5jjJZ16zSyvdNbW fp+7d9BTDmDvFL32ZGaGrQCLfY2JTgUm1I5hFQmlsStYL59Kw5Pfs+rVSNIgqYM78S01pJJ+hkl/ I3UUx8wOWOGSBtPIPeeIN1LJW+/4vFWdOW0//fEP7Rvf+nt0DmS5F/3+YEmjXql9MQ7SqGWM+YA2 RGD4XTpm9sk8jIBwcOLZGNcAH5jGZhA3XLW55RyYwgBK/yMrUQ5lWWju+6L1tKDICpPuXFcMe214 k1WyN2k8twOBhESrrmmxGYWZzj2HP1zyxdYr3SxgSddFKREqEub4RYSslbiy4gFluamYsnpvHNCu jNE+CiGUuYdP28W1i6xx7kzmQK9lptVZS2eRYwBHe2/wPrt2CFwJ0QACmXl2kOgL8hfYdtlVON9F H6us0rohkE2nDnNk9FNL7fq8nTh1Crcj9B24nQahrSBySQGSwkIIQF5BniXg1Fj+wbLwbi+CqT+E oG4nPAh3eq4ggYzfVHpw/Hq4hUwg4ghGrFgfSvNi4hJgzDKggZk4Xj5zvtbmcTSnnbg2Er2SJoM7 SeBXIr7P/NWml12O7rtFcoR6Cn91YHwyTAiucNAtyB52jtZ+dv/UJWn/KSs8dtZS5AWhjegmEHhn eIKSqBZ2rJNYLJGaEO+1D13BA0jTu+/4I2tGst7rpEVeZeTgONzbbYd+90tbmp9pX8Fys5gjPtVf jn21SdMxZRRpH61iw+7rJW65CTrs0TT9FI4NAtH1NCfq7pXKp9oRBxCuxpSt4zxtHkKc5UpPeNny pdZ03U32yu+etPKSTFsyv9jpHyv6xjXr51KV4/bcr39uh06eJw5vqa27/EorL0fXTAwg9Ctr7hy7 BSbyV08/bjVP7LQNa2dYeWmu5aYlItX1Do47wNtacLqro992bztkt9z0OZs1e5Yr42L1Ratpu2Br Fi6w9OxUm1eEZPnMPps/d4GtWrHc63mQAmhusyL87uGEQpIm0VeFzZTj6VOnTqI/nUq89hIX/eT+ +++3yoUL7Ymf/NgOlM+zhD/7b3bonZds949+bDMqZlrVufN2gahLckaenkwEJdb5ML60ZPGfjyRr VmW5rcb4ZcmyZcwzGGY6UJslbWhB1dHxVONHUqSS1tZWF8ZO6jnSn9Z5psNxnkeyRYY7MuD68h+o kPES+SWACC9cZOE5c7X748YEeY1RYXiVyUYn2dXOfYyamTz9loVAReteL8KRCbVjWLG4ApKzW1kd xZBgrfs4Bx8AOE5Fxy+RXS9IJYOBwwf2WSE6f4UgvgjseKmPc/Zsjm7ue+hh+/b/84/28ovPETv4 bl7TqMZaMT+fvieCDePVbvD5UKYvTjCi6j5xoj5Y11iunPI5GdWukWCJP0Adz/mukomYm4S5+BfL AW0nMjTAUPmZBHLPxZS+ntiohcRxlb6exrcLQqeVTIxmQFxeZCi1u1OWBM4qWQddz0ji0Y/lnH4J tdyxHb9iTZLOJLZ1WcUrH1juroP4d8IKb14FfSCxPcd2AI8Jg5QJAlWwAokoSsK7ISCqbztHfNpJ y7FtWmGqJaFwffjsKXv0lTedZaqYPzT9sYRptvcPHbGkzjctjVjIG9ADurr+gqWUVFjo/gecXztJ DKGzzlu/umi60hDMneA4Tlcdpq8cD1m0sGrB0EJXhs7x6VPddhKnubPLORJmYyFdLcfk0V4XNkrS QKzInfoBDKCPc5fWq98uwPw1EgKu3SH9pTmi7/RRVsbZi7b4yZcs/QLHf0RAacYXpZP+KGMEt3Wp jUwQxjAIM9gI/u0hSkqYTYX0xbQRED2Xe6xPn3/K5qUn2h89+KCV4klBlua9MCPSKRV1HWnuqvyR kua6ki9l8n7xSd+5pPpNw2Low/EK/Sw+44fIvpRJFtVyDyN9QEkDr9y8xRphqn7062ftc5s7be2y Mpgo4WCSbVg/x84T7/pcYxcuz7a4I1v1gsZKG2cxkUthkpJSvmp7du+w13Yd5bj4U8uxFhi6NMsg gkvBvJlWTwzgHb/da5UF8+yGm25w7wuPW7WRZAORiipNJ74smy+24Dy6yA6cOg0UagwgDaVOX0Tb ujnCfuqXT2EH0GWKcKIj3F/84uf21ptv4Iom0x7+0h/jW3CdzcD5dRd62R2EUmxjLd9z9JDlr91o jcSWrmlqtcTcEkuaW2pJuMOS8Rvq046P6OZ4s5mj1O2Hj9on+/ZaSVkZNklF7qTRzTvq5HZp+qJe bu+pCkZSBC0dXtYgcWxsbCSk3kzHUyivQtv52bXZc9d8+HcnPPp6lzHA7xMXriC/KtPwDdPtL0x+ w0YpVaEdXbxr1yCNXKRto+Qf67YMNEGuSElj5eSZLHV8xBYxGKeeY5Ymz/+97FL37frQXt/2kp05 fdrKQICv/Pl/QRG10A3WAAEcqSSqLEXJ8so56Fd80R770fetFCK+9qprHPEe6ZUR74nqTKUhIxYa fZOKRmAIZ+KSIiA8NIhjY1wD1F+CMXpjhE7sSzypBdduwo39ykC3KJtjhvQ+cHQEXI+7gqwsohmw IMtJbVjSGeqSgrTPeccftsgKR91i6MoAOkSnFYInIiLdLzd5uY456aiMnWlbSQEMWr61F+e5MkQw eUS8UdU61sQijfWxEnJ0PplH6krXnR5pCuJsddaGm5zYPwRTqOMBZdA87ZXIn5BhDRDlC1iHdrz5 vLUjGTxK/eZtvdWKC9BxY0dMJDVLgPuWT7fpSupXdww/XQWOUI7G3HXLRLp0hHLGvyVJh8cMwS+7 Y6gZ5RV2BuO3U+carBTpiCTHqoxoXS9Hr6ETF/HPh97UbHwHIsmIDBrfg0nV7gApsM00ggfyyw3s YIYRrjT+CTBnKc2tFkLC0g7968ifx/5phMEjr1PXYXwTOR4OYzgUZiHtxdI0hIqBwuF9+tKzhHUL I/n7ipVzzCZ1AbnkEPOnuTl+jUaopG75Y6Nr+iRxzy4LnjxuPVdcZeGSGdwbob7KO4E0OOyTruXY 0NR/5HCrV5xAuAqobEcnwTGuu9EBTWBDnIjK1UaOWxMJSv7urjdt9/4qu2LFDFu+uJSoV+l204Y5 9vGRFrvssiswyshzY6fynKsoxlGncAvnL7AZpTPsIhaidXUXrAXL1IYmmK2GZnv3xcPEy263wtAM fPZ9kZMBNggOjzyff0E2MCJXe9/51A6/e9yWb1xijS21tn//x7buiistAHOqsVX/uFMVjDBbG886 Qw7tLNsVShG97BYYvvPEwVYzNT9mchpRxGakGF3aFMw5Tn7wmqWWlFkS7ouy2YCEsvOdMYmYFz8l Q7fDeBrJTkyzGQ29dhGfiIfrjloqTtXzOCLOQcol62RJ9BJAXF8iqPejSa6ESJJGnuK0RCcmc2fP cc/d9tofYyaZ3vH5F4cEfkUm8u01eCJvxJzXo/7jZ3dNok/UBtce3RBSTyJJnBJzEkyX/G8B9a8j j8b8YmchcXcvugEf7/7I3n7zNauuOmvziXm5DiLy+9+9Yo8/+qh9/S+/6ZBPStFjJdVHJGcNk+XE mdP2+M8fI2Zric0iJmsPC+X4iQaoEDEQk+zA8WAM9JnLOJHOGq/kweeDiKOdm9ekwafTe+WvAUPb NQIMdWv07SE/oh9ceg2doR0KVN6N5K/KstL6rSArmSgbPRAzTWSiLCD1k/RmvCQL4QBER1lVpnxW dWkVnECC/UMXNsFObb3aqq9cbu1FHBM6oiqJOK4PJoo8EfCjbnB4npqHVedAZ0cqy9hKVt9PKDM5 2G5lEM7gw64VUecLB45Y6OA/2cbrNtl1113npA1oV7vVp0sr0ETrOKx/vCr7zKr3a1iW/2Q/vQmv 9Qh9e9c7cnA7kzBdZ04dRxG71QryMt1GIwmcCSP9C9USVg2Our+IUxAFMB5GnlSicAEzJRwCe2XG 0lNi9DqLcu3gH91s4R1nra3iKquevSSCYxQ0LDn3L4y51GSl95qABLmvl00FzGPNjjetMtBtX/3y w+hXVTj6KOZPqhkTRPsBqP5cH1g8mUwJ4F3oiR9a8NP91t/eamHCddL46Une0ExPWWOWEsvojFnA qA89FiqCY4Dp4TKBcUBJCR3ANLt24022GAOfQ/t32euf7rX39u4gWkgGGxHoHKdsKaglJLARDON9 I8A6KGZM5MCtV3xnEmEkIzPdKioqYO57rYd8XfwdOnSQUIL1tmz+apzlw/xHmHKtk0VI527bd8jK fpFmp4822/XX3mzHzxy1ZE4TdKTrq+fIwj1RDBOM1dbNG9n8dFpamow5Anb35++xLVtuAvXxyAHz JqTqI+/qlSvsvyMJVFQlGXx8evBTO3L8hB07vMuO7SZMYeksK1uy3NLxhdrPBlUnScJfuUhJSc2y MuSYeWmldq71CJtbXH5V1VttbT2MYI7ls6lNpl+cBNrRXY+Wi/7rnv5EKyWp9KL8DPa+6uwSmzKt AWIifTyO3+h7ID+rz6m0Y0IMoEiaD8wtTjG3kIUXCYX0UvYj6n3r9W1Wdb4K6V253fH5B2w2sR0z WdQys4vssR9/x37zwvN2+023eAM+DgwNvvwXbb35c3YRM/nHH/2B/dW3/htOorOc3sM4r7vHalME TWLJPsE86jMfSSf4aqzZqTzdQNJHHFvDJHMTbgCGAxprLWPOJ/0PjYdzEYCeXFF+CnEtsWiUPo1j /PR89BEToVR4sW7pr0CM5IIgGWImP4Fswp2FXsyVUcZIl3YSa7iTuK9OZKcOh5i0tecj7dE0mv6+ UF8PKXYABGobELPG2Qvtg3u/aj3gv5iUhmOf2pO/e9mqzp62u+99AMVvT9Ioplke+0fvsdh7Q7js lTRQmdhfjiWn3+Y4FT+0Cm5mcmTKOgSOqL9lXVeGMvZZHLnKhbOsNOVaKMQRXaCUsUcSSEiHyHwb XhqSbxYaqWV70YmHPh/1F3DDSKbrrlhiVTmzrTV7g3WmIfmNLHbR76lbEmH0SnDpIhcxFypms/gh 3cHdRg/5qw59Yt/88pds3oKFjv5JT1YbgOiwbtHlxXoNqpP4cN9gkoxiMjGm4TgaToRnwi73UBkn nQZLGK08H4sHc04IGK+7N4Vno4GYUIGjZPar6T8GHHtRl8QEyviycs4CK0JyOnfFGjuGakc9jOAZ xuuaLXdaHpK2nld+bwmMYyL46FnlyviIDYibI177Q1jN6h+T3ZUt4wrpwacwLsJuxXT2q5JFBKL1 HJXWPIZvyc2fs1vvuhMn+LXWgR7x7NmzB9ZL6RDLkE+bi0L5ypRLGIEDriyaS3Bs7JLw1tVH2icZ Nn9eputbrXgFRQW2BovmixcuOsnc9r377PBLv7HM+cutcg0h6cBZ1w7V0o0Fm3pcHaUlZ+Evtos5 mY4qET4xaxpwWN2I0UOB+/OZPo1iAx5M2nCR0sIpUWtrCxL7RFzazHDMoFdBPIZhpSwJojZ3Wldk zNXdA/FUe/yO8TP/p/qm8rTB0eMJtGP4ujkhBlALq4d2kZ4a8uPS3tMgS0erp6fT9u3ebe+88bpd wJ/R7DlzYfzutgosH7NxphiEOVRasnSR3XPfg/bEE4+ZnB1s4UgrllmqySEl+Pvuf9D+6R/+T/sl 7z/81T8DEaQKGpl1DsLwD9d93IwfNqjPBtOQH4O3p3ilQVXJbjjGGZMpghp43eFCnGCJ2KjoEHgR TMlEl6QZPGECR7B1OBIPVCpyIeavk/MuHRl7cS6FRV7fp6Btn4jUbsLJb6tWwsh1HxaeTUZcTjGZ Y+DZwNhMGOgYL1CHMHOrXrtwACTzUbg809pLy23b679lV51hd91zt2u/QvOpT6ZC8bzeowg1Py4N 8trqda33OUbrp+FRpCG0RdCkG0p3upSBM9wc/OqdO3fabVxD0DEZdSSVZDvjkCCqB0luRRxWDcrq RO9oDFQY9sLgT1EixRNOLgtYPdEYEoj3Kj3ngX6PZJUxQPmBvbb+6R9aNzpVv//a31qTpMU8DyIB WXfyoC2ur8FnmWoM0+GMyIeXMgg3liuf7muddol69cNwdj30ZQtCo8MYEcAJxFLUuHlcTR0cH1jU K4wD4iPvhrseIU9U9vEvBW2qZYwMRfTGX13c4ABG/dcD3mgqJooOAT41LdPmVC6w0oJy61y+xprR L971/ntW/T//D0vleP0susK7cKmSmZ1lRaie5BdVWi7Ou+VeRtJC5wqEMsVEhZEUyn+qksdceTBd n8KoJcyea7m33oXrlaDdce+DVoKrqeL8PJfXZ6x6ySesIyImVvL8UU+tr50YHSk+t3y86ijb9RuE gD25S8rn6bJ4tFYSuxQ27jk4G6+cNctW4OR6/6HD9sLrb9jRN+pt7qatZI9MOK8IV6Q+RE2DMHPS mewl5Kb8FJ+vqiaCUotVErtbR76yE6jFP2wLRnPSF8wGTnFRoWVw5O0nqc7IsXr1eYxqUIWQPrkY wETel6GLoPtY6/rIf/E/2bfqPh4WJ4gXg3bIr3MYwzQJzZQmxAAKjN9RQjD/2pU05AOJnxukLjvw ySf25qsv4cutCnH1LLsd0/ZKENExfuRROUIwJVVy1WWXc+x30Z575lfOx99KAlh3xaDIpJ1RMTqE D37xj+0Hj/y7zUKqeD26Ft1u4Ruje2jE6O0Y0qhJ/vD6yUlMx6jGJAv3XlO5kUY4D+vxapAomAMk APFpjEqVJEO7WOFDMYZBJ0+0EgauHWKF8+cIrpBtxKQqdrLqJePOw0n8/I6J5Bbap4mATbb6kfe0 Q+5pz8YJNbtenAt6EpKhVVJW+R1Moj0d6JONlGfoG7H9EgPmyvLb4L4haOz6s8vnopO12V567Q38 Y660JYsXOAIZgjHxiXVsUEbJxRoctbSNkmnyt908iRf+Dq/WkN2Z1z9YxbFxVICMfKuFZinCjNt4 0OkBFqWgHK1pPHE1JDcweu5XtxsmqJtNgaRtE25HZCwzs4kYU3vemtoLYfCQ7Lg5F11xdLOAn4rk w625AFeMYrnWmIP+4upjBy3tZz+2vmUrjPNsTmUH2JDoQiZ+7TdSb1JXOVM3WR+Xz4JwRyQqEy91 hDcEKBpYJAswgs2NFnzhGQug8xjG4K+3AMvmSSSV7txq+PNnEmWM98rAsA1risiX5m43f71cJGKN LqMLSZ4zOdLdve1le+Lxx+zLtUcsq7bW2nPZWtamWXNNkl08FTKiBLKA4xOVDV5W+QKbO38OjGGu 7d97wAoLC2C0VnmkLbJDd/hMZV2bK2dZwjf/q+WDx/myCien8FTMn5LWYh01J4JfYp4cblNh+fHT ea1wG7mdyyus15X3y9tA+eMmWEHmQpD2yW2VXNDor7CoCIORIvv2I/9hFz/ebaWriHsc4eddoZEP jY1cNCUgwAmC14pnnNibbE3oOp4PnbcKdHVlEFNMeXl5RJqCsRFz6jO/flk60s5gI5UV5dRa6kN6 V+MgOqr1QPWVjqVWal1/5skH6ndmTBUgM++5Gus9v4xL3pXUE/31rk7b9dEHtnP7u/YFDHpmYCwj 6+kJMYAeUguagAORjnQarhE0UGV01NtLxINPP/mY2INv2tkzZ6wcPYX/l733jJIrO/I7oyqrsry3 QMF7NID2aLZFO7Yj2eTQe4kjiTM62pE7Gml3z9kv+20/7Tk6K+msZobUkDOj4cxQ5PSQapoetiPb sQ3aotHoBtCwZVDeV2VW1f7+8fKlqcqsyqzKhEidvUBlvnzvvoh748a9N27cuBGflOCHxq+RE47S 7AjK8sncj2/DnHfd/4BdZvD9Ltu5/4ZTwZ2bt7H9t7pNn8q2gLr7MD7nPoF7mB899n0OlfTYgUPX Yg+YyzglbPCc1FtBzkJvBDQLSJbqLoVCWT1/OMSXrhYhfujlSMCoBixBEng/rYg9i1Boq6SLbZKB vgt08DJr4XSk+CRXkm2JBh51cg20y5Nu1YAkOPeeJcPyF3L81spxiRm4ailG5Aag4YR1eVJdNDnP S6hYP6oMsBq0apDk5hlY2W3MTNBFC6H2PYdtAFOLMx+cssPX7GcglcYhtVrPfCm/X6niM/CnfuT3 csG5llesYAB5vBBMYCEmVSlsIx3uqWRCiVTXBsIzWgPXqJAJkQy+xP6OhaVcqsjuTaetNXnIpUw1 eTiEy+lMtorXWKwsL6TKoMgi1U1jCOtXMKXfBv9w6lgPEqkMh+KXdu61X33ud22OLf7JBuJQg4cA AbZIVJlqNHPxyRnGZg3tsnlF2FjJmiG4vL7D9nahNpxpKFNwIKiYwl/u4izRBuVn3rfKv/uBEYjb Fq5BwO3czAtpxMn9euYTGj2g6TrezYS0yi8JV4nHy9Dop2gqnpGZu7RnVfRn2fp14ebpro8+iB+9 I/bixfN2hVO7Ix/2Yw9IpJrGeuvANEAeDeqWcD91qdd++d4L1ouBZ9+5Afsn39SuF/aqU5O+GCxH GyhXNLon9y1RHajYvtOFnkAQwl0QzxXlS/yteVn3pSUrk3sRfPtFGjGlQlNXj3ZaW8PhNvbyiqdX UdXW+KjQgjHgastbgmAF5VnAbKHv4gWrLq+2TrSb0igGdnpAALfKOjc/YyOzcqBcziGQKquNNmDz TdQn/l+50o/WlHc7utD24fpKwmriPZVJ5aBKwNXb6gZR9yySesbCnfGznAU5h68RHgOcmnOknUWE IIUNp+sSJ6FCWHaNvbtyyhdfqoy+mIG+wXgTtIR2XxUQYZbF0iuvvmR//8tnbYLt/iMHr8E8rj4Y z0BVkAAowgT0CYhWhp2CO1aN4MGbCVdG+ydPvGO/evZpnDRf4FRujz388UdtF6eWWlownGcpLWFl tQnc9+trG+2Rj2PT13fJ/vhbf2z/6t/8rzj65bSbWnaVJCaWOvjYfQ84/j9HgPyXf/i/Y4+Aa5lc kUKokOqUIucqCNb5SJ3dsZQKieA6jgSeUtXGy58gmONIIhXi4iQ6s0IPTeNLRoOItiGkjZFh9CU8 sFehuq7BE36uk+saTOhPAQUy6JIqnnhwO+5bLpNXnd6rlXqc11UZs1+0espaFy+wPULYnwUGZvni oLHT4emXhLZiJU1ccWgUzGBZAKsPsP0SZwCcwThfg6qnYjSVw9CHYBYDYFC09M9Q0Eq/V7rrsC4B Bv0S72hdq4mpGcP3CHZTZeWc+m4IbKyUU7XXKeuIwqLAP8ovXtUBNw2o1fyei8VtamKGwVb2gvnR ilGVt+EYJv34AKch4xxCYSyMwac6yKSk9p/hgMAptCdySbGomU73ER6uYFP2+Me/bFEciv8ujtO1 ENI2Y7CUEuwNJK+CPvSXgOX3NgAz66shjsyHZUzQi5g7LOKHzZhXUCeRQVQvvF5BsaGzXi1JHRLF UruvAj98HGclV0VVFmnnvfuPsPO1j747bdNsb05PTWBnPGVXRrGFGx622YkhvnttengaARwBbWaW U7qjdv7ipP23xx5zB/Pbf/WkNd9+j5267nrbzYR//NVX7Ne/ftGOEt9XYQAlMMk27uTJk3b27Bnr Iz72zt077aN3P2CVCFwVmBIsfO+/2iJauqlPfc6it93Bglp8hvcFlZMrJVUtG/W9yomqq45aqMoO exJbvcf+9vto8sY4wT5gp/7uL60CTeSBtp0InbXY8g3ZpcEzuM2ZcK2dgE8jzE5OjyOANiMI1hGD uAmlEpE4gNvR3uHlCvuXhDfNC3y5YE0HcCFQW8ZBHg5DMbfoEGo9tpNROofsApe4Jy2ZXKJIONSB qauWGHAi589bGe28iMZ+UfG5Vbl8kuqbaACXxdzmW1vc2DkSOeTV195ACfcU66UB2nevPXTvfb77 WofXCAnOSgUJgOowPr3BDJHTH1j0cdTxW3bY/KOftLdPv2/PP/usXbp43j1aP/jQJ2z3nr3szbey siB2IMhWE/y8NIkP2b60NLfZ57/4NfuzP/tT+4tv/b/2zX/6z2FcCZAh+6W/kbqWVrGKlc7vEND6 P/6n/8f+/Dvfsn/6B/+albU0R8vfDQmt7wQlU6CKcwXYFOTUVXGAB1CCiSMBsTQoksUNedN5ISRf 8unGL1R8tZJ4wDXETKYasOT5fBYD/HMXcda7q81XlGHHX461ihMSM7g70BadVrQqa3pSp2mLz9ri 1KJdYCvFH1OXXPDS3824Zkysqx21nshZG5tpp3zYiKnzJRB6lAgm4bCT6l1N4BvlNtkwZ7R5WqHk aHpqsA9HwsO2fft2r5PaLNfKPe3VVS+dRvoAlqoX8sGqL637oShU6pS9FQIeCBa6bTJDwC+ftr/K iDMtLZQ3HkUT/bntW6HhIBq2SRn7/k1sFc+zSNA4u5z/stVMpJ2ZxJfaxByLWDTf9bMMzu/i20yq YoTcAABAAElEQVSuXVjAVrWAyxsepEzEHjIL2AlSSWs5i/Zv8u6H7dRff9vuu3zR9uze7ROvDoNr 4s43hW0bljv8Du/nC6eo+RBwFzu6be4f/4ELw3Iq76oe13QWiClZkQRDF/h6ftnFQ4JPWgONmnBW 8xbfVWidq7DtbCI6zSKHLRQcQQct5vGAIDu8ebby5nDDMoowNYpQODPcb4PDQ1Z3HpcwCIKn/uq/ 2r5337IZnD734SuypWeL/el/+Tanck/adHyKeMBH3ZZOh0NexS5f4c1a21rcBZu2Ugfxy/fBiy9Y 95//qTV+cNJewx51Lzt327ducV6Xbz0dztOiR3wh/nbWCge5RJWdLRNdTF/6kw/AW6+/0W697gb3 IziK65pnX3jJ3jt1ihCNB3HEjl/DyKjdTBllr6c0h+ZybAzn+AOD1jw2ZN3UaYSDIr2X+9gVRGPK yWPND44jIfzpPf2GdIHw6eVEu8cWtpuE8bDSTTdQNrz9pi0+9fdWfpgoJ8fuce0njJUQAhOVEcBS JIFHMVWGv8TysXFbQklGiJT8MakB+Iu+9LxFnn8adyi32tTtd6LxO27Po/EbGRmyXQh+d95zv5vf NbD7KufRrDOSKRy7kjdWv0iwNCNf5J03rOrHf2sT2B38zbnT9jZSfReG0w898gnbxcmlZgl+qF8l sGlQVYPkm7x/MrJt2bbDvvSVr9sf/6d/bz/C0fMnP/153DEI0urQhE8OJb/4pa/ZH/+H/9t+8t// zn6H4+uBUnjZuxBQDFTSJPDCsQx10XAKrtfBERUN7EpAjiiBq4SVEakYUDSwyCWB7FhkECyHtqdn Jj0qyNbuZuer5WXUJCwmlwCpKCHiJflz8xBGiflbecr/+/O2m4439Mi9NrylC1s9wn0xyReUgI2J itVVjxEtYsbi1UNoW9AqxtnWANBCvMbmpjpskoFPjb9APRZpp4iEWwbQ9aZQ0Fj+vtw2zGEn9d7P fmC37dtnB645lKRRAfP/crDJ3+oniaE2ea/YF94XRbyrkHLRMURdiQZwVlsp8E/GqBlmgBrZiipa dxKacHoRtyxzFWisQw1E8sWMC0HRNtz0RAz3HxwEwfavDsYtZwarmsbQfWwUu+hq7mPTV41GkMWs h37LgKI+w1Zb+yaLYDbz8yeesD3svMhdURV8p34Et/KXu9+GOaR1V8pQhPj4ws1sFfbcxfoQgixI VDj69RJakqAGfAYXBSN2HtPAsM7380IIbK9Flqosf19Fcc0a3xW+fUHb8547ZCYKUiVCV5TYzw1s AYdllsN3RemQX1CFK5SWcAyhsO7k21aLX93FfdfY9ceOWQ3a4i996Svuv2/3gV32s5//nEgif2PH 7j5m9919rzuP1kJZcYKHOFUrpcmJ19+wB+bidvt1R60Tc6xmwpE5qSiolDgK2aatUy2uXanDWO3P vWKypSWfOgHPxUMuJGocR8t2++23o7ULFuY6tLKTRerf//2TnOYdtwObdvLOkoebdR+EvKvYwDX0 wwZ2/6o5RLLIoirC9m8kUmUXLpwnx5L7/9Wc7wuytIFOUocWSGJ90Tgsq5yp+x8C5OJTT9o0ZwaW cGhdd+NNFuFQasjqAC9tgm5lUo5RnyVCOy7qxHUhSbxF5SK/esqiP3nMLiOT/cWbr+JPcdB27dpl d919n+1AeK/nAJH8R7ocRn5JcSFbFiQAiojOgQw0ZXsP2PvsJb/ee9nmEPQ+/onfoTF3ELUB7QzM qqyB8Kd3Ck8BqiVU4tdwmvHL9l+//9do/bvwln6MVcEa9oAwgdTOhw4etIc/9nH77re+ZTt37iEk 7VEm53R7wAQZhCykSOFFXf0NrwhZggqtnnedT128DvGsE0Z+r0Ek/QdXwAv5vbWeXOqEwiO6qU9L XpKh7+bNW9xZb33dDMHUdSiEIWZZ3dWUsn8INc7aFojBM+UMdAsMXAoVF3/znNWePWtVe/dbrIst Zq2wifbR2K5BVhDyTMJN4Sor5xEUYvh/0yCp0tIqSHlzkVlrXJRgSRnQ4Eh7F5utIzxYM6+ljVZ5 osuVTcLfLA6zT/38h3bjlk77PCeAtYqWql9uYDaa0iGUuu1L1xnTqaA2Vq1WtrXzG3QrYyzrxw/Z 5jbiNcM3edcbsFEm7WYmvIs4IK/AdlVY3F2LZvZE8taH0cWn02j/qoncUdtQTb6A2vqsZ4KoqoF3 rwzDt5O2ONNgk9FDLDQQAhOgxG1a8CygTahibN66/wZ78eUn7TN4XOhiq1Tbx7KJDQQ6XnJDpwBH WBaRQgpOTe7hglh8M0tf8YNlyhgiTL5UgotE3bNBdvqHz5cVP1v+te8VBUgONMAOmzoPNKqb+AHL UdoreDHgg0DpQrM4X+iJj41s/Vd7+LfA1VMLhyG2AGRpx3Yrv/Eo0WTq8Z+ngApLdsdddzqrRxk/ pzlFsp9tdO2Ibd68KfD/x3sRxo/JSQ4fEcf30A032JFbiPCxfYdVEVyhkgMqsiWUratMrORVwAVU 7QRSjtDnbigQRhLjjaqtsZeepCvnK/kbFK8pVbCjt4/xt5V+Jh9+9dh7v8Wh0YH+Pn8uMIIpBUAT bmAMjafs/MtYJOl4eyWumaSNdOHP31j5kUDlKP2aokir6lIpfaKcRVLVTTfb/LXXYbsBLcHnNAZU +O5KqMW6o9ZhFuAwi6JVMYkUhlQCJHWYxx72vZ//2N5hodiI6cdtx+5l92eXn7fQaV/RJzxvobql p4IEQL0ooixR2PIDB+yn+9EwYJv3qa98HZV1qxtceqgwMWI6loKvg2IKRhkqlqO33WW9MMVffefb tpmj6zt3H8QgNZcQGBg/xjg6/hp74K+88CLG3DWolhkmw8EjLI8XUgwUdKrwdrG/N0aLPErj5BIW /kpeGa32hEtIS1Ez4DrYALY+xbyy7RPGZnyPjRFarg8v+A1YuJer0wTyFk/DFOSVHytPjJ4K3K2F wzQrg1k6zuUDuwmwTsiv/VusjtBIGBfaJHY1U8Mxq29lAVNI1cK8TPoqe+AmAcxEY6htGARWUB4t SgT3Shzj/vR1SFjsdX5r23cWbebJn//Abuhuta8SFk6hzSRYaDUeRoBIUGOdWFR29RVVVpD0Xfwk 8I6iRPBTJQ7rkbqjK6+VCqCJgAlzhglrDsG9WrzkDzPz5/xFm29prLAzE5M2PsjkyexZxvZVdVOl T6ZlSFv1aHA6jxO5oSpq40zGNa042+V0eVD/BGQm2ygG+HWNMVtEo21lYxhGDdh4Fduh+Mis4lBI HZPzYtUEBt/EQ63id8eMnZoZYaF0zjZxil7DXvmFCxZ547gt7t5vcTwkLE9ykFuF6s8dS1NXVVWT vAqj7UndcJ28HmyUkZYjT/u9ZtsL/wZTODv58FAEeFmLk6DRasLJ8vfCdg+LlD5dsXuZaIPgLTmV VptJ+FI9qhgHPXwa0WAWt+4MMmvc5KoiUkkerkBwDbsC23ClolO+OpShBaLw6hBCB0LWN7/5TTRw rShyWnCjFShy5EtyenaOdyrAI+2dQC3ZydNnbAIbvUPsNkQRIAeIZNNYA6/SZ1QHHy8kuXqFgrFD gk54KEnbsCpzh9tzUk7qUP3++/4ebzF+BUIx2TCDQDjbhUkD9zvQIDayNSz4LlAqM0n1WC2JFmp7 5ZuHftKMl91+h/tZrMTOHKnYBcON+sxcrQwrn1Ee2sdP5vjDNSqRDkCKOP5NI8D+aM9BO3DnMfsU NpvVyGTuHoiKhoJf+mvp1wUJgM5DelsUZHDsZ5WxZesO62BrTk56A+EvHfw6r9XgoPDG4rMSRnz4 Y4/ayOCgfedP/rP9L//633GMHZyseFOJgRINTwzjx+Ov4FmdE8iDQ1dsJ0zzyO981nbs209+rbHS U0hsfYs9Sp1KhaNUcLPRI0EzoQzJly3bRu+lw+Za2gitBNVM3bgSGMK+IX6qz6oIqr7U3rwmtgoE PA0Y5YTyWmAA6f3oLTbRhL0ebgJ8qwUtTV1rvU30znG6km2zWkmNYvX0gqyBJltWDoaEGyRyoVAW Z9CNNfhEH0JDVlixNgmfrfUt1f4URv/vP/0T+8ienfaFRz+GM9Qtrk2Q8MdOjl+ruYqTGHIAVghZ ioO3FFCyUyW9GaU5Y5wtOIk+9YRrOdpB3NXFCsIZztn7ONydr0UTh+CnRXTHyyds51/91OKNdTbw +19mGw/j9LplQ3KiMNKE6AhyHXnnZzgRXz7JSfBJJmRC1IGsopoTv7gMibDoKOuMWG1rOYdQCDao 9+C7ip/+yMr+2/ds8Y57bOkP/tAW5Lw5rWJVbHNrohWe8ckp96FZyU5OJfVX2EWNtElNYMHUyP+F 7C2S//t55Uxv4LxeWE+mNI1x0AQFA8koZuKHvgROAuECA4diVntflKNySUxZBmXlRw/kdns6Cdwm YUo51a68g+yHOxq2WNlq3b9/P0wgJ82ShbR7oO1pLZ7RuOFaS+wkntKz0WefsfOvvGTb/uW/tlfP fmjPv/KadSD8tbQ2Y5vX6VFK2hHutOVbhxZR87jeFzyZwmgnJoq9rHjMKwVS2fVJqFHSIaYFVs3i PbmqKWebWk+qeLeKwyoBSYK83kWDG3p11SS5QgKgxuUKDkSUs1PoBeN90SM41b8qiCI/zLPgWbFC IzSnA9Tj1l17sOeULTphT50Xsr6QcXPZaJPxLOsPJzcNsITqV41YrsYjhdttWV8q+GYmQXR4o47I Hp/mYMe32K//iz//lv3+P/tXCOyBXzgZry5g1H/qnROEl3vKPjx/lqDQW+2RT3zS9iAZN7Kvr2XL CqIElfG2L7iIBbyQQFPAGwVmFblCJLRJyZOjyGyj4uEMVq3hICC4Xj0+tIWlBWUUTUonf0vn+9ww v4zoHO6XbJUiCR5jiMcPnqZzzDfX2Vw73vI1wjHwSAirZP+rthXbrTG88M/hJgDNSyU2KAUJgSpw evIyJdqErwWcUC/G6HYsNlUxLXQqGIxkH6gyFJLKtP2CUfgHTzxmRzAY/+JnP+0acg2Gcerlwh/w vQiFAM6VF97SYYNSJrFvQIYCiVFgoTSJ5cIQjGjQjYlqXqYDTGBBqQqruyaY1hpNvSw8JuYZpPHj xjZvOQKhhw+sr7YFtA7zwFc4rRlODS/OaLtLERWW4dL4JdMCmLiaLeHqhnE0MoEGgJtcUx9JcFzL XraqFnMHCXg+HnAfLaNfSqujjpAGX2G/ZNMlrcHly5cYY//IbrntVnvoIULTIR34EB8SK/wukN75 Zy85AtpdLQN9vcMto3P+BV09ZwJsIICvnrXQpw5aH7RbODb5fJ+lKiE1CUWMbz7GGgS99KQTyBov JARWAESLbI2Jgis/rNIy6l49mj2NNwHl2JbFOf81L/3Sel57xV77jxF7rKIWjfdOm+uP25tXLtrc hx9azQu/tkaYZwpXJJ949BN2113H3G5R7EfXcrzBaC+uLbcTr52yV156Bf4nKphHl+E++BkeyS/M wRjOLXg51X/1XOXNUv30qvp16i20gLwgizCqRwreDmCteO0384Y6NH/uDYC+Sw/2aoQ8kU+hCxIA RSINHuVTExZ563VrP3/OKnfsCmmXD7788ghRyLl6g9+yJGjr2GRf+iqOnv/zf7S//ovv2te+8XsM XEv2wXvv2jNP/j2niC5Zd882mO0zaP72cJQcJ5GolZ05gvZdhl9IliNblqUYP5O4kxfFgJoGI4Qb fqc9KvKl85xglgxV0PDLwftveucSE5U6fyWnvzQ5X4rhigUD+jr8Y6085Z1ZeWkw5K6ojBPCGkR8 jyFExLd89kWZpBVWa3oyZlNj8/iLUlxOqdQxe2AA3EjFJTwBhWgRQUdV6VTbKAOu7oVF0f18koye e198yvagrfyHX/iMbWK1zdoa4U+2W5RUdcoHUAF5ChVSCwB9VbPmoovLRhpKGVCHOBFZiahWy6GM QgbVsCJqn6nRWRubmrfzZVGbaa5nMpWwpqmszKYO77L3fu93LM622iwh5ypw8Bubx/+amDOtgKJ5 JY6nWy4N2MymDhgGzZwcUsNLadmS72g3ZmGaaCUS9jTTkmvhPuK3btnJ3zZbQgOk+mhK1YGPKKYU 2vpVOK2/+eu/spfPnMcF3DwnRj/iBwCUxzGRR1gzcIaVLdK3xhdHUiR4WcGAw/t/SWsCDtVFqVQE E1yQ5HKJlYGavOKEeQSpsFj+nPsCI8GHR4HfPvhWfKrtWUXk0HgbR2sdKlC0fTyL5DRy7kNkgSkb La/FVv8u27uALV+UMQ5zvXGkzbZhNNRne+3Vd39sdx67A3gATiTh1HpF/kmldR7Cxc1/+c53fBEz MT2OB5E9zr+yg5SAJtx6x9nZYaTXojASOwUApvFRNNFfmHTvtyNRUOhWjmlc9OQJa8M/4noWGwUJ gGoB+f2r5ph4+Q+/Z3exX993zz3BarbEVPOGwT5m+46duIf5in3nW/+ZXejvOtazZ067/cJDD3MC GaPOVgS/iAt+AePkLpoqlPtp0Z74gJ7JsEWDnQSUgC9CwRglTVeDZlkaRmh9pSr5SW2MrUP54BU7 13fFtvdE8BGFfdVaPVik8eVyFgqJdIw2iq9Z34Q5gXynMOLEZxZsJjZjUbY3qtGsrJdphHacU8Ez CKHh1C3N3yyaR9bcwM2/3dTZZzj1N3bqbfvd3/snOFsPPLuH274igyAWNQEwmDiLCvV/HLAs5EY8 84lPpywH+q8wlijcFhkLIaboRPtMT87bhcm49UY5TYwd8iIG2VoECJQmtnhdtQ0jBC4yMSqUXxX8 thAPOSNBFuDI6fS2p47b1pdet6GbDtrL996CHaE0MqkJNSSi+Hd2atrmR+PWSWgsF1xhvDhOk5cI GbeEHZfYTFysrTfkXJ+ENcH++G8fs+Pnem3/I5+1C0//zN55521OEt4Dr6IFdVoVQoSwRIV9Bxiy NExhYPLIfTVw5FGMjWZxXgOIqrNG8/hjPrJl09gkzpNAJo2fTB/kduadV96xSfjp0KGD1o79vZJO 6P7kjbfttY4dtu+jn7Pytn22b7GJrcgyG+zG2TSL6B74Hutqe2P0LebkXXYjARrUpzQuaetaxaU7 eF8rw37wZ0/8zEaHJ+ymI0ftwvBJu4QyZ8f2HYHQ6IVDsFTZk4VPXniZCvtIvetXqZ+FgSlC7hB1 +pStOq7NnYxTtFf5kz+3OqLj3HJlyBoZDrSBXkgqTAAEsoOXFgY7kTIcPwfFCBS5YWUKKUD2vFqb ktJFc36KMNp2Pnzdje4S5qe4htmxcxeOn++zvfsOuu+kCE6p/VVxy5opQSyneGGEWxN0egYYPsW4 6Q+KdK2i58c1RUIoMI60iPBSoAJuSv1Ov9L0KbsQDULlCGTtHHaYQ0i7cGnYtnbVY2tSlVyppr+X vF6rIRJsU47ao5rZcQkv+O5cdKbS5qdm0AamXDEkYeZxoY0Wnf4dmm9zFzCaupekIiItJHp/Ntce niHLRxmGw4Pvn7AtHa12hDibmug1iRd92zcNdyC6pN0owWVG8wRSR8Db+XTnQsoDPNeCpY+8YunE MDCDg93ZGWJQdzVxKzEeFQKfpu3F7u/DMiIoYGcqCBlQEvWRKU01xvOVRO+Y6mTHArMD9WUJcjKY j6H5m5+YtV0Dw9b44WWb4ZBPJe6KJkZm2CpLefQPiyYXSOff6eUEeBPhnnCZAizZz0qLuIQ2R9o8 5naEPwm6moTRPnIC84mfPG5PPv+8dd76kLXuOWT9771jbxBN5tZb0dyQV6G53GRQ5U7QKMRZ1G9n gGI3dmYJAx6DxqpHqVAlaOQ8lom+iL+SSJYrjfPG4dXnAyWw/wWmAHJlFbO/e+zv7NUTL2EDGrOX fr3VvvGN3/WdlvPnztnjP/upVX/kHpvdfp219c3jp3LJLnURrg2Th2Z2T7b0z7MImbDTODT/R7/3 VdtEmNYFBEDRHDetYnGL8kNawYG+PnbwnrZrd91ttZU11ljXhjB4xc5HzlsPTr/lyDmQBbSDsrEU jmGqd4J6GwO4wbdFDw1zWngGif7KZZp5blYM3p95x4VADuIs4dzaO3SBDF2QAOhFpBHnrrvJav6w 3Z7/029bE5OvgMhQs6hJHBLSJA2wOpRU07feficRPtrd6LENJ8GVbNvpmThLjZtfyj9nfvCy50qV KEuFsr+yrruqfqmTk1hIVJWS4VsdsMog+V4dRzGnNzNIXLnCxNc7gP/HBWtv5jQlhVtOD3W2OSx8 ZYy8yHsLTJblGDdnTcBXJ1M9NRnXIliOTCEU4NajBlcdKsDqpUxBVVm06h2aw0C3rJpOi74P4a+S A0sHjv8aRHF778bbbR4tUb42dirTAJP0sVuusxrek08tV1iCNt9ypUr4m3Xl5RftcXhbPonrEwnd 8nJf1IqtXGaIn4RWaXhklAMWLAL88FBwr9DP2RiaY+JNVYrxxLDLkiI/VI9P2O7v/8LqLvTbuUfv tv5bD+EVOE7Eh1kOe+DpgMmyCt678uDNuItosAtdHVbbWGPDLHg4ZpIB0bU2OJJ+69n37bMf+yJ2 05wIRWXOjrD3Bbmy4awHAiATB1KgtvVOE17tF08+aa+995413XiHNeE4llA8hr2/XbpwAeN/opmg aZe/S1VjZS0yirDxH2qAEiNJovAOXjpkwfgjbKVKYdkZYZKVKgQXB0PILo1fJbyuw3AV8MUk27qP /eCH9vwbv7JD9+3Bl2CFvf7Eu/atb/0JuyBRO9c/yKKmxa7v3GdtA0TWYM1yqavaxmqJUcwhu55e nJgzrPZuqrK5uho7xwGRqZsnCN2GWyr4UbylkoufpCn/xZO/QICpsV2b9tnA1IeEfaOv17bb6OCw L7791DJ5JSStucOzRvWD1gg0kGtkLe1j1R0MoacKjef6rS1utckiZiK6zpXCTcX5u+/Hg8BWe+37 f2XHoC3du6BUkAAoJpOB6AJeypc4St6PU8lqCqmCX80kTUclk97BQ/juSWhRdCrJOUp6ZY14eY4i K6eB4tdETStmL3W6CihSVQjHntSdol0F9chdG4le3jmkxQCrnIV24fxWPqmujOKMeW7CutuwqULI Wz5gzMvAmSXW5l8et4o97Ta0bwcQclQmvE1RpAWpRvMyNT7jPgbLdGrS7fbCTLmr7/GAZztsON7J QC3DfTo4A23XpQt28+Pfswirt8HN2+zyrgO4Y8ghkKaDh+cXWfUtDg/Y4SOHvQOqT7imx2eC9MzF u1a5167tBvEJSQJRBdtAZVeuWDlbT/Gdu5P3N4gh7XUhyp4mcKjd3MA2Kx3XF5bZs616153ZQjDR LCsmtB+Rmbg1vn/Jms5dsv6jQ4QAwx/lwIRNjE7hjqOGQ0n1fvpyYk+PTfUwKQ5xAGQaHnKAqdYQ f8ZQ/z7z/Rdt/45r7O577vHZREKIAt3L5QVOElg04XQawe/MyfftNSJBvPPuCRuK1FjTLfdZ0+bt uFWqsomBSzZx+oTd++CD9C0OWwmZo+LDbQCy1mZVWuT9UHiCyuX9ynoylrAGQXGcXuspWaHvBIhc ICjwVY2d1Qh+4gk//AGfDA0N2w9+8AMWBK/awbu2W89ewq3Bp9fetx/Ncp8tEqWkruMGO1i2yTaP wXPRRbu4qdpGcXbeAi9vlvDH6YoBtIEj8O4BtISvE6liFK8N997/oO3EBVEDC5OA/mX2zom37akn nrSbdt+HZlCRvpiRqVINYd+k6BkmjFkjOz1t2DdLM8atbGupAmouzMVqnPXDUj0k0IasPo8Wfgmt axUnepW8m/nVKh+IOUsoP2ZxJD341FOM/znGmVVAFCQAim6qsr5lCyhv2vnrQVYpRdZHqxPXVetO PUrg7Qkx52etfGjQFtuwdWEgW7uhJZoVixmyVsJvOobSo8ldgKI+KX1FHMMaPUB55M9TEqA6k4Q9 OQqvoQNdGeglNuYY2sBaa5S2Tq0cMIm6nEXGp2zrr16w6LstNvbPui1GcPFVNW8gk41edSOwQDY5 NgNIbLbqokR5kDuC3DQRfy3MRW1wuputFPpMYhND+OZ4dxq/hhVMyNL+rQImowUVyHwK+7R6aNQG r6sDaJJnAej0yMhc5B8SZkuaBN5RaCLgj0pJuIVw3F99TCisXIKVmTQhSuBTrNAYPvaaNyVO467M GryYixSJYna1Vlt7P4HtF7UFrH+ZqZx6xTgYcumR22zg3ICd3dRl00PjaFyiVtFAWCjqPs2Co4ET 6xEOiiw2cECJck2MTjL2UlqNf9BIB1ZmOWjy7PdfsOZIj33tK19POgGXTagOP1Wy96u6zc7O2g// 9of2yjvvWRx/mtHd11vXpi1W1YAfNBGANEgIsN1bttiDDz3sW3S+FS04PJOT4hKuMRz/1fjwupQS kTf28hYvEcIC+6TqLlGrSu7nGM/kRWMSk663334LW7zHicd7wY7ce8C2H8SHJP/U/9p72qwRh+jz sWqLXdphrYO40NK2LzZ/YxL+0PxJ+KuMLVl/V9T6mzkrwMmSXbXbbG5HuZ0aP23f/t73bDsL9SOH MddqbrJRQrz94omfW1fjNtvasYvxUQNY0P3Fq9GKOutYJL72+x+44qmsuzsQAMNMnns9H0VoFxbh vlinHwbukXINBivL510XukrAVR9WuLsB/NpK89eNsCuH8fmlBBdjxhH03fzLEMIvTADkrSQKj8CQ 0J9pIPLhLfk0hL/O7wDOWtAY+1KJAS6KzULFi89Z/J4HbO7hj6cVNpUt80oAisAMmUBX/EqSZ8WT 38YbV4FeIkses4ymJGkC5QIGBYhPhI2Nje66ZWRwyHrZQhhnYOrAwW4VjnfV2poQF5WZ1WYce6sl aYwTvCtNR05BkJfVYbX9W8m2oHxKTo3O+BxcLSEwgxlVgTAt2uRci43HsNdytx3B/TL6z0jHZvvV 57/BQIJPrbYuK8/bO3TEJggU34nj1nqi8bi+W3Tg30oxIyxHcb7DKAXFgZYFitjLWQxBDP+i5Wz/ LibigubRobMAzHVrWd8HpyYdNeg8Qpb86cnv0NwsAqgE0QRl1cw+gMM24UDtxQ3R6Id4DOGtobrS dlQu2PjIpFkT2/R6xDPxkeCgDDYcv9i7u7db5a69tsAaoJlFRi0xr9tfJkYpE/O5Q3uw95u0Buz9 pDGoaZQbF8xuODgkntO27zQuZp5/7FXriG61r3z1H2D7hx9IOkaMCViB7d1OCJya6F9440174pe/ spbbH7AWNH6VVZgkcH9BExplWkQLMXn2lH38ntutHee4cgMDmIR2QfQJK1qq75Ij8IKXHAs0c34t OSKhAYnwOE7hXZn0KCyKbPBkAyrhTw6cFSf4J48/bu+9d9Iad1TZbZ++1lq6Wtz0JXnCmHeqcZhf OVZjkWEOFeF9Q8LfKIfi0oW/gU6Ev5aoVcE0m/tmrWGSpfPuHTjE32rlfRds4p337acfPG1LnGKv ibNlXNtje/dcGwhD6hRh4lr9qxX+qxgdt0VOu0oAVP8UP9ONrkoK0YS0c6SUq6LvkkV+9mNj68nm 73vYljBBW9NwTy97UzGa8B1D6xcnukmEMHDN7Kr6jkGylfKsngoouiULqpLqL7yxOpyCBcAV4NQg Mu7EanGJ0C7SlRQjqQqqQ37VUGbK8epLZr962sqb26wMATDYulgNQoJQjkwwSplWK8cG8Qq0OOoq pWDBWcL6qB55rmq9FLCcNk4ly2kSl01cFL94EwgOQ4MDdv7yqLW11DFp4oeNvBWEkPvgC/dbdBsn 1xgAA60cWhIm3jiTtlZ00twtTz4+QWY5lZZdl7QuMZz3SgDMlgQ3PtdgozOdDJhMxGkgVT25/+jd js0VSfZgeVaZwdJscnTYDm3uxjaR06VM9nFfkPGghCmx3CshhqDZk3TAMe0itn9+WMYXBGkE3HAp 1F9SfSaJUxMPAhH+aG1MvMIW2RKHjirALwFMxdCSYQH+WMTUpEzmJikwfqn8w1NxOz04Z1MxBMo+ zBJGqmySXROd/5bz3kpsA6vgNXFapKHGynFsG2URuwRPNL17zvZiF7goTe+uHjtDqE1FASnHdlVD bC1CovjcTR4uD9lLP3nT9rQfsC98/ks4Ae9xyvhpcCZhRTUQvyjJJdbpD04Bp8HaduzzOKSaSOUq pmFiyBaZxIamxnCTNGGHjhzxdyRkupms099vlfijmG28VlFLjUutW/rktchRFd3WWCYWcFs/+AbL FRf+tCA4ge/cb/+Xb1n1lnLbd+8W69jWZs0d2OppPk+XsgAkv5KV0xU2z+LjYods/lLbvpW+7Ru1 voTw19NPCMyxmI23VJI3imlBxHZPbrfGLc0siCc5V75gNeXVRA3BxAH+Fp/5AiyNXFrQxuqbbQE7 1CFcfiH+OT1VF7nEXOugRBqodV2qn4cNqB2W5A9wl514yyr+7Nu2tGOXRTgTEduyPRgL1sAkfqAJ /GPk4nmrPn/ZokRdqdu3Bwkb7V/i/XTSrwEyeKwXNYfIjZQIg5DKxZqvFiwAhgUEA1zE5En80Yq/ +FMrQ3U5/9GHbbGxpQgtEwy0Kr3wrV0NMlHnhXsf8BiIi3fdzUu8mRzVBSl7ctj6EKJSJZgnUBOX CIETKS8qFaUAwVyQd8sUjDPZJnm+GWi+EKgwEtFk5zYtCHbNBNeuYWIdw/7kYv+A1Xdge4KUKHcc I/u3Y2eM4EZPk4DRefykdbxxygau329D1+/1RdVy9OkDlK41kPoQn4sUECoe67QptgCz8aLYU4Kf Uh6smizOIguusXOnbdexo9gjRvGHiOCKICJNaAAtmbWoF9KOgqWoMJcDS4fu05YPZMqV/mT5W+v7 HfBNQDFBdwzUsQoH81U1jTYyNoeWrNEnwsByM8CjN0QHd6hcycCTlvwZMAYQpqYQFWfULiw+dNK7 lgG+Ep+CM0yMrP/RqFT7RKw4zpoU9Ce4MQztYw28w4IlznUUG73FGMzGlpsK6QbjtPUAwt9zf/uq Hd52vX0R4a+LRY8mUvHCXEL486J5xXiVZ8izbujvtBXv02E6LmOL+rMf2FxHt/2wscna0Wp0EEJO ncC1f45UEzTQBEvfKxI3pRpVBhkjrTM5DkeyTgB5vJYgR6o+ebxTcBanEfSFhlnJVTDAbC8Isvp8 Jr3DJlIkDQ/tlxgTNS5K+1zBwDWPpvf4a8ftL//yL6y6p9yO3L2XAx4sUOhv7k81JFIaWmn/Y1UL drmrkm1fHfiYZ9t3zrd9B9j2lfAXhWF60Pw1jsUD4a+TU/DwxabBWWsbiROxhrjaCH0pujDX55Dk 3EymttEWMOfqn+h3n3fd7Ar4OMyihVDrGr4Dnkwr52qX6vOe1mgUaUmlUBDNlDjP5X3K6Q0dlhS+ bu8BzkLssEU0eDl3jvzt7B9VCOBVhLQtw69yGWO6GFI7BHnXCd5y5lKVOKUVOXvGKjkYWNXeZbEH HmEHgT3+sL7Zi+AHeHM8Cm+HlAqQJQnI4zJWq5UXzlnkF49bGZE6Fg5eY4ut2K7kCtMbgsz5LVyq jb4S38GvtT+xH4jffrcZ0vgSbhd8Rs0DRFi7tRFsIAdIwgDvG4CyxqvqSGtkKdpjEKU1VdHAhoDW 0ShB1ek8aF+0OtQurwaKamkDsTvpu8KJMia7KEfQ4hjLuxCrjpyoSvdzr1v3s8etHLcbw4d32yIr 1iC0kqpKx2SQmptR/EkGW96plt2gBofEABEWPf1bOCKVw9a8VGeji3UMhGQPCprMtvx38kGOi3JW y1fOnLD66VG78cabfKtRg+k89q+VDK4lTWqXZeUvBb4UitRV0fGI8MvaTnKLTsnKNUUXA/zp8x9Y YwxjdHhh+WEiLw/tSe6MoqnE2tqdmEPHMcf42NzAKVrW2WIV4Ipnooyb06iiZ8aZKDvY2uWe2tB5 kUJMbO22E7/7SQqDfVALAugQpgZoXeAm/iRQoH3GDvV5hL/rD95on//El62T0FuuCWYCZtcaWGqs IIXCqzR9jS3NLEpwG8FJ3/IIpgsSAHsv2q7jz9l8O+E1N22zIw991OrRni+Qnx24ABYVU/lUv2Ti XaehZixcgkUuX8bJNCePW/EEnJkz+cpaF8IRdM61cm7keViLq8TQGynqGu+qJl6LtKrANi6Luz8/ BD4Jde4zEuLO4t7o9IWL9sILz9nxtzAb2NNke2/b7tu7QiU+zNV0QjEfnbeJunJrxM+fC3+4Hujn wEd/c7DtmxL+KuxiJ/aCEv6GEf4G5tltgc/hzwrsBNX1glYI20LYV6ZFBJuyqhprWGq3vt7A2bH8 EUr7LUlJkUL82NzqYDIAU4qM3+k/9EQ+1qWNVxn9lC4XErI1pyiOcUy2insO2Ny//LconOqQNwir 6Abp6ZByXIeooXN992Z2hYSE8QHn7NIyBtNLmGkZDLKuKLreUfkk2B9/1crfes0iHNBduOV2W5Tf Rq3gVkmrawAFmIHCt2AY6ALCqRQkCO/+0QgcvXT4emJLItWz9RqIr0GWgj7FpNQuWC8lGGT1smeC J++iDChxWRAwcQEvJ6qUCbCIv9IG4yJCTYFSVWmPtQSS1AsbvFLPWMGJG4SZ9rrPzT6spd3M81Ic 5J2IMmoyd5oIFh0lmK+IxaqTtr5oFs0QGuk847u3Wu3ACN89TIrwfYJ9VNN5oiJMMVn7+/rg2Tzb GPMzbJ1xUtMN47PRgzJURjmMQiSRiel697KfZzWyZ2MwXJidtIvP/NQ+d+9dHvPXD38wEHpIu+xv Fe+u2h06ljIJxWoDdLFwO4+pX6qBw+R1C+rY2Nxotf112Fribw/j90KShKZy3A01yIk0aoRAiRmM bs6HqOFqm+AJTvqOX5lECCQeqdca2lKGheoKG92/1VFq4l50H1/ybxrQXkV+46mTtrVlt33xM1+1 jpZ2TAASEWDAvbyJQl5eYRKj6jNBDPRss/dv+6iNIWBOTYzatWxHaeKLIYzGQpqoYZQSX7osn+Yw CocHFphoKnAaHf3OH9ni5i02//v/jJ0gFAGUqfAkBCXmsSStCy9d3m8kqhCMP3m/VVBGjV1OLdpG 32oijXnBXxDJQ8wwg0PnYeyhT71/yu38zl3+0JZqY7bzjm7buncTWukgTno+ZNfiWn7+2nuxI2Tb 94qEv1Y0fzgrd+FvlG3fVrZ9XfNXZt3D2LMi/MVYeA91VnJ4hNjVCI3Oi3nVVn2CUHRV9EHq0tvb h3eoGR/7KjFp0NpD1t1ryDlJTKKUN40+RLRlSbckWzIFkDjQ0t/vhHXNI/ysKD7lIJvHNGVh/0Hy AE95HajeWT2pR6CgDxaaVexAbZHJBjDQBuYl/DkuL5yXK6yLLyC3bqMccVsk2s8CkbGWKYazFiy3 AMioVT45ZpW/+DkURmV8n7ZXkXTZu3fCCbNOy6nDP0iYIfIvcBy58E5PZVCDRt941cpwHBm7BS/3 nIx0qoYjV9aiZ7mpiTDflvDXE0JTNk7IAn7dt5IMkieXrBvRVXiRujj7lawqQQtuGHw4cUES+cgT VLnKULxURXaQU1LWet5xdRrz8p3X2fA1u2y2DY2L9/5gcF2gs89MLrg7jCpCrnm8VUba2ak5m5+e wa5Kw0+O0nJbBvuVUWxkZzfeNjr9e+aXz9h2DqLcT3+UpkqHUebY+tbA4u2ycTS5IVCfYKrJnaU4 T0peE4q5EodakXnMnSVrculAsLlw+RwhJeUHj/zKsGaCt7BXqkVrUaGJFf5xVkx/mRtyNN7A1vDE 6LSNIQQ2taNphK8chT4CqdFt/zS4q+2VRP/RwXHrPTlk/+4P/6l1tnXitBffrOxRxdkTW15E/daa RUlG5v19aFFqMDhHMBVcjBRsuHOTvfipr9rlM6es+v3jthMNgrSJjPTkod4iledNXAKnjNPEld/7 rpWfeMdiX/q6lRHKq/yVl6xsO8b601NICWgB1yEAOgVWNo2KX7zk9RG45dQqHgpBkkBWykSTeNI0 qZaXfz0d7NDBILVt76XL9u67J+3Nt9+wK2O97NjhObK7yrbf0m5Nm1jgMI44H0iKyiMpV4RY5l39 MauYjdjAJp32RfMn4U82f0Sfkc3fBTR/cfrLpuG5pPB3CVcx89Eya1/EYXHBhKEP8U4tQqAcl0/g o/Nc/Jzt2LET7w+Bdl48nje7qV1WaRt/DD5tx77xxhs4wX7RPvnoJ+3w4Ws5PIPvWF6X5lGadk/5 kc+zOlrySwj0aYZtWo3doULCMy3/AGEZmtvywUE07FW44WNxlUgUEwUEAKl87NARm/+dz9g8Dt/Z oiKHQw6zZv3OKQAuMbFVcCqo8nvf8UEosme/xQ8dhs3C2oJZiCWF0xALrHgLkYSTpYFRKlDtRv7o P1gZJxut/F8gUHKqBk8bJU8UWPVRNUTIUiWnWEi2UiBR2UMkpa6Myu+4kkiLXKOwITZGML2tP0HT SUb0fLRxoGcpZ9DwkFsJFMoTb2QybsIHE33GS6BnDKiTrGCrOOQRrQnsCxNPrRb7rTg2MHMcHKlE 66x9iFTf4N1EEqzZGQQ1bU1XMOEmcIbP1/oOtO8UhYFv/OxJm3zvTfvm738Tv1gdXi9385EYwMP6 rgVzI8+z1XEj8Ja/K/YNSFQgoZYDWuO3oKsuKwRa0ZIxSQJQC+Ysl3uJvkFIt9omuRNaXibnlIz7 mni1XVxBaAXB1u+sidtakDSgCZwcm7bxwQmP7FEm9QPPXDhjUJqeZpmC37QKto39HiP2+Xcu2+bu rbZ//wE3AZhlu1lbU+4aZhkylTDKTCPhcpzx9czZc1a14wB5OexEv9Bz+aScZFLpH7xkN+7Y6vV2 AVDCq+egPBog9afq8FWOsXnklZcRAN+wpWtvtNhHH0QQ/KotYW6x2MJOkPbTf0NTkodV+RzNs+Gi J0jlbbZhYKsAAI+qUcWCQmsELQpHEJCeeeZpe/2t40YkaqvHHdbmm9qsBU22nIpXcvgoEBKpfp7C n0ogF1DV0zqQZGj+Kl34q4S/Q+FvooVtXzSCcfipmyg40vzFMaaT8DfG4rlzdN6iM1BfBS40gUfa 8CoihZTXyd9rH6Ea+21zD54CEtKfviRYrZa87VcpgLNDov8J7rXXXQeeAfsrXNi8d/179rFPPGr1 bPuKbxBl17XhGZQh9e7aLIgyjrMWEWIvL8nrA67Ogr6Y9ib0WULoW9y9D9kJn4KaaNIe56JJTgGw jAFwqamZwM5yXkuLgVi2LUnahY3oAxwDnX7ngXBFQXhRRvnMsiy9p13CFUgHtR54KxCsdiNAFNjn hRVaLf/6niUnfdGxJAm4pQK9vLxOsgS+krZPcSqkSdhjUGqgS0xgWjVOjExZA4OVtIHTbGNFFvCz Rt6qem0rLHBSExuuecoAf0r4Y0xLdPag0hocKjCEjpNnZkz2d/hokxo/oxMsoiVssMG5Dotp62AV ermgR/nkHiZI9ClwVBEtRLFix3GhcPGpn9qj991r199wowso6iea+FNj3ioIlrfjun6XGr4KFYoc xWn/XNWEujxaiUN3wy0aRZnpZPzrH+61mnpO4PqS3YtoUUK3KYrMHAJc4EooALeINkRspkgbGazA 4xUJZBFm7XpgTGHTNzYwiT8+eJJFdZQF+DwDeRw/Lg24MQqBiccufdBvdxy5zydxnf6WXRdH052X w3whLmmGVJ4yFhC92Oid771i2255MGPiUh+JIWnOXDhn193xWedjLZp0glg8pmo7vdijcqrRl2Ru E3/kUYvs3GULskUlJOP81/8xh6zQPiiSQxpXhmXJ59t5WUhKmZLw1f7JH8XH6HMjYEuERu2qBooy nnkINxrq/Lnz9md/9l0biffblkObrK1nL7yL6yoOFIVaZFVZ2q1Ck9Dp4MUV+fmDT6PICBL+GjjU NIHfvwuMpzH4uRvNXweh4OI6LUw0kLGacmvmVHzHAJKjj8OFYk7kd3piVoMddEs9NoF9A5ykr7JW FmraatfjCgbZvITAHEVQHRVRSbtCEWB14lv2k5/6lO3eucPefO0Vu3jxgh04cBChk/EcWtBNsowi OYAvu513CyBALLFdvISdoH9rkZjgW9U5BSe4ylf4U3FyCoBawcW37bClf/FvNZrZAis7loxu7ySM wQCaqJHwBrgTNwr4AuYSRsPx3//nZqxQF45c76tHNUTJk5D46FhCbI5DePhbL43WIoTTXy0CEh8V 1nqhGM9LWJliNEcIg29NZtLbM3d6E0jg12GQqVHU6tBraIgDTBG2FzBkb6oatpiM/uewbTWEL3pI tbQ5TdKWpLheh0JqOAiigx1TROWoYLLWCc8a3LJICGRZgwBZZ+OjW2ysnAk8uQpYSXstnirnKAu2 ifOcKNNJPZQv1oBD6+ue/QmOQufsR7FZu/vozaxAP47SHWGV/jmLsKEJ01nYwYaVXomjKHeEyJu9 VG2vuoBjFVoVpR4AUQ1yUisx0QhXa1ur9Q30ucufGjkCJ0nwa7g4xDbYvI1v7bCZ9kbu0uZqDDTB 0q4EaW06SUMUQXtTjSuYkT78nWFzWIOGY5yQg5OYxMgfmysFE6B0yGlibArTocDXn2xA4/A3LEFa iU/09D+eXvjwnM1wKKrKt5Bc1PJiluETc6bvtNWULdieffv9ngQEX4okiZQaX1yrhUAZxwxh4bY7 sPdrBjN1xgOEL4A0ya8sisNd60N9rNRjmONQAddZxrXq4M8FO0H7vPKvM5Nc+1ShZRPHjY6MEK7t j206Om43PnzQalhYyERFTSitdCHavmzFka3zXPWcDTSx2IU5XPhj23cyQ/iLWScOoedZEF/aHGj+ JPwFTqI5ucuCW8LV+lPwbi2RQuYZEy9evOg2gd34CPTIT7C1xnfvwsuQeJNAjSRLL3se/lTxZhmA K6mvYiQ34E3ipo98xHaw2KnFz6z436uQ6kLhq6X5htZLlGGBvrmkk71EvvKksZKUUR9VMiCRP1vr I7cAKIYB0cJuBgQwaJJKB5yNwGshy/qcwi6x0o4fOMRjVpgMLG4NmchcQF2ygl/1pioVEiyDiqu+ lcfDNGJlVCDjRx5w8s0CXFCmxJN83ys0X6L8adUrFELe+YvYHhKWpH5j6HH0mtwa2upYKc7YzGiH zdUftFlm2QppPWaHbTaCtqcaw/wyBLL4rI3gR7AF32itTXMc1hINoLRIzsTN2GsRBqMFbLCmxmXf QuxUbQ/HozYxsdVGlhrdHgb0WZM0f7WT43bL439jdeMj9vyDn7azdOzh3vN23Zsv2+6Xn7EIWp6m f/t/2N5PfdqaNBBQn3mWuXH4N+yHLvxnxVDMm2ChXUKcxYScCauIjZ8JeNmv7HjUVBrby6loDZqu ZgScieExNCnYjLoWELrrVdHCfwdg9Z4WGxExxSpJ72hXRcbkXNkspgTTEzFrbG1AkSfXHSw45jh1 KM0OPBYmCXJzk7OcRo+5vz+d6g3GZDFjmCv1rfKovfSnNMciA1UQmiAmED1MJG2tDbx/0rbt2GXN rWzfUm8tQDTJ6dVkezschxoMmyxWCDgcZFCmZMYQ8jq+HeE63ivklSQO1aVUKeiREohLtZ4RueVK pFILDhr52Wd+ab2j5+3Bf3SnuxgKmiS7MLTeWi/gALoaJ5kd/WimJfyx7XteNn/waffQvB18/kVr u4jd4bG7bLT+sLXgpLznEo7VYdVh/AE2wOdVk5Qprd+spyzqfw01TRw+qbIBYsBXejhQXBdBb2TM 1U8Gq/1XSeIKN9nhQuE1K1FSyd1WNz42A+FPiy7+eL4GqFWwFPJI9EIuIpayypY4LaKqBn3bbxYC L5U3twDoiMARjmWORMNVgG1tOTqFZM0rQC75qlkqGsG/OmQN0AQ1Kh5GIMEw7Lkkqg18VamU1VLh HUniOxzxEyUo3hetrtEs2UaqVLGT6CeYG4MtkuhPSZOyb9/5oBPAVdBzlCm4xGiweANG/qhvFlh8 TFZ0B5O7hMUyRV1Ao8eqr3923EanR6y1bsza2zGCBpa71+BEpzQ+EVbacQQzbeUpaOXcYrf1LjSx JcJEv0pVtCJumJywnW/+2ir7znOuaoaYr1ts76ZuO3jnHdbKAYQKNI1t2MVW4i1+gcFX8Yxj6cJf kl6rIApIsbFPwGsADChbGlwOvzSgl9U9GMtyjWOSrbTFo/LIxcrIqREErzg2VJgIoBaYJDRWhP33 eTR3GbxK/5Cgtlqq6xv2LeSxLSw+CHUlEwIZ5FfVyR9gsM1axSKkaiJxOjMBTFt4A+eH0NThyBnN pMgkQVWCWkAy4U0RT79C1xJcWid+AiumRm0BfovUN+kpTYmwGZuz6Yvn7cZH7sNlDTZc8JjbltKD kjWBDqKYd//wpnghhU4oipAEsOhAM8qVnMMyyZWRZ8M/EjSS1qyUSaYG7uIFJMffPG5brtlsdRwu isl7dwnIqLGse2DO6kcJHyebPz/wgSuhkZhtIvzmlrd/Zc3nXrX+TXXWv3Ovdfdx6hdJaYDDJ+OE MqznQF3AtRukCrxXjlCkgyHzHEbtvdzH4ryaxVqT9wcJNvgvyaCBN7fzbH4NH/YrHKH4lrkOfqhD SPiLafK4ykk9MKNCifptpJlXFwBVwTToGtfCn0XnawecgJ6grX4tr7KKVLyUrA0gE0g3ApzBtOKd N6wCW4GFW2612EG0mhqhBdrBFwFHlvL5MO2gw/pkyVSkW+o/Ss4LpUcXINvApyZwHdRQLFUJgb4N QuFnJqZtdq7Jpuq6mAalYw+QuL2rX3KD/759hv3MUqQF25B6651usenL2Nd0EZ4LzV0Nk/lUDxM5 8VprMbCW3cjoeNSG4ghr1VrQiAFypwgdqQ+r6l9Rtl3bttl1D3zUjmF43EOQ7zpcDVQ/cD/lppt2 EgydiTmG5k/CnwanjLT8d8bDjf9IZ69St304QW+81KtB0HC6Sn+Eb3zA5buWiCTN2ENPEpKtupbt Tl6L1eP4XuDTQKgJgkE6O14tcmsGx2zfXz9h1Rf67M0H7rTxO2+xOtzARMRj4pUEu8jGVP4HtaiQ fZf8hU0MTtlrT7xj999zvzWxGBBvB5MUhcjR/opKooWKtIU9W3dYC/Z5w6dPWNdNd/IOFKBMo5cu oEmZswN79wZwKIM0IGHV1N5KoFu1fkGuDX7mqMcGoWa+rno7wVSxUiFMa5MSoUk0i9dN49rQ0IDt PMIhnFByyaz1hn8tIgBVcQgkMr5k483lST9/svlrvzJvs3XVdu6a3TZnw7bQ0IXwh3cPDof2I/wp PFzDDJo0NNsb1f6lKhL00Qacti9NL9jZM2dt2/Zt1irXdDCrlOfIblmaWIzMw3QCpoBmXInn1SXl WF39QHwTHJ3KyHaVfqzkVVVDLsC0K5RHdVaUc20BcMUr//+NrBSAOxQcuuLvfmCRJ39m5Vf6Lb6H iBIYrCqJIUuaxNPrYoGSlup/GHDkqWTS1pdiX6rzSsBbpJ3GhvDL18rWr/xLrZWgrdyAlJVLI9hi YwRtLbt0xh545nHb9PLbdvG+m+305+73bWY5iJ4bqrRpYr+xIF11etGJz1GcDZ976ke29ZOfsi3H 7rbGXbutCoHDD5SAd5ETZ9pq0FaEa2Xo8Rrfs6Zc97NmXufNUvPxOotV7NdESrkAcuELYayjs8Pe PzPMYoJJDVvPbEKqXKbI7Usy+YShtgukOm33x3CgW3bmktX2Dlo9qoXJqrhtffZ1i+Brsu/2a21O 2mhALLHtX0Os6tmLg9Z5KW4XiIbw1E/ftf1bDtnDH3sEhhQuzACY4cTXOTmNMiiE1wJla21tto9/ /CH73o9+bAszk5gmYPs3NmHTVy7bR67ZZ1vwI+bOpGnjoH5pnSiJQbgy7yfr+1t0cTVqUfIxX/RO 8JjGBPltrJLroZwDxMYaSK0uNzBj+P27iP/TBcbETUOzLvzFqhEIN9Xa2e5HrOeaW6x+lhBvCH99 HBi5gj/MGhavXWgOIyxgizpPwavl8HFTbauNT5XZuQ/P8zviN3XPCgAAQABJREFUmkANVTqWl94l 18O64hWlYOj7zeT9bONRUOrVPwsUANV0IQFCsqyOYH1PBbuobJKzGDoxE9YoZ6a8Hojb2DMiVM0S LjoWuzbzG/LCNYLv20KlIpngOhJHlFZayqMT1tIssA264eQ9AERaCtE+pUnAdfD62EgK3lcpdQrY 3btz7ZMl9IhVdCL8yXg9T7okqutbyRW4jJndzLZZ3GqGRyyKP0DN2oIdX6jE3QZCZWSGrePAXUC2 WpRhIhBDg/jhkz+2B2681h793Bfcvk+HUiQvzGsbjpFLq02RXeiDAWglNDWH85e3y8rnRbsjPG5H mSBG0QCnALnGNfWzxFer85jENv3JFrABb//12IVODE9a+2YddliZ3OcfT5LdBKFrkkMdiiDj20f0 xWrgnP/igzY0NmmjHzlkbafO2+5v/ZSJFZdCzfV26e4brXp00rqfJ9boODFTOWyy7cMLNlLZYEce +KJ9loWCtn8X6c8xGAVx0ts+aPpspdJJcRmzw59M2MfuvpvFRQUuQt6wuTgRHXo67eBHjnCycT8C Z+BEP9j+XVY/b/vV6bXsjXX+LD0OYfBROTu51lnuZa8JtnfMZfeL+JPRHS2XN4yNEhtcC10dWMi9 QtwYci1MZtFnXG7D+4ELf4Hmz129dFfbeA2C11S9RQlYvRjFiTKuYgYQ/mQzuLmPbeMJjbXwK3Do GsVLdDgtphvr2HUBx+WLl4itW8fBKHZ9vB2E0P8Le9B3i4m/eDUpAJIqlkoBT6d+53tVkACYMQFl 4s8XX375HHZQpVKiCZhR3agI3KCCAmb+k5+x8qO34hFfHr6V0muQfh08LcZnKP2LuZOMgLahfOiK Vbz0nHvnj197A+VTXTdWhlDGyOCFYlQiASNZOu+5RQBMQWPEvYwSuFywgz9OAbPFNesjUeE41Gli CANvHD1mFUc7bfSa7X6aeCHGdm5/JSfgWADMIQCiaZSgly1pMu59+2Xbj+Ppz33+C9bc3MK4rbIu YBcWCn0BX5aK1tnKleteql2gYfJHrtwbvF/iiTMo3dp9XjkkjMsWUD2rs7PbTp99n7B7causChZ3 qZrSZmjtAh+TGBVgHzh6ZQxalVsd5gFyG6FZT89HbtpPaEAWC3jr73j1hNVdHsCtCoczIKxc/9QO DNuOHz2L1fyYTZFn6fwVO3jLPXb081+2tpYm1/xJ+JMD8FTIt9z1UXvNoXnBkYT7MDt29zE7cu0R 7wtR1NQNHHSplJsJMkrTLG1hetL7uuN9P/NRerbfnmvVwXnYP0pUbsFOEKtUaLxR4E8E+lOn3oe9 4u5SKLAiLU215hnOFmEEHfhoR6MX48CTTvuOM762ECFk8+U5DtMtWV93lNPCURf+erinwx9jOImO Y8dag2awCltAhYRbxmobKLQWOBFramyzgZHzNjo05DGt1QTqer4VnICeaJUN4PrNeTWY8ddfnoIE QDF0ipdLScYAdvGYYzUCBeJTMWqjgdLa2m1BsTAB6L+TgwAPi4EkW1VCXI5QheAGhxMqnnvaKv7k P5ntP2RLW7faAhMYaqVsEPK75zMA8B2PKiNcxU5hZYoHV4dAFEM3WVwErGkGC9cCrAON7KkinKS8 uPt6Ju5mDPhxbzBMDNfJanz+Ed8RR51LHObw0U1kWp4QxBcIAD717pv25S9/gUMlHQgVRNVh4JyN p/ex5S9m/63muBrbTWrtYHupVG0vBKqMvrPXtbh3hSRbA6VhoTyBtmjJGhsV17cO90HT1tKJ3VFa NqcIeeXSRbPNPGEC6qO1FmVrLCJNBIuNMH8QpJ2X4aOJXVus777rba692YYP7ORgybzN40popgtv /9gAnrr5sF16/rTtvPWY3dXe5mHhFPbNo78kih+SLKhLiCVVON2R3aj2wqJov2Usv5kDIWHSwkN2 Y/MSSsmcEirDHGnfCZxpd4p66VTyJnGKFhV2CCygEJ+lQxHALiX8RGWEQuvY2fg0J8jFa9wJKhhW t4jfOvA2Z924z2oewHdkQvgbQ/hzVy+h8Me2r2v+8IzQg+avYTxmo2gNL3UQeYTS9FyZReO9ZFON jMEshOtG3I5h4+WEj6vZBt8uH51oAbF5IPpJZUIRG4z2ydleNBLxfmtTZuHXW52CBEDN/0neysRf VDK6nCFM/BeaJM6iYhGwkB2EoTgV0mCcXuigLsKlVBwcAazUZ/oqwIVmlUF/+PwqY/tTbnaW6AjF SF4/ADkvCEeRU7HbWwLLIpoZ5D1POqC9gPO+WAWalXVqAAVIE3pZfav1siQuJ1qIdtnxDI2jzlrf 2q2qb0bhKo3ryqRtzsELZ4wNNzQxN/opZdEVn78l5PWV5SjkTgbnFruRVhSkBIyVDYc6S0bFVmTy 9mBO8SgLFTBRF45hz54/Q3g4tHr4knSBFRhyNSTHybI1VeeI1uITslGLDtWFcSajSsEPoR7f3mXv /v6n3Rl+jEg05Wjq5psa7OTXP8b1gg3hIP/ZkxO2/4abhMQLqBOIzJ9e9DWKn6yQ8IfvVSBAptdb P8W+EvzoLiuS93V/nuXhitxFuFFqNEn4ol7yRxEKngLhY7IIK/ilQ+MIZbe5Y+cOTv4u2viQIsoE vupSpSnOlQ6BRBk7a67EcfKMQLe5xrd9W6bQ/F1KaP4k/LUE2749vYHmb7QtivBHCDO0f52Ds1aH +5ipehyadyEQwpg72baNFMOnCoxaQaz0+vlZixGTeGFy0iIcltKSOtkENEcw65e8WYpD9DWghHVZ I1vOxwUJgCKdCBmk0nScdNgpXCHOEnxrdCs2ogzS6EeAI3MSKGJdQKFq+GDjEiCXTEjxW26zxf/z /7Il4nIu1eGsdqN2gF4B1UXIMiop5EVKQWW8OkWAqA4SZyvWnfMyu8UIRRRfQvTSydoNpnLsTpaq sAfTrAlNlohpHZ+esIoo4Yp0AiRbUj7+jRPS7YbDBwnp1uxuN+TaRQLEepI3h3+s5+3839GkJrdQ pWx95y0hWB8p8q+M58wPibSrGvn03YhLoKqKamz7sLfCEF7aMzaZOKEdhH/T4SNNlIow49eSAXIk vRrFPjCGrWgMP2OIX2hzWLCgxZna3MHWXpmdeOKEbd55yA5dSxhOPeNPrl3SF32B3SSI11jQ8JoL juwcryCvnq2ZxGP8L2VKgc+nQOsoCWCFw2eyEqHwUgl20DHXUcj8XhFracs+gm++nq4t1t22xc6+ cdFufuSIxebSNz3zg5dPrspZmbiw+4FAN15bbk1y8hxq/tj21YGPahYxofA31oqg2Inwh338ZoS/ Np0WxjvCZWwGp/juHJvHgTr9qwisJZLHovgkZPE9Nj9t9TC1H/HzdggaO9lvUoyWT7V/A/NkMm/A 04UXM7uKIgecjEEiE3+ON9Z3O8AjjtBkWcoUskPpuCGDZiWqjaanIOETKqyKOlUTRrE3YI+4e0/g ZzHMtgGShkb6mfXaAMBlrxahiEmIKqsOgMj0sRw3MNo6iy1VMcHi0DdJqGT2dV04PVjZLi7MEfZt 3CJobCLYbYWctRyohMbJSx/a3OVz9sCDDyEtMBVBTLnd2FAqUn1ylSFsFy9l+CNX5g3f3yAt8sIP jgLQSPemakejUevo6MQlzDTbvIS24qYEs0p8A7qWOU+YcgnTeKHf9v/547bzz39i8V5MAuQjTTMh MCPAO/v6Bet9Y8C+9MUvWR2HR6TpUei/9C3ajKbI+LEKEbzMgpP6WyW359PzXDy92rvrepYnDdcF O+OlfAmW8VJeP4IlQyJridCo/eSeRCYuUU6J333nMXv/zbOED/SjQXmVs5BMckUUq44T77eS2L6y +Yvj5JntXBY/bvPXjO9KtNY9RAJReLhRhL+LbPumC3/zaM0vEht4EtOINuwCO9ki9gg6hRRklbwL uDkaae62/jpO02PXGqZkE8BbIR8n74WZfgu/w7qo6OvpNgUJgEKREjbWgy5fCgewr0oD+SiYb7nW k4+6JEbaks3RCRQgooApqvkvtAnudyl1ez2VCN4JK6D6rIvd8kGtyqTXIp93VuYJOIgVITF9VdZy 2cawZMZ8nzlWT4tBEIEut3lCGMbGxwmBWm8Rbbtnow04FSc1Rli3D5/7ezt260dsD37X5CJEpy4J iLiyEnne8ebwjzxfWHc2ej9lLWWSMOWkKC2aRBUKQJKot4Swdmzxqplopqdwa4GgpmgdftYnZLo8 CLTEQqDhYr91Pv2abX7udaubHLMZTpMLvpyKnz5+3l5/4pR94bNfsQMHCQHFff6zjbuSc0WzYFwu oAB5lHFFlrBtVjwozo0QfNAqJaoLYAP4fJYIhVNDsFWhDfTrfKgaw85uAY2b8Fx/w/X4c6yxgUuj LHgLnNrzQUaeWCXbt8RGb57iZK80fwh//Ztk81fpmj+d9m0Yjwc2fziJ1rbvpoTmbw6h7wKxgSc5 Ldw+EbdNvK8IIdJ4FyNpIa1Dd5Py0MkWdVVCAAy09EFzJ+WXgAmKgfZ/EIwUzYKqaAxypiuoPAVx STj/O4YU/oIQ5pM5iUcNms8L684TdtDScUOyLl7G0tQmXeDwMSedHmEV0+9t4DqYbOhMpalKqr03 0iSJskk7pzi62hrT0kWndCO+9ZsbuCZm//MT02sQCvjxvgu2hCf6SrStFRL+stEFWEuUY/bkm3b6 yR/ZFrZQPvXpz7m/Khnf+6S+zu3fNUpYtMcZ1cr4UTQUVxkQPJCbDVaURf0qsMDDHhCb2m7cPc0S wcO32tKdTq54M8cN7PnGt3Xbxduus1PX7rcRJspaooxUVVXa6dfO2ZtPvG+f+fjn7M677oR/pWFe shn+NNWnp4ymyPiRnmtj1yFPJyfPjYHL+XaIp5B2yQksrwclIhi4NSYn2atkaLAFJX75LF4OxBed 2Kdee+gG++Dli3nVfj2ZFhAsm3G6vOmyDnLg50/bvk0S/pbc1Uvj6IKNaNsXzZ+iHEn4ax+ImTR/ F9D8TdRGrJVDId0IfxLY5CdQYeRkvVCMJDddM7OzRE3TyXvGXXCo7ybB+3Xwq2TNUoyK5AkjvU8q hnyhqSABUGRMCRtJkhaKM4/8V7GBNOoUTrc86hBmoS6OgwGhVCRLoAgqUsLKhBXwkbqUldlYk4gC 4WQSQzhTCC2VVgc1crllUWvJUe+mMyft0AtPEefyiv/W/awJBItsL8eI4rHIALwwM8XWyyyspC6V 1gbAlG3Xuad+bE99+99b1ZUL9o2vf43BugObwURYt+WzelaEuW96XcMK585WhCfUax2DTCGIJbQ7 +dJIWMj7heUtDInOYDgf0Q9aW1ustrrOJoen1jV5laPOm9rUZh9+6UHr/fz9Vr25jYgjFfbmL0/Y 20+ets998gt23/33+5azfP7NMtnyPyjAskq6GYITrVR9MkSYaJvwZwm+1SJBq5SoLoAN4PNZIhRO FsEOOmYJqBSA9LCcXMZZQUozX8lBv6M3H7XLZwZwJcWiQT5gN5RUiZBI0Iv/jf0jtv30kLvR6sf9 y2CrbP7KrKd/ziT8jbZV2GXZ/DHmdg/OYfMXs7kanERvDjR/LZg5bOZwiFwe9SMQDumgVKJFNlTU BJQ4ztXnF2bwqdriAqBgymRCbe5NEuLSjd/qFLZLinrh9FxItQoSADMQpPAXgi+vvEk8dKASoqEs IReE33kVr6BMybr4W6WpTWoVIBV4QcUrOHMw2ahTFfxqXi+EYIuhEFNZYzGis7hDbgZKfi/kEGAW 0fxVz0zbzT/7od31139s+199gfIysOYgqIYUHfgor2mw6rZOlDTYGE5P2uwIgiNCpwsyQNCqrP/d t2yEQx9bujrsd7/yVTuw/4ATUDs3OplZFFoWBUjuJgrbxTtkiXHlLkUxn9BRCu4rstUMyiDtgmwB ZzgBGVfc1Rx8krPEEFR2gLGuZqvY3onj77g9/+PXbODEuH318//Q7r73XqI6sIWGTdUs2pV4jg6R bBchyviRE3PBD8LmdifoBb+d/wshnsLbJX8cmTlLRDCQaExOsleJ0AT00vIyOAwiW8BrDh+2Lk4D d3/nx7bll8fd7CWzzvn9EtTYbB27Jk1Wgf20hMmK9wdt358Qtegn37FLQ2/baZu2pckptHkKi7lk Y901nOzlYBRj3mYJf675K8PmjwMjiW3fHjSHEv76uOeaQ4RXjw6SJFZ+5cuWS2PyzOyUh/2sJ4KS BtaA9GkN4N0+QJZ2Nxu434p7oUKu0OEnrFyBRyHTBbIitFhYihXfV7GBxAX6K1l1BBgEMON6G2kF eZbfAEUwGOhBCSujCkiN5sgS9Vpelg3/zqjMhqHFEQClAZRmbnEh4rZaotDKhIaFQS6O3cgCAmPM T/GyPkoRNvMVJwVtSt5yDLArtN0QJ1QcWzIzCIGVtfVW1dxmYwO91v/y0/aPvv4PbPfu3bZjxw7n A8VulAH3+iI4ZhbFi5irnJlZN/TLh1P3d1Oqtqd4qocaKHsjbaj8K18WEtUl/xSYQKjxl3De3WyV lyttZnLeGnAMXUiRNXB7bGr44Mzxi3bihQ9sd/ce+9g/+Di2ofuYdCvh14BHJPyt1ryZNoCFlCL/ envOsG0KI1neSHx4SeYuEY+p6YLKBE1fKnKViEZJ8vhFMB/LPlQ2xBW0T0NTo93NmLTrB09YxYGt NrJvh013NPlJ28x3c//yxWtZlY0N19vc5FlOvF+ySxz22HXqst308pu4OGq0ia56u3jlpGv/+hVr vaHNogcPWHvdLuuZxSHzAJFtpPlD0JsgPF0bB0a07RtBU9mbEP5qONG0GWfSchxdjGbQGml8ZsRa cK4v+z/BlN1sCDvgqMQvfZWyjbzDFqde2VsqVXhVRejUfwpNBQmAGR10HcjyLVxQEWqkSvGSKlia FDSQPkNJuth4MhulNERLlZ2alI5YThqBV0dzXigBrmK0dzqV5zkEEpGYNTFDOKx6mQdnTeUMTHEO abz6wKdxvnvM+rftJF9u8Uw8s8T2r+IDi0PLtNWLKw/5W9Sd2ZER6MRg9+tn7eY9O9nOu4/tvOBU moS/WQY9j7hQLBqmVzprDTd2U+D15xpRv9gYvNXfLhZRVsMCDmfk1fKsfKaSwSome2vZAjY2N9r4 7Lg1lAUah5VvpO6on/pihHfnpudt4OygvffSWQz36+2Rux717TtpFaU1lmG/FghrCX9qimQqUbv4 GCZylXpwCSsiIl+VVCKCUXa1dbIaJUKjdhEW4VmSFwHcwQhV7c49NvQctno4E49X414oWZAcRNVz 2UmziJW2b3pi2t5+7oQNfGjWULdoHWyn3rTjWtuzv9Yajhy1Rnzrfe7I9XYXi+tJ8o6NDFr/yJi9 c+4dG/r1cxbpOmg1e6+3S5tqbIIhr40IIVv6CWrJMfnLneVo/qJWi9PTLWwF1yIYLlARaQU3lBh/ xyaH6dKUlz4kITa1MEqDDJqAYonxLO1RMS8rOYQShZYb3YRfq0xhXdbKl+t5QQKgSCcGC9IGGywE k/U7gJ3ClTVTcW7CKKXFk6CTemupSAZcgacHJxi/OKRZAcU7qSPiUckrswJ9vjecFmRWy8p+qpVT us3DoxZp22yDrA7LQmv+LACv9Gy1oe4eDJjRFuaoooKNT02M2+lnfmq7b7vHyloJ/QZtAsrgjBSf izWswgffetmiV87bo1/7N1ZdhX8qyiLhwV03aOs3C/713FJ9wy3n9bxfyDsBnmKVPAtmr0yW+yW5 pRYrLOmNVDcosxYcf88P9NnSDAIgBziS/cLbJGgXuqVPrtoqHr44Zr0fXrZL7w1ZJS6Jrjv4Ebvl 5tts27Yt2ADW+ingmIQ/GEV+IfOZF5MkyydzYdVN5g7avXB6JQHkeZEajUvHY96G6q2lQ5GCXVKS hRUItoHV/EI3u2e//c3N19kDX3vEYrVadIb59Jwc+s8iw4uWuF7COeTk2JT1nRuy9185Z834N/3C ww9ZR1e7NdY3WkNjs0VZ8ETn7iBCTaVt5cBbD+q1OIvZBfys6uDF3cRFf+f4cfvVU7+0kxOXbOtD j1jnYoN19cVspPeyDXZV2FzrTpPmz4U/fAjKVUwdQmA5Z/XWmyKUo3xm2BanR2zLzm3ejwLhTxBV y6D++kzyl1dez4ufqlkdVrPYlzCtvo9cjSqBUuijaCm9TQOg6+n+BQmAGQhS+ItWpRBQgCdouAyc YYaifYsdArYoGshlgDLLXxqiJVcBQiYmKyFzh8JVZr2WVXoDP1OtsX5aqfqasGY5lDEzM2u1DDiV 0gTWxWjt5BCQo5RoX9gKziX86SXFa60mkkfZ80/b9O6DVrf9gJUzEAYakiWbHh600fdet/63XrUv fewR27NntwuIKHSw59JwVDzhL6yEt8f6SRaCyfkdghavlartU8hLyMBJJOBYJ5pgcuFlJp6G0VGr GJ6wxeoKm9whW1AWYZLy6Ydz+GObnZolJvCUDV8YtqHLIzgix0nu5i320aOPYBKwx3q2brVGfPyJ X6UZnodJwlPhIc2TRc5yEeRZZ0WywMt2S+2tdg+EwGw5inkPZKWtTgDfCRdQr5ilD2E5vcKKlAiN 90MNyFzoEIgfckPl1LFrl52IVNvN7a1WGQ34Sm1Xzp98V06OTdpg77DFJxD60OBNETEjNs/7c4vW Wttu99z0UbvphhttE+ECK9xBObUSMqSZJRaycl2ln7KtjrqKC40eixcdjNq6udv27ttnjz/xc3vv R39j8527rHcU7eB7r1rVgf12yzWHrfPSgFVPL9pQu04QR23XJDstCtG0nnbH7Ut0asiq+s9bTS1+ COtw/ZygyQJ9aQXpwRHOACuehY23gW/tDODFybX4EezKZStcLsUMjSMn+nTxoqawLuuiHSUpSAAU 6VIkXU9r5Vv3ALY3kC5L0VJhUYAt8KWrTWIV7x0oRFrk77TCB+2TdqOYqNSxRC3VxSmm7+ImMbTm z/UmLyIfGvCGhofhcE7abuu0JVa3Uw2EZ/Oyrw59NeFPh0UaWOne9OSP7faLp+3pXzxmVzg8cjca wcnYnL2MdnCUwyA9dVV27JFH7J777vNBQAba8xjzrzfax2ol9io5f22AcKshCJ85eH0k+CC8X8Rv F65KXI2wuOoryQE0vJnHt4rn5Ob9CBNXLTwxOIKQV40wyNZPHN9sQ4NXbPKlKYzoF62GmMCtje12 x7U32TYEvq6uTmtDa1xTI7dB8Ls0KTC9YkHLLKBQ/k/RrHTt4oNk8JEHhTaYpcTtH4Dns4Tkctjy cFzSulCBBHx9+SWMuWvnDtvSvt2eeew523ftHquqxq6Z8Wf4yohdfG/AFqfMaqprrbGuxVpqu2xb 525rgR+7nS/bcXHUbXUcohA8CVHiz5k5FtCYyEhzGPJnjPqJhEqYWfNHXF/ioB8+cth9Zb744ov2 xptvWw0Rc7Zjj/ju5Qu26akn7JoPLtkHR2+y3o5dvohSXOBCkxbccsy0iJZtPjZrVZz+rSU0p7ST Sjpgtxxq0Ny6y1/QgT1vMT8qyhMLJfr1LL49hwf6rb1DUX04SAPOcp5DziKkkPJhPYW3cLAFCYBC kCTqOpDlXTyHrcG5tH1UtQkEJtWqRBVKShNhbfKmQt4ZfRITT6t1SlSNsDDqN0rOC4nr4E6RP9cJ WyswxiG0L/PW399n9W2E2WqqsekoBzusesPk0SquipNmPcOsOunJQ031Fh3rtaM//B5Gz7XW8tkv Wu3Dj9ouVs8tBCOvZUWqCVohm7CCKTKR0sCVELSwpMBLuIbX1tk+aSXOeVl8/Wg2VKpAqlbZcuS6 p7c0hkujsoQ2D8t73GIsEnYqMSFWLFlTy1bXoDSzddbR2Wk6lVgHL9TUEv+UyUD0E19oC02TleZA vV0oXb0G+kiOM7lKvf77am+lQssWvPUb+JnkXVUs+aPIBVVbJghXIjRBuwTlF+/EGGPK0TQ1cRDk n3zjm/YM7qzOvnLWFufkrLzC6hHOPrL/TtvWs826ujdjk1zprmPkPkYRbqrYtoy46xgtSpZcG82a 1X1QzrHFG+VQR3kZjvQTjJBOOeRLxx/FDrFSYd96euzBhx6yo7ccddgXe/vtx3/5l9b9s+/aThbQ Q51Q/pqd1sNp4fAUcIJaa7cDdawd67NK7fC0dtllFmEVO7ZZzabNnKyP0JcoWS5mDQudN7K1i5Oe I1xSCnwMk4+zZ8/aNAqCbdt3+mIPXaCHiiwW2wXyC8jCeqUXJo/rggTAPOAVMUuJes2yEup06Hon gmWgcv4MeG2dLZQT6soHXhehKRFzBxgFvKQIUmiCq7w/I7JroWjy9dd7+TzGxXGrZwLWYQxt63ID WMvaIcut1RBGGOlG2tvtpc99wxYP32ivjPbZHxy727pnJmyBSX7zF79iEbQ8vjMCoPn5mM3yZ4Sf yzUmrYYvn2dXoTWCYhRIq3zK/tuaR1tuuD+zCm3f1tdbExVpSDSwwg/uJcrL0aNHfbtMWr6QdHEk vXkkPpSEzomhMmDjvHE1uGBZ3/ltbTxR/n+WqoRtQH3w/uInaisQwA4cOGDbt2+30QnMDjhwEUEw qmObtg5ereBadsyeYDyRQlopCU7iT2midc9NpbmQwLeoLUzu6S9M6TwbPpOJS4xFjQKR1IOrgf6h /vDaa69Z55Zua6++zV740z+yPjrAzoEFqyc2sJ/FSgccIsjxrQN71VOjLMRnbZot6Vk0kVFst7Gl wLcq5UyUP8frJb0txSTFc5o1cFhGi78Pz56zckKEbtuyxW3SKxkPJFj7tj2lKVbPLYCESRoUKAAm 5FsfzdaDLol3jYtSwk5DLTTUpVgNkAY581IIJJmUqFreEQVfKfwOfhX3M1H+AEWJKiMieVUS9Smg BiqXJtt5om4Mjw1ZQ2c9WxapcsalGkxLelLLFt0cA6YO0eWVeGkJAfPM/sNmew5Y3w++Y29zCm7X H/5vpoGpvK3NO/YcI4EGA60C57A/rMImp2QMoHp74fOtRF41XZkJ2gaKphRNV2ba2B21X+k7ZFjG DdILMmjrNpIos5cd0LL7iaBxkc1UfAFH4b6tG+DygT9E//+19+ZBkm1nfeCXWZmVWZW1L93V1dXd Vb2+fUNPenpoQwhhHBgZhkUCSWgzkrE9JjwRxEQwE/5nggnHzHgZAgZsBQZLYFtgQCgQWpCQ0fLQ vr3Xb+19X2rfs3KZ3+8799y8mXlv5s3MewrpzZzuyrud8+3nnO/stCV738sVQFzrRcuV/dANcTg2 AHXHKbCgB9OL/MPSAjZZYeOzRysLg+69M9bj5xk8bsMBY290FqdrDMDh4zQDP4AgsoxiCfujYvgU NwaC57TgPZ/1HX70Sh7wjjjMP7/PCW/rgxUnSMDQMdKhZ64fniCHPjmX8N6HHpMDJxbkuYkp+cu/ /Zo8PvIV6T/zCklt7EqW3mvMUEF5vTk6I7uY072OkZ0caMtjz0w7tqp0h8CyfJhPbrRCLnaRyTFa rmF2dlZWF+/KzsXzUh7C6SSj6JCgPCBV7pdIt1rlFkW0ARPxa5TjT2vqAkZHDqBVMC3Cjfg8PgOM BG4jhNDDa82hPaSPk1QZoKJ444obwPWVE4eoLuOo0k0h4hRdN2ICbdYm1zAfj1siFDAPj3RSzaUK 9vhDhmN/rw2Mv4uC0rRtbWr7tc0V0dMoXCenD8uFS1ew18E0EqD1jIJ1FyWrZWHPlrJa4bSB+T38 mfxQQqzQnOpeZdChLrqSG6szy1VXAExqgNAhJ4LwyKaTt4uGxSYWgWxubkk/Tgyx35iIWJMKScKK oqmm733Qi2bYKEpivCeJzPAM7IoJC/wc8Sksei/v1Nl0hMuIiuVxwCkDLqzlwObkGIpl49fKgkyg F4/TDeikkKQ6sgIPgduGSHis+0ig9UE/e3HsKnb2OL7uNa9BeygNxzQjb/qlD0j65Gflwx/+Y7nn 8JQ8npsH0du1POKB5MlMzDe6qKqOWsyvG5nQUZa1jVso5wd0KJtzFe25v/VUNT559tH4OoFnyoen zzP/8z6DYfXjGIWS8xdl9+mzsj43K1Ozh7F3bBZVFIfsoQ+QwylCdSzGoYWyIStBHcdJF4jTkQPI dKwAqBTdDwy3bgKyDXG4AV6DSgSs0PBPM2rtS8J3jjlRIyDJwEOr68Eg2jFuKk0VnMHXLkHH38kM QociC3bura2sYb5KVg9E52a6XF2ZKue0Z8YAr/16s7ZqL2LepfrM/lqr2O9vaHpW8wQrHDuJn1xY Fsw1+CYmkrjRgIBqr2GMm7CzeFrRAA97A3jvIhDsfvBCO04iz1spqNV6DxzaYXleYoWEGteRqELE 78bGtDhRxcB1II/KbAj6JF4RfrcCI6EYFszcvC5VzGkrYzGD7vzeQJd1lwxfDR+TelTgZMVlDyCt 2BqdIVyf8MPZLnT2THndwFR9koaPzY9qVUhj6snm72FviGIPP1zggQ47NII4AmLkwZ7JN7/5R2Vj a0f+5OMflYefeLcMZwvowKNrSjygG3IrrN+VPiys2xqZxBQe7q7KebfsUSxjmLkkWziCc3NzXaYO wMHyAtNGBeVDobeKFZU6/nua787urg59sy7mUHgR19LmhixhIcza9rZMYg7mMBzXDLoKdQ9EEAdR dRaISP97Cclgh6EjB5A2jUaE0VDt0iHKGNGJJ8CTdxsjYadRPMi8dCG82Nh8BlwhocB8tcQmq5uI daz4D91AapemO+AsRDjpNoszJtVJoWjgAGprMtj91w598DsMP42VnupY475cxAHsWAF86etfkoG9 VXnDD/+i2g/xMRP7lLtSd5A27555060RhyB1+sqt8Kgj/iWFxde5lQkBY+i36b39ntA1KfrbkWPc mH3A1gsKpO1bXZb01avwOPqlMjYuVW4L4jkWPo++UojMf/A/J3XDOkzZcYTGngVMDhpR2PqzV+60 zvfgUy76HBMoadjBUHAf/zBPr6zOA4ZrMTzKBShv+fG/L9evXpBPfum/yKsefIMcGJqFg8e98zCF AvMGB+5exZzGErZPycrm5AzK8ZKsbS7Lxu66Tu3pRy/a5NS4jI6M+s4jaWwXYpLfDkzL71xEo845 6wRMC7pWyMuRsZwcw4lBd7ZX5MZLa7I0PCRH5k9AFjnPTkBZh8R1GL2J5o4cQKa2rWZbuTZBTOQF ixu/bZMIxFAgmjtp1N5NaKQEXhK8SxS0AsBX3bjmhaiUl15NL0quBm4v4qIT2IdCoxbQ+lKiCbUz uvWEDwyarN29KZuXX5KNW9dlE9vLFHCmyOlT98iPv/FnZH5hXuf94dhWnTjt0w5UvDd5pjO8Ndpj 3BkkiitG7O6jQIauXRqqyZdf95S2TVnTS9uo3UWg7j29OGcIiHRkpkPb7oQxdTYsP50k7CZutwYA mVex0rWKHhfuV4fuFbxoznfGihm5+Vs35IamsaDVCEJjJPQSwuKonMOgYiKaDg1ZqcIPF0txWgT6 75RKLjJJwSEcHByQt/382+VDpQ/Jl1/6lPTt9MvUzBTWy6VxEk4R6sN+q3AIb+2uSnkdm0gXt3CW exkLKyaxuG9IN9cPLmhRn6SNHDrloQ240M+UVx6bAXIxDsPK5qZs5fskO4SV1pDFHEaPdtE9+8zi kkwePOw7gPjUWQ72C0sqB38qY0UZ+6cjB7AL+LEJqYuoiMiUa4wU+T4Enw3/JmGkFi6uvHXJFmET h0WZMCdazACHTjHoEjYLAr/5gPvSHok2QwidgEz1ZWVnbUku/vVfSA6rfGfGx+TeQ1My/8SjWGE3 L9OHDsvY8KAWjNzOA9M+muRixORMWD47LHSIxaXqWWG658RnyemNf6SdKyy+IkyV41pu7is2YnDP i2mM+8LrTDu0T6zEL2EFLBfg6Ex8ZozGAPDOqxbg9H2/EBIaSermWVkjLyh3HKGowVUEkG+HiLxk PnvULOco9rGsxMPMgYPy3ve+R5awUOLa9Rvy3LPPyQaGSgcGxqUwsKDb2mSxkXQRw6bDEwUc84b9 M3EKCRdaBYOOvsSUg6YkYSQm8YC5l4DLHk6OGtGel+7ckhH0/HGxmC6IwV5la9tYIINGyiDmkZN2 nbvYoWxJOllQNjpVjMd3Rw4g0/hVQJcep4e3zcW2aNtE6/kzJE6hU3h+bu0ZaDMAljbE4yrQAriW XnHwR03CCTbOzTCsKFInONSWOzToIMfMTDxP1QbsEYozWLERZwdK4FYyxS0c9/bpP5NHD03Lm974 k3IEy/i5X1Y/DhrnvlrcB47lGOcYYr6/2TbBIrXXOp0YydlPiV0J1hHoehoh0w71Up++/ZNj8DUC IC8WvC57/6kStUIy5bJ82Q/lg4cqh/B8pmqiTPJOddKDEXCqRwpbbpg56iS2OZi3cGa1DguP05yq wzdUvMrMDJ53mDpmdOZH/seP4ouZrMNoKiaDpeeahdJmdchN8XFICUZqUjhBZFLGxyfk5KkzeO6T K5cvaxmr+2wi/uHhEZSx2MoGcbmHpg0s52kqnUiYsiINPTNiiWi4cvubHH7Y+6d4FBH8GSwOpG3T +dzCUNG1zaIcmD+p9QnfM66J3wCw1SOZR9DU1D//Ogw1acZIaOB3gSUG7LooRNGVROqgxHjYB15I BXgxm4K6xAczcAnek6af2ayOYkjZeRTQor0TKKm459Qehw9y2BPKlA5YZYVF99whOkYW447t8B6x eqtfXvrCp2Qeffbvfuc7UECNA4kZACUkrtriflf4b/Z0IvTQHMzY/Pv+Dyxo9oeTUEEmLEDicMsN oRsTdIsnhln3Ljtlwdh/78CiITAf96oZtZ7wzGgQmwjRRCT0xXVuoWPmOqgNKxLT+6vOoMqve8xM zq1iKlglwpXKhEnnLovVwlmUuxnM7aNzzni8cuUwh3pt0HIdD5q3ArqMTxZgIzLxJhWIGxtKSA7D 1nTy+rSHEiUmGk0zh+fk/AsbMgUncAgnl1xYxkKl8Wk5MI0TqkAI0+r0yI6JsfkRiOMzX4elIwdQ CbXJ+ZCgAC1YvWrmBXPO++m7lFodse0f2Bq1E3bbx+4+hit11FHkI3EnOx9FHeLWDzYzb25tae9f nx5SiQm4PGQ8jQUhrZPrV7Y4N+7ektWbVyWHCeQ3n39G/sGP/ZAe5cMWqA7zYp4fAxd7cKUnne6W HbzdMGNQxP/dDxygxlTOcSQZn/TGmIaV/WHIPRZWbpCXY0Rq+27VUlOTY16UDZuZa1gTvfNZ0Hom UdA1YJ4+nPYwe/Sra+ZQ/0YnNdaSuCPp3P5kBw1o9pWlUK4WsaqXJzgxUG7rG+uytrwuI2PDcAyz cAKNu6J7bAIAy+tShzo0bmzyrjldsRw8QD2JCg7r1778BXnqqS/I3Ny8jGJawlRuUIrrq3IpjUUt A0Ny9Ogx3YybDiDXKHWlPsiP/NCeu7WBjhzA7qhUfXb4Y7Iof7sSTGxsRnSxo3cZ0fixhqcuQXzv JLMK0e5G+5A8eZ3MAbSSZaGxubGpxxlxvgWpK1dwhmU1Ez48GyA7jW0G1i6dl8UvfkrGhvIojEoy N5iVU/c9oK04rurSYV4AVa4tUvscgFV/q7HrX7l4Ar+uc4t7+MAANvajJ9u5V6Y6JjPARBux9uJC 94TpGr6Hg2jcWrRb6GSDgVisM6Avkv6BoFRWQORWNUZervRi5AQeDJpEdW99N27FxbK7hN0V2NBm UAdwfQN7rJ6X4bsjkslzD0EeQycygeFizgWkFjnVh2VzZyFZjVjnj2chc4j66uXn5EP/97/G2cRj soujUY5gytAMFnxsY6/D7akJOXr8hG7QTeePI0lWDp3xUIvNqU2lCg4a7YKtzhzAGs59u3Nl2PvG wMsOUaeZrTsBdGLLwbg8y3Jne0duX1mSiUMjmKOHMzK5hUuboouHnF8++y155OCY/NwvvF0Lljur m7rYw3bT123xsj9iiCc80vK9RE88qv8/Ess0RF4OzFon4OXAy37wsD9ZEqUfV4E4KgBs/euaF+ME GYfI6mYY26TwnOJCfkSd6BJWjxRxss7VjWsyhhM1sjgFhMOt5P7vIlAmzN159Pxl0fXH4/W2Vlfk d3/rt+Sx3JYcwlF8//3OsqzCcZ0jodj/8NjCCckXzPQkpiffPctWh6K6kwDJ+h4MRiQ9CyYWZ+6x OG/9x+IzoUh+M8Ox3LppFoG2nZ1tOTB5QCrFlGytYdsArP6taDHRhn/sMTWBcxu/e+2G/MZv/7as rG3I6ZOcpJvVFiaHf7sLQfe0OwhtUykK6sM1LsB3jIJOxsvH0fDyiGOZqX04zo5tbTCxCPshLGvG DoVmQTtnB4hYwfjlcmKK8AEpK875IDrTWGLRz628hoeG9Szh4t6ODOXHZKJ/QKa5ETTKap5ZbLXo E7rPNxzuHcCSXzp/nPO3idXLv/kffkf2rj4v//ChAxiyhsMKMocw3CunT0v2/vslj50k6PWR+jJ4 4PXvMkQ4gOCMe9iEGJVvB7xxRr0BzorAGYp9lLqunN0HRvbF0fT58C0hcUkShY+mA+hKERLmsbQ+ y/kiWMmrhUQMUrmibPqeB2QznZMv/+1TcvPGNRnMYUIyegbp++1iwkpXLmA3jmwHPGvUboTVKQ7E 1+LKMS7H4Ou4do+rVo7VIU74QU0sho33ilbl5V5oMDS3SAhdMYTUb73KyE8PfahKnPJCDHSawI0j kRGs4cPnzPFNvVN06NAh2drdwFZe2zJ656qM3LgkM9BbRud4d06Khd6ruLjVyyCdPx327UOHwZr8 zm//jtz9xmfllx6bkTHs+3droyj5oREZwXB1BZ0LVS4khDTZYRe7P4E2ChxhvlgSOg93AKslyWAp dgqTMOsQgw4rwM5F30UK8t1FsvhJ9okb1V+vJteOK8yjcI0iSIJbxXSkd8s2W41jY2M4BH1AijhC KItMGHfyFcvpVDUtpTs35F/+2q/JK1/5StRDZuk+D/dmcMxyULrfk/cptDCsrL8nCeyIKPecKAYU 4M5Lmf0wTGXGOSfQoHu9GDNxL7T94oT8uMJlpWSt2D4bGSb8i0KY8zI5p43lMafejI6NytDosCwu 35DixqpwM6/pyQndhsvOoeucCi7O6jyVTZHFkHsOzh9XLnM7sBfPnZN/+3/9K9n+7mfkl39gRg4X MGqEqYx3tkrYK/YQcAEZ/uj4lfCjcxbBW1udMR16O1NY2MhrM9FtIViSI6/NcwC5z9lnPiXZP/qw lO9/WHbf9T7sqj4IAGbljL9+hhrqQYiRFPEDPBkaQgwRtQTT/iMnnxKfK0Y8Clx3zdEO9qu7FKIy 0urd+KL007FOQArNkTY6MjIiWztbajs8Z7Fc5qoyFVAUOn3fh96+5efPyhy66B9//HEMPWD+IBxK e7qHgd8SRPhH37TcyUsV4uMJJyORt8yXDtkgjSYrOkaiiIjLrdAIXTlxjIfsOA/kQf/cYmK577o8 NlqHZrrO1DFkQMUrKwZbjBQdR7E7SxiZIbmjbGPEpFg6pjF2AhYsXj7hligVdE3piloM+R6dOyIX ipdlbTAnhyZGsQpkSnWndHXIM7lQTjz9xKYPEalJdjxmMTpK54/P3/j61+XD//635HjxpvzMI9ja pcBTPsryzcvLcn1rWu6HA0tHlcEuVumE5L5bt6Xv9i0pY8uY8izOnA8GyKvXnVKaHUBMmE+/8Kyk vv5VHM2yI+mfe4eUBwqg3njl7sw5wJkqpxMxBdJ2dLsfOIIEOcZnC+kgyoTv1QGgEThkpdOMTVI4 hMuVv9whPoXh2irmV5DMNHrx2hGbTmekuLwkV7/4GfmFt/yYDMH5Y6bdQ88fd6338i/gdB72Jb+A LFV95+R1loJIXCrep8a91Nibqaw4RkXw/HOYXQCcjeV9CEDimhfDh2NuwATzNHlxGVw3lsiDSsoh I/WagJ3Vv0hOfA1wWf6avXOrumL2xMkFHO4CRrEohIqrsieNcbqgQFN1ITOcUCf9WPCRhlO6hy1r /vzjH5cv/ukfyo9PVuSV9x+UYYw4LW3uyh9884ZcH5yTEw8+hPhwsUAne/8YYtPLshYdEKn1FRHU TWmsJC4fmkGFxlEtA4u/vdpYswOITXT33vSjmD7VJ5WTp6SClTj+LoUUWheCq5HbwR0LaOe4nCMw DBNNQGkdSKHDqO6RuO7M7EZQyI9Y5lHTZQabbfIMX/bg8Zv6LRGS5PYvu5urcvZjfyiPHJ+RN7zh DYiPeX9oxfXq/NVQ1mirvUv4zr3qDcHuDSBhwfwdgfP0sR9qoX3vg4VpvnAtTcOHe27cY4CkWhU8 CQlSUdDI9sPQEqI5Dhiywy1SbE9bHiM0yiZ+6ISyN43PXYUulM/eyCycP9YNe8UN+cj/85ty9quf l7edGZFHDoygZzAtd+H8/cZTN2TyVT8q//hnflYunT8v12/cAA/wpTqlF0ym0JlRnpnVc60r2PqG p1PZ3sSu+A5J1OwAYh+eyvyC7LztHeAY56eid0QlzsQUvid2Eme6UruaGh9CSvCV1VDXKg4Ci773 wJMn06EbHbXnLy5ZseIikcwdLgsegCcKU+W4YMoyEw8294Fi5lSKwDcz6PbWNuwWa3+xJYztdjcx Gn6xUGTr5kV54TN/KSex998vvus9MoSD5Ok48lxf8hmPiga4DY8mz5DIJKA1AOdjQnSGQK5/pXgc 8eBhqsncLR6DjjisvdWz2vMTwGq5QhQO0Sh4X2gubQyYLB5HIjMy9/D0rIBoAH4dxnKSPLkIqgpg Anx34lIkzliwYrHVidqzfZn41etdhDrs1Axqhk4g8dv62R7/1i161X0XjdiMnljC+iUtf/3pj8sL X/q0vO8Vs3JsIo95ieik29qT3/zqTRl9/E3yrvf9I52LfhXrKBjKsIFurExtZ2RUKlgNjaEtLU8U oP3xbJc9kgzdOIfNDiAo5XmK2KyGIM2fRz0Vw/H5DCrW1aUVuXvntpw8c4a4kw1QuJ7b2o3UOqDE GEMHCbqNavmwOalbOBHpmDloCxZNRLRkX5uyJ1mYHUKjmRrnDxNsMet2Z4fHfggOFb8ug2MDeh7j npdJ6kthSAwZ6s53vyx3vvhX8vpXPCY/9ZM/LQcOmqN5OFFXe/86pKcpOmS0nzpxW0CTu/3gxuKg gbkLlJXzZh9YMXjc8aFSQu9DFdsVaU0J23UVXPNCum12dcWDwnUnojqyKS8NjspKrU4UhXEyXbBV I91AVx/AgZJM1djMgceeDvdSlj2XCgDo68VoJ9av9kSCyD0syHjqc0/Jq2YHZHY4h82dK3J7fVs+ /K3bUnjsTfKe971fRjBqauaPYw458iOqmq6D8t8CAI/Iu3HzuiyvLkquP9dxBmp2AEmqKrhZGRQd 50ttb27JH37492SgMChPPvlaMNs1fxEJbdEcRkNEki5eq3FDqfznLBC0/XPEDtXFjKnzmkxOcsOO R7/i6iobxSGLzFBm7XXCOX8MzGxXr12VpaVFJMVZjDhlfAyLOfhe55Fw7khDIA8rZ78tp8/cI+98 57uxR+eAxtjD3EFs3p5oMNgdKZ+UAoHB0cxnsozQxgjRHS9qW71ObInJtC1lYkbvLJqasacYl2qB bWcxUbz/2tekcu+DUp00JyR0RmyM2JrXyI9LZkCH5lW3OEx5DwU5cGR8SZpC2WZM/3WyNyYfsldK CwBH2VLBQu++3JJlwoOG3Ei146+xJyvIVvC+UzKYluVLp4EpdCQJ3lIWQ9EPPf5K+fKfPSsXVq7L DoZlb/cNyn2vfYv8xNvfIaMjw+i8SuEEkKLsFPeIsVN0MePjHGU0+i5fvCIf/v3/KPdgC7P5E6dk F+cNdxLCHcAICH0wtK3ijnzw939Xblw4L7/yq/+zHJo7Bu+8M6QR4GuvfS2jZ6v2Nvk7NWqAdaUj UlzHQN1Dgvx4cF3yQWq1YjY6cVl2dioY9v6tr63jgPGyTEwPSz+W4aczOB4HmaFcyZs9LeuAog0I kR148o3yzKc/Jtdv3pDTJ04gLoZ+4QAm1omianGtFMvYPuEBGve63w9eTHVmpefkCjbcYgECGOvg R/6TZD77aan+1Ftl55f+KUZwuP9lcmWNr29VC+E61E9yZEerlOR3MQwYDTD8C9Go/h3x5OuF7IST 0PPbIA4Ca3zuGYEHwMB1aFcBQjv1ASnbEhYW9iOvVdEb92M/8RNy39FZOX9nRVIZPB85IsdOnJZB 7D/LvrA9zB/f2t3DVjCJ94z5XPT1ZXUE9j9gBXJ++rC8+12/iKPnuHixM18stgPIcWZuqfGRD31Q LmC7jF/5n34Vx5qc1DH65I3CGoIrs/blqBatY+2dWkUARLtblQ9ZsWy1S9DhdyXdR+IQkRZnMGrF RWZc6AdwFWx72JZTHhc0Pz8vFy5c0N7pwsS4Zr5KEUNjqUGAYzFcD68KZ2/s2GkZGJ2Sz37qk3L6 l/+Jtg4b43WoipDoFq8reRl1mGENiyuEjCReQe+mde6SF/DgmA0rCsrMmYNGM2Y+IS+8uihfPDWk YctpnIDDBowWMmyoEW+SATxwhEFBE6+jQJmlgYQrLpkXy8DJbTiTZMfkFapEleSGE4UN0EkS3kSp UYTJk00fE3uhWFQHNr+4YKpmVN300sVhlhhMntS7OEn8OHSr9koVLARJSy4/ICdf+Vo5iXc2W5Nm wvZ3jvBTJn+TwqKS9Y01+b0P/g4Zkve94xdkktvEwOHEY0chlgOoCz4w+e9Dv/tB+eY3vi7/9J/9 C8z9u99z/jrEGIc8zxYIuXNVxUFg4zig3YK2V2shWhJ4jNlviV0BF/+VGyu0xGDXA7IS0/LNPtRH 2benCrd68eZXcPHGNDLBhUvnZOzgiMqjtItVU3msCA6lCMQjt4weOyUvnfuG3jNayGhxaOpYLz3E +yImx0iUFcUBmdPWHOKzFXQsGXcdyVZmXQNon9AXmmcI7VN0GANKwPy/tZ96m+Rf9aSksG+rZoiE lWOLMPSNo4xxxQtZ57BWvxRyGenj5F5kblaqJW7HhBo4uf4U8uDQgBu16Aid1QvROUJh8rpKy2je Vd5XuCo3x3qhoKh79gDrvSJt+8MstYNewNIebBR1Tgb5Lhh4VGgRU4f0zIAO4AZhxLpHD2QFW9A8 +/R3ZBejsf/o/f9EDh04ZI6V60J0MRxArLIEZf/5Q/9RvvXNr8r7f/mfy8LCcSwGQY5MtLYMsm84 cSlHi83YgUtMpsL0c5JFnODVlveGC4e8EBFzqpY8XVhbLJ49ecWI20gBtwooIReW8VepYgVwfwFd 9pRHY0wPOL4VlxdlbAgLnrxojNkiRQyq6qMQFv8iadBvvf2oOsxPb4DapVZGkpROM0K2pJWV5k8O 3hjNOACs6tbeRaJwhYbGCq+ogo1yS9iyq68PW2W46P2jgKgUVYzNIXyZbGDxMjSYBx/s/uN+a6Y/ PtuPjXcx/LaLpflcnd9rMCICP7bg7BVgWHrAZt3iTPeK0+hCpcRbR0GxqO6JwBUiwlVM6vS7YMVA 9zKjd+kED82Fs/p4KAd6vzDbnBAN1XSPfdM0r/Vboj+e83fh3DnpR133Nsxdn55Czx+HprtEVO/G NgDh5FIedPzh3/+g/M1ff0Z+Cc7fPfc9AG+TR2R55UFDmkQeA9wEbhMBXQ9Ei+j6V0k/1TFQ95Ag Jg8uM2kXht0JIRa807JTCbKYoqlj759xGDDpdndXbi2vSh4VCKdAlfb6pYx5ElEFFnu1S9vbcvPc d+VNP/RGxDNd+MhLyQULyy88kwPdCKm9tBpTdPbss4JazaXuDVWuuSGW/cDhHo8W/aoQ6IUsWUUR dUKhpm/XMqvq2dvM09tLd+TLf/5HsorFXamrV6WvuItVjnAEQULPLLpmw5M7HU0N9uo9JnWp6QUy ccSTj8PjwX9OigkPjsLdh/qrZ7IhBzp6pLeMMoR/FQhf6w1Helaa6fyV93RvwZ3dLTlzz30yg2Pm SnjXvfuHPrxogeCcO1SkHx7CHh4AAEAASURBVP2TP5KnPv85+cA/+xW554GHYWiwNPaqOK3UaM0e Wy6FSuYBvxcBRsvPfvFyJi3Gu7VfkrpSFZqBMEyf0pukIDfAqSHCBzfM6ECDYaYBefNjcBXwlStX 5c7NazBN7O2HoxOrGSyJb9FDncIegBf/5i/lobmD8tjjr4D8MN8IubiEa5Imp7CUHzfyolQIPlmq m2Vt3xg87njxmLHoHF+T1HQDqcyTtCSiUP03fE/wkbbLP8WVINw6UICf4h5gjgLFlEH5otttoLJ7 6fkX5V//u9+Q59//Ltl939ul+lef1MpKOwd7pIG4VFgu6zCFrUbQI7WtkjMfqoE51L3BoTampPDZ RfBkRTtzpBePExDv4eqBDZU6flxnOyUR+aGKbsfLFy7imNNtmV84IYXCEHCzA4suXPc6iXAAseIF h979OZy/j3/iL+Rd6Pl76LFXqJdLQ7DoyLyLENR/8D55XO6rzXr6reSS5sTC9XoBkgYfgKcqx089 X4EIPd5aTuKCIR176JFe2dxQ55f7Iu1sZ+AAYvVvhH3ylJvF88/J5tlvylvf+jYZRGaqAAYWbyFN awr41f61pdGCiqCjbfpOIrShuxNQYXHJimvd1/Dui8Ai7aNGR493YMN1CWNNzCUzzGP8c64VDwdK MclMHsBcq4yUn31a9i6elyr29sTQExRS47hr7ThnxFDp6z4BksN4DZbBjlA0lfNBnGE0dfvOwN0H xQTypCuZdSuD0HQUDOz+4sULsrGxLgsLx6UwOKSbS2v8HpkImQOYknx/Rj720T+Rj/3Zf5N3vff9 8uijP6DdnKaVianAXG3myvtTrmgI+zA860ncLSbDC8stVyIjXJOBgIQ3ROkiKAOQliJzhsQy05YD kkMqspmsLByZk9WVVVlcXJT+UXMCiF0g0giIeebif/+k/Nxb3oKu9Hsxn7WCDCVS9OA1xudzBuM5 HH7ilAieSUncnJzOOUmslqICcRnlkFI3QdVhDMANAg8q8wn9TL9ic4GNfFBoKjgXCIIwHSKBurVc UV4c4qGoIDPtCTCT24IMJnav1qsjP4mBrANECfHEhDIm2qdx6sLJ4wvyL/7l/yKjf/NZyQ9PSgrH k1Z5pBZWYvYUVC+0YWDU8qwnaNGJXcL2sVIr4MOpeRkcLPMMGrUEn4LkbjzFwJbVz0gOsA9JObHl pFOZ+Sh7uyGtsKPLVy7K5vqaLGCfv4J3UpWWxfjGuovW3K0RNDiAKcyzyMLx+2P50//2X+Xd7/uA PP7q10DxRilKT4AlFjwulOXnHfIfwJf8LTgjUw6NwedFiXfFjYVremftU/Lygqg8WdXzlRwmpR0/ cVTCY4E4URxWKBM4K5E7od++fZubNmEhyLb09WM+YMMwMJ83l5flkVMn5UfejDOvkb6EFtZO5PIt syVFP5Z+kSY7MZ1y6MOG09huUIrwAoth9ZJVRBxmehWhP+GoV0Dh6S0rFAK3A3HqBMbSfjid8d+S kfixu4qpKPBD4TnC5euFBNY9dEVxaCKb15nTXAYOaW3vFpHHstKP+UcPPfE6kcefxDPyHnrtuQ1H q8aWS9o6hV2ncsd6UdqoGgd4rO4t/43P9n2vVwPXrX1ZGq0dOxCXRdH71avXLl+5pB0bx0+cxDGl OBKOgkqQ8Loh4FwuK5/77Cfg/P0Xecc73yuvwikf3HOmzskjYX6lmiAldSIzhuC2kvEQqkBd8UEc 4MXDQafBRSBck4HIh0NeFBFxEYcjZhQuNB+HDcThvD0bCoWCTGAPwNLejmTyeansmaPh7He9Inpx fUVe87rXy9goNs5k7x9qFe7eHoaThUU/9n4it2nMxdjd2wP8kmxgAUlpZ0f6drZ0cjq3BghLr9Th gy106mhJ6EHxBuSQENgQMODGMR61LQpNBRdCQqKvHCJhniQTDlFYUVBmpqx0lSc9TNS9U35SmL+7 LdtYxc9tNfrg9PWhUVdFD38RzuEOGllheczKIdZV9cKYYMRVgUzwfqHsUmCmIdazTEhvZKBNwbqg e8OJKxvzyl8wo50ykfR0/0E5scJyqZbuSTQpYTuk9drVK7J0967Mzy/A+cPWZqBdycZH5nnGYYdE L3Wx3wPYj/2XPv3Jj8lH/uDD8vZ3vFde/bo3YLgHkw+twIAmcIun5md9mcCP8qQIDGvudEXI7qCT BZ8XPqjK9CbhHxoBQ7gTY74l82ulRb4a7SEJDOTE4mgHT+Phh04gJ49T2MwWXKi0jWPh6ASmsGdS GhtFW6B6RuPujoyMjWhBwzpNz/0NQUr+sI0gHD9kSMD8xCc+IR/5yH+V6ZkZGVpbk/furMjMgRlJ vecDkkULbW+7oRvQqqUdI0l8B33k3lWoY6UTJbkiqGe4kBXHs+sY6xloPQCicKgTIqsj35FeYFoa gnWBeZPsL/FQXkXstYaRYElzuJfvIEfNWe7MO1lGAI0i88mte0gOldWLQvSRJQefkIxOajD12QGu Ol5q6Jzc2TzpSC0908xeuSvo+VtavCsLx0/I8Mg4jIl7cDYHfdcDI9oDSOfvqS98Tv7wP/2e/PTP vg3O3xube/4sbuRGtgZMIGYXwcB32WviU82JYk6tD7wQPv67cJjIB+EqC+bHZy3xG0VEXD1YXFui DDNxW4HGUgxQGjN7ACvrq7J5+4aUNzbxBkv1i0Xt6aMOCJf7WgZXS5ObyOCZx9rqqvzVpz8pI9gz kEf9XP7aN6T6ub+Wyhc/jwmFF7AWy/QSNsJR2MBpC53G70k8qzoAyLQJk4AYBQM50u/9j4rT23vV O4XWUim94aildoiEZqwGV8Pm6o4yM2VlMDc4wKaNLAdwAyCVD+BhFcPhXs7NpfPHoicR7gDEaB2/ rgpk8lMrlPnkKDDH4x8LAGemTKkDBxvBykUiWgiRB3ghAvy4amgoJ4pEWQqh4e/4FWjj9mQ3blxT 5+/osQUZHhuH3JudP+qc/BhZda8TLJpMy+c/82n5Axwo/Na3vVNe98NvljTehSmBsgui0ufgi4Tk 5+fLBnwJgQ+AMSYdeJH4rc+LZh8HwlKKPbhA5konVjB+MeCIlRrY2p3FHXW1MXkdwDE9u+jh08mx 1SLmDmFFMGqTMvdLwgHd6F6Qvb2i3L67jMO6y1jUYRZ2lHUOYDMGYyFwGjMZedvP/4IsYBXWC9iI 85uTE5LnwpARLMd/8EH0QrK3ghQEbMoS1gw20TemrgngTRS6AWZZ0at9cIBn/0BCXm5FpvBtfnHF V50q6h6Sw2jLMOe8+MZlGLF4k+Nk/yCRA9+8HOulvlZOlsdGHTQ+J4XNFdww+qwdO1JLGMpY7+hk X79yWe5gHvux+QUZHYfzB8G0pbNthGj0mes3rsvv/vsPyj/8qZ+E8/cjmHeBCrOVNuBh0Es17noP mKNpwheTdWKw3hJKrI9wDsivtqJiJeg0EnmBnBRHp2njxa85fdQH//yiJx6AuLGICI6OsQ+Pr7hp Y8cDXBp9KxtsAYubl/NEEA7r7mJDwOr1SzIDp7CIyeU3ttZlB/P2ythTaQ3PFd3XDAs5aM6AyZ4G Xm0gu1zpm01VZAAHfT/y8CNoHPXJYw8/LA+cOSMD2nsMcgF/b6+sK+WZJhg0h2iPOT/oU/BzT/eE xt7MTAYO6kAOQ9WgtyeIrRNrflReWsfr6Sv1TsaSFVUESUTSoLCImB2/BliVl/LhEA8IY15RXMqL Q8FZ3TgSGWVck1ny+UV1qHoxmJy2llkQaBnmUB/Qt5GXWxyqFdaTEJtxnlzg8xQDmbmqi9WiVCdq aM6yvtpZhz/0qW7DF7tz65YcOXYMU5To/FHy4UF9FnxSX6yHMgxrrVLycz//dnndG94I5y/bsuK1 srMkNT7b971e/UoU3KvSegUYmR5Grb02kRF6/uDzopDIjYvgweXqzCiLSQgtp00x+OWbeUzs19d3 veBawwfPuiIYsQYLg3L8+El5+pmnMY8oLYXVNRmHZ1etlGQZi0RyM4fpMckn/vSP5dH775FTJ05A ZiUZ7IfDiHN+GjsCS7DAbbzEIQQ6KZ1zCDNInx0ZVllzmlIRQ8LcEb6JZFfqBp/Ucw5b0mDRvhl8 zmLfQ+DjNhpclYxpVIkGy4qC9ZWUKIoAsISJD0Cu3QLH/z8HsCaOFne0a6Nyt3ox+cdaWguCvg8+ qbyUIV94iVNt9aKAHamGOIKg9Tn4IiGuDB4HgEPoM66stemQCPv+CvU2OiVu3biJ0z1mZWJyWgv4 ttJQI2sbqyU36RF0Mz75g09KNofVVq69h5akNH7sjbFGaJHP1qOJjPB99MGxM0tJ0ObMD29chvj6 Z0w/Nmx4Y2ND9jDvLwvvaAv9ersgOn9wRvoGB9BTlpeBYbSuDh6Wf/dv/41cvXYdTlQWvYBpGcC2 LnT0goFZgk7hNiYkbWKvl214VkVMTOK5pLv6XMH3No63Ci0Itbd78srpWNiuE84f1WFazSm00rkq OZ9Lg4+EkSqe76VCszcZ7m/q5HVRT79v/fWvE3za/6rBPU8Jiicc1MuAhXDGvkffqkfckNcC77S9 533uRTWNs70bn9lL2lkvJhY9IYNlMB9pAPv8GWe4Qcakmx/0gr0ycc/RLr5LYYSKOFk6M4rBbeJq ghY/mT5UfJzfZAbAWsS0n1gScOisgxKBBHFJPx1MniPMwGeurqyg0ipjyX+gCvfuyVInauI8LaOK ErtlAmkz6Ocso9Kuhh1lhE1HjfCQxEnweKBmOmGnA1qoCoL3fjpI2WFUINKjANXYHDFDISkzDZ5Y TFJpawMDgzI8PCKHjxyVHGw7n81IEVMb+jC/YntnF42dvMy98nVy4VtfkV//9f9N3vmu98hjjz1m NnpGVtjDjtBB7qypm7YCFpUYEzYUIWIwbiOZmg2Vn1axGlO1f+aRWNyYmrLa3N5Fj+afyJMvPiMz S8uSevs7Jff4E1LdxUbVyaIFOpMvEwZbY1hlVXt0e6facYMCAtJyRXXkBoWFanXSSZls08a+erYW O36XEX2ZdZk+TjKywlLfqby0UAYiInMWmAudIgB8g8PYGBlxlfM1w2h51k1HFOv2TezMsIddH7hl Cst4hj1sBdaHrexI/zZO0ihiDngOU3a48FVFB/+DJ0n1o7OAcXYxDJSBH5FGGvoq3PqL8fawNVEW Dto2Tpy6eO55mT95LzZlLsgGcF46/4KcvOdBhVsulUDHiuxub6pDZ/aw5FFu9EkQgIMw6fBxOlWK BTkqFtZ2QyMj2hmRwmH2qVRZ/SWM8eJkq01ZWVkCjTkZR4fdCvaxXdrclFO4Xn3xWbmOBY8PPfgo eg4n5am//ZLkpg/Jax99BBA5Qah1wIQ/E8FWcq2is2zW6KYmJC+heYgm6YGF7LB/08aqXLt+TXJQ yuG5o4ri8qXzsgbhDUGIc0fnIQgoxEsVpCV4H6QtiIMa2tvdkMvnrwFCFRX/cQjfwKtWyjhX8nkI Z0pGx6bx1VOEAiN1hOQu1NNvpZI0Pg8uLjpvwCFLFnQ9X8nxQ04Mjs5kpW0S2jsIm0RGGMEQbQY9 e2wpXbtxAyurbsBGdmX4MO0vLRlkptN/73+Q85/7S/lff/1/l//xH39A/v4bf0idKoJpnEun1HRG kjXn2hVwkwiUDwsQlF0qqwx676dyKIz+4s9kY2lFCji2MfX4q9HIQsHVyEiXBFjWmfVd6d4njQWL 8wAc+4DGefmiciIj7pgx+nbNiVU4LM0am32V9JWicoyD4OlQaHCEK5gPHaGo5XXLiiNEyosWLkZk Hf1CzuvwJYrFXXWSdnBeLju1+LeB3Rt24XxNov7vh7N19/ZNuXLpgoyMjkkKHUPp4Qk5M3dIvold HfaKO3LfAw/LFczFW8QWLIcOHZbFpbt68tmZe++Va1fuyAvPPa1L00+cvleeO/s0nMGXMHrUhzl7 k3pix7FjJ2R58bY88/S3ZXhoXJZXl1CnpLCVC/DB8SOOtbVVdFIUdF75yt1FOKjohEMnRQVTiXa2 NnWeen9+EAsac6jPKxjJ6lf6lxB3c31THdMB6OPGxRflxMnTUgAv5196Ubbg4I6PYhcMjALdunpV Dh1dUNpbyRL9HVaj8XKF9gCpYXsWEYDOIqK4s6He6uTUjKQz/eok0ivehee8dOuGHMQYdwYbe2bA 8NTEpNyFsK5cPCcL8Ki55N8EA1sfQ8jiJP67N67K+PSM9OcGTE8ihuRKnOiPJdQHD856Hn5abl6/ IueeOyupM/fp2DpkXB+AhE6ju+LNDg8CUbPI6mnp8ilYzpi+K4eImFM1t4Yopkv6g8moBzo2nQYm 0XmAEAZ7lnNwimzgvD22AivI8Ft3bqNgyMqVp78j127flZHBvEwM9EteW3rUlaenLmiw+IJXgqnp JCGggMlO/1KZm1RjLiBof/WPvVkqW0tSeRa2/sonDAngxWgpIXtQ8tmAcqN7Ek35q3kZDhz/kqGE ZNNIKcDq/GJjAM7QEG1NZu70okpR/TuSV6P8HD4breOXBacrY7OwVWaumDH69tXiCJdi8WEbnMlz RLgMKLNshWZetP1l9CIa91zDMDExoR1LHPFjA5iwsvA1UugZ2YVjdAVO0/rmtqzCCRubmpaNO8uS 39uSSxde0jpiEKNHQ9h37wbm413Eu6npg+hMGJOz3/oWehPZuzgKp3JZ1jC3/Pa1K3DsRmUL2471 pTLoYdyWr3/1Kbn3zD0yUhjW3sdtbEWWRr3DDqnCoOkxzKCzK4tnnu3LvMvTb4qgh6a4trElBcxj 34S/NAgHkGKnv7SDnSvoe7GnkyOaPPVqa30DQ8bDsn3hnPY+bmPR4yFMdVqF07uMHsO5hRNtHUDT vwkkcWSueYUUebpqzDvstqxASDfXNnFGKrpP2Y2JqqowOiFTM4e0740MpHHI9wiEvIqeQXruFXp+ Vv9Ut3fPS/A1P3H4OQ3Yd+kpo7vXdJWiC7cwJAcPH4ESjQORxvjY9ua6rK0sy8ED7PljXm+EZqpm hevqx87LU9yN+JNCCrgqQnLpNlgMcezFLSXN0GEaOtTPM0WDtjmLjZsfuP8+uRfn/qKVICtLd+TR UwvyI489KP/83b8o/+b/+D/l1a+2TpOKshl4N288dTvROhSxA095FxMUK8gPORQa+Z9+qwz86q+J nDqtBUUJC0KMC9gN8fVplAf+wI5d655Uuw/7kPeVCfLijh9fL7accSA4q2/DhTteHJAeDpLlQ/iX RN/6OJwUAKgbA3Bdqd/i0KwP6djnRAXlw6XEAkzFRYJkXJhXgj+wvLwiJcz/RntfiWUvYD+cLfT1 ac8ZOxhmDx6SoYkpGT4wJ6liCqdtLMIHKcvY5AE4jRm5ePWmbMGhXMPZ8mNw8MbHxmQZPYEk7fAR +BjwLLfgbBHn7NwcsndVLmLj5k1sK7Z89za2FuuTUTii7OSiv6P48a6EcnoPnWFcqMghZ3aM5dHT l4VDx9CP3Suy+MugU6vKnip0XHAIeA89mxz2HcWoFuNwyhznuHMI+kX0SC4vL8ojjzyCXsSsLIL/ XfSADsEf0s4MhRz9gw0kEDqQuVYp2kXjmzeMIo3ux1W5fOFF9YzXMD5dXL6DTXNH5Di6SnPYQoOC 9T174OMQHInchPc8OFzwiLAw7TVIOBy7UlHOv/CsrONgZDK6ubgoBZz2cOKe+2UQnjA9Y4MDlSKE dO3yRfQ4HkK3L7b6QPcvWwGNgQbtrvfPYNNMQxk3o28kp6tndXYsElc5VCkDAyowh8xQSATfiVF6 UvPFS0cQuuYKd5LLjMprFhnk6LF5nY7wQ69/g9x3371ojPTpvAtWCdzLD1M9uuqB9EgIuQCx8uNT FxKnu1fUO7e72UN+TGNogXNEUsgPbGnxNIXGzu7usARSQYicd+zMkAFZ86/KK4DX0a3TfK9m7Ome xuc0kBPiSN7GfLLJA1G4ZoWcOJaXr3ctOH0Ok70BbLLBdr87kRl9+3nGkfoVrPJBThwhUbhGUnEc lzplQdbDmD+3jp6vIpyfAuZ/s0eOjhl7z1bQCZSD48SRH/oJeSwGLGB0coALAgsDmIJ2RO4ubcgW /Jb8LEYuK4va+5bHVKKBwSEMwebgR8xh0V9Rnn/mGfgyaZlC7+Fl9BA+f/ZZycHBxMxw4KzIGBzL ApzGy1/9MuqVHOLCYYMTyGHgzfV1nQa3ePeODIHGQfQIkjbuWTs4OKhD2H3wYThaxTqLkuZaPvbs 0eHk/szjOPOeHzZQUY0fOirf/uoX4ZwuYvgZ251hyPprX/+KZCcOygOHj6mjWCenkAeeZa8A4+QF q34atSXOpKtoF+TR+VOytnxXLmO+1Ty6Hwcxzm0WmIARDFPRUaT3zMAhuiPzC6qgOzevyQEM2+LM Lo8YjaI/Sh/vUKGn4UTOHl2AkrekfO4FmcNcv2GsmunH3EIeUG8nexLnDnr/rl+9jAq9iDH5u9rr eBBCoTIN9QqUgHnjLvgMEEXdQ4I4LVzXvKDoBCq1A4syQS6SAkXSSCd7AkksMxGXB7GgPHjwoIyO jsr09DTsc1CdvhLicSNozCJQpykx1hQQfhID2CwhssiFVCwgBjDsoBOMEY0oTd5sTtPNG58F3CQJ N5wWx3asSPcBhwrNLR5FQYXoTbg0e31r9W3yvuP+WYiL+JxKjcAtU70Kp0165cORboIsOELRJKYg zjasd/S5F7jknc7dCJ0jNoZ1Og9eAmgeZfw0Gv7sgBoYHZLTWKzBnsIjaCin4Zwdxn57GTiHP/ja ER0uHRjEfGr4IiX0zhEO/QU68lMYWmUvIYeB6cNkkf7hV7wKnVIlhc3FHCV8Yx2Th9/zxjf9qJz9 7nd1WhKdP+Ifxh+HcQexHRl9FcKfwDQ4LtbgSt4b169inUIe6eGYcn8vxKVzWKDTioUr3Cg6Axjc ILoAh/cgnNAnn3yDpLh6GHyS1te//k3s8dAOtjiOdGAOYHt9UdA6pATCghmUyqNzRqIgJclgG44C uk0H+/Pam7K1va1eKicpLi7ekTFMWlyBF5zO5HRSpi5nhkAA1jM4FjINJs1HCg+9igPY9DYLDzoP OMPoRUS9jTHyHZ1PuIWh4cU7N+EpT0LZ9yv+W0urMkyhQIA1HMqMRYgHh8EIzlmpRp6oGZUZlWFe JM8Q9UNMmluJlE9JBx9JT4AtZay02GHN+VicHsBMp9u+oKVFW+Z2Llw0bnvLlLWeMDcnNrS4kpfR glkU4uUa8ttMRu9vIByDwSEvxOGE+DD2iYi8OAg0YxofUThEQ8oJ3gR3eqFS9B+V46p8ARN6zCjl 5jAYGyYbVJIjXB5slpWOLAwS8iBz7ovDoFggJsrNJS+qCjWvLrAgHVfcwpfyAzVLHXO0kY5UH773 w3Gr7mBYlp1G+FeFX0Bvgz2DxuuAs8Z51R4UUmL5rmYx5zqvUDVufmDIx8UboNFAOJziRp+IDhtH mQglBceR8NLpWidUBr2EDBXsRbu1tS0TAK/T2HRdMFMxPlYl2zntEBId0Bx6MDniOTg8pA4nNcMR zsHhUYXH+zimDVYZGhwj8zL618igCQHn2PWD0IPYyJAeLwXHnpcNnL5QxHLEyQMzsrGClb/5Ycxd qsgWhokH0YN3YGYO8bA0WtlVcjSdL/gAJTqMi+7dA5MH0fWKjavBKHHsoEt0HV24U9jfbWN9C708 E3IAcwJZlnB7mDQmiPZB2JyTWAv4CI0YPF0YXQ1Q9B3BWtDsOnUQNFsaVhxADwfpsuwMx9jdW5qq BtyU4AmyQGArjEOkK5igW8GSe2bQOJnFgop9hbrdaDyKAvDmMxwVp5f35IYyxK8zPAaHKfp6obV1 WhbSrABcB5YtLgM5cM0F9b1fQXG5FZlr0/JFpeUynyg/BzxZvVhLdoDC5HWfI7ACXlzkfcOLCw4o +xpc61PoEWtAah0l9StUVbW4ZFuf8MOqm2WGCYCCW5vGe+lf+M3isfH9j7ghHAvJYKBQzUKWctMq VZOy8Ug4H4IS4sEM0BRgOYi66R4OIK0zfjBC8ATQlAxeNjzr2SnMQ+K4GwUBD2wcTt4oVuFaAbLC Paw9d1jQQfcN3ad+a1lh1sTTiEIZg0c8g9U5QRzD8OwLx0/77HDJtdkosSrT6NLlEDGdvzrBqFJZ DXQmg0aaWj5bVhyiUGtS+GTIJSJw6qHwDbAl8918dCMwQmVjgD1lXCHGrQF2MKejv3+w3ia6IblN GmNflq82kbv5vA9qV7KIx1EjxrJN8zXyws33c4C6VVZkwzEr2pOlONzZmKrdKMexVsCIa3kpAsiq rjJImC2qgqw4LY8NEnVE3KneF5PTehKVmIoKMoszdNmttsgDbdmKy5qAvUbCRQKbxsZpm8ZGbLg2 wvE/t7D75jTggwTgz/Sam8Sd0uT1ADYz5xMVcUNBUmFBhLxXgzc9nkZgeKddmDp5vAaM49l0/mwI wvETthAIV/kyHv7rD+H1YXVxMFhDMufl1dNq4nlCDCZyca9EErB/kzAWV3BDyLSo7DUkSm+vWii9 N8B10icWOoTudBIE7UxYZGCfw8uJF3e2pj4GwGs5CQ25khrh1pWdjqxB+UDNSYm54oWkO9RITTJA onVV7Y2TO1O+ALQjgZEHdcx5dcJBM1xXtmbg7ov2nTdiHamiAaztX+5NZvCYaDrxzUdjEmcE3jAD CXvXwE3DI3vrWodGmI3PwdStvmk8RnDeUgtSlPA9daECw88+8GIcax9pwsxYcO0swMbr8mrtt61x dAnfS0bwBoVDeREHZjZQYpat3qiOSA1GHGtFZeUaB7lj8UlujEsTwW+Pr1VaZIYG4Kh8Mfp2rxfP iPfDyAyOHmXfKrkvrcYejFaJOv3mZUSWle7ypIHM4UGXwZgupeaYF7BBThxlFRWR4cGtvHrSRSek QVC99jD7Q8A0pdi4vYjt7c5sykuBcDNeG9gjyMDVi6FYbY6JRVA4DlaFfeglZMVYSXySrAcb9EXy oBx6P1rQ8N4yFvzY4t7mhLaCJlz8xZJXPT7qIogmqKf6mPbJw8VLB/g4HE+10wy4N5KTYBkh8HYy s7STjy4C5UYUcXgJkhUPlbEvxuVwdUeCjodAY1mdkI9Ydmy7GzrAQbvkxtwM7W3LAA5t/lGIQZ2G CdXapI0XjGPfGRT4pVy7VL6F2wTTB+7dgBN0AxFT58HIjajKuoopGgrjdMmJjs6wEqGj0lI/QGBc gM45sSmYZ9rZWTSXFkqLq9ULo7TSjdpxCzhtPtl8064s64UXbjViA1kJ043q3UPC+1YsW1j11/bl DO0qyEc3eGwd07Is8wzYu9ST2erJ6jzIfNi7AIwgP4HXkbdmOhl0ECiL49pAJNCGD+RbnTmvrNTP 5IMfSHCQP/3IV8iRIe+9z7EuGSOrDsTuERSnZVPBOXzr2xu6Eob76XATMR7NtoE9A2nQg5gHyKXY 9SbGR9Myj1N0Vsp72F9nQwWl22DwHD38K5eLsorVv3ksSslhe4yWoQP2CacK2MvLa1jFnMZ+PmN4 0yGAlsTUPnJDS85bzPBEFXpPUcrme5DQcbmGdKvYtocbUjKT8ui0gUGshiKuqAA8htv42Yj62N1Z x8bcW9guCMvcaQstZNZNrwyd/AoWGtEuOcfUbj8UxYa+Vxa60x33veS+TP04gq1lsIVRXTHaKgVO +MCefqvYxoi8jGBPKa6Wh3ajE5EFH090tMYvuzi1h3tfce+pEaweq3LvrDZ4Op0DyLyyhvzJ6R55 b5uaRjqCz8pGiEqqFeiWUGCblEsVpwExLrdrsPbC8sLoHlsoIE6Ju+ejnKEtpLn9VIMIbbog/qZ7 IgGsYOBJRFVsCUG4rAiigrLBTBlDN8YJIySDq1qB3NbWkTfL2AZiBCsZebZpPR1ReKPek18PuokC 2aytL2NT2T09dipfMCsIw9OTD3xRpsJjmLdGqs1ldxX7tC3pthx9LezZ6L8tklBCytjewzhKWCmJ bUF0VWgIqT70Br2GRIXq/Nj+553NVT2uawB7t/XnI/K/p6qw9D4g/8bisLrHhsIrZnNiljFZLF40 9aeNZxNae7B6te/Dr8bGbBrEqe7JyqI5gYLn0IbWxYxGcLDzEFHwS11owoH6aw0nZ9COtSxDfd9s Gx4Ij71ItZCAuo+Yz42tV0gf9/uzgfmeVLPebAxqnQoHXxrFyVf4ZlB4ckK9wpM+SsjvBdSNPN2M sHe313Fu8C72OM5jHjltICBXPLUNdbwwLbYow2EZ3K+YZRZDBeUMyxraMTd57hSFAmnzY/YBBOS4 5KvMSDylx0tEQpgLjjVZlYsvvqA7YD/02Kt0Q+ht7OF3/dJFuXPnjpy5/wGZxtFw3IOtMbDcrNN1 YwQ8s/Dd292Rq+dfwpl7K/LIDzyBo1Gwn095V144+x1UDhXA3sNm1GdkeHQKKZrxKFi+Ji9tA4kq ybnnz8oGdwIH/gPYV24G+xG26mWMwBqNDfLdxJY5ZTVkkJbe0SNnIhOoHjrFwkQVbMNzS3dO34Aj QFm94onX4r0CDEXHeS2KKSY6Gu/G6qJcPH9ON2Lmhp0HuQQ/zPH3MRI4aYgZ4BTsYQn9zjZ0goxC J2BAM0wbIqPZjERMm9uGXX/jK0/J1IGDct9Dj6JwiNOjGQ8Ze8u2ttbl1rWrXLIkN69eltP3PeQX PJGEtcssDQlRzMjNK5fhAKxLGmIaGh2RYyd5gkgruSOiP7GpAWDII2VFB/MK8ucaNm9/5PEnsJ8V dqg3FhSSAq+oskYaIJP15Q00HnBkH/bYYqG4iaOTctj7ioX9Hhz/MhqCPGucm33zbM4NHKVEe6bj x93+mU4bBb6crD5a8It8qHkQ9sV9uxjofO7Czrax3VQBTjP3GYsuqMyQmcWkAMJ+UMlsrq+ok2cb FDwh6eJLL+BkAG5hUZaTWETXD9kZAYUAaWPqzE9bcPYog37dvoKN5JLcxp6tlNMOtuo6fPQYjr6a VbtrxgBeqP5oCvAFq+vR4C9h79VBnLFqaaUdLN6+Lt/+xlfkfhxaP3t0HnHsxksNmBp13/DZPPKU pxVUjNiPDdttkCiejrC9hYYGdMW/HFf3Y3+0VroJBR14yY3hSzg5qBZSsrp4Sw8Y4D5w4zj/dWpm APijGwFUSwsL0690KOmYmI4KHHgAXm7fuql65wkQeeB66LFXImvUS9+YMjEY3fAuPEAvxS0cgrTt 6YU0peSl55/DkWObSI2NlIeHhefbspEVDBam5lk8+NknGEnv0XDFVmy70H9hCJ0imI9PHCy/rl+9 gn3zuPHyAOz4fsQOkYiHyOJrBM98x7zoN7qYN9H420I+L6IBM4ZNm+n0b/MZu44QBbd64f54TSES SQU7iKxgPz04dV7Dnp0wN1BO3sLRcCdxHvChuWPgsyTLqDcvXDgv09jZ5MwDD6EOiALahB0yhr3i dI8gL/QfuPkz93PNgm7eb2KXCh1hwjduX8MyLKiAECk2I2vzhs1pjdIRMJQE6gOGAickeNG48Jy8 A7Nw8OA9kxHdJgab5cziOJUsDjEtodBuKuwtNaCL7ZposRJPVTdkPHRknn3kOlSCvC+rOMKFhybf c/9D6KEbluuXL4PeOJW0Ig/5MTxxSHkLcJew8/Z9DzwoB2ePyOVLl9TwQ43aQiIT0YzYWP6VfPNs Q1Yug+g14bEvlGELoWtaUtk+GF5Ufyi4jp04bU5SgYERF1saUcvbCbumkXbYDB6B3K/A4adBTxw4 gIw6DeePPSfRAjFfor838khM1gHnNkTcNDNWiI3C44WlClrNd27ewF6COFsYQ3M1eYRj1Pk50aVm QyK2PlkYj8nM4SMyMT6FI4CWdONzO4zakMA8kg+SGMvIDC/MXZNocZ65/0E5srAgt8FTEYVPSztW DHGFRjzYiBW73c/OHdUeM1Zs0eUGomuKZi5oKqYg9HBDRpQTbYo76udwWDodNL1HIbmNiq6IhiE3 UGXvWR4VD/GqiAya9r9egj06mMh72iuu71LoLRs021yhTGsN08iglVrorPAw+LuLy7LCHvJ+09PC PcaOn75H7rn3IVSqO7KEBnNLG2jBESvifuxhtgIH8A7OGs1m4SSBNB5APzN7GLskzKAyLWPEZAlC 8o2pCaJK31NB40dymsW5UruQ/TXA4b3p/WJFvSuLsK9B5Es666000TY/ebysoaK+jUZyhlt8qRKQ EnUAGwB0NGgbrebGGTY0YSMrIA+0Qyfsdd7a2QUv0AmQwDWTyzi3niNXPAliBJsIRzp/AO2R1Qzf e2P1sraxJrfQQCIeq5fjJ8/ICfzlUV8OoaFhnIUI4UdiMB8y0HcJDv6Vu0s6aqF6Qbm8hL1454+f lGPHTsgiHM7iLupjQ3UdRMOHhztUZDhvF/rmSV3Xbi8K++ozfEYv9s0bV+XIsaNy5p57cUzaXfzR juudzDpkYQ/UB/Buo05ks0HpR/5nQ5/lC78xj6WQH9kwG8BGywN4zw6BMhpPJkIY4No7kw9T2Kd4 WVbRmZBDfiFcnuF76PBROGD9uukzpUB0kwdmsWnzuB7TxrI0diAvIJY7UPCgXCqcdsrySzd7JgJu V4bLAE4sGcZexznkm13QxIZgU+gAdVNavPDmAHYAhQTyj8FezZP+VirshsfwCJRMTzqXGwQzBr4W 4mgZsHDTdyHpa6BMGv42RqMgKsicbFmm+zDEi654awU0jm0UDINw/Ljj9jh22r6M3iccC8HlyA3Q CLk971U4qtyoEcWogiiiItsFvDIMfn0NZw+y94F7DDYS6jGjGNqjUdpYsVE2eexOTgMmSBZmNFAa SgQKg6nlRy+K5QUtZB6ezf0aOeS4hm7u+x582Dg1LeG0Z8Tqh71/bFHyqBqeunHz6jWtrE+gMEDt YwgK+TXyao+HAuc/+vZpHb5EIcEhTfDE44DahjgofFtjIZdDS/AWGrdpOYSKc3NrR3XVbKE1zGwI mYqw9i7szsqMFQ+PD9pCb8ZN9ALSuaF9a94JS8h35EMRRUUw730cSEDdD6Glzk1Hb9+4psfIseVJ xzzKjgklzhAwh0c1v0D/3Huzlj9b06dfyUscvZBI/GcZoLUmC1beI3BHfjZkuAEsDBp1tBm2qWeM Rh6BCLDoQLLhtcte+BQqHg73sGUOfWCcxui0ZT5RUvQnPBpwo8K6eQ29sBi9uIvTivpwtOUWrlMY VRgZm4CjmdeRgCLo4Ea1LBsiQxQr4HHp7k3kwSU0XO9KBWXJLq5T0wdknFtpwW5u37wu29ubOCbx GGITUAQefgrBQ/veRDl4E04ee2aX4TT1qQM+IrOoPK9fuyKj6KHhzg10YhG9q0DaltEDtwQZLeH8 0zLyfAWOE89szaCnlw4BG87F3SIqT5yMAH3V67yGNpIEEMeTInieqp7sgF6l55/5rjYmpnGG7CKc KA43rqPnfHQMvebHz0CEIQ4NRBghRSWCvKwu3YHeb+s5rzs4t7sEOxjDGbJTcC7Ye0mZFjGNahZl DefPRas/nBvi2N5ck+vXoV9cF9GjlIFsCsODcnhuAUOOM3p8K+eY0t7Y29yY/wmZfBAWg33WB33m 9J4tuXL9Kmx1Q+6AhzJ0P4LOhJnDOFEDsLdAewGjcZvondvYWpOpNHqZkS/jBNo8e9x5hu4O4FZR 93JfX+o3DV8i6EzS72Dg2bsUFmtPNjo5+6M+NGhG8+EV5MNVuQPbyiIfbsJRndZ8OKk9byxbNBV+ uI8syzQ65eyFbK3pGmam34WDymkr5KWCRhc3c86TF9RZOk3Fsxp6AbQzNjz2YI/cKk8boQ2ktzCK GuIWd4CKr0a3LaIFPnlxwwujqtzFkMKz3/m23ITRacXnxScjxKOZX9/BpPAQXjkaLht5NVRgaBnn 5z339Hf1LD4arBonIpt86MGFASh8XDmURliKO8CKIYgf6l7WPdBb5zDp2e98R65duYwh5iEcQXdM zr/4nNy6dV29dg5FtAwt4AfTbaOVtoYClK0DHjmThSFneSQMaMAMNzW8YPz6eyvc+rfBJ5KxiALn 7He/I9evXFG5UUarK2ixo8IcHuGxNG0yJtEo0AjtQAnrKASef/ppuYChvwoyPp0X9miduf8+FAJr wLeCTBlSaAaJbXuPggfd6JTXJoYdcvmcDKMQ41wWZpg9DG+FKLwt1GAEVFdaoT3/zNM6hL0DPNcu nUerEmcxordmAy13VhRWIsG0tXtakJFY7V3z3SoKnmehl6sXL2glOYPe5fseekQLZZ4hCS+nOVHg jfao0gmMCMwjm6D3+bPPyPmXXkSFgiOM0EpnC30FuI+fOYMCCBurh6vVgxoNv4YW9oTK+TnwcuXi ecO5V0GG5/VaSt6xA4p/zQEv+Y1x7EeIxI/q3+Aj7724KnuKDomCUQJQLLTaFULQeTccPsY9XAvY q3X66qHUEkXcsdDxCQ7GMXCycCh5Jinx5FEZDLL3CnpgxcZK4vy55+To8eM45op5sxXuUCSKOwt4 BcClw5mDk8SeBTrI3D+MDaUz9z4Ih+CoNgIrVVaiYbBoQWHvyRPkRdoH87ApDMuiDOFwFef7bmM6 w9VLF7Ts2oAdr6LsNsO/EbCaC2kiMAFJKBs2JjltoR9lCI8bpfPHvD48MiZDKAM4DYSya2PMgNks T+qBVRUbkQw0HVbQ5EXrPHw/cmxBTt13vw6fs8wOl5d5HckOjJxDlgXygqg5sMDerP4M8OAfpbMM B5G8DqAzI7pcjpAjUhBICvou4HgzOitwl1X3uf4Bzf9LaBRMTB2AIzsGRwmdHJxPF1KGqJSIBsw0 SQzvtScO9pVFj3IaTtggZMXpGuxhnj9xAr3Xt2DHL2iZbzpKmqCQ2tCgdTjwcm6c6gb2xd6yVJXP SBIUMGnXd7iQVuiKL0h6fah/Qxw8Ro091JoPQTd7kdlINkJkfMBCPFuGWbrMtR561BOh0JHUuo/g YLemY8fkLKXK48fExQEXcBjpxHJ0A0yFgA57FxIt4hWO6wAllFOHQUkm7kBavhufntL5RDyYnhMn 2YLhHJM9VNbsEWQoolXNdyW01jjRsTkYwFRwALxGY0XHSn7h1GkYAjIpCrE9dg0DDlvsFBZPF7l8 6QLOJV6WW3du6zCQOqBN0ADS8h8pxxQyySQKymF1kmgQbDlNTozJjWvXtPDRlmYYbMsY+WhkxH4L XLlgha0XGsU6WgcDBbbIaATbcKTQrc6GTSB+/S2KDc0R9W/rnsAjj8jjIdRZFD4aHy2xW9dxFjOG Aykjs0qvLlX9A3nRNw3K92MZY50/fQpH73AxRhaFgTnomi1qOoOqi2hGDPy2AqvqIdw8aofwqqy4 AJP0l7USo6YsrT5xTTeUQbTqaUuwtZPghZUMYhZgW1vodbiFiqwC528X802GcgPRclM+WzCrUDFd YnxMjqNiZm8vW+vcsJq9baw099BqZ7kQKRKAj/xmOQafHLpaOHnSFEIwppuw38sXzqEX44QU8K1l LyPgmGaUBRh+Zf4cRoWyAKeGumHTpYgeZg7FFFEGsOXeypmNkhQbQyw3+lFRcfI18wX6/5UIpgmm Y0/GJnTEXrw07K+COUIpVhys1AOCYpoo3dOJoHNGulOAwblE7NlksI1fzSsBePox5IfZMrzsRtky eQBD/ZOyibyRG5mQwyhbeCY1h7Kef+bbqLwLcgDzjFKwabqiYcGQEJRAMBbKSzhF7FnahvwqmNs0 N4ceJUTf0zlb2xhtGIDDxJ4z4zTRX29mC9onCv6FCC2H+YmH51BGotzfW16RI5hPyJzFRscQ8tDy 3UW5vYpeM5zYxDKf00DqlFZHcgteMCQ2hrNQixgBKqJn9/CxebmGHuzK4h3YBJw3OAacD2iasSS0 GZZ9QxtqZJTfOJowMIhyGN+r0P2RI/OAZxyKPJzcXcoJZY72ZqKsDgGjMmL+pa2EiEu5HUSlznPJ OWS6BoIps4pnKHuoN+/cuiWHjxxFeqyeRrnZHAzk6HyJMhJl7+yRBbXfLYxgHD46r3qhDthjNw67 KO+V5Wl0brCuHoTNowj1A29ViryhAQS+mUisl/oxHWoOZUhB1vDyIObJDaJBTl5GMMpwcoE9pujY QA/gGKa1tK5jLEYDnb/kgcP7u6gTOReuHzqxxsj6nr2J/OvDtDISq/rhjTpb9XnGyiqIhRpiPhTk ww3IYGB0UuaYD5FJ2CDaw0gfp2CV6MtAbgzsJeb84xKeuRAFBq3v2/1wOJdl4i7gcQFJDryYhoXh gfe2d5RlwDbrF9Q52tOpBUkAg1F/4EXnt0ZizVqNhKSFAL+qVdRHo1CzOFkhixYGC+fbWMl0HcNY LNAunHtJTpw4A23m5NyFi+ocXr95EwrFYc0zh8MNnDoEzKDNEX8fKq9B/DGDcrz+AnoakPXl0rlz 6MVI47DkSSzOmJGzZ7+jjs6JU8ALSD7tPtlByP7LuhvG6Mtifhz+CIMZ8foddBHjvGG2eI4dP43X gB3MNXUQ+NAeD2OxtQbyFV4BFeU2V4LiMcfWFSqwEAaYzA+0j1ZBZYchuUH8kRcC38HQDw1ucgqH XTcLKASch6RRMV5MgmClO8hMyoBMSGedPVt30a0+jjmAI6Pj4fo2KeL/ovDlVAPKn13rOxh6YiUw CJvK0mFrx08MeaXhkA1k7HByFT1lDyqOwrUrmPC+jYYBVs+GFs6WDSJpjYhfuTJyEH/M6HdvXZMr ly/BgUZjA4ukRjB8Zp0OC7XTq+oFLdqBQauXsty5fQNDf9ty4+o1HYY6tnAChTnnT0bQywot6ptH EPEE8+cSpmNcPn8R9KeQP1+S+ZOnMdxEfsIqtAiuAJQtck5YX1tlFYPnQUwjQX4BIMisTx1nTY1n DtVyOIgTxGkbdKrzGcwVwrcaZ7yjEYcH+0Udf9oY8ghhMZtvYkiKvVjlyraWN6ETzQHW4CLOFrgA k84E5xXSeaqyZwM2vIFhzUU4TZXxqjz37DNwDhZkdGIK3w3UcKqb3zI6HTqeucSerDIcaZaVxMHK jL20dKyZX47On0BkVAke5XXQFC3HUpoDcVBErEhzgM9eOTqr5Jsr/u/BQimqO41pLSN47iMN0E8Y LOozKhheoAPyAqc1leZ8ZXY7cCo7VmtifiNTU3dsqIXyYYFHozEAoG+djgHbqVCACjmNRQz3ylU4 S3ycwUhQDnRE44m2cSMzwwvtdaAMJ48OPuezwAZou2z0jEHnccplZK8mMoy8oHt85JmzbPjTGBiV vVvH5o/L+RdelBKcnNmj87qoKphDEE3jGlGZLzDVOhWpuvgOOmCjaQj6ZX7kcxo2toSpLLdgY2no 5+j8SSxAYgMwQi4ARtpom8HAUofZhMOl1InmY7zYhf1y0Qep3EJdOZga0Z4y9pqxgcN5gBwmDssz hFcX+IL5ELbLzivKjDa9g7xx7uIFHZHj9J88Vn0fODQn51BmrmKhFoVB3+bYcTSsWR61CcoL6M2i AeQ3QIC7CF521ZHEsD3qZDYuOLpEB5e2wLmI1J+msTjqxWTfdnRlbkdolIZ52/JXNR8WwyiLXu4Y MuEQVjBS4cymXDnF3prjxxckNX8U7/EOjhzj1gUYAClqxR/1RZMsoFA5BQcjdeoknlAAcd4HjPzI wik5uMtVoRlkJM4RDAOIl3xvfngTGYzBkKKUzB06JOWpcc2gdHbrckQoBHCveEI/Nr2kgdN4+9GK Yo3D+QEEECkP+0Gv7RFZ2RFxPwqw0/c9gKHGVgVZkERqksEiDX6r3Vt+qdvxiWkZQuuwhEKfR69F ZUqb2sBvz4cfH/LqR8uKBRDlpPLCx9YUIgJQWG4srLCrzwsKhT6uLESq2cNHgAB2CxiRWYHAlA3+ tKVGbYQVGSt6TmTmcEE/Cm5uzxBWiBG8BoJXPN5zi4vlhZUMV/0tnMDQD+JzGgNb8ix8o/hh2qhv jSg1LngeQoF/6swZkHcKT17+bMzvgcSGjXpZ8YmFKyv1ClrOrARYyahM8ZET5el4BGVEh0qHmxDL zDvz5vAEcLW6VQrArFbwAaZZARZQxhTQkGX5Qx1FBfKicHyhN8ckzXRgZuHop6ADuJUaiXPmXvWa 16jMCCTfahuYFvAJTMmHY3EAjbwqGLDlbT/KroVTp+AIohdHezxR3kTqH9y0wGNxFDAMu+A1isg7 5cM5swzH0dOszgGcq4BI9Zv/0wIH41g8U5i/SPh2j0TC5TAZ5anDaqy9WwVVjmonNBa/sAfbLCgz eYJ5g/PzhrC4kXmfK0Wp/lBeAIDDkK3YsbxMoHzEchKFSbxcsFgojGCY+QHkSTbWw+msOUpkJjwQ B+Fx6tJJ1Ck2j5CuWQxlT81gcQH+sZeNZYD9HoSmMFoVMEo0V6oOysLhOa8xZhoLk+jhHIHTnML8 T64HIC+h8oJsTYB92lvvjT6C4AKcM3Cj0mAd2Q96+zAyZ1WpjTU4iXbkwQzh1gNjea8Q+DogtsZ8 aPuQ2fGygLmxC0fmNAFHtCivw9PTMjPJLeDgTONfHOePcS017KSgcSgZ4AWD5zrcO4y8k0PZQkdv CL3dWseg3tGGDpXWFCzEpg+xXtANpWuNrm5YcoMfFg4B8WD1VQif82TCOr6sAvuwQCODrnQjaYrN MDCQp9/Je/OuEYZ2naMlyjYRNyq03eJ19Hh8M7NnMeHUwuNYCyGzldlPhwBPtC1Lk4XBgpwZlDxk +BAqXBs7cEVUdZZQCZAfv8Ik0ohQBnzyyMmrFcgtTiAXMGU/KiUVFTjQZo1fsOJLBRAVGe8tJF45 NJbNmZW/jTIKA5HCvLEqe9c4/O5Dao5pcfALWc6iF41Zx2inOb7/RgtU4/CyhY9uMP9T1I3ygY/M nHECykPQj0zLfyxEYGktQ5AZ7z6n29g021UjHJ0gDtvKwk5bD33UUrI3MI+GkQakVd3DrqOCuhCw MfZ+60ThqIgN7znnqF6HBkcUJjpSFTiOmHyFsqJ1YWFFxlZ7JsceVEI1mmply1VW3NANe15Tmn8t 0cZ2apqyGAjZWpWBb/FE5TTGSsPYtdBu4yhYWdSwkbxavrTUBa+0L8JmLwjti6MhlsJgPHtPHCwr GWwepNOf1bLTw0z9B4nQ2KAF9sGii1dvU1fvS/OFZWIdEOgzO0DdmHI4qiyjiKj2EvFwiIIIIwJ7 5K3cG2PRmbYshMlDVYFEHHbVciwCB2GYvTFxw7IIjXzaS9q3F4slDADdbSKB/pGuZUAcnSsJXTIQ KsuyfIb7JRp7jMRE+Kwn6RwAY1Q86ptbYlFWNkfxHYeCON+RobF+1Jf8UaCmp42jBaz7QgPiaT1n FeOlZU89pwIxUB+KVynRV+aHIJnpYCsZlMXkJgoN822moV5gWTYw5PkAtnERQiYdnBJ4pn1xvqJt NAQoMTTqC2Vcn+vrSH6kzgyCYDlD3lj/0hFFC0FtRvkKICDUjI70EYrFgd7mbMC/UPnA+RyyZSdx mbg1UHhXAS6Ufdw3UHHWPuqdoTDwEg3bW1hrwG3sOF9XGzKBz+aWeJASzHBaShVykiJtmGVNvGDw 1mKn1m7fqG498wU4ARzirH2IAleC7LYnjqE1zo74qG1cmBqwWhQUdfDV8moiYUG0u5eXm8gRlT6u wqt9q0unD2HfyEfwfThfKZRo/eVxuYvVvTvIZS3RNCOO9wY8TGC+Sn4Ly+5vm+GreAnjx2IBkUMm m8ztyejdW+CDPa4OAvCsjEzJ8OCm5HbWoguCHlCzrNnty8sOhvEr5cUO+AhyHK5vSxa/cm7VVumg bGR2MJcIc3o6wGTgWHytcKHoh3L2diZkMcUpC63iWuo6v6ZRIk9gq43UKso23LvBAgegryTT6RUp 3LyNRgA11TqQDiulYMyo94xTRSWyNorFBMsX0HBDaheZEr03q7lpyR6ckkJ2xav4ghQ23pOLoFQb uQp+MzFz6LkZyA/L4t6ArKa22GZuEyxMC8s+B5PZb8F38Me3+2W9OiJrqHxdaB8lowygDJtRi8ad AAAMhElEQVTAEFV5nb1E9fiTeiKe3FBJJm+9JOkikISJAMiI3v+Em22sbuUwdphT2Ugbe462CoOy Nz0g42u3AawOWn10fKJDMjTS5iCB+lT6lEIDaX1kTgYm6RCbXt2QaOaVZYakaMBN0O799/a7uWo9 WczKyi62PhrcgFwiImr0JiR4a99ZuM3p+aYfvKSB45aMYL5iSDKbvMcrdwhN3cTK53XM2Q3y3yNc m5yNsuHxIRnIbcjojeuSRs93FBoriUYJERa/hb23eNg4LmJOd7GC/R1pY2w1tAikYWe7JP/qDz4q P/umV8sDJ+YwxcQ2B0ISovyiXfaPHpAqplTlhzGdokX0OghAlhs+AZKMv5fpK27I0Lc+agp0y3Vd itpDik7SADZbfMU/QPfrmvRVVvCxbclWAxDzjjMjKqljcmMPG8CWr6HibNNSiwk3GI1dvIOVIRmu PCh/u4HJ9kUINcoaggk7vYfMHu6vytiNPVm+gUnprW2hU+gan2sechM5KWRuyegXP4Wetl04Z8kj 4lBR8bHXSHbsnPRfeQE2k7xeUqhoyiNHJPPE62Qiew6G3TKrdSUvJqruYJuFyg/KlY3zsp6+CStO Xl4cahuQAuYKPiRfw0Jer2HaNc1hCZllMwD8BK6b34UHyBLagchYT/aNZmVKzkrfl74gVe1NCqOo h3dAUsGwZOaHXiETlz8nfSUw4yBPprClU2X2jZI7MigT1WeQV5K3Y+qhupmTnfIpOb93Hmy4UQx2 P5XZyj3y4mpJzqN1nnxpjGFWqPRQtiyPwiG/+x1ssN2mnujWAjBDRObuy8nM5z+N7QqQYbRLsDU0 ksK+mII6cq3j8msKc60yJ07KVv6wTLz4GemLka4bdlNokPX9wM9IfwFbr5Rc1ZPUzFEsFBiXc7sv usn3wJCFQzOVuke+vlKWNSwYcVFPkpPjBUzdurkla9d2ndWTq2MbMje7JhOf+aRksAhGR7OAO9GA hWp9jz2KtQjrkr/8HeBoPTLFxiEOZZIy1hUMXfymTJXP6rSMVjSxntweOSp7r3gcvtj1Wvdxq0R0 XeEXpAqHUGnAAcSjV/KhxyhGRcvWZRWFJzME77nxootAB5BC4QrNilYA3WTB1pRpawk9ZRymYRlg Ziwkj0crY4Dl3C6VF7qGEw/UA/6UBzic5KKq45wJYyIaBQ5e2JsVo/DslALqHoC1MNNVyo56zYiA fhLt2FgxGUs2UBOUk66uRjVq8CSLg9AqyLsVDIXRDNjzoIwljQbi4WR0nUPGCfzEk3SgCtCaYQ5J E74D+1KSISizCIV2RqQOeLG6J3S/R564kg0KkT8wZjtvKVkMRjqsHmjPqnYamosAPrhYSG2LOFyg oU0BLstiLY9VgK2Z6aY9pflQ7ddlPQniWU9SVH0UVjeUtuZdxcMyDNGoG1f1JKmv2rpRdZQ8Lyoo ZQg/LMMgOBcdDCl6s6iHTQBn7coxZZ7xzR872tqmoRFjgQiLLz3kgknbBo3sxVKNWgcQD3HkTST+ WAbTMFGchG0pa4hg4OovhOeiO5h0Uy/qyCoPcQYQGsiM8ai6Vy1xHghwuBCXTz+AW/i+nmIQGTcK KzIyYJmwuOKmjxMv2BBRo3aBhIRQ8ybLEYMb7RvImm0cYVBOoA9ViaLDD68OAnVvQKPWcWFfWr14 9JMhIjMIE+aGsIPAnSDxiKfMrNySx6NVswe2hidZcamkWA6TIzocZdx5OJPEpAsQTI1m9OPCxtSu WPB7DDjgQ2VCuBZ2na0lKTEPFvAYVBZh0jg8y1I81paTxWHVTr1w5ocvu0TRKAMGuNoBn9ncTDik 4QFa+yIj5KdV0O+BSLwNPIYmpZDw33T3mPvQeE0v6wF3NvYBLVFRJvg39kWCV7JlWKsJMkHwAKWV MpWEgs04ZvomWSSApj1lqk3Fkjh8C1C1YbxN75UL/dBpsr0n9YZk6ej5GgBLh0NZ6hloFAAjowDK qIhdv1crVhvrGkS8hG4FpTQQBS1As43moHikdRqLeKgZl3rplKau4nt8GGbccEN9MJjVm25wKHzg UUzGCBRn0j+1BobhyVhB0lgIz8qJV4sraTwGh8WUNPQ6eK5YsEgAv8K6X5+JzAFXAGnLSjcupmWm 8epaeI34EnymGugI9sBCZ+4vEDlSf4NUHBhYA4a6Rxi3Ne+694k8qJZ6UlJcMnqwg5go9kf7JMY9 L8Syf3a2f5jIl5tgnA3Hmnk5CCogfvcyg8D2wflXlhyrnjgMK/tgBPvAyz4VYijGHDNTB9+hbhyz EciWL4tb1URnHlwT3x0mh2/O8kYxOzQEkEno2hJwVbiRD8DWbTrAUJ2NN4mp+xc++cTnCInmGxUY f1znImqFZuMIjwdWOfGF1738W6W0InPEiaJWHPviaBKT+2D2kXOHx+pkf7hxx4dCNspHQcYbN1ZG qNpzpjjc8aNlseIAL25YMb2Y2G7EffAYcIrKkZBCheOUEdW32dImFHkyLyEutTFA8/qak4H7MobC 6pGr2nupXjpzAGlnQOjY3NQEeuIqhtItDxSgKTtdZVjC9bC5QuHxa3mKwX5vUfYNUW9kfk+kpqzw 51b1gL4fOkFG0a1Z3DLjWFb7bRWuFeNYGY3iermw45oPys2xU+6rxvTI+I/J3wSF5dDeFE0QV/Kc vLwgGle5l36lzhzAuqLZoSFAS3RsFYMjeyB8U2kSkWJyYxuWfocolHCF7xqJVQyXLTkMYEMH5a3s HKCyoF2qnmQTvtkA2mJ0wAxB+qvOHMEnWJoXloG6rNd0LhsXzjlkY99AQ/nkw8zPc4eVWFzjoEZU J84zDNeZ7pP2XaNxLSvPpOw8UFcWptPMXKz6byLYtUKaEH5/v2BBDOX0IjUcIoHkOOw4zp5L3ACq mkV8bjzHtefYEkbXoScuRizRxrYZZTBXrux5Q87JIuGWCTwDt4SKs4g/nlfsZPQBMiulgYuHVpfc FNRUA/fo061feJ6gtNs8u0tZUu3YsbyKfY4EG69iI8guAbVIhn26qmXAZoHDjcF6se4WaLiYhY5Z mXvC6dZGySMijjLySRl5DNtnOVlwRhZ1Gwis0C7BiLm5qYveQEqHx7ABC8wL+nGhGJoTVuVxqykt k2ALTrxN6pt2RsGZrW1xTTqoxBQPD5RneeZCMShdUEbyXGKvDEuaDcCjSZX6YM2wY5Zj+O8kYGsz 5QO74MLGUMZ02D0Riyic4VxFGVnhRrssZ1w5aahTWVaaMoy6dyE0wkX5hX1HjI0lj4NWrHuzsixD meyqntQyEvBtPYkd7WOps5NILFbKMF7dZoj1F8uxGBvad4JD49LGWHbZerKdjdHOYe7F3R2pFHeR Do4dM12rQPglJOKeM+qPtYmvsBBHaanFxWGHODT7oTfhc7weijT2G+sfOyapwW2k4Z+LXIpzBVPT chT2vFUagWOWPA62MrNlHE7eNyV7Qzh8HYVO8lgo9aocw/mxg4WSjE3htAYHvNADyBT6ZRybO/an XostjeE0u9jYGJXM2Py9OD5qEsebzDvRPZ2m/oEJ6Rs/BoeWu5XHs0tE7DDgbMnquBwtH5ctbG9s 5590CKRldNpYPoWDxYcnsflmyYFGDPo+HM93GEcDFUuQF8oFJyJjmVHI4OQMHJ2HEyd49FbiAXbM DaaH5o9LuuBVnokjIUCcIT52RrIj07h/GH8ucj6nyuB0ntSsHN/jRrCsrJO3ZVSZMlmdlfRADqfB uLBi47qMZqoyi13sC3s4r4F+RvKsqEM+cTgv2Vc+KbKB03kclJUpOMv5qQOSmR+RVP8PexUi+Ek4 0AEYPAw7HkKFXt0CdBc2hgafTMh4/5jM8wi2XsYCI/inqvMo90cyR+Thgbxs75VcqB5WXJWD+ayM Z4syMe6unuwb6JOx8WHJPvFaSe/toI5J/gAAOv25o3PSNwQHE6d1xLHjNKL+cP5BOXh8SqqjoKmd 08gaHserVgfmRIb0JOkIDQZfsxCHHaZZr5qQ2tzaQuMUhVOcDM30Gg8/tOeaI+mBS/ACFLA7p8Gw bLYedoYIPNisrzo1SJNFp3rhltYIzpAY1fvTTYjHFS9OumLDRG5179jQKCig8GUXRkqP73RuntMM SXV782Wpe2fM0K5oWMSBiysbIw7F48iboT6N2tuX5YzbQ6DbR1Hxz1WgGqx/4QwPANPn041wXTFC KVndqyfrDJHHDPA5Exhpp+75z23g+cnMKS7x+FndVZYk8bAvngOunDgvw4gGuHzG8NwisBef563H ik4WNFPih1c+xw2BhtX/C0h9/coLNGgDAAAAAElFTkSuQmCC --Apple-Mail=_B2080E11-15D5-4295-AADA-3B013FAFF482-- --Apple-Mail=_A8C81A1F-1878-4DDF-8313-A644275E00C7-- From nobody Sat May 2 18:16: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 57DC83A11A0 for ; Sat, 2 May 2020 18:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=00KUZYZA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lv89gprX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfS3cwbmo-6f for ; Sat, 2 May 2020 18:15:58 -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 7F0083A11A2 for ; Sat, 2 May 2020 18:15:55 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A30B95C05A7; Sat, 2 May 2020 21:15:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 02 May 2020 21:15:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=0 WL+JK3TeUAUXSAQWtU0lQjARQMw3xoQu7Kc5bnqf7Y=; b=00KUZYZAAEpJhcRKh rPsh3d0nj7TzHvRqRWTl2OC4WMLh8F1RYXNnvt6gIe+KB2pUQLlJr4RyYX4Nw5Yl QTKhkZup8o+Ba28GY0t1cxR4AEy7MZ914RaF+0N5lPNDQmJipXkQSYIR6F1eOwzE YvPbpK3Kt/aYlRoESIDQK4Ws7EFbH23QFJgqLmUxTv4xpNmc65IM+VhKlxx0ff+e tMcoJTGbivOz4r1CCpAMBv8iFB+ilXd8j4rXjfvZxTHcJH52fZQnPSClag/GyfKA hmjr5rphX9VFfHtoMBEx9c19hD/l9M/9hBwRb/BUmHpgpS4ofP3GplBrAxabkLCv r1Ebg== 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=fm2; bh=0WL+JK3TeUAUXSAQWtU0lQjARQMw3xoQu7Kc5bnqf 7Y=; b=lv89gprX3hlYirR3zm2sV/UACWVwV4I105VdVsZNzv52f5ARdCe0u+/LN DUfSOudtQDbjBXWAyFXp7Eglytg+MrhCYjzECVdgeEo1ZnjRwkTwne2FANh7o0jj 2a/GAuOzwXYNtGU6ys9EvZJiAvs4vdwhVNseHHyo6FpCyz0RZdydjEzVJLPBbU1O sKbMoqNZ4GiTqBlhOr3WVP011UUDAiaqOowtKdhv+Xpm4l7HuK+dWHoqUCL3Cbst Wa6j3JhYJQGLpnZQCTsjhZe7G9ND8hKCXJvXJ6nLW07EHKqn/iYHziAIbxg73ehW mSJ6Sy6PhIilVLudGxKxFQ7+rMSbA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjedtgdegudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepueetjeegjeffvdegkeegheefieeivdfhuddutdffheevtdfftdevgfelheejffei necuffhomhgrihhnpehtihhmvggrnhguuggrthgvrdgtohhmpdhirggsrdhorhhgpdhmnh hothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 0568C3065FBA; Sat, 2 May 2020 21:15:52 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <07A54E01-C334-4C31-A8CE-880B7A78A476@cisco.com> Date: Sun, 3 May 2020 11:15:50 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4429DC0F-E674-4F2D-A3E1-AEE7A680A821@cisco.com> <59A885AB-1F57-42DD-9B55-CFECF44D2C16@mnot.net> <07A54E01-C334-4C31-A8CE-880B7A78A476@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] follow-up in virtual meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 01:15:59 -0000 Wow, that's quite the spread. Could you send me all of the timezones represented (specifically; = Northern/Southern Hemisphere matters)? We have a tool and I'm curious to = see what it says... > On 1 May 2020, at 7:39 pm, Eliot Lear = wrote: >=20 > Good evening Mark, >=20 >> On 1 May 2020, at 10:10, Mark Nottingham wrote: >>=20 >>=20 >>> On 1 May 2020, at 5:36 pm, Eliot Lear = wrote: >>>=20 >>> As part of the IETF =E2=80=9Cshare the pain=E2=80=9D philosophy, the = 9:00PM GMT slot is not offered in the poll. >>=20 >> I'm not sure that's really the best approach. The extremely limited = slots you've offered put the proposed meeting at either 1am or 4pm my = time; guess which I chose? I'm sure that someone else is going to be put = in the opposite position.=20 >=20 > Indeed. >=20 >>=20 >> Rather than having us battle it out with a false choice, why not open = up more diverse slots so we can see if there's a time that's at least = semi-humane for all? >=20 > Unfortunately I don=E2=80=99t think there is. Please see below. >=20 >>=20 >> Or, rather than using Doodle to select the time, why don't we = calculate the 'least-pain' time for all involved timezones (as we've = done on the IAB for a while now)? >=20 > I did indeed try to do this. Based on those who participated in the = Doodle, here=E2=80=99s an illustration of the time zones we need to = cover, using timeanddate.com (assuming Apple Mail doesn=E2=80=99t move = it): >=20 > >=20 >=20 > That is a pretty wide swathe of the planet. >=20 > The coming meeting will be inconvenient to Europe and all but = impossible for India. The 6:00am GMT slot is also inconvenient for = Europe, inconvenient for the West Coast, and all but impossible for the = East Coast. The 3:00pm slot is inconvenient for the West Coast, but all = but impossible for Melbourne/Auckland. This assumes the same group of = participants. I=E2=80=99m sure there will be some variation. >=20 > Thus the share the pain approach, so that everyone has an opportunity = to participate. >=20 > However=E2=80=A6 we have time (so to speak) if people want to change = the approach. >=20 > Eliot > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Sun May 3 01:14: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 EA02F3A16CB for ; Sun, 3 May 2020 01:14: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 Jh1MulESr9zN for ; Sun, 3 May 2020 01:14:45 -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 D8B553A16C8 for ; Sun, 3 May 2020 01:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2661; q=dns/txt; s=iport; t=1588493685; x=1589703285; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TykumAoXKbC8CsrOQxyQAutXszjpWHV1beAXF9r/DAc=; b=CSJZMyobEWbVnxGODU3P8Xaot73GEkW1XZugjV9bW4fisAejFYKqHzUz 8zvYkSVW/pf7dejCCNj+VzbdnbUwlZWP8Dz8tKIcXXJMRR/oKGSE2nyrE QWzYlrc7cQKmXyE7qzIamhWfJs88ldJqQFbCpfIsn+kw4Q1m3ZtU8FSgv 8=; X-IPAS-Result: =?us-ascii?q?A0BrAAAdfa5e/xbLJq1mGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFHgipuVAEgEiqEIokBh2slm14LAQEBDAEBGAsMBAEBhEQCg?= =?us-ascii?q?lQ4EwIDAQEBAwIDAQEBAQUBAQECAQUEbYVWDIVxAQEBAQIBAQEhSwsFCwsOC?= =?us-ascii?q?gICJgICJzAGE4MmAYJcIA+xbXaBMoVQhTaBDiqMXoIAgTgMEIIYNT6CZwEDg?= =?us-ascii?q?ToHAQEggxIzgi0EskmCUIJvhSaPeB2CW4ELh1OMcIRyqWSDRAIEBgUCFYFpI?= =?us-ascii?q?oFWMxoIGxU7KgGCPgk1EhgNkE4Xg0+EWTuFRD8DMAI0AgYBBwEBAwmMXoJFA?= =?us-ascii?q?QE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.73,347,1583193600"; d="scan'208";a="23528032" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 May 2020 08:14:40 +0000 Received: from dhcp-10-61-111-153.cisco.com (dhcp-10-61-111-153.cisco.com [10.61.111.153]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0438ELeX014059 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 3 May 2020 08:14:40 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Sun, 3 May 2020 10:14:40 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <13C33D9F-C8E9-4893-8607-6EE1B2F5CD24@cisco.com> References: <4429DC0F-E674-4F2D-A3E1-AEE7A680A821@cisco.com> <59A885AB-1F57-42DD-9B55-CFECF44D2C16@mnot.net> <07A54E01-C334-4C31-A8CE-880B7A78A476@cisco.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.111.153, dhcp-10-61-111-153.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] follow-up in virtual meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 08:14:47 -0000 Sure thing. Under separate cover. Eliot > On 3 May 2020, at 03:15, Mark Nottingham wrote: >=20 > Wow, that's quite the spread. >=20 > Could you send me all of the timezones represented (specifically; = Northern/Southern Hemisphere matters)? We have a tool and I'm curious to = see what it says... >=20 >=20 >> On 1 May 2020, at 7:39 pm, Eliot Lear = wrote: >>=20 >> Good evening Mark, >>=20 >>> On 1 May 2020, at 10:10, Mark Nottingham wrote: >>>=20 >>>=20 >>>> On 1 May 2020, at 5:36 pm, Eliot Lear = wrote: >>>>=20 >>>> As part of the IETF =E2=80=9Cshare the pain=E2=80=9D philosophy, = the 9:00PM GMT slot is not offered in the poll. >>>=20 >>> I'm not sure that's really the best approach. The extremely limited = slots you've offered put the proposed meeting at either 1am or 4pm my = time; guess which I chose? I'm sure that someone else is going to be put = in the opposite position.=20 >>=20 >> Indeed. >>=20 >>>=20 >>> Rather than having us battle it out with a false choice, why not = open up more diverse slots so we can see if there's a time that's at = least semi-humane for all? >>=20 >> Unfortunately I don=E2=80=99t think there is. Please see below. >>=20 >>>=20 >>> Or, rather than using Doodle to select the time, why don't we = calculate the 'least-pain' time for all involved timezones (as we've = done on the IAB for a while now)? >>=20 >> I did indeed try to do this. Based on those who participated in the = Doodle, here=E2=80=99s an illustration of the time zones we need to = cover, using timeanddate.com (assuming Apple Mail doesn=E2=80=99t move = it): >>=20 >> >>=20 >>=20 >> That is a pretty wide swathe of the planet. >>=20 >> The coming meeting will be inconvenient to Europe and all but = impossible for India. The 6:00am GMT slot is also inconvenient for = Europe, inconvenient for the West Coast, and all but impossible for the = East Coast. The 3:00pm slot is inconvenient for the West Coast, but all = but impossible for Melbourne/Auckland. This assumes the same group of = participants. I=E2=80=99m sure there will be some variation. >>=20 >> Thus the share the pain approach, so that everyone has an opportunity = to participate. >>=20 >> However=E2=80=A6 we have time (so to speak) if people want to change = the approach. >>=20 >> Eliot >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Tue May 5 16:36: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 16D5B3A0C56 for ; Tue, 5 May 2020 16:36:00 -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 kgTJptSBxA7d for ; Tue, 5 May 2020 16:35:59 -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 DE0983A0C57 for ; Tue, 5 May 2020 16:35:58 -0700 (PDT) From: Jay Daley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Wed, 6 May 2020 11:35:56 +1200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2020 23:36:00 -0000 I=E2=80=99ve seen some people suggest that the RFC Series could be open = to other standards development organisations (SDO) to use as their = primary publication stream and therefore that the RFC Series needs to = maintain a degree of independence that allows that. My issue then is how that fits with the use of the RFC Series for = publishing administrative RFCs about the IETF - Does this practice = intertwine the RFC Series with the IETF too much? Would any other SDO = also be able to publish administrative RFCs? Is there any point at = which the ratio of administrative to technical RFCs becomes an issue for = the RFC Series? Are any changes needed to mitigate against that = becoming a problem? To be clear I do not include RFCs about the RFC Series itself in my = definition of administrative RFCs. Jay --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Tue May 5 17:31: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 943783A0C6D for ; Tue, 5 May 2020 17:30:58 -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, 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 fUwpjWQlabhQ for ; Tue, 5 May 2020 17:30:56 -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 9EEF33A0C38 for ; Tue, 5 May 2020 17:30:56 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id w29so38404qtv.3 for ; Tue, 05 May 2020 17:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=a1FlaXiZ2K9UANdo0A6+CVB5usQEtIQV/E2J6t8ZYCA=; b=zdubrQgQF/oRJUZCyHhWu+Djt0EZ6qI0r3L7hbg9eJwgY/9QpVfRBXJE6Xrqn4udpM 9VmuvP5TPvClpXRGxugGoPNdxF8Ql8Gola+C/p8IDZjRoTHHUuHuGkIMg5fbObUokwKv JgzFjNxEQEvOEFBnQGZ8t2gekz8ac3J5k1N95R6qqYAHid1xzzGF4hrDk72hXNajGJIK iEA5FfdQvijKiQgv3vagCkEtb5lE+lw5LixFJFMb2wnO/e+5XTkNm1D7zHtlBmPvCSNj p8nxD9jzkm786VxLr1RhQYz6DLUAoIg3PhIAv1ulLa9A96AW/AUaT/FFVhK5k9YbliIC P/xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=a1FlaXiZ2K9UANdo0A6+CVB5usQEtIQV/E2J6t8ZYCA=; b=lK9Thl+LN7Fc+DbnZoONGlMkT6KPtMiCtYTloLtLGadda8J9XMxAETVsknWeuip2Dl 7vhezi5FfYMrUG5OEuTHExXaH8jHfC8Z6XGUTbqrOHLxLCdbmHBTMf9xphTsDFrSZJIE CoqvtjGEUHCLtiazdMalSTQ+Ik3k5jRR17Y2aTgBnUnEtWLSKK4oj+1O0QSNPfOPAkxq zVwKvsr5f3Sm55g9MUdPyN/6JBtp7elVjl3DCVJWLPpkeHYQW0iklNTrsOjvB4wJJ0fn q2jl1F86PoljDhL0bV6ntZFb98T0fH8HuT5YJyQf4cZrhvWIvGAJsAgCtTmeJoSzZTm4 h8nQ== X-Gm-Message-State: AGi0PuZJXU0x9JYf8syH96VFcVhf3oW8FY3ReXDW4YIyk92UDBCMroVa jqdubUXPKCY7pkE+L15fdnT8xH81DRkagQ== X-Google-Smtp-Source: APiQypJOQ4N6TScHF3Op3fOBwr/CoL040miJ8Kp6VbJ67d+veBMomMnE6iqPtHEUggey/r8cs2Z+vA== X-Received: by 2002:ac8:3025:: with SMTP id f34mr5795850qte.219.1588725055150; Tue, 05 May 2020 17:30:55 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:78b4:47ec:38f7:5b9e? ([2601:18b:300:36ee:78b4:47ec:38f7:5b9e]) by smtp.gmail.com with ESMTPSA id p75sm419543qke.121.2020.05.05.17.30.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 May 2020 17:30:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Tue, 5 May 2020 20:30:53 -0400 Message-Id: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> References: Cc: rfced-future@iab.org In-Reply-To: To: Jay Daley X-Mailer: iPhone Mail (17F63) Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 00:30:59 -0000 I think slowing other SDOs to publish RFCs will make end runs a lot easier. I= do not think making it possible for the RFC editor to do this is a good goa= l.=20 > On May 5, 2020, at 19:36, Jay Daley wrote: >=20 > =EF=BB=BFI=E2=80=99ve seen some people suggest that the RFC Series could b= e open to other standards development organisations (SDO) to use as their pr= imary publication stream and therefore that the RFC Series needs to maintain= a degree of independence that allows that. >=20 > My issue then is how that fits with the use of the RFC Series for publishi= ng administrative RFCs about the IETF - Does this practice intertwine the RFC= Series with the IETF too much? Would any other SDO also be able to publish= administrative RFCs? Is there any point at which the ratio of administrati= ve to technical RFCs becomes an issue for the RFC Series? Are any changes n= eeded to mitigate against that becoming a problem? >=20 > To be clear I do not include RFCs about the RFC Series itself in my defini= tion of administrative RFCs. >=20 > Jay >=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 From nobody Tue May 5 18:12: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 7B8FB3A0CD6 for ; Tue, 5 May 2020 18:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 gRyw-_bFIUBp for ; Tue, 5 May 2020 18:12:24 -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 7674E3A0CAB for ; Tue, 5 May 2020 18:12:24 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id w65so154318pfc.12 for ; Tue, 05 May 2020 18:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dpO0JmiMBM+fdoN077YKm+bMVZaUubm5rEfsPl734Ck=; b=K2t8sHVvQb08LnHfQREZ7knTdNPD3I8YpAb43fgvNYsvfp2XO4jNUNwrqikIbS4+Je ZAonaAHfkYvX1HChjffohLTm5QQmF3UISW5WBWMtIG+lD1Bmu7eRHRJA3XN1I71LaG/F lvgwpzKmMIq7QhYE0PemXU3ooFt9kD6q3N2pGxBIMT514OHkEwov184/enjn5XZB7EcA IwUSZHVCb3Dnv9GLifBkvZN3ssp67gZVuquxAsxSWA9uA6FIcS4qcvYCVGazKoU8sJ38 qbwFjUczE+cy1j0AwCN1EJpjf1nzteU9QHPFIiwSgbDZBYo5VEPhL70ytvUQxMrbDqVc s3ZA== 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=dpO0JmiMBM+fdoN077YKm+bMVZaUubm5rEfsPl734Ck=; b=OTrmFYypr54NoIxQLPkcji1+QW64LqTixcZalc8OQAiz9IBoG/jVTtaMHsbKgPhCrm HhLB/ARUKNXWhx65W0dU5cJb4nax0l4JLYVH53HAG0xTvGYa+8HPdUu8fnbyqIz9np6x rumN6xheV28I6ds4n7CCKW/fL4/vOnd5Ku9lxxxHs+ioYSqVGqkDX/fkO/crmwKNcw5U c3ZK0ihCIBLrCF7DKI0e+DwA8jsDtxO3pvhXtQ2VqN9XiL+W6LFx+Ae8zQOls+dc9vVB CJp/nhYnt2IIP46Lh8u1ZgrFheEaHVyiAuCj3bK+cpmuqSffScxO2uZHJtCJrtmcvGT4 5uew== X-Gm-Message-State: AGi0PuZ2JvHOKfCRttMq1P5tP4EUA8yo/1qvfDb9e+wCvAorKTVjJi7t Qak+Y/vfDV2gtVQLOGDljYB/76oP2fY= X-Google-Smtp-Source: APiQypL0J8ra+Q54zCVeNTEW/lS9zO09LK9RYmtsW4p9ZL8GbfvdV1oBIdv2yq/hAM2fEddb8Tnzng== X-Received: by 2002:a62:144b:: with SMTP id 72mr5886701pfu.246.1588727543423; Tue, 05 May 2020 18:12:23 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id l5sm282705pgt.92.2020.05.05.18.12.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2020 18:12:22 -0700 (PDT) To: Ted Lemon , Jay Daley Cc: rfced-future@iab.org References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> From: Brian E Carpenter Message-ID: <22a4cf4e-74e1-e49a-e214-24bf4ac97fe2@gmail.com> Date: Wed, 6 May 2020 13:12: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: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 01:12:34 -0000 On 06-May-20 12:30, Ted Lemon wrote: > I think slowing other SDOs to publish RFCs will make end runs a lot eas= ier. I do not think making it possible for the RFC editor to do this is a= good goal.=20 I tend to agree. While I think that having diverse streams is a real asse= t, allowing N streams that all assert that they are standards is asking f= or confusion. However, having this issue on the list of issues seems reasonable. We may= end up with a category of Bad Ideas. Brian >> On May 5, 2020, at 19:36, Jay Daley wrote: >> >> =EF=BB=BFI=E2=80=99ve seen some people suggest that the RFC Series cou= ld be open to other standards development organisations (SDO) to use as t= heir primary publication stream and therefore that the RFC Series needs t= o maintain a degree of independence that allows that. >> >> My issue then is how that fits with the use of the RFC Series for publ= ishing administrative RFCs about the IETF - Does this practice intertwine= the RFC Series with the IETF too much? Would any other SDO also be able= to publish administrative RFCs? Is there any point at which the ratio o= f administrative to technical RFCs becomes an issue for the RFC Series? = Are any changes needed to mitigate against that becoming a problem? >> >> To be clear I do not include RFCs about the RFC Series itself in my de= finition of administrative RFCs. >> >> Jay >> >> --=20 >> Jay Daley >> IETF Executive Director >> jay@ietf.org >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Tue May 5 21:19: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 5CF933A0D40 for ; Tue, 5 May 2020 21:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 RcfkZ5igO3fb for ; Tue, 5 May 2020 21:19: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 4A8373A0D42 for ; Tue, 5 May 2020 21:19:33 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 49H3Jf0pWPzyfh; Wed, 6 May 2020 06:19:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> Date: Wed, 6 May 2020 06:19:29 +0200 Cc: Jay Daley , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 610431569.438588-4f643dadda114fe2989670bf29275294 Content-Transfer-Encoding: quoted-printable Message-Id: <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 04:19:37 -0000 On 2020-05-06, at 02:30, Ted Lemon wrote: >=20 > slowing other SDOs to publish RFCs Nice Freudian slip your autocorrector created for you. SCNR. Apart from sorting this under Bad Idea, one other question is how much = control we (IETF/IRTF/IAB) have to prevent this from happening if we = think that is a Bad Idea (a.k.a. hostile takeover protection). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 6 04:09: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 DD92F3A09D1 for ; Wed, 6 May 2020 04:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe8fdGApj8Pa for ; Wed, 6 May 2020 04:08:44 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 F053F3A09B4 for ; Wed, 6 May 2020 04:08:42 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id z90so922935qtd.10 for ; Wed, 06 May 2020 04:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5yPMt8etCoPKSbLE7hVvD0uG0sdkHwyd96/z0gNyH38=; b=ZrilhTId5cjiyfEFow2or9i189Bvvnn2Xrvo4v/kasTXbmAYth7A8MER8ysCHjUbGy XJs0cOfc1I0fEtsaq5TJ5iIsfWZfkXI0oInJ43fRhEbF7Gl97VSYXajPnF6OadtZCKBJ JP6THDAgUYfDyx/2ZGavyYrSLjKp1Rc6bhwtHGB4sVMWMXw+J2En0To/mJnBXtSEFZbS 0WjnPaiAyF/tBNFL6Q/IuRvThnJbJde5y/0XjvO5R8/aIO02jsygOwNUT/cqrRxq3i+U 5hoTG+iwPDKKFjHxGDie6Zgq8kxCuxXWdBl9hNed16FMTGNpQoxqbG9305RaiJZ2jt/f NCuw== 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=5yPMt8etCoPKSbLE7hVvD0uG0sdkHwyd96/z0gNyH38=; b=m29nlvmeogu+I0BlgU2e49iTtuHM3r4bMK4O0TlaX+sep1LVaVU65fnc6tcA8iGKSL 9njjkBfsOz6dx2JDTs6/6qznmIzRryCEkSzQg7eM6TidXqsuiyp7/1Msu5bUvxEInMlY ZQnAVwomC1UOCOLGoDlESr3VWVaNucFPZG8PxhO9/IcLKqEG5Twyl0ysdCyyqykyjy54 GAAeTZLhhRMw72Rwk5mRI8FUJcxS1flTMMdzv33rDAnO0SLGl9OFg5GwqjKV5UbZjV1U M3bmDHJiAfqWkK96/Pn0LrSlRczGWH5+wD7qzniPLV9wQa0opnxqXyF6/4erIc2LpRX4 PDKQ== X-Gm-Message-State: AGi0PuYShER7zwcXYy1Bw6G+H3cRTQoObpzr1zgU7rXKfv7v4FZ8BCY8 ZJtxVxZUvBS6DA5PMXFqdSJ2FhIAS35jYpCOlC0= X-Google-Smtp-Source: APiQypI+8GCV1nWfjADYNv4XYZpYj13H9Ofsuv6w4v/4biZ87ThwEWMnn8K5YnDqi9WdNX7eWNWqc6PP7QFTKSgLHRA= X-Received: by 2002:ac8:4819:: with SMTP id g25mr3959868qtq.279.1588763321714; Wed, 06 May 2020 04:08:41 -0700 (PDT) MIME-Version: 1.0 References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> In-Reply-To: <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> From: "Andrew G. Malis" Date: Wed, 6 May 2020 07:08:30 -0400 Message-ID: To: Carsten Bormann Cc: Ted Lemon , rfced-future@iab.org, Jay Daley Content-Type: multipart/alternative; boundary="0000000000006c4a3005a4f8c930" Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 11:09:05 -0000 --0000000000006c4a3005a4f8c930 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As a hypothetical, what if an SDO or industry forum were to come to the RFC Editor and say that they would like their output documents to be published in the RFC series, and they would be willing to do so using the existing RFC publishing procedures and provide the necessary funding to cover the expenses for additional personnel and overhead? This wouldn't be a hostile takeover, it would just be a new source stream. Would there be different opinions if this SDO were somewhat IETF-adjacent (like the W3C) vs. something less so (the Society of Automotive Engineers)? Cheers, Andy On Wed, May 6, 2020 at 12:19 AM Carsten Bormann wrote: > On 2020-05-06, at 02:30, Ted Lemon wrote: > > > > slowing other SDOs to publish RFCs > > Nice Freudian slip your autocorrector created for you. SCNR. > > Apart from sorting this under Bad Idea, one other question is how much > control we (IETF/IRTF/IAB) have to prevent this from happening if we thin= k > that is a Bad Idea > (a.k.a. hostile takeover protection). > > Gr=C3=BC=C3=9Fe, Carsten > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000006c4a3005a4f8c930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a hypothetical, what if an SDO or industry forum were t= o come to the RFC Editor and say that they would like their output document= s to be published in the RFC series, and they would be willing to do so usi= ng the existing RFC publishing procedures and provide the necessary funding= to cover the expenses for additional personnel and overhead? This wouldn&#= 39;t be a hostile takeover, it would just be a new source stream.

<= /div>
Would there be different opinions if this SDO were somewhat IETF-= adjacent (like the W3C) vs. something less so (the Society of Automotive En= gineers)?

Cheers,
Andy


On Wed, May 6, 2020 at 12:19 AM Carsten Bormann <cabo@tzi.org> wrote:
On 2020-05-06, at 02:30, Ted Lemon <mellon@fugue.com> wro= te:
>
> slowing other SDOs to publish RFCs

Nice Freudian slip your autocorrector created for you.=C2=A0 SCNR.

Apart from sorting this under Bad Idea, one other question is how much cont= rol we (IETF/IRTF/IAB) have to prevent this from happening if we think that= is a Bad Idea
(a.k.a. hostile takeover protection).

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

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000006c4a3005a4f8c930-- From nobody Wed May 6 05:32: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 A82EA3A0AEA for ; Wed, 6 May 2020 05:32:23 -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 NoKE5_DMAqAq for ; Wed, 6 May 2020 05:32:22 -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 2377B3A0B47 for ; Wed, 6 May 2020 05:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1217; q=dns/txt; s=iport; t=1588768332; x=1589977932; h=from:mime-version:subject:message-id:date:to; bh=5f+cc32i4GSB77hDPmisrKc5HR9k0//S6HCSTH8a9iA=; b=FdFr6+N/yHPx3v28ociVGBfUqMrg3b74HnUZlJk1eMyj5R2nYYAVv5yp sLtr2JG+wZHODToua+xoGGzALwPY9v97a/DUdDiC15NjhCb1pXpBJ8VB0 YrReI4y1GAFr8F2AfUTsW9iu0RVIBLdOhp7SPAnyi6xQ2nnPquiPcDvYo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCBABKrbJe/xbLJq1mHgEBCxIMQIE?= =?us-ascii?q?8C4MYVSASjU6HapN3hXUcgXsLAQEBDAEBIwwEAQGGazUIDgIDAQELAQEFAQE?= =?us-ascii?q?BAgEFBG2FVgyHDwGEWAGCfA+kZo4QdIE0hDkBgRaEdwaBOIxeggCBOAwQgk0?= =?us-ascii?q?+hRuFJQSOboocmUeCUoJwhSiPfh2CW4hhhFSNEJlrkASDRAIEBgUCFYFTATe?= =?us-ascii?q?BVjMaCBsVZQGCPz0SGA1Xk12KWD8DZwIGCAEBAwmSRgEB?= X-IronPort-AV: E=Sophos; i="5.73,358,1583193600"; d="scan'208,217"; a="25939051" 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; 06 May 2020 12:32:10 +0000 Received: from [10.61.238.191] ([10.61.238.191]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 046CW9m9013524 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 6 May 2020 12:32:10 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_36EB9A18-1CFF-4969-96C0-99830E7ACCF9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Wed, 6 May 2020 14:32:09 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.238.191, [10.61.238.191] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Reminder: please doodle: Deadline TODAY X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 12:32:30 -0000 --Apple-Mail=_36EB9A18-1CFF-4969-96C0-99830E7ACCF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is for our 2nd virtual meeting. I invite you to doodle now: https://doodle.com/poll/y7ia9vvzifrhrycv = --Apple-Mail=_36EB9A18-1CFF-4969-96C0-99830E7ACCF9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii --Apple-Mail=_36EB9A18-1CFF-4969-96C0-99830E7ACCF9-- From nobody Wed May 6 06:12: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 0943C3A0A87 for ; Wed, 6 May 2020 06:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 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, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FWr2VC22nWIV for ; Wed, 6 May 2020 06:12:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF353A0A85 for ; Wed, 6 May 2020 06:12:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49HH7J18Nxz1p2q9 for ; Wed, 6 May 2020 06:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1588770732; bh=TvuXI08rAxgs2GUKb9JmDXmlseFGfZBj+IDKa6+zRzA=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=gYaq5QBX3FcEM4oZeFSoAO65mu6AdLYqqVi5pnCZuBp1oDotxmGeitkROSmpCGtTM eKiDPzuRQDD4KgSB+aU3JK3CrnAop0xcCY/YDFMd6O2s8/Al4RjV7UDn5Sd4TjDry6 xEArW+lV02vs+WKY4Y4J1uwkD/RsOC/+OxnMnmPE= 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 49HH7H5NVtz1nylD for ; Wed, 6 May 2020 06:12:10 -0700 (PDT) Cc: rfced-future@iab.org References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> From: "Joel M. Halpern" Message-ID: <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> Date: Wed, 6 May 2020 09:12:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 13:12:14 -0000 The cases in the past where this (other SDOs publishing RFCs) has been allowed it was for a group with very low publication rate. And their documents were published through the Independent Stream, and marked as Informational. The particular group was happy with that. There was discussion of creating additional streams for such use, and there was sufficient concern that it was not done. Yours, Joel On 5/6/2020 12:19 AM, Carsten Bormann wrote: > On 2020-05-06, at 02:30, Ted Lemon wrote: >> >> slowing other SDOs to publish RFCs > > Nice Freudian slip your autocorrector created for you. SCNR. > > Apart from sorting this under Bad Idea, one other question is how much control we (IETF/IRTF/IAB) have to prevent this from happening if we think that is a Bad Idea > (a.k.a. hostile takeover protection). > > Grüße, Carsten > From nobody Wed May 6 06:23: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 342923A02BE for ; Wed, 6 May 2020 06:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lpaoseBRSzo for ; Wed, 6 May 2020 06:23:30 -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 A81973A00D9 for ; Wed, 6 May 2020 06:23:19 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 49HHN55xTSz109s; Wed, 6 May 2020 15:23:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> Date: Wed, 6 May 2020 15:23:17 +0200 Cc: rfced-future@iab.org X-Mao-Original-Outgoing-Id: 610464197.275714-258f1d5205493bb1a16e7edc7bd4deb8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 13:23:32 -0000 On 2020-05-06, at 15:12, Joel M. Halpern wrote: >=20 > The cases in the past where this (other SDOs publishing RFCs) has been = allowed it was for a group with very low publication rate. And their = documents were published through the Independent Stream, Right, and we have the IESG process review to make sure this does not = create confusion. > and marked as Informational. The particular group was happy with = that. >=20 > There was discussion of creating additional streams for such use, and = there was sufficient concern that it was not done. Which does not surprise me, as it would remove the IESG as a final gate. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 6 07:00: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 3D5243A076F for ; Wed, 6 May 2020 07:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.355 X-Spam-Level: X-Spam-Status: No, score=-0.355 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=1.54, 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=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 qlrxJ_2bZyXR for ; Wed, 6 May 2020 07:00:51 -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 271B73A0747 for ; Wed, 6 May 2020 07:00:49 -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 046E0kJ2029829; Wed, 6 May 2020 15:00:46 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8CCE022040; Wed, 6 May 2020 15:00:45 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 76F7E2203D; Wed, 6 May 2020 15:00:45 +0100 (BST) Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 046E0fcX021033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 May 2020 15:00:43 +0100 Reply-To: From: "Adrian Farrel" To: Cc: "'Joel M. Halpern'" References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> In-Reply-To: <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> Date: Wed, 6 May 2020 15:00:40 +0100 Organization: Old Dog Consulting Message-ID: <09de01d623ae$bc0a94a0$341fbde0$@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: AQKbrH33UjxDS4/A/+R+8CnFbrphhAKOp2oMAqB9jrICPkmURabUlarg Content-Language: en-gb X-Originating-IP: 81.174.202.163 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-25402.005 X-TM-AS-Result: No--9.550-10.0-31-10 X-imss-scan-details: No--9.550-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25402.005 X-TMASE-Result: 10--9.549600-10.000000 X-TMASE-MatchedRID: z5DqD3Ob673kQwDXuLnCoXFPUrVDm6jtyeUl7aCTy8hzeyET2AiZDyzy bVqWyY2NMUKJukKHZVZclrB7vjWGxAQY2u4OB1PN1a9nQumsfmp9fBnPNXVD/yNBWGZQkFR8oD1 LUlwKHRa875G7tK0B8MCaL/b91hU0P9YLmypL7ZqK2+RZ4/fWSQEoHzC4m9uQuSti1BoHqPYgfJ jGCsgARfyADIkhx/IM33DUbhesK8kX/TezOcHTecCQs6qVpjnlRf40pT7Zmv78g8n+WW7IPTJSC mhB4T5q01P39PgZGsqI/h6Y6IXmwW37z/25P5odyf21YeIsPYYgT/sXtGXrfyD5N2KTxq5koCyy 4pUARDcDNg0P1t7Y2hAgipU1AOLB8oWuLhK0Tf23RxL+7EfzsE8b3EVTfyDm/1vUyJ9kJXKJlMg QaW1mzV0WFL7LX0deujAorP/yspqrCgcAAGytCBGBzzzijUtVB4Id7CiQcz87sEw6V/IotAB3nZ WN6dEsyqY4Xr/0pbqzRoLWnk8b2z4Pcn5OGAtGD/X0Tn3Ms3iuuK/EsLHVNBZ50KsQddqXCt5V5 6tXaooSZmqWTdxLddsaE5T38gdYNlBChwzdMMzCtSG/SQAC8ZLQR37yyvyamyiLZetSf8mNwWY+ KmOUGwzKt8/2P4LVec3QM3secWZDkJdBhn5RHZXp1f+lmNxctIMGU1rgUojDYma5W69sQGB8AdN JLw+DlExlQIQeRG0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 14:00:54 -0000 Just chiming in here with my ISE hat on... This ISE is not inclined to use the Independent Stream as a mechanism = for other SDOs to publish their material. If they are real SDOs they = will have their own publication venues. However, their may be occasions = where it is deemed beneficial to the Internet Community to reproduce = material from other SDOs in RFC format thus making that material more = accessible. A recent example is the translation (from Russian) of = certain security specifications first published in Russia. Now, without any hats on... This thread cuts to the very core of one of the issues that is least = clear in my mind: who owns the RFC series, and what is it for? To take a very concrete example which has echoes in what IANA does, = suppose that the W3C [1] decided it would like to publish its output as = RFCs. Suppose that the RSE thought this was a good idea, suppose that = the output was "related to the Internet" (which it probably is), and = suppose that the W3C had money to fund the RPC and RFC Editor = system/tools proportional to the number of pages of RFC it wanted to = publish. - Who would make the decision? - Who would have input to the decision? - Who would arrange any contracts? - Who would be responsible for ensuring that the W3C RFCs were easily=20 distinguishable from the other RFCs, and who would agree that was the right thing to do? Best, Adrian [1] Note, I am not suggesting that the W3C wants to do any of this. Nor = am I suggesting it is a good idea. I am simply using this as an example = that may make the hypothetical more tangible. -----Original Message----- From: Rfced-future On Behalf Of Joel M. = Halpern Sent: 06 May 2020 14:12 Cc: rfced-future@iab.org Subject: Re: [Rfced-future] Another possible issue to consider The cases in the past where this (other SDOs publishing RFCs) has been=20 allowed it was for a group with very low publication rate. And their=20 documents were published through the Independent Stream, and marked as=20 Informational. The particular group was happy with that. There was discussion of creating additional streams for such use, and=20 there was sufficient concern that it was not done. Yours, Joel On 5/6/2020 12:19 AM, Carsten Bormann wrote: > On 2020-05-06, at 02:30, Ted Lemon wrote: >> >> slowing other SDOs to publish RFCs >=20 > Nice Freudian slip your autocorrector created for you. SCNR. >=20 > Apart from sorting this under Bad Idea, one other question is how much = control we (IETF/IRTF/IAB) have to prevent this from happening if we = think that is a Bad Idea > (a.k.a. hostile takeover protection). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --=20 Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed May 6 07:06: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 25AF33A076C for ; Wed, 6 May 2020 07:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlcUb-pxH3NS for ; Wed, 6 May 2020 07:06:08 -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 B18713A0784 for ; Wed, 6 May 2020 07:06:07 -0700 (PDT) Received: (qmail 56681 invoked from network); 6 May 2020 14:06:05 -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=dd67.5eb2c44d.k2005; bh=YLkU3WNFZEYwtrtxxeNaCaMaKZ23Q2ge2EuPdNBfGqo=; b=NmSQF/S3u5EmYh+3o5Cc0A7nscuS8kVl1ncu5f8bomoN/EoC7ESqARROCP8MHK9KT9lrg0ytBGRYpjKo24Kn8UP6FLj11xawBEtW6ckO5StadwdEYd3pTMDdCBI0l5MZ8HSfceHPlSCG/aNxMGmrJoh3tnytbBf4HrOCKAc6yOR9M0Os4MaiT8bd6OtaHeJlHHjJQzlyNx1cCBVCff91rk5hx8GYYidW6l5aVG4PT9EeoK+qU5i+P/4JZsjBVVfp Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 May 2020 14:06:05 -0000 Received: by ary.qy (Postfix, from userid 501) id 5F04718D374B; Wed, 6 May 2020 10:06:05 -0400 (EDT) Date: 6 May 2020 10:06:05 -0400 Message-Id: <20200506140605.5F04718D374B@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: jmh@joelhalpern.com In-Reply-To: <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.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] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 14:06:11 -0000 In article <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> you write: >The cases in the past where this (other SDOs publishing RFCs) has been >allowed it was for a group with very low publication rate. And their >documents were published through the Independent Stream, and marked as >Informational. The particular group was happy with that. > >There was discussion of creating additional streams for such use, and >there was sufficient concern that it was not done. This sounds sufficiently hypothetical that I wouldn't want to spend a lot of time planning for it. From nobody Wed May 6 07:55: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 5C8923A0A0A for ; Wed, 6 May 2020 07:54:55 -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 T-lsLEuHzAEs for ; Wed, 6 May 2020 07:54:50 -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 2BEC43A09FD for ; Wed, 6 May 2020 07:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6284; q=dns/txt; s=iport; t=1588776890; x=1589986490; h=from:mime-version:subject:message-id:date:to; bh=DcSZWbfPdTRwI7GnW3IsYaZLOIbrY4mOMsTT3LgrQvg=; b=VBpZh1V0nQ4JeK86QKQq3HlSa9cRI7kFsJh6R1aVru2IsAZejqJ95wjz oK5S1AcKygNYPUcGCaFmRWdBx9zoQwLfdlkneeGnDPeigHuYj+Pta2iJp q9q0hikvP5CuKpqB818ytcGz1uVJecDEFWHOkyeHh55in6BNv5OVpivNz 4=; X-IPAS-Result: =?us-ascii?q?A0AkBQCIzrJe/xbLJq1mglCBeAWBG1UgEiqEI4kBm2CGE?= =?us-ascii?q?YF7CwEBAQwBAR4RBAEBhms2Bw4CAwEBAQMCAwEBAQEFAQEBAgEFBG2FVgyGG?= =?us-ascii?q?09kAoQYAYJ8D6UFjhB2gTKEUBhohQIGgTiMXoIAgREnHIVyAgKEdTOCLQSyU?= =?us-ascii?q?YJSBIJshSiPfh2QEI0QmWuQBINEAgQGBQIVgVkLJ4FDDAczGggbFTsqAYI/P?= =?us-ascii?q?RIYDZFoAQgGgj2KWD8DMDcCBgEHAQEDCZJGAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.73,359,1583193600"; d="scan'208,217"; a="23611418" 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; 06 May 2020 14:54:48 +0000 Received: from [10.61.238.191] ([10.61.238.191]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 046Eslde020205 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 6 May 2020 14:54:47 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_148E70AF-9A50-4B8E-85AB-DCB5C4B0BDA5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Wed, 6 May 2020 16:54:47 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.238.191, [10.61.238.191] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] For next week's meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 14:54:56 -0000 --Apple-Mail=_148E70AF-9A50-4B8E-85AB-DCB5C4B0BDA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For the agenda for next week=E2=80=99s meeting, I thought we might start = by sorting what we think is important for this group to address. We = have a pretty nice list below, and I think it was Mike who perhaps = implicitly suggested that we sort the wheat from the chaff. I wonder if = quick poll would help. If so, I=E2=80=99m thinking of using = surveymonkey. Any objections to that? Eliot The role(s) Sets strategy? What technical capabilities should the RSE be expected to have Is an understanding of archival tools important for the RSE role? What publishing experience is the RSE expected to have? Responsibility for the RPC and its budget? Who owns the series? Authority to impose minimum standards for editing of docs Tooling responsibility? Responsibility to set publishing standards? Insuring compliance with publication standards? Establishing/overseeing formal processes to determine the value of RFCs = to societies? Provides recommendations to make series more accessible to the various = audiences? What level of effort should we expect to accomplish all of this? = Relationships and lines of responsibility, and transparency What roles are defined and what is their relationship to one another? RSE, RSOC, IAB, IESG, Stream managers, LLC, ED, others? To whom is each accountable? How is that accountability expressed? What happens when there are conflicting requirements between the = streams? = What we want from the series Record agreements Timely publication Copy editing can slow that process Role should fit existing organizational structure Bespoke tooling is a bug not a feature Should we worry about legacy? What happens to the series if the IETF disappears What happens to the IETF if the series disappears Ease of navigation? --Apple-Mail=_148E70AF-9A50-4B8E-85AB-DCB5C4B0BDA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

For the agenda for next = week=E2=80=99s meeting, I thought we might start by sorting what we = think is important for this group to address.  We have a pretty = nice list below, and I think it was Mike who perhaps implicitly = suggested that we sort the wheat from the chaff. I wonder if quick poll = would help.  If so, I=E2=80=99m thinking of using surveymonkey. =  Any objections to that?

Eliot


The role(s)

  • Sets = strategy?
  • What technical capabilities should the RSE = be expected to have
    • Is an understanding of = archival tools important for the RSE role?
  • What publishing experience is the RSE expected to = have?
  • Responsibility for the RPC and its = budget?
  • Who owns the series?
  • Authority to impose minimum standards for editing of = docs
  • Tooling responsibility?
  • Responsibility to set publishing standards?
  • Insuring compliance with publication standards?
  • Establishing/overseeing formal processes to determine the = value of RFCs to societies?
    • Provides = recommendations to make series more accessible to the various = audiences?
  • What level of effort should we = expect to accomplish all of this?

Relationships and = lines of responsibility, and transparency

  • What roles are defined and what is their relationship to one = another?
    • RSE, RSOC, IAB, IESG, Stream = managers, LLC, ED, others?
    • To whom is each = accountable?
    • How is that accountability = expressed?
  • What happens when there are = conflicting requirements between the streams?

What we = want from the series

  • Record = agreements
  • Timely publication
  • Copy = editing can slow that process
  • Role should fit = existing organizational structure
  • Bespoke tooling is = a bug not a feature
  • Should we worry about = legacy?
  • What happens to the series if the IETF = disappears
  • What happens to the IETF if the series = disappears
  • Ease of navigation?
= --Apple-Mail=_148E70AF-9A50-4B8E-85AB-DCB5C4B0BDA5-- From nobody Wed May 6 09:01: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 F08053A0CA2 for ; Wed, 6 May 2020 09:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeMdZ733SoRv for ; Wed, 6 May 2020 09:00:57 -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 175D03A0C75 for ; Wed, 6 May 2020 09:00:49 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 411C12CAA8; Wed, 6 May 2020 09:00:49 -0700 (PDT) From: Wes Hardaker To: "Joel M. Halpern" Cc: rfced-future@iab.org References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> Date: Wed, 06 May 2020 09:00:49 -0700 In-Reply-To: <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> (Joel M. Halpern's message of "Wed, 6 May 2020 09:12:09 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 16:01:07 -0000 "Joel M. Halpern" writes: > The cases in the past where this (other SDOs publishing RFCs) has been > allowed it was for a group with very low publication rate. And their > documents were published through the Independent Stream, and marked as > Informational. The particular group was happy with that. And this makes sense right? The IETF is an open organization without true membership. Anyone can publish documents within IETF streams by getting it through that stream's approval process, regardless of whether it came from another SDO or not. Some see the WG formation as burdensome, many others don't know about the independent stream (or more importantly: understand when it's acceptable to use it), etc. The question is: are we happy with the current balance, or in the process of re-thinking things do we want to shift that balance slightly to make it easier or harder for publication of specifications that may have originated in other SDOs. We could make it easier by having a new, separate stream as some have mentioned. We could make it harder by requiring copyright transfer or refusing anything that isn't original publication (like many academic journals do). And, is this even the right thing to be thinking about now or is it a distraction from the primary purpose of this group? [note: intentionally not supplying my own answers] -- Wes Hardaker USC/ISI From nobody Wed May 6 09:01: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 25F123A0C98 for ; Wed, 6 May 2020 09:01: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 x9rra1w-xj5L for ; Wed, 6 May 2020 09:01:09 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 B9BEE3A0C0E for ; Wed, 6 May 2020 09:00:58 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id j2so1770082qtr.12 for ; Wed, 06 May 2020 09:00:58 -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=KuBhe2ueb6/b8I1XKncKxvQsh9ADDFE5g4/LheUEdKY=; b=Ks6GZ9DteLXLalfPjjBXiBqfn9GJXkh9k1zY6bp5s0zyRqXNMQFzD2ca6MvXjSx+ju If/tanyC2ZBaAUfJZa8WsscUq16SnE1GqQXdpUpDu0ZkYyf9eiz3EWd1l92wj8F668qV 9n3XJkLv4L7WuHGCxpQ1RYcLnKCgryytfkMSBUsMfB8XEGdr68B42yAvfuI9V3NaS0Tj W3Roi360fyHUGnwN1zVsEWovSmoYnTOwSrYDEv8dQ+rDhjBBW26BQb99VnN9Hx4P02AN edCL2gzD/aZ+WkW2+UYIkK8SfLtitL9iSTEBurhW4j/244m51MSL2P1yw23GW6gZYCJp WFUg== 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=KuBhe2ueb6/b8I1XKncKxvQsh9ADDFE5g4/LheUEdKY=; b=TFeLnDK8pOKTEO28YWJmV3Ipz3qqzH5KJNsUHV6ApONqPZmVhqTCFfqjSL+PNtRJYb ImF8q/r3sZIS8g9Z6Khmg9jGvbIb5AaHFksW3ruI0ZyVpKa7TOrx0jJXLEK3HGj93XOS gcPNrQgl6tL6RLu5TEdugqUYKqpsh5XcWfsNEupl5vEINrHoFy0wv6l73BAma6qgPI4+ wF/x277QrJUZE9/PAIma8RvzVKT/FXixvPDJB+gcprlFHLRFYU6GxfQHYKQKVreO19bq 3aggWa6QL5XczA0WSMGjMpYY/iuqDUW602B+DSR143hEs7lmsD5Tda1ZjwcdqW18J/og Iy9g== X-Gm-Message-State: AGi0PuZ2P2iS3BBDhrXrcyV50+k7hw2aJi8HhXE71WsDzngh39tUGvus 1aLzlcyUZ9MR+86rg8b6xaZ7GUYYTL+5/Q== X-Google-Smtp-Source: APiQypJ1svwTLgRezAz+OIQdgAkrZi1XtbDi1TVeYeTw+H5rvh7oqHjXr7hFUMfbVV9CCFs/lu9l7Q== X-Received: by 2002:ac8:550c:: with SMTP id j12mr9038535qtq.22.1588780857222; Wed, 06 May 2020 09:00:57 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id p10sm1801125qtu.14.2020.05.06.09.00.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 09:00:56 -0700 (PDT) To: rfced-future@iab.org References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <22a4cf4e-74e1-e49a-e214-24bf4ac97fe2@gmail.com> From: Michael StJohns Message-ID: <4ad597fc-6a3f-ada1-68aa-f28273988479@nthpermutation.com> Date: Wed, 6 May 2020 12:00:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <22a4cf4e-74e1-e49a-e214-24bf4ac97fe2@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 16:01:18 -0000 On 5/5/2020 9:12 PM, Brian E Carpenter wrote: > On 06-May-20 12:30, Ted Lemon wrote: >> I think slowing other SDOs to publish RFCs will make end runs a lot easier. I do not think making it possible for the RFC editor to do this is a good goal. > I tend to agree. While I think that having diverse streams is a real asset, allowing N streams that all assert that they are standards is asking for confusion. > > However, having this issue on the list of issues seems reasonable. We may end up with a category of Bad Ideas. > > Brian Given that we already have a stream that's published at least a few standards in all but name (e.g. IRTF), I'm afraid that horse has left the barn.   The question is more do we either a) ban it going forward, b) grandfather it for the IRTF only, or c) normalize it as a possible model for the community going forward? I agree with Adrian's plaintive cry that this shouldn't end up in the ISE's stream in any case. There are a few ways of doing this - the obvious one is just keep doing what we're already doing and allow re-publications of other SDO standards as appropriate and useful.  Other possibilities include distinct streams for non-I* productions but still published as RFCs and a complete new series (think "imprint" in publisher terms) that - while published by the RFC Editor using the services of the RPC is labeled distinctly and disjointly from the RFC series.   The latter could provide an independent revenue stream for the RFC process and help defray some of the IETFs sunk costs for getting RFCs out. Later, Mike > >>> On May 5, 2020, at 19:36, Jay Daley wrote: >>> >>> I’ve seen some people suggest that the RFC Series could be open to other standards development organisations (SDO) to use as their primary publication stream and therefore that the RFC Series needs to maintain a degree of independence that allows that. >>> >>> My issue then is how that fits with the use of the RFC Series for publishing administrative RFCs about the IETF - Does this practice intertwine the RFC Series with the IETF too much? Would any other SDO also be able to publish administrative RFCs? Is there any point at which the ratio of administrative to technical RFCs becomes an issue for the RFC Series? Are any changes needed to mitigate against that becoming a problem? >>> >>> To be clear I do not include RFCs about the RFC Series itself in my definition of administrative RFCs. >>> >>> Jay >>> >>> -- >>> Jay Daley >>> IETF Executive Director >>> jay@ietf.org >>> >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed May 6 09:08: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 BE6C63A0D76 for ; Wed, 6 May 2020 09:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4oVLCF8sEGQp for ; Wed, 6 May 2020 09:08:19 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560A43A0BE5 for ; Wed, 6 May 2020 09:08:03 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id c10so2516480qka.4 for ; Wed, 06 May 2020 09:08:03 -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=GfaG/Li9b92sQWzUanD5B/vHNbvBQzSy24ftmrt3Abw=; b=xZDbRpjlwHx72XcPUM86hGlPiQ3xiqN/yfD/M6UIOVq+XWkpTLewKLhU1Odfh5L1WM ZzVVLInADsD+WsQPVBptJZq0EmYDZ/tTko5t23hwmZbewGSFHYk/9ewLN7yVTn17/nLV MWw+dHVWImKvcq2fkCXXOlhOgdlzX97xvHefpQjatwsToX1KBLnnMR4aczYbS+MIbuby X2TyfOU6bwsr306mtB1jMaLk3s+9+66PSVo8eu7sIvDnxBNp6Xq7I2qwWBSNDEdnAhpQ G2HPczB/YvFPMFxZMsWhzgOBSDsmkKGB7FeODcksdNTFHCm3IIObnEBUC79LqayJgD/S AMww== 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=GfaG/Li9b92sQWzUanD5B/vHNbvBQzSy24ftmrt3Abw=; b=juD/N1xjkNumisA3msp7j7s+QokDaCgWDJvm6MBm1jkmtncDwENktPMSBM7mvNg9Rr b0LuIPHRTzOi+tMDAx7D4w2PhMHLzv3wzNDpOOyAbUHm/rSIp2K4r7vKUvF7u9hbo2KR n0Tsk57Q6YvgICfRXCi3qxeMImfA7Pdtktt1qBiW9TcaCBCwMgeAGJfBBpTs4lTWQHGv 2Sch1Gto+fUpl6CZofBBxl3elY0BoZd2CfcvEnTsRevCSEMJXB6rP2zRBx2Y19Lv5Gso fPGnCU/TdEinOYBzWbgBgc3oF8goDM0ruQRmNn9f1D8pMzMNVz6BbsOMUBJmObTOGMsg pPXQ== X-Gm-Message-State: AGi0Pubh6S4BSU0XnXR9/LByI8LM0EILWOf3QqdvOl50fBv4y7aleQWA u0FnKPoNXp0ih2AwFVSWPSctCZ9gODBZrA== X-Google-Smtp-Source: APiQypLrCg9GvwfOAauohAixn8YYw20WKOy/Q9fkM4Jmmcj5dHzQcfamMDyf6uhFhyxb0AqSnTgAFQ== X-Received: by 2002:a37:a412:: with SMTP id n18mr9353494qke.134.1588781281607; Wed, 06 May 2020 09:08:01 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id t42sm784894qte.23.2020.05.06.09.08.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 09:08:01 -0700 (PDT) To: rfced-future@iab.org References: From: Michael StJohns Message-ID: <18551dfc-6cba-fd3b-6ffd-44a05cc3bbfd@nthpermutation.com> Date: Wed, 6 May 2020 12:08:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CD4B06EFB349D06FE3CFE612" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] For next week's meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 16:08:28 -0000 This is a multi-part message in MIME format. --------------CD4B06EFB349D06FE3CFE612 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/6/2020 10:54 AM, Eliot Lear wrote: > > For the agenda for next week’s meeting, I thought we might start by > sorting what we think is important for this group to address.  We have > a pretty nice list below, and I think it was Mike who perhaps > implicitly suggested that we sort the wheat from the chaff. I wonder > if quick poll would help.  If so, I’m thinking of using surveymonkey. >  Any objections to that? I'm pretty sure I didn't used "wheat" or "chaff".  Instead strategic - applicable to what the RFC series and RFC editor is - vs tactical - problem reports with the current process. Use a 1-5 scale with "need to consider now" being a 1 and 5 being "can be considered after we consider 1-4".  Please include comment boxes for "why do you think this is a 1 (or 5)". In any event, most of the stuff below is probably 1-3. Later, Mike > > Eliot > > > The role(s) > > * Sets strategy? > * What technical capabilities should the RSE be expected to have > o Is an understanding of archival tools important for the RSE role? > * What publishing experience is the RSE expected to have? > * Responsibility for the RPC and its budget? > * Who owns the series? > * Authority to impose minimum standards for editing of docs > * Tooling responsibility? > * Responsibility to set publishing standards? > * Insuring compliance with publication standards? > * Establishing/overseeing formal processes to determine the value of > RFCs to societies? > o Provides recommendations to make series more accessible to the > various audiences? > * What level of effort should we expect to accomplish all of this? > > > > > > Relationships and lines of responsibility, and transparency > > * What roles are defined and what is their relationship to one another? > o RSE, RSOC, IAB, IESG, Stream managers, LLC, ED, others? > o To whom is each accountable? > o How is that accountability expressed? > * What happens when there are conflicting requirements between the > streams? > > > > > > What we want from the series > > * Record agreements > * Timely publication > * Copy editing can slow that process > * Role should fit existing organizational structure > * Bespoke tooling is a bug not a feature > * Should we worry about legacy? > * What happens to the series if the IETF disappears > * What happens to the IETF if the series disappears > * Ease of navigation? > * > > --------------CD4B06EFB349D06FE3CFE612 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/6/2020 10:54 AM, Eliot Lear wrote:

For the agenda for next week’s meeting, I thought we might start by sorting what we think is important for this group to address.  We have a pretty nice list below, and I think it was Mike who perhaps implicitly suggested that we sort the wheat from the chaff. I wonder if quick poll would help.  If so, I’m thinking of using surveymonkey.  Any objections to that?

I'm pretty sure I didn't used "wheat" or "chaff".  Instead strategic - applicable to what the RFC series and RFC editor is - vs tactical - problem reports with the current process. 

Use a 1-5 scale with "need to consider now" being a 1 and 5 being "can be considered after we consider 1-4".  Please include comment boxes for "why do you think this is a 1 (or 5)".

In any event, most of the stuff below is probably 1-3.  

Later, Mike



Eliot


The role(s)

  • Sets strategy?
  • What technical capabilities should the RSE be expected to have
    • Is an understanding of archival tools important for the RSE role?
  • What publishing experience is the RSE expected to have?
  • Responsibility for the RPC and its budget?
  • Who owns the series?
  • Authority to impose minimum standards for editing of docs
  • Tooling responsibility?
  • Responsibility to set publishing standards?
  • Insuring compliance with publication standards?
  • Establishing/overseeing formal processes to determine the value of RFCs to societies?
    • Provides recommendations to make series more accessible to the various audiences?
  • What level of effort should we expect to accomplish all of this?

Relationships and lines of responsibility, and transparency

  • What roles are defined and what is their relationship to one another?
    • RSE, RSOC, IAB, IESG, Stream managers, LLC, ED, others?
    • To whom is each accountable?
    • How is that accountability expressed?
  • What happens when there are conflicting requirements between the streams?

What we want from the series

  • Record agreements
  • Timely publication
  • Copy editing can slow that process
  • Role should fit existing organizational structure
  • Bespoke tooling is a bug not a feature
  • Should we worry about legacy?
  • What happens to the series if the IETF disappears
  • What happens to the IETF if the series disappears
  • Ease of navigation?



--------------CD4B06EFB349D06FE3CFE612-- From nobody Wed May 6 09:51: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 F03103A05A0 for ; Wed, 6 May 2020 09:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uvECC29LXxiH for ; Wed, 6 May 2020 09:50:49 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 1CBE73A0414 for ; Wed, 6 May 2020 09:50:45 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id x12so1950033qts.9 for ; Wed, 06 May 2020 09:50:44 -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=8cbGOt5KPSDPYotkVAcu6VyXSmXMYfJHiO8CCr2Qks4=; b=G9pRN/Im/EBJWDsca2FPCFnWQKBqUa6T/KmmlyBnUPo/m3hZeKcjrct4Z8WnKKGWM0 pLIEZE1VnBiuKkEZndOVljusVD8X+tfC53zSYiqe8D1lJaY8N+xNpyvNYd0P7tSYmDiW FJ12DeN+4jBhmmVNduC8M+6p3qNCzuTy4gRflUx9YMqe9Q3OXs2dXrl9a6MLZ4aXvl0B zoZhb7kC5vuAtzRh6ouKfKsb6wJiOOK/h2Wb/N2a31QEO4IkFFZhhTTfgL0CtlaWmnhH 0nHHdxP8cg4memcxHZIAh7qfNeMDIm/hBzyas01LGUn4Zdw0XCYl4kU0+IwVlOGdQk7p 7guw== 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=8cbGOt5KPSDPYotkVAcu6VyXSmXMYfJHiO8CCr2Qks4=; b=muwI5NSNerdTDiiTAT3b4wovmFewylT+qceAw1V2lBKT/ZwBqmIPrWzcndsSgTvtgN 6YrJ3+vCc3PBkI1LDvNX+79kBX45DeeHTROJdLcIVDf8+5GjThg+BNNewbx/k9EePnNB rbg9d+grw80LT8u6vpVnTbMB+d7x9Da81NueRHsbGU4hgTxDT8eMqOvbeHhjp4yXXGmp i7sYMK1cSM3j3KiYsKC8OQ4kOJU3XAo9wCCyRz/8jtvswv9qPUX2DS43D951ye4BKhqu igzfF5PTOHd+LAMcaHyPGmdVidXGnRHaXnlS7uVmJiY5vDdOUqBselbshhZlrSH3IsKp 8gWw== X-Gm-Message-State: AGi0PuZYfhgPCyGxLvAej0SYmU6Cz8FKdER8CiLx0qEZyVVBwtkFgcn9 aqaH9KvZ/K1H1NaPEwy8XCcIuyZ/+yESQg== X-Google-Smtp-Source: APiQypKFWx1z1OSfxrPkRGKcjhqnBXvjPtA7Jkfmj2L85xXtPWAoiDWoxIShC+fq7Bc+AcSgD1zymA== X-Received: by 2002:ac8:758d:: with SMTP id s13mr9061676qtq.105.1588783844048; Wed, 06 May 2020 09:50:44 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:c426:c2c:6d30:13c7? ([2601:18b:300:36ee:c426:c2c:6d30:13c7]) by smtp.gmail.com with ESMTPSA id o43sm2007826qtb.49.2020.05.06.09.50.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 09:50:42 -0700 (PDT) From: Ted Lemon Message-Id: <8CC59CDB-FAD7-4651-9EFC-CF9CAED6DF34@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_119E07C9-98EC-4F93-A232-01E0082C592F" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3636.0.1\)) Date: Wed, 6 May 2020 12:50:41 -0400 In-Reply-To: <4ad597fc-6a3f-ada1-68aa-f28273988479@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <22a4cf4e-74e1-e49a-e214-24bf4ac97fe2@gmail.com> <4ad597fc-6a3f-ada1-68aa-f28273988479@nthpermutation.com> X-Mailer: Apple Mail (2.3636.0.1) Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 16:50:52 -0000 --Apple-Mail=_119E07C9-98EC-4F93-A232-01E0082C592F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 6, 2020, at 12:00 PM, Michael StJohns = wrote: > Given that we already have a stream that's published at least a few = standards in all but name (e.g. IRTF), I'm afraid that horse has left = the barn. The question is more do we either a) ban it going forward, = b) grandfather it for the IRTF only, or c) normalize it as a possible = model for the community going forward? Brian's point that we should list all the ideas so that we can discuss = them is probably right. I think the IRTF publishing RFCs is a bit problematic, but Mostly = Harmless because there is a close tie between the IETF and the IRTF. = Imagine ETSI publishing RFCs, though. --Apple-Mail=_119E07C9-98EC-4F93-A232-01E0082C592F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = May 6, 2020, at 12:00 PM, Michael StJohns <msj@nthpermutation.com> wrote:
Given that we already have a stream that's published at least = a few standards in all but name (e.g. IRTF), I'm afraid that horse has = left the barn.   The question is more do we either a) ban it = going forward, b) grandfather it for the IRTF only, or c) normalize it = as a possible model for the community going forward?

Brian's point that we should list all the ideas so that we = can discuss them is probably right.

I think the IRTF publishing RFCs is a = bit problematic, but Mostly Harmless because there is a close tie = between the IETF and the IRTF. Imagine ETSI publishing RFCs, = though.

= --Apple-Mail=_119E07C9-98EC-4F93-A232-01E0082C592F-- From nobody Wed May 6 14:32: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 411E93A00D4 for ; Wed, 6 May 2020 14:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HucnhFJ6kdrA for ; Wed, 6 May 2020 14:31:50 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A87F3A005F for ; Wed, 6 May 2020 14:31:50 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id x77so1794120pfc.0 for ; Wed, 06 May 2020 14:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vsgIooYdQFiQw2DkKXvYB14jJokyexAknaSTl+6pWxo=; b=tOIqtQY1v9I4K6YX0bbm2o78QVitQGRgKDOeThs0zuF336KLU0Tncgfe7JNBfIM56l DR5qNdio3JqZ8zI7bGq+mMBzkLqPrmSdFNfSOX/WnU5zycZTMF1DUGHHDmS/RaR54FEU 6p3ZWWTgPR1BpqJeLh9DGMjUXzZjTiNn/DTXOr8CuRkvapNAiCe/GBoZeIGYo8EKlQRd n2CoIX9GyIDo2Ow0nQ0ftS3iGePjlyuqrvfDRysJ4rf9UEOQMGQAc4Mp28Nw8k/n75Jw QjeHSEokEoyLxs+JjF48D8gmxWoEDihc1PJC3dlMvtd+7maGthRStD8+PoQbvMewToiE h6Ww== 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=vsgIooYdQFiQw2DkKXvYB14jJokyexAknaSTl+6pWxo=; b=hNUooLwBIm8vovjwfuMBdk+2JjDnfVvdwesUoEkIcBdPha7zhXDcpOJOwPjtFHsx+A oqQyJokzjmj07Pl66iD8Mo0k0fr9wB77zqTZCZzafp62X5SOfqXTTr6jtAN+pApsb5TB nUom1InXpK1Lslqg9sQqghxVSpoEWgREMqPn1xmMt4Z3X/zrk46u1F167UdYeCJ5FONG EdF/6um8L3HnDcH/07f3yfdv9Cq+3T53XG3bzvKn2Q0xx964aSOblHO9x02RZ/ej95Vf scKWb/RwYXQxRK8PYiuzv1ffNmve49GOKwg4V2WvAx7tZ5M3sgBRf/pXjxRcALBX5I2+ NyVg== X-Gm-Message-State: AGi0PuYrYFoDgmoEDy+orvVRj6jYm0H/mSxBZkZ4CWfOZ1z82Vls65Q/ LhjN9f/XXrXreqSgww9sSlGFRJF+LBo= X-Google-Smtp-Source: APiQypKFbRm/UPV/2nvMF1hv+0w/PL3ulPTmUUWpct3QeZV6TzGqKp9fds+JCOBCMkDeSteft7XRsQ== X-Received: by 2002:a62:174a:: with SMTP id 71mr10738967pfx.297.1588800709533; Wed, 06 May 2020 14:31:49 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id 9sm2369306pgr.17.2020.05.06.14.31.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 14:31:48 -0700 (PDT) To: adrian@olddog.co.uk, rfced-future@iab.org Cc: "'Joel M. Halpern'" References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> <09de01d623ae$bc0a94a0$341fbde0$@olddog.co.uk> From: Brian E Carpenter Message-ID: <4c826099-3811-97bb-fff6-0f1f9f60712a@gmail.com> Date: Thu, 7 May 2020 09:31:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <09de01d623ae$bc0a94a0$341fbde0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 21:31:57 -0000 On 07-May-20 02:00, Adrian Farrel wrote: > Just chiming in here with my ISE hat on... >=20 > This ISE is not inclined to use the Independent Stream as a mechanism f= or other SDOs to publish their material. If they are real SDOs they will = have their own publication venues. However, their may be occasions where = it is deemed beneficial to the Internet Community to reproduce material f= rom other SDOs in RFC format thus making that material more accessible. A= recent example is the translation (from Russian) of certain security spe= cifications first published in Russia. Yes (half wearing my hat as an ISEB member). For those who don't know, ISEB =3D Independent Submissions Editorial Boar= d=20 =20 > Now, without any hats on... Ditto =20 > This thread cuts to the very core of one of the issues that is least cl= ear in my mind: who owns the RFC series, and what is it for? Indeed. See my earlier note about Principles/Charter/Strategy. To respond to one of Andy's points: >> Would there be different opinions if this SDO were somewhat IETF-adjac= ent (like the W3C) vs. something less so (the Society of Automotive Engin= eers)? Yes. To the extent that the RFC Editor operates under ISOC auspices, the = Society of Automotive Engineers would be out of scope, according to ISOC'= s Articles of Incorporation. If the RFC Editor had Principles/Charter/Str= ategy, we would have a clearer statement of scope, of course. Brian >=20 > To take a very concrete example which has echoes in what IANA does, sup= pose that the W3C [1] decided it would like to publish its output as RFCs= =2E Suppose that the RSE thought this was a good idea, suppose that the o= utput was "related to the Internet" (which it probably is), and suppose t= hat the W3C had money to fund the RPC and RFC Editor system/tools proport= ional to the number of pages of RFC it wanted to publish. > - Who would make the decision? > - Who would have input to the decision? > - Who would arrange any contracts? > - Who would be responsible for ensuring that the W3C RFCs were easily=20 > distinguishable from the other RFCs, and who would agree that was the= > right thing to do? >=20 > Best, > Adrian >=20 > [1] Note, I am not suggesting that the W3C wants to do any of this. Nor= am I suggesting it is a good idea. I am simply using this as an example = that may make the hypothetical more tangible. >=20 >=20 >=20 > -----Original Message----- > From: Rfced-future On Behalf Of Joel M. = Halpern > Sent: 06 May 2020 14:12 > Cc: rfced-future@iab.org > Subject: Re: [Rfced-future] Another possible issue to consider >=20 > The cases in the past where this (other SDOs publishing RFCs) has been = > allowed it was for a group with very low publication rate. And their=20 > documents were published through the Independent Stream, and marked as = > Informational. The particular group was happy with that. >=20 > There was discussion of creating additional streams for such use, and=20 > there was sufficient concern that it was not done. >=20 > Yours, > Joel >=20 > On 5/6/2020 12:19 AM, Carsten Bormann wrote: >> On 2020-05-06, at 02:30, Ted Lemon wrote: >>> >>> slowing other SDOs to publish RFCs >> >> Nice Freudian slip your autocorrector created for you. SCNR. >> >> Apart from sorting this under Bad Idea, one other question is how much= control we (IETF/IRTF/IAB) have to prevent this from happening if we thi= nk that is a Bad Idea >> (a.k.a. hostile takeover protection). >> >> Gr=C3=BC=C3=9Fe, Carsten >> >=20 From nobody Wed May 6 14:35: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 897D83A00E1 for ; Wed, 6 May 2020 14:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTIuF9yA0WuG; Wed, 6 May 2020 14:35:35 -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 6FFA23A00DB; Wed, 6 May 2020 14:35:34 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C55E92BC-04A6-4A91-8930-A266B7ACA70E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 7 May 2020 09:35:31 +1200 In-Reply-To: <4c826099-3811-97bb-fff6-0f1f9f60712a@gmail.com> Cc: rfced-future@iab.org To: Brian E Carpenter References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> <09de01d623ae$bc0a94a0$341fbde0$@olddog.co.uk> <4c826099-3811-97bb-fff6-0f1f9f60712a@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 21:35:38 -0000 --Apple-Mail=_C55E92BC-04A6-4A91-8930-A266B7ACA70E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7/05/2020, at 9:31 AM, Brian E Carpenter = wrote: >=20 >>> Would there be different opinions if this SDO were somewhat = IETF-adjacent (like the W3C) vs. something less so (the Society of = Automotive Engineers)? >=20 > Yes. To the extent that the RFC Editor operates under ISOC auspices, = the Society of Automotive Engineers would be out of scope, according to = ISOC's Articles of Incorporation. Can you explain what you mean by the RFC Editor operating under ISOC = auspices? Jay > If the RFC Editor had Principles/Charter/Strategy, we would have a = clearer statement of scope, of course. >=20 > Brian >=20 >>=20 >> To take a very concrete example which has echoes in what IANA does, = suppose that the W3C [1] decided it would like to publish its output as = RFCs. Suppose that the RSE thought this was a good idea, suppose that = the output was "related to the Internet" (which it probably is), and = suppose that the W3C had money to fund the RPC and RFC Editor = system/tools proportional to the number of pages of RFC it wanted to = publish. >> - Who would make the decision? >> - Who would have input to the decision? >> - Who would arrange any contracts? >> - Who would be responsible for ensuring that the W3C RFCs were easily=20= >> distinguishable from the other RFCs, and who would agree that was = the >> right thing to do? >>=20 >> Best, >> Adrian >>=20 >> [1] Note, I am not suggesting that the W3C wants to do any of this. = Nor am I suggesting it is a good idea. I am simply using this as an = example that may make the hypothetical more tangible. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Rfced-future On Behalf Of Joel = M. Halpern >> Sent: 06 May 2020 14:12 >> Cc: rfced-future@iab.org >> Subject: Re: [Rfced-future] Another possible issue to consider >>=20 >> The cases in the past where this (other SDOs publishing RFCs) has = been=20 >> allowed it was for a group with very low publication rate. And their=20= >> documents were published through the Independent Stream, and marked = as=20 >> Informational. The particular group was happy with that. >>=20 >> There was discussion of creating additional streams for such use, and=20= >> there was sufficient concern that it was not done. >>=20 >> Yours, >> Joel >>=20 >> On 5/6/2020 12:19 AM, Carsten Bormann wrote: >>> On 2020-05-06, at 02:30, Ted Lemon wrote: >>>>=20 >>>> slowing other SDOs to publish RFCs >>>=20 >>> Nice Freudian slip your autocorrector created for you. SCNR. >>>=20 >>> Apart from sorting this under Bad Idea, one other question is how = much control we (IETF/IRTF/IAB) have to prevent this from happening if = we think that is a Bad Idea >>> (a.k.a. hostile takeover protection). >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_C55E92BC-04A6-4A91-8930-A266B7ACA70E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 7/05/2020, at 9:31 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Would there be different = opinions if this SDO were somewhat IETF-adjacent (like the W3C) vs. = something less so (the Society of Automotive Engineers)?

Yes. To the extent = that the RFC Editor operates under ISOC auspices, the Society of = Automotive Engineers would be out of scope, according to ISOC's Articles = of Incorporation.

Can you explain what you mean by the RFC Editor = operating under ISOC auspices?

Jay


If the RFC Editor had Principles/Charter/Strategy, we would = have a clearer statement of scope, of course.

   Brian


To take a = very concrete example which has echoes in what IANA does, suppose that = the W3C [1] decided it would like to publish its output as RFCs. Suppose = that the RSE thought this was a good idea, suppose that the output was = "related to the Internet" (which it probably is), and suppose that the = W3C had money to fund the RPC and RFC Editor system/tools proportional = to the number of pages of RFC it wanted to publish.
- Who = would make the decision?
- Who would have input to the = decision?
- Who would arrange any contracts?
-= Who would be responsible for ensuring that the W3C RFCs were easily
 distinguishable from the other RFCs, and who would = agree that was the
 right thing to do?

Best,
Adrian

[1] Note, I am not suggesting that the W3C wants to do any of = this. Nor am I suggesting it is a good idea. I am simply using this as = an example that may make the hypothetical more tangible.


-----Original Message-----
From: Rfced-future <rfced-future-bounces@iab.org> On Behalf Of Joel M. = Halpern
Sent: 06 May 2020 14:12
Cc: rfced-future@iab.org
Subject: Re: = [Rfced-future] Another possible issue to consider

The cases in the past where this (other SDOs publishing RFCs) = has been
allowed it was for a group with very low = publication rate.  And their
documents were = published through the Independent Stream, and marked as
Informational.  The particular group was happy with = that.

There was discussion of creating = additional streams for such use, and
there was sufficient = concern that it was not done.

Yours,
Joel

On 5/6/2020 12:19 AM, = Carsten Bormann wrote:
On 2020-05-06, at 02:30, Ted Lemon <mellon@fugue.com> = wrote:

slowing other SDOs to publish RFCs

Nice Freudian slip your = autocorrector created for you.  SCNR.

Apart from sorting this under Bad Idea, one other question is = how much control we (IETF/IRTF/IAB) have to prevent this from happening = if we think that is a Bad Idea
(a.k.a. hostile takeover = protection).

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



--
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=_C55E92BC-04A6-4A91-8930-A266B7ACA70E-- From nobody Wed May 6 15:07:55 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7F3A0C20 for ; Wed, 6 May 2020 15:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMU4z3jkwi6N for ; Wed, 6 May 2020 15:07:50 -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 840813A0C28 for ; Wed, 6 May 2020 15:07:50 -0700 (PDT) Received: (qmail 15771 invoked from network); 6 May 2020 22:07:49 -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=3d97.5eb33535.k2005; bh=cjvxQE+DJ96ZAxHf35OxEPaeysGQX5l37jEHKP9JNIQ=; b=Nq1Y3iDlSyjSVYrxoqFqT4DtG4jZm4eV4/rxzN0Kmf8PsP4vrfhyDtLcOL4LC6DqAy9PWhWbHpzImGEBGmBngc+sKJgDzPYEixkY6aE2Zbo22rdT1ide89CtgXFOO+ao5yZ9ttIYiq9a0GBn66hxXvL2CC1J3mmLG9q9xtQPNu8/uK6YYR+ld7BJErxR/IpTqKsdcTL9AtkaBS16gogUatfgFH+DKtzYlZfVo55sblDy9D1CCBiV5D9WYDJOWhcS Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 May 2020 22:07:48 -0000 Received: by ary.qy (Postfix, from userid 501) id 003A618DA917; Wed, 6 May 2020 18:07:47 -0400 (EDT) Date: 6 May 2020 18:07:47 -0400 Message-Id: <20200506220749.003A618DA917@ary.qy> From: "John Levine" To: rfced-future@iab.org In-Reply-To: <4c826099-3811-97bb-fff6-0f1f9f60712a@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] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 22:07:54 -0000 In article <4c826099-3811-97bb-fff6-0f1f9f60712a@gmail.com>, Brian E Carpenter wrote: >Yes. To the extent that the RFC Editor operates under ISOC auspices, the Society of Automotive Engineers would be out of scope, >according to ISOC's Articles of Incorporation. If the RFC Editor had Principles/Charter/Strategy, we would have a clearer >statement of scope, of course. I dunno, what if SAE were publishing documents about network protocols on a vehicle's internal bus, or between vehicles? This still seems awfully hypothetical. If it were up to me, I would say that adding any new stream needs the agreement of all of the existing streams and burn that bridge when we get to it. 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 Wed May 6 15:40: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 50C373A0DA0 for ; Wed, 6 May 2020 15:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDG55-musIey for ; Wed, 6 May 2020 15:40:23 -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 24B633A0D9F for ; Wed, 6 May 2020 15:40:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C0E10BE4D; Wed, 6 May 2020 23:40:19 +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 Orw_72RcWDa0; Wed, 6 May 2020 23:40:18 +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 1D5D6BE2F; Wed, 6 May 2020 23:40:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1588804818; bh=cVXogDn9K5czwIJx5ISnIyrUwFZbC4us8xu8xKSzDDo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=yBx+VW2G6OlUN9/0jQYf0xCc4z/TSBYE0/ITt9xDKu+YMf1XasKEZj3SQY/Ivt2Rh S5nNHGZ8psell2HibeyC0G7vDIRIeyFaEVg9MH3BJqWHlIfHwkt7uoDI0n6YVJ5QFz TBjlaz3ySOZyhufosTOfDgUy2OlLZmV1QXHt8rVo= To: John Levine , rfced-future@iab.org References: <20200506220749.003A618DA917@ary.qy> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 6 May 2020 23:40:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200506220749.003A618DA917@ary.qy> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Qor0YEApG0VQok4KPZgIyY4Jwlrmw18sc" Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 22:40:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Qor0YEApG0VQok4KPZgIyY4Jwlrmw18sc Content-Type: multipart/mixed; boundary="954Jm34YkVJAL6rnngNWAcEqPiYuFqHqE"; protected-headers="v1" From: Stephen Farrell To: John Levine , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Another possible issue to consider References: <20200506220749.003A618DA917@ary.qy> In-Reply-To: <20200506220749.003A618DA917@ary.qy> --954Jm34YkVJAL6rnngNWAcEqPiYuFqHqE Content-Type: multipart/mixed; boundary="------------E05BD960F1ED602743F7E20A" Content-Language: en-US This is a multi-part message in MIME format. --------------E05BD960F1ED602743F7E20A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 06/05/2020 23:07, John Levine wrote: > If it were up to me, I would > say that adding any new stream needs the agreement of all of the > existing streams and burn that bridge when we get to it. I'd maybe consider "agreement of the RSE and all the stream managers" or somesuch but yeah, that kind of decision-process seems rightish. S. --------------E05BD960F1ED602743F7E20A 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----- --------------E05BD960F1ED602743F7E20A-- --954Jm34YkVJAL6rnngNWAcEqPiYuFqHqE-- --Qor0YEApG0VQok4KPZgIyY4Jwlrmw18sc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6zPNAACgkQWrL68XsX K+p5Kg/+JH2OQx3s09UDjH5MrRjmElc1Zd9xX5DSl4yKMTJAkYHdBFp41Ve1xdC3 cuUP9Nbx6gOkxrQYrbdL0MtAn3+ZZd/MLHV1AqKtHZNOXvwYosDwTKZl5NVvWQw/ /xwwAjP38pwIkoSgHljdb+bmBF2DOWgLXHlXQk54cjEa37aVL86cKL+g7IjEBgBv gAcZmLoCElyLGt5tNot0nPe9Eikw7zbZLhwpNq6EGOAYY3dCgFF9aWy7MGyU+gyT MdtEtfq0yZe6iNdWweK9Gp8MSgA3ZsAjsguFvnyc0dNhZtxUkr4Ml+e7PPIze8U2 t7qNpm6si4oAvBIES1aLIPCweH/MUO8JmoHw01sLFH8mii2vcbM3bR1IP6FQTO1K cYSnHeB98rt5O3/zZNL66SgcgLz63+YXeeNJRtyB7ibs7yAuGP0zNuoss3MEEGAg UZsFextahWDmYtWI3lw0Y7T0JR1iNUYa0Ilpovjs1nvHdxsEsMwpFE0/AKgUQY3p KbfsLXhvhatWW+hIExM4LHkaobP63FstWMpwz/HTjUFDg61rFSI3Zn+YLX2QxsRt pcaSKzrarK1Kiht4Kbb8HbXz4P8YlnmT+0Jl5T9QxILOSpMP3AyDyMuEKi7J+YqI ADk0dr8u+RF0oTD1Cs/kgPLi8D4BnrdiEag1c3diVspuOOngq5g= =yk0u -----END PGP SIGNATURE----- --Qor0YEApG0VQok4KPZgIyY4Jwlrmw18sc-- From nobody Wed May 6 16:00: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 E59213A0DA8 for ; Wed, 6 May 2020 16:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 T_uEBmURfdzj for ; Wed, 6 May 2020 16:00:05 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F593A0C1D for ; Wed, 6 May 2020 16:00:05 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id 18so1936072pfx.6 for ; Wed, 06 May 2020 16:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=JTE7dDpN/Bm04G7DB9lE+zR3lWxPQNrOAR533ehwPeI=; b=ffXRPkUm+RFe+PVOkMUzcrRn3USgdn/OPu1f8avOZeOfTLPBmgLiDPFjyN35z3sKMA uaDW02kzb5UqiuniB8JSK7FibcJw/FLlowDHlhmltW97V4cCAFEhPSaYuZGupv2sXwAT CPcT7WMe00RF8lF9Ee1CkhXT4xet0zQQTI43lf/ckqZP/pJaasvX4SgOl6hCKWS0RkNA N4zDy4gcUqtnEwMGR+K6p7gX+eOJltLKPgMYXnWjwipd0qcUAl7hecMisZ6UImuRIp/r 0rw9aPxXjPXV4SgQWpVfQ684cTvPUXeh4Bqg1ZWEJiVYCkvqEDEJe/B19yxNar+piA6m 5peQ== 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=JTE7dDpN/Bm04G7DB9lE+zR3lWxPQNrOAR533ehwPeI=; b=FiJdGPinSkHz3MT25Dv7VM5YmqO4dQXcuzA9DVHhcgLY7926m63HUkbIxquK7ui7Fs 1OeDA19jU9aRhGyp68qjp2hpSYjfLHfE6PetfUtBbwrP0638r+ZczpZsJVa3D5MUxwlL 2KBGwm2YV/Rc6w/Rcw4fMWt0kYB8gHBn4IYDE8WpVKGX5N+zS5Kfd2JUNlorTl76In+w n1cM6ZOaJbgziWT7RO0aeuK+KZ9OWv5+hSbHqs8A6yVrzahQyUNcS3JOGIXoRxr+HRmf LOMZbLI9WKxGYyFMPMk24ErZifzxLy9R2Y5Re6rqkHFaspPPZmSeQEAQCxcPJZjPaIeF o3sw== X-Gm-Message-State: AGi0PuYitsmtAFMKVYEL0Wq1hLfMTzcVTVcLhsK44Y0EEIyGrc+7yvFH 0CLRAtUYFbhHKiQzQ0/lobvPQqcC8eQ= X-Google-Smtp-Source: APiQypKJQ2roJXSEFzpdqrBRLrtlamFzwj5eJjMY0DKOJqnorlbUJdBdC3ddNJN+vYklF0qZCrNhzQ== X-Received: by 2002:a65:5302:: with SMTP id m2mr8672260pgq.135.1588806004242; Wed, 06 May 2020 16:00:04 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id y21sm2828352pfn.148.2020.05.06.16.00.02 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 16:00:03 -0700 (PDT) To: rfced-future@iab.org References: <20200506220749.003A618DA917@ary.qy> From: Brian E Carpenter Message-ID: <27cb122a-59f5-72bf-6ac1-2023539255e1@gmail.com> Date: Thu, 7 May 2020 10:59:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 23:00:07 -0000 On 07-May-20 10:40, Stephen Farrell wrote: > > Hiya, > > On 06/05/2020 23:07, John Levine wrote: >> If it were up to me, I would >> say that adding any new stream needs the agreement of all of the >> existing streams and burn that bridge when we get to it. > > I'd maybe consider "agreement of the RSE and all the > stream managers" or somesuch but yeah, that kind of > decision-process seems rightish. I agree. Incidentally, CANbus (now Controller Area Network, originally Car Area Network) is ISO 11898. "The protocol was officially released in 1986 at the Society of Automotive Engineers (SAE) conference in Detroit, Michigan" [Wikipedia]. I don't think they'll be asking for an RFC number. But the IETF is doing vehicle-related work in IPWAVE. Brian From nobody Wed May 6 16:03:58 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BC43A0C24 for ; Wed, 6 May 2020 16:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 tH-5V0vGfpRx for ; Wed, 6 May 2020 16:03:53 -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 B3A843A0C20 for ; Wed, 6 May 2020 16:03:53 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id e6so1735972pjt.4 for ; Wed, 06 May 2020 16:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=g8GqpzfzBd2wCBwm01Efgzi5nHgH9+Z8SwNL2WkbxH0=; b=LkOjztEpY/AnzdlL12JsRL7QLBlRB/ncigRQHPQUIEp4n7Y/9d1CUM3WctAmYgNqi8 2vFO5yID3bVmmpXEm0FTJ/C7mqifvF1uZTCWozEb+Du6AJy15TqkJ4VIIPje+JPJx5ZD bmeMpuBlmtLMvHE4ZvF5mqF3NCh2xjsxYxQprlb6SgAVIu8fPGJEbePwfmNUhh9c+jhw HliOFj5yZd2QRhV8LCLGpfowIOTLLL/Bm6tpDjGlDh4aE8ZAbYjU7y8UZmCRk859dcUV vLKDx7On7/4zkmuCFsC1ucPgYoST1I0KBG9L3YK/mYvW5tGRbe/cpEym9MUX3np4fjKW 6fWg== 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=g8GqpzfzBd2wCBwm01Efgzi5nHgH9+Z8SwNL2WkbxH0=; b=IkpzVt57mKClyrcuiYd+q3HDVvkE/TsnOHV45HhNU3Ex4KO90LfDqBempNSpNQeIbp FcPogO4uf92HraUc6mqa2/+f5NPbkJWu3N9ZjyFtZgOsqctpzla07n+wK9IEfjJYl8hd 0lioCaZgwm6PxDi8qMGiBq1U07aX1i62Ao4+dDoOJM8/FsdsyTZMeSg8zamRLyxrKdRJ z8lTeE2zJApRgeAVLimPx+lnencm+Ljo3GpfrPpRLWaCYuG5nPnKv+mtxcJR9QAwym0s xmIrvNmyoCGSbSvQufW9ZETgsk17+d6SRVcQAwTDvFhesat7JX6kWZhzveb+ZgD9js46 UwOQ== X-Gm-Message-State: AGi0PuYSj2cU+yU43fhtm6hWmWToYpvaF4G2LZEPDHSFR2z1ZxWhwGK/ LY594zC2lQEB3Yolw9thqeyWLQnGmAk= X-Google-Smtp-Source: APiQypIPgRURCW3mkI5x8X57oWr1piu7hvtHxXjDGUt7V4sVSxSMCoNbM3HldFbsM/3pfg+PepB+mg== X-Received: by 2002:a17:902:464:: with SMTP id 91mr10704847ple.261.1588806232860; Wed, 06 May 2020 16:03:52 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id z15sm5618609pjt.20.2020.05.06.16.03.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 16:03:52 -0700 (PDT) To: Jay Daley Cc: rfced-future@iab.org References: <2CCDD10F-3950-466E-A685-77BE1A4D662A@fugue.com> <541336EE-B64E-4B5C-B9D1-1236D0879623@tzi.org> <5b8a94d9-7d2b-d038-9a03-587070a885b0@joelhalpern.com> <09de01d623ae$bc0a94a0$341fbde0$@olddog.co.uk> <4c826099-3811-97bb-fff6-0f1f9f60712a@gmail.com> From: Brian E Carpenter Message-ID: <770d775f-051c-0fdc-1e8f-341737802f19@gmail.com> Date: Thu, 7 May 2020 11:03:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Another possible issue to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2020 23:03:56 -0000 On 07-May-20 09:35, Jay Daley wrote: >=20 >=20 >> On 7/05/2020, at 9:31 AM, Brian E Carpenter > wrote: >> >>>> Would there be different opinions if this SDO were somewhat IETF-adj= acent (like the W3C) vs. something less so (the Society of Automotive Eng= ineers)? >> >> Yes. To the extent that the RFC Editor operates under ISOC auspices, t= he Society of Automotive Engineers would be out of scope, according to IS= OC's Articles of Incorporation. >=20 > Can you explain what you mean by the RFC Editor operating under ISOC au= spices? Sure. Until the LLC came along, ISOC was the direct funding agency. Now, = it's an ISOC disregarded entity that's the funding agency. Until the IETF= Trust came along, ISOC copyright was asserted for RFCs. I think if anyth= ing ever came to court, that would all count as much as the IAB's charter= claim to oversight. Another reason why I believe the RFC Series needs a well defined charter = of its own. Regards Brian >=20 > Jay >=20 >=20 >> If the RFC Editor had Principles/Charter/Strategy, we would have a cle= arer statement of scope, of course. >> >> =C2=A0=C2=A0=C2=A0Brian >> >>> >>> To take a very concrete example which has echoes in what IANA does, s= uppose that the W3C [1] decided it would like to publish its output as RF= Cs. Suppose that the RSE thought this was a good idea, suppose that the o= utput was "related to the Internet" (which it probably is), and suppose t= hat the W3C had money to fund the RPC and RFC Editor system/tools proport= ional to the number of pages of RFC it wanted to publish. >>> - Who would make the decision? >>> - Who would have input to the decision? >>> - Who would arrange any contracts? >>> - Who would be responsible for ensuring that the W3C RFCs were easily= >>> =C2=A0distinguishable from the other RFCs, and who would agree that w= as the >>> =C2=A0right thing to do? >>> >>> Best, >>> Adrian >>> >>> [1] Note, I am not suggesting that the W3C wants to do any of this. N= or am I suggesting it is a good idea. I am simply using this as an exampl= e that may make the hypothetical more tangible. >>> >>> >>> >>> -----Original Message----- >>> From: Rfced-future > On Behalf Of Joel M. Halpern >>> Sent: 06 May 2020 14:12 >>> Cc: rfced-future@iab.org >>> Subject: Re: [Rfced-future] Another possible issue to consider >>> >>> The cases in the past where this (other SDOs publishing RFCs) has bee= n >>> allowed it was for a group with very low publication rate. =C2=A0And = their >>> documents were published through the Independent Stream, and marked a= s >>> Informational. =C2=A0The particular group was happy with that. >>> >>> There was discussion of creating additional streams for such use, and= >>> there was sufficient concern that it was not done. >>> >>> Yours, >>> Joel >>> >>> On 5/6/2020 12:19 AM, Carsten Bormann wrote: >>>> On 2020-05-06, at 02:30, Ted Lemon > wrote: >>>>> >>>>> slowing other SDOs to publish RFCs >>>> >>>> Nice Freudian slip your autocorrector created for you. =C2=A0SCNR. >>>> >>>> Apart from sorting this under Bad Idea, one other question is how mu= ch control we (IETF/IRTF/IAB) have to prevent this from happening if we t= hink that is a Bad Idea >>>> (a.k.a. hostile takeover protection). >>>> >>>> Gr=C3=BC=C3=9Fe, Carsten >>>> >>> >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=C2=A0 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 From nobody Wed May 6 19:11: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 3B0B43A03F1 for ; Wed, 6 May 2020 19:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3c5LO0eJSiQ for ; Wed, 6 May 2020 19:11:02 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB483A0365 for ; Wed, 6 May 2020 19:10:59 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.205.129]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0472Akvr029684 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 May 2020 19:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1588817458; x=1588903858; i=@elandsys.com; bh=U6Y+cQTuDF4aLGc5K4Al6+HNZ0bcnzdkKg0YCc/9DLo=; h=Date:To:From:Subject; b=IZiH4nfJWaL1HxTVqWFdto0Y2ucbs93EkmlvzxSCBroavpReMcwA8WeTau9MpiYpK a4JvJviy8ULw/BihWgg+rG6IhrcjVAvhyE3ieoXDn0P0p7JmBdnjWTLAy3x231utCL thJUQjtaFkSfwe5/s3QHh5evUffOc9PbqYsbH6+8= Message-Id: <6.2.5.6.2.20200506165446.0beaf308@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 May 2020 19:10:32 -0700 To: rfced-future@iab.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: [Rfced-future] A few comments X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 02:11:07 -0000 Hello, I was reading some comments about what can be published as a RFC. A few years back, I reviewed a document which became RFC 7704. One of the questions which I considered was whether it fits within the RFC Series. It wasn't what would the usual technical document. I spent some time discussing that with authors and make a recommendation. Around a year ago, I commented about another document which became RFC 8280. The document was about other technical documents. However, it was not the usual technical document. I would put the two above-mentioned examples to exceptions. In general, RFCs are technical documents which are related to the Internet. There are different bodies which are there to assess whether a document fits within that description. What if an entity wishes to publish some documents which does that fit within that description? It is up to the entity make its case. Another approach is to foresee what might fit within the RFC Series in ten or twenty years from now. Based on past experience, I would say that the argument has been made before and it remains, to this day, hypothetical. One of the advantages of having a RSE with publishing expertise is that it helped to bring in some insights. It was not a disadvantage that the person was not an subject matter expert in XMLv3 as the role of the person was to understanding the issues instead of being a subject matter expert on every aspect of the RFC Editor function. My outsider's view of the RFC Series Oversight Committee is that it is an additional layer of management. That committee has another committee overseeing it. There is also a RFC Series Advisory Group. The structure is a very elaborate one. Regards, S. Moonesamy From nobody Thu May 7 02:06: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 13E983A0AAA for ; Thu, 7 May 2020 02:06:08 -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 asSnD6s574wF for ; Thu, 7 May 2020 02:06:06 -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 E8D3D3A0AA7 for ; Thu, 7 May 2020 02:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1892; q=dns/txt; s=iport; t=1588842366; x=1590051966; h=from:mime-version:subject:message-id:date:to; bh=rNin5WfF2pa14INYZWlQchYgN8eF4zW+nrtXu7hOXPY=; b=gGbEZiRC+z/cbHhDU+/0SzbFVVB98cOv83NNJz1Q/28q4P1FOKKJg2xM nBiZDvWqUdkPsS9ekelhzNW247gKcbP/1rsfIymBTHbtuHESYRAPGe7Bh hPmysgR0kE5KzYUGpLarojUxtBBjF1iQD3Wzsl2/2SxQyMCJJ5hXRlOPg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9BQCozrNe/xbLJq1mHgEBCxIMQIE?= =?us-ascii?q?8C4MYVSASjU6bWYgMCwEBAQwBASMMBAEBhm83Bg4CAwEBCwEBBQEBAQIBBQR?= =?us-ascii?q?thVYMhWiBJwGEWAGCfA+hM44QdIE0hDkBgRaFAwaBOIxeggCBOByIJoJ4gi0?= =?us-ascii?q?EmQqJQZAGglKCcIUoj34dnSCZa485S4NEAgQGBQIVgWgjgVYzGggbFWUBgj8?= =?us-ascii?q?9EhgNlDSKWD8DZwIGCAEBAwmSRgEB?= X-IronPort-AV: E=Sophos; i="5.73,363,1583193600"; d="scan'208,217"; a="25906030" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2020 09:06:04 +0000 Received: from ams3-vpn-dhcp6724.cisco.com (ams3-vpn-dhcp6724.cisco.com [10.61.90.67]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 047962xq001784 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 May 2020 09:06:03 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_6A674811-EA2E-47C9-BD1C-4B6C2B4B81A4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Thu, 7 May 2020 11:06:02 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.90.67, ams3-vpn-dhcp6724.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Poll Faux Pas X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 09:06:08 -0000 --Apple-Mail=_6A674811-EA2E-47C9-BD1C-4B6C2B4B81A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I noticed that one possible day for the 2nd meeting also happens to be = Memorial Day in the US, which is an important family day for many. It = was also a quite popular selection. Before making a decision, it occurs = to me that I may not have been the only person who missed this. If = people would like to change their answers based on this information, the = poll address is below. I will wait until Monday to close things out. https://doodle.com/poll/y7ia9vvzifrhrycv = My apologies for this error. Eliot --Apple-Mail=_6A674811-EA2E-47C9-BD1C-4B6C2B4B81A4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I noticed that one possible day for the 2nd meeting also happens to be Memorial Day in the US, which is an important family day for many.  It was also a quite popular selection.  Before making a decision, it occurs to me that I may not have been the only person who missed this.  If people would like to change their answers based on this information, the poll address is below.  I will wait until Monday to close things out.


My apologies for this error.

Eliot

--Apple-Mail=_6A674811-EA2E-47C9-BD1C-4B6C2B4B81A4-- From nobody Thu May 7 04:34: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 95EBB3A0147 for ; Thu, 7 May 2020 04:34:22 -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 f-dmOtwCjISc for ; Thu, 7 May 2020 04:34:20 -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 605863A00E2 for ; Thu, 7 May 2020 04:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3334; q=dns/txt; s=iport; t=1588851260; x=1590060860; h=from:mime-version:subject:message-id:date:to; bh=K69Q5b4sp1Z4AE8uUcR8D0T9uW6poJzZt1+PUTuiLmc=; b=ITxaGoL08BHS3e0pcyGL/PX+r58094e5+FvVP81JOm+ceBfq8l5lASAZ J86h6c6YBZcaYG4wq9qIlfhXgNssxkdtvfE/mu/sano4BS0YKp8VklnMs bh/AD8BVPrDRRoSQLnsVU34sSanOZey1iTtwAcFvFMC7nxc8OD5cc/MdM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAwDn8bNe/xbLJq1MGh4BAQsSDIF?= =?us-ascii?q?8C4MYVSASKoQjiQGHY5N3hhGBewsBAQEMAQElCgQBAYQ/A4ItNAkOAgMBAQs?= =?us-ascii?q?BAQUBAQECAQUEbYVWDIYbdSwMBgKEGAGCfA88oH+OEHaBMoNMbQGBFoUIBoE?= =?us-ascii?q?4jF6CAIERJwwQgh+BcIFjBBqCFgKCGCszghIbBLJRglIEgmyFKIV7igMdglu?= =?us-ascii?q?IYZFkmWuQBINEAgQGBQIVgVI5gVYzGggbFTsqAYI/PRIYDZBODAuDT4pYPwM?= =?us-ascii?q?wAjUCBgEHAQEDCZAngh8BAQ?= X-IronPort-AV: E=Sophos; i="5.73,363,1583193600"; d="scan'208,217"; a="25971597" 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; 07 May 2020 11:34:01 +0000 Received: from ams3-vpn-dhcp6724.cisco.com (ams3-vpn-dhcp6724.cisco.com [10.61.90.67]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 047BY0qj011716 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 May 2020 11:34:01 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_CF398677-3ADF-4138-833F-EFF04DA0F983" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> Date: Thu, 7 May 2020 13:34:00 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.90.67, ams3-vpn-dhcp6724.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 11:34:23 -0000 --Apple-Mail=_CF398677-3ADF-4138-833F-EFF04DA0F983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, As a reminder, our first virtual meeting will take place at 9:00pm GMT = on the 14th of May. Information is below. As we have been discussing, = in order to use that time efficiently, I invite you to indicate what you = think are the most important questions to answer. I expect we=E2=80=99ll = get to discuss at most 3-4 of them. I have created a surveymonkey poll here. https://www.surveymonkey.com/r/9XGKS89 = I will close the poll on the 11th of March so we have a day or two just = to agenda bash on list, if necessary. Also, I am looking for volunteers to capture in Etherpad some notes. If = you can help, please unicast as it will speed the discussion. Duration: 90 minutes Webex Information:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm6e894a38b5cf6c139af7eca0891907ca= = Meeting number (access code): 618 351 526 Meeting password: DSnNT3piK67 Thanks, Eliot --Apple-Mail=_CF398677-3ADF-4138-833F-EFF04DA0F983 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi everyone,

As a reminder, our first virtual meeting will take place at = 9:00pm GMT on the 14th of May.  Information is below.  As we = have been discussing, in order to use that time efficiently, I invite = you to indicate what you think are the most important questions to = answer.  I expect we=E2=80=99ll get to discuss at most 3-4 of = them.

I have = created a surveymonkey poll here.

https://www.surveymonkey.com/r/9XGKS89

I will close the poll on the 11th of = March so we have a day or two just to agenda bash on list, if = necessary.

Also,= I am looking for volunteers to capture in Etherpad some notes.  If = you can help, please unicast as it will speed the discussion.

Duration: 90 minutes

Webex Information: 
https://ietf.webex.com/ietf/j.php?MTID=3Dm6e894a38b5cf6c139af7e= ca0891907ca
Meeting number (access code): 618 351 = 526
Meeting password: DSnNT3piK67

Thanks,

Eliot

= --Apple-Mail=_CF398677-3ADF-4138-833F-EFF04DA0F983-- From nobody Thu May 7 11:10:51 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED3F3A0C3F for ; Thu, 7 May 2020 11:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7_20-fFkGzx for ; Thu, 7 May 2020 11:10:21 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333DE3A0C20 for ; Thu, 7 May 2020 11:10:21 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id b188so7112923qkd.9 for ; Thu, 07 May 2020 11:10:20 -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=kAKRVhgGAnaj6C6axaokwx0s0CXKeJfdZU5onVmlan8=; b=BLEQnwDhK9+f5Aoc7Q948wDrVBMsa9W9hl1eBepKrITOX1aR1axEJolaCs+gEZbL73 CzCwiSk9hguv6BEximjIFhllSQyau+KijwkbiiVbtjD7+Rf1FOYnkOnFykSVoC36AEyx 1H0/Cn5T9uK2QaTN0pSD/SoopJXgLozl7YM6e21Q4JdmM9WrilU7wYTCZs62ggtj1zLG V6nxOesMqqRTjQzqjAtGkP/kg5N2m2PrSxckB0uRYiBNUxmcc7K4GICavsXlf4LMIfiM G33SZ+snCWP/pzGMO4+JBra0j8eUlp97lAS/8jbZQ21F6lkBR8gcfoOOPs6VSPsQ4t23 YFBw== 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=kAKRVhgGAnaj6C6axaokwx0s0CXKeJfdZU5onVmlan8=; b=YQZI686daEs+Yw5NbqJgk5fOrl3aXkfCPYjSEg6W7WEGix+m4yD7oYT4kgOxDgqdzs PnZuBSjRSoAIE4FzFCOlax98lLFgYKH/ASE3QPqNiqmIZOqBFqgkwTGeh4Mb8auXbwmH zEKfu+0kYtBTDggQjkNsItPi3gK5iPrOFI6wEledZKphiiFBCp0B6ZkpdvV+tC+RbU1n ta+1yniwL2gC5AJ0QS7Fe+roCdlJ0vGBDulZHFOcPIFfh3ITfrEdk1pFW0mfoFhA7/bd QCzLN3yfRpSl63kT1o+MCP+zZHkJG8/r1+JyoB1pByeHUQkjR70ZuXX1pBelkam+habY 3lxA== X-Gm-Message-State: AGi0PuanMoj0guWJi2/lyIt0yZWuog45i0NNUeHoh7kFA7gezpKXKZN2 ljpFt+98NozxDa9BNlLT7xwGy8kmSuZhpA== X-Google-Smtp-Source: APiQypJHtl6HMC/FvUQlWu0u/jUzIu3lUVXoEnmGraz0TiDALJa169CVOa1bC7av+hbirC+o3s3j7Q== X-Received: by 2002:a37:4844:: with SMTP id v65mr14653979qka.447.1588875019448; Thu, 07 May 2020 11:10:19 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id q130sm4716065qke.80.2020.05.07.11.10.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 11:10:18 -0700 (PDT) To: rfced-future@iab.org References: From: Michael StJohns Message-ID: <374d33dc-2cb3-324d-8489-4a7d258dbb62@nthpermutation.com> Date: Thu, 7 May 2020 14:10:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A3B2DC8B56AFD89F56D14975" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Poll Faux Pas X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 18:10:26 -0000 This is a multi-part message in MIME format. --------------A3B2DC8B56AFD89F56D14975 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 5/7/2020 5:06 AM, Eliot Lear wrote: > I noticed that one possible day for the 2nd meeting also happens to be > Memorial Day in the US, which is an important family day for many. It > was also a quite popular selection. Before making a decision, it > occurs to me that I may not have been the only person who missed this. > If people would like to change their answers based on this > information, the poll address is below. I will wait until Monday to > close things out. > > https://doodle.com/poll/y7ia9vvzifrhrycv > > My apologies for this error. > > Eliot > > If I'm reading this correctly, we have a disjoint set of {Adam Roach, John Levine, Joel Halpern and Bob Hinden} vs {Nevil Brownlee, Brian Carpenter, Jay Dayley, and Mark Nottingham} Please consider using the "If I really, really, must" option so that we don't have to exclude one or the other group. Personally, I think Nevil, Jay and John all probably need to attend at a minimum. Later, Mike --------------A3B2DC8B56AFD89F56D14975 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 5/7/2020 5:06 AM, Eliot Lear wrote:
I noticed that one possible day for the 2nd meeting also happens to be Memorial Day in the US, which is an important family day for many. It was also a quite popular selection. Before making a decision, it occurs to me that I may not have been the only person who missed this. If people would like to change their answers based on this information, the poll address is below. I will wait until Monday to close things out.


My apologies for this error.

Eliot


If I'm reading this correctly, we have a disjoint set of {Adam Roach, John Levine, Joel Halpern and Bob Hinden} vs {Nevil Brownlee, Brian Carpenter, Jay Dayley, and Mark Nottingham}

Please consider using the "If I really, really, must" option so that we don't have to exclude one or the other group. Personally, I think Nevil, Jay and John all probably need to attend at a minimum.

Later, Mike


--------------A3B2DC8B56AFD89F56D14975-- From nobody Thu May 7 12:41: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 718513A0CB1 for ; Thu, 7 May 2020 12:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0A49Caqlfry; Thu, 7 May 2020 12:41:50 -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 2DAE23A0CAF; Thu, 7 May 2020 12:41:49 -0700 (PDT) From: Jay Daley Message-Id: <67D587A2-31D6-404A-AD47-0CF2DB7C30C9@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_D0DCAA3C-DB95-4933-BAC3-8713D0ACF7D8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 8 May 2020 07:41:47 +1200 In-Reply-To: <374d33dc-2cb3-324d-8489-4a7d258dbb62@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <374d33dc-2cb3-324d-8489-4a7d258dbb62@nthpermutation.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Poll Faux Pas X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 19:41:55 -0000 --Apple-Mail=_D0DCAA3C-DB95-4933-BAC3-8713D0ACF7D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8/05/2020, at 6:10 AM, Michael StJohns = wrote: >=20 > On 5/7/2020 5:06 AM, Eliot Lear wrote: >> I noticed that one possible day for the 2nd meeting also happens to = be Memorial Day in the US, which is an important family day for many. = It was also a quite popular selection. Before making a decision, it = occurs to me that I may not have been the only person who missed this. = If people would like to change their answers based on this information, = the poll address is below. I will wait until Monday to close things = out. >>=20 >> https://doodle.com/poll/y7ia9vvzifrhrycv = >>=20 >> My apologies for this error. >>=20 >> Eliot >>=20 >>=20 >>=20 > If I'm reading this correctly, we have a disjoint set of {Adam Roach, = John Levine, Joel Halpern and Bob Hinden} vs {Nevil Brownlee, Brian = Carpenter, Jay Dayley, and Mark Nottingham} >=20 > Please consider using the "If I really, really, must" option so that = we don't have to exclude one or the other group. Personally, I think = Nevil, Jay and John all probably need to attend at a minimum. >=20 >=20 For info - the blocks I did not select are 3-4:30am for me (and Nevil). = Unfortunately I can=E2=80=99t edit my entry now but if really needed I = can do either of the 5th or 7th slot. Jay > Later, Mike >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_D0DCAA3C-DB95-4933-BAC3-8713D0ACF7D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 8/05/2020, at 6:10 AM, Michael StJohns <msj@nthpermutation.com> wrote:

=20 =20
On 5/7/2020 5:06 AM, Eliot Lear = wrote:
I noticed that one possible day for the 2nd meeting also happens to be Memorial Day in the US, which is an important family day for many.  It was also a quite popular selection.  Before = making a decision, it occurs to me that I may not have been the only person who missed this.  If people would like to change their = answers based on this information, the poll address is below.  I will = wait until Monday to close things out.

https://doodle.com/poll/y7ia9vvzifrhrycv

My apologies for this error.

Eliot


If I'm reading this correctly, we have a = disjoint set of {Adam Roach, John Levine, Joel Halpern and Bob Hinden} vs {Nevil Brownlee, Brian Carpenter, Jay Dayley, and Mark Nottingham}

Please consider using the "If I really, really, must" option = so that we don't have to exclude one or the other group.   Personally, I think Nevil, Jay and John all probably need to attend at a minimum.


For info - the blocks I did = not select are 3-4:30am for me (and Nevil).  Unfortunately I = can=E2=80=99t edit my entry now but if really needed I can do either of = the 5th or 7th slot.

Jay

Later, Mike


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

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

= --Apple-Mail=_D0DCAA3C-DB95-4933-BAC3-8713D0ACF7D8-- From nobody Thu May 7 12:51: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 0A1073A0CE7 for ; Thu, 7 May 2020 12:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1Wb7q8yQZ-p for ; Thu, 7 May 2020 12:51:33 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 38E203A0CE6 for ; Thu, 7 May 2020 12:51:32 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id p13so3288619qvt.12 for ; Thu, 07 May 2020 12:51:32 -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=/8E+4WlpQ4x33liX42gqdUbQXEA0ofir8dvmwcfiKBk=; b=Txi7JJxr2RdVKflR0DXdub3fUfMmJkuPfssczwKqcmrmWxlvx697HaoeWeagBM8d4k lJJhp22FYzEJJX5A7Mxpk/tquMkUzq4df8MqVub6G95gSuF2yTYWytQWBcyZgs02fbjN Q3yj3c61+mjzZoHd0mcjyeLtfR2N2N5eM9PopYx070i20aCuve32HvvP9Tt0MUEhiMbs Oh8+M3ohqAFcX0teZNhJ+NL6jSxbujHTA3OX1WU+45Dttel8OvvQgoLpKp1pHD7LpZ8l 3AgcoAZABDj/OY4dLlpBIdZ4OFOodN7I1LvzKgYmgyFwSCp25kb6qV+Tzlcbg4xEA3BS rjAg== 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=/8E+4WlpQ4x33liX42gqdUbQXEA0ofir8dvmwcfiKBk=; b=fkrrcpUWxXYEN/ROJ05TySIAhLdedpGo3B3/i9/EdVOJKcFbjRUn1c8rClIj4iHWko iJ5I4pxVYYHlhnE7UOyT6mBWpPn7+SQlWHFKKF7AxZFcL18rDvTUxWPlYrbJ0HMtbI4t Z7Ofe5VgGeTWG8ezdKiptwJ6ThjugPqCyVHtmsM8q7TqaKm2rQ+n6jyQ0o4aAdBYxcVN OS61fNhf5lJgCayu7gfu50PW7I5ehrNhoxEstlhTYVrU8m1z4+TQr4cs5U9fLcWf3LrN 48BI2C/Snt8+3Ppzqmx1YommW8G2mifd1YPPTpNihKn2GNdQHANjiLZO+mRiIEE+Ftes m4ig== X-Gm-Message-State: AGi0Pua2DuedoC8Fdo75QDT/Bkixmjjg+pLU6cVWx3g1GIETEvadPVoH 9Rlj2yLUBE331FiODeStjiE9+poTaAcUbw== X-Google-Smtp-Source: APiQypKdzCXCNIZAFaa16VG3DAajzEKagmFyok+2lJQrHlpvDFRBMs1mjqx7jB0cezIs5MGAZPRDrQ== X-Received: by 2002:ad4:54c3:: with SMTP id j3mr15309199qvx.241.1588881091719; Thu, 07 May 2020 12:51:31 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id a194sm4997016qkb.21.2020.05.07.12.51.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 12:51:31 -0700 (PDT) To: Jay Daley Cc: rfced-future@iab.org References: <374d33dc-2cb3-324d-8489-4a7d258dbb62@nthpermutation.com> <67D587A2-31D6-404A-AD47-0CF2DB7C30C9@ietf.org> From: Michael StJohns Message-ID: <692ee4bb-47d3-f231-b995-22e07b94afad@nthpermutation.com> Date: Thu, 7 May 2020 15:51:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <67D587A2-31D6-404A-AD47-0CF2DB7C30C9@ietf.org> Content-Type: multipart/alternative; boundary="------------A05AF804E540215F81D4EE97" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Poll Faux Pas X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 19:51:36 -0000 This is a multi-part message in MIME format. --------------A05AF804E540215F81D4EE97 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/7/2020 3:41 PM, Jay Daley wrote: > > >> On 8/05/2020, at 6:10 AM, Michael StJohns > > wrote: >> >> On 5/7/2020 5:06 AM, Eliot Lear wrote: >>> I noticed that one possible day for the 2nd meeting also happens to >>> be Memorial Day in the US, which is an important family day for >>> many.  It was also a quite popular selection.  Before making a >>> decision, it occurs to me that I may not have been the only person >>> who missed this.  If people would like to change their answers based >>> on this information, the poll address is below.  I will wait until >>> Monday to close things out. >>> >>> https://doodle.com/poll/y7ia9vvzifrhrycv >>> >>> My apologies for this error. >>> >>> Eliot >>> >>> >> If I'm reading this correctly, we have a disjoint set of {Adam Roach, >> John Levine, Joel Halpern and Bob Hinden} vs {Nevil Brownlee, Brian >> Carpenter, Jay Dayley, and Mark Nottingham} >> >> Please consider using the "If I really, really, must" option so that >> we don't have to exclude one or the other group.   Personally, I >> think Nevil, Jay and John all probably need to attend at a minimum. >> >> > For info - the blocks I did not select are 3-4:30am for me (and > Nevil).  Unfortunately I can’t edit my entry now but if really needed > I can do either of the 5th or 7th slot. Ah - the above poll is for the second meeting....  Mike > > Jay >> >> Later, Mike >> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > -- > Jay Daley > IETF Executive Director > jay@ietf.org > --------------A05AF804E540215F81D4EE97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/7/2020 3:41 PM, Jay Daley wrote:


On 8/05/2020, at 6:10 AM, Michael StJohns <msj@nthpermutation.com> wrote:

On 5/7/2020 5:06 AM, Eliot Lear wrote:
I noticed that one possible day for the 2nd meeting also happens to be Memorial Day in the US, which is an important family day for many.  It was also a quite popular selection.  Before making a decision, it occurs to me that I may not have been the only person who missed this.  If people would like to change their answers based on this information, the poll address is below.  I will wait until Monday to close things out.


My apologies for this error.

Eliot


If I'm reading this correctly, we have a disjoint set of {Adam Roach, John Levine, Joel Halpern and Bob Hinden} vs {Nevil Brownlee, Brian Carpenter, Jay Dayley, and Mark Nottingham}

Please consider using the "If I really, really, must" option so that we don't have to exclude one or the other group.   Personally, I think Nevil, Jay and John all probably need to attend at a minimum.


For info - the blocks I did not select are 3-4:30am for me (and Nevil).  Unfortunately I can’t edit my entry now but if really needed I can do either of the 5th or 7th slot.

Ah - the above poll is for the second meeting....  Mike




Jay

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


--------------A05AF804E540215F81D4EE97-- From nobody Thu May 7 12:57: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 290033A0CFA for ; Thu, 7 May 2020 12:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TmUkIH7BqmF9; Thu, 7 May 2020 12:57:37 -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 D16AE3A0CF3; Thu, 7 May 2020 12:57:36 -0700 (PDT) From: Jay Daley Message-Id: <46C0178A-F68E-4DF8-AAF2-A8406064B4E8@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_DB4233E4-03B7-4631-8D6F-B4F35D35ED5B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 8 May 2020 07:57:34 +1200 In-Reply-To: <692ee4bb-47d3-f231-b995-22e07b94afad@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <374d33dc-2cb3-324d-8489-4a7d258dbb62@nthpermutation.com> <67D587A2-31D6-404A-AD47-0CF2DB7C30C9@ietf.org> <692ee4bb-47d3-f231-b995-22e07b94afad@nthpermutation.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Poll Faux Pas X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 19:57:40 -0000 --Apple-Mail=_DB4233E4-03B7-4631-8D6F-B4F35D35ED5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8/05/2020, at 7:51 AM, Michael StJohns = wrote: >=20 > On 5/7/2020 3:41 PM, Jay Daley wrote: >>=20 >>=20 >>> On 8/05/2020, at 6:10 AM, Michael StJohns > wrote: >>>=20 >>> On 5/7/2020 5:06 AM, Eliot Lear wrote: >>>> I noticed that one possible day for the 2nd meeting also happens to = be Memorial Day in the US, which is an important family day for many. = It was also a quite popular selection. Before making a decision, it = occurs to me that I may not have been the only person who missed this. = If people would like to change their answers based on this information, = the poll address is below. I will wait until Monday to close things = out. >>>>=20 >>>> https://doodle.com/poll/y7ia9vvzifrhrycv = >>>>=20 >>>> My apologies for this error. >>>>=20 >>>> Eliot >>>>=20 >>>>=20 >>>>=20 >>> If I'm reading this correctly, we have a disjoint set of {Adam = Roach, John Levine, Joel Halpern and Bob Hinden} vs {Nevil Brownlee, = Brian Carpenter, Jay Dayley, and Mark Nottingham} >>>=20 >>> Please consider using the "If I really, really, must" option so that = we don't have to exclude one or the other group. Personally, I think = Nevil, Jay and John all probably need to attend at a minimum. >>>=20 >>>=20 >> For info - the blocks I did not select are 3-4:30am for me (and = Nevil). Unfortunately I can=E2=80=99t edit my entry now but if really = needed I can do either of the 5th or 7th slot. > Ah - the above poll is for the second meeting.... Mike >=20 And I managed to edit my response - and I note that they don=E2=80=99t = have a "ok if you must, but don=E2=80=99t expect me to be in a good = mood" icon. Jay >=20 >=20 >>=20 >> Jay >>> Later, Mike >>>=20 >>>=20 >>>=20 >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future = >>=20 >> --=20 >> Jay Daley >> IETF Executive Director >> jay@ietf.org >>=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=_DB4233E4-03B7-4631-8D6F-B4F35D35ED5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 8/05/2020, at 7:51 AM, Michael StJohns <msj@nthpermutation.com> wrote:

=20 =20
On 5/7/2020 3:41 PM, Jay Daley = wrote:


On 8/05/2020, at 6:10 AM, Michael StJohns = <msj@nthpermutation.com> wrote:

On 5/7/2020 5:06 AM, Eliot Lear wrote:
I noticed that one possible day for the 2nd meeting also happens to be Memorial Day in the US, which is an important family day for many.  It was also a quite popular selection.  Before making a decision, it = occurs to me that I may not have been the only person who missed this.  If people would like to change their answers based on this information, the poll address is below.  I will wait until Monday to close things = out.

https://doodle.com/poll/y7ia9vvzifrhrycv

My apologies for this error.

Eliot


If I'm reading this correctly, = we have a disjoint set of {Adam Roach, John Levine, Joel Halpern and Bob Hinden} vs {Nevil Brownlee, Brian Carpenter, Jay Dayley, and Mark Nottingham}

Please = consider using the "If I really, really, must" option so that we don't have to exclude one or the other group.   Personally, I think = Nevil, Jay and John all probably need to attend at a minimum.


For info - the blocks I did not select are 3-4:30am for me (and Nevil).  Unfortunately I can=E2=80=99t edit my entry now = but if really needed I can do either of the 5th or 7th slot.

Ah - the above poll is for the second = meeting....  Mike

And I managed to = edit my response - and I note that they don=E2=80=99t have a "ok if you = must, but don=E2=80=99t expect me to be in a good mood" = icon.

Jay



Jay

Later, Mike

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

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


--
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=_DB4233E4-03B7-4631-8D6F-B4F35D35ED5B-- From nobody Thu May 7 12:58: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 1ED103A0CE6 for ; Thu, 7 May 2020 12:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 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, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 lmT-ewAg0dIS for ; Thu, 7 May 2020 12:58:35 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2593A0CDA for ; Thu, 7 May 2020 12:58:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49J45l33YTz1p2YD for ; Thu, 7 May 2020 12:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1588881515; bh=c+liur0DPQmNquz/PFwVn2VaLVCXn1ie/XH5L1KFnsA=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=gQgFIhqhxwGO8yHjPSpbK9kE1phY0ThQNxUkSN8Zval3BPNtEdLim4bKxvClhDvXv Q/F5jYJ1XVtG7lDV1dMbceIEbWO0VXh6JjMZD8lAK9JkvzfxC6mOoZNag8sgISuBer 3r2/kZpDu4xdYGjihG11IZM7h3F5k6scoFYGl3LI= 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 49J45l087Nz1p2Sx for ; Thu, 7 May 2020 12:58:34 -0700 (PDT) Cc: rfced-future@iab.org References: <374d33dc-2cb3-324d-8489-4a7d258dbb62@nthpermutation.com> <67D587A2-31D6-404A-AD47-0CF2DB7C30C9@ietf.org> From: "Joel M. Halpern" Message-ID: <97ffa1c1-7c02-d30a-554e-5fc1fe034ce5@joelhalpern.com> Date: Thu, 7 May 2020 15:58:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <67D587A2-31D6-404A-AD47-0CF2DB7C30C9@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Poll Faux Pas X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 19:58:37 -0000 My assumption is that over several calls we will use slots that are bad for all of us. While I could manage to be on a call at 2am, I would almost certainly not be a useful contributor to such a call. Nor would I expect Nevil (or Jay) to be particularly effective at 3am their time. How Eliot will manage this rotation shall remain a mystery. Yours, Joel On 5/7/2020 3:41 PM, Jay Daley wrote: > > >> On 8/05/2020, at 6:10 AM, Michael StJohns > > wrote: >> >> On 5/7/2020 5:06 AM, Eliot Lear wrote: >>> I noticed that one possible day for the 2nd meeting also happens to >>> be Memorial Day in the US, which is an important family day for many. >>>  It was also a quite popular selection.  Before making a decision, it >>> occurs to me that I may not have been the only person who missed >>> this.  If people would like to change their answers based on this >>> information, the poll address is below.  I will wait until Monday to >>> close things out. >>> >>> https://doodle.com/poll/y7ia9vvzifrhrycv >>> >>> My apologies for this error. >>> >>> Eliot >>> >>> >> If I'm reading this correctly, we have a disjoint set of {Adam Roach, >> John Levine, Joel Halpern and Bob Hinden} vs {Nevil Brownlee, Brian >> Carpenter, Jay Dayley, and Mark Nottingham} >> >> Please consider using the "If I really, really, must" option so that >> we don't have to exclude one or the other group. Personally, I think >> Nevil, Jay and John all probably need to attend at a minimum. >> >> > For info - the blocks I did not select are 3-4:30am for me (and Nevil). >  Unfortunately I can’t edit my entry now but if really needed I can do > either of the 5th or 7th slot. > > Jay >> >> Later, Mike >> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > -- > Jay Daley > IETF Executive Director > jay@ietf.org > > From nobody Thu May 7 13:13: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 AF2203A0D36 for ; Thu, 7 May 2020 13:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCVfxbuvkN4W for ; Thu, 7 May 2020 13:13:30 -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 8F6073A0D35 for ; Thu, 7 May 2020 13:13:30 -0700 (PDT) Received: (qmail 40752 invoked from network); 7 May 2020 20:13:28 -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=9f2e.5eb46be8.k2005; bh=R6gAUGBgCAw/jbazTPvcK2mv8bEqGZCYAlBJwS+u9Ww=; b=DFAQc6N6i0TVwAa3Hn47jo4kxVDksbC4lgnoeXqGmNTRlJfuq3h/id6xjlpUD49Gpp+cfDud6pxlkobb23RSx0p0N+BF2WXNtiAN0T3ELEIOsl67aLFdXVhOVo2BOPBvdGdH3Dsg4XUHEuqNctfiiwrJqksWtOdBtIyWO02pCe0KWuPVl8plTSAsE7qI9U53Hs1em9XQma1/W4vLwQd9aYs6kULFxRqap2hxJqVxqMhtJrsZLCMAgdncwF4fVKtJ Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 07 May 2020 20:13:28 -0000 Received: by ary.qy (Postfix, from userid 501) id 53A3518E435C; Thu, 7 May 2020 16:13:28 -0400 (EDT) Date: 7 May 2020 16:13:28 -0400 Message-Id: <20200507201328.53A3518E435C@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: jay@ietf.org In-Reply-To: <46C0178A-F68E-4DF8-AAF2-A8406064B4E8@ietf.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Poll Faux Pas X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 20:13:37 -0000 In article <46C0178A-F68E-4DF8-AAF2-A8406064B4E8@ietf.org> you write: >>>> Please consider using the "If I really, really, must" option so that we don't have to exclude one or the other group. >Personally, I think Nevil, Jay and John all probably need to attend at a minimum. I added some yellow checks at times which are 2 AM here. But one of you will have to apologize to my wife and our dog. It's rather a challenge since Jay and Nevil are in UTC+12, I'm in -4, and Eliot in +2. From nobody Thu May 7 14:19:04 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBA23A0DCE for ; Thu, 7 May 2020 14:19: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWR-tvHykgAp for ; Thu, 7 May 2020 14:19:00 -0700 (PDT) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17AA23A0DC9 for ; Thu, 7 May 2020 14:19:00 -0700 (PDT) Received: by mail-pf1-x441.google.com with SMTP id p25so3611747pfn.11 for ; Thu, 07 May 2020 14:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=+EHAmLwj3FXGmboJQPhd/GW0XLdNzKtouy/aFmtQJV8=; b=cj0IknueqWQwWI9PNZNFShZKBUOlUeG1JQj2P9W1hzIAORIJ0OKlkHsxcWI8TPDBG2 HiqD+G1ifmLpEZqmkFTo6kJIc5NuhTc2obNpZectYSJBAC9lmchLaTaHkjpCUtG/Ng/8 +TzTbCG6QCl/WGFIiKspkmzCgqgB5roXcvnA7x8uGQ+0b9RIzG86MVwQxHOJjgRzbybP vqtSriOlN/59LO+yOg7v7qIG/WSMNPpf1852wHBgTMcKoUeH0Wid1rNVTUsHL8FzVbRk qK9Ur5adUbqMfIKy8MTi7uLEp1uYiXUcX71Qe3FBtCUVur3mLT1mZP4AEwWqpTDEwIV0 oYIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=+EHAmLwj3FXGmboJQPhd/GW0XLdNzKtouy/aFmtQJV8=; b=UY+PenwD0EX+teWl09FFdIu7hNREo5J+sMX41sfUEYK7CR1RNAr1+qVWe2c30M8ayJ 5jAqvaU1dQ3iY6ZNjux7hBG93JPg8FQasTzrVNufbO1epd9hQ/4p4ogJquarqskX8PIe YGl1udzeG8rlIrvKWBARyAUqCtk9ZT480GMWt2jiUuORD7QKN0GjtkIPwehGdaNPbXVh bTmQF9MY7yNU4ZmrtGdgKN+wUYrUE3aCtlLmZl2hEx/VmIPJ4Eh9SRhcUds0Bi1Y/1rO 5M/BJfQ0tJx+HpT7rRImUZ6sCbXkfi/jtmoDIl/jSVa5+n6+cbld5p53lof4/hQduWsv 6NSQ== X-Gm-Message-State: AGi0Pub5McSngG2XGFOjBXhYmGch+oHEF8lAXTopVdTetCa068qtvf6P LCFiTfyHnjB2Lg1i+h6XoHA= X-Google-Smtp-Source: APiQypJeiC2CCVzR1A6Wc8tc+Bzjb+4sPMeEMlVSEnA2fNqsLcXimvUpAKlxvZ6jga//FrbjFLf3mQ== X-Received: by 2002:a65:611a:: with SMTP id z26mr12539959pgu.341.1588886339416; Thu, 07 May 2020 14:18:59 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id i4sm4613820pgd.9.2020.05.07.14.18.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 14:18:58 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Joseph Touch'" , "'Adam Roach'" Cc: "'John Levine'" , , , References: <20200507173543.CB30A18E232F@ary.qy> <4CB1B614-A67C-49AC-9CB5-A64EEE8A87EB@strayalpha.com> In-Reply-To: <4CB1B614-A67C-49AC-9CB5-A64EEE8A87EB@strayalpha.com> Date: Thu, 7 May 2020 14:18:57 -0700 Message-ID: <044701d624b5$1f578c00$5e06a400$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIPSyh7PUkuN89oij78//BR4CrS9QLCpaAgAlkOTcaoAd3EAA== Archived-At: Subject: Re: [Rfced-future] Marking TCP/UDP Port 109 as "Historic" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2020 21:19:03 -0000 Consider some IANA registries as needing "editorial" updates. What would be useful would be a (moderated) archive of metadata and = comments on IANA entries.=20 =20 If there were any IETF "Living Standards" then some IANA registries = today might turn into one, and under the purview of the (new) RFC = Editor. If not, we could still ask that IANA registries were more readily = updatable, especially those in application space such as media types and = url schemes. =20 -----Original Message----- > From: ietf On Behalf Of Joseph Touch > Sent: Thursday, May 7, 2020 11:36 AM > To: Adam Roach > Cc: John Levine ; ietf@ietf.org; moore@network- > heretics.com > Subject: Re: Marking TCP/UDP Port 109 as "Historic" >=20 > Again, ports are not deprecated. They=E2=80=99re deassigned (at most) = but wouldn=E2=80=99t > be reused until we run out anyway. >=20 > Ports do have informal notes; there=E2=80=99s nothing bad (or = worthwhile either, > IMO) about updating those notes. It=E2=80=99s fine to add and easy = enough if > someone wants to waste their time. >=20 > However, that should not imply also transferring ownership to the = IETF. > That=E2=80=99s a separate step that IMO should be handled on a = case-by-case basis > as needed. We should entertain a process change in bulk ONLY after the > IETF *demonstrates* that the load of per-case changes is too high. >=20 > Right now, the load of considering the change is itself too high, IMO. >=20 > Joe >=20 >=20 > > On May 7, 2020, at 11:31 AM, Adam Roach wrote: > > > > On 5/7/2020 12:35 PM, John Levine wrote: > >> For once I agree with Keith. If the IESG wants to deprecate ports > >> assigned to dead protocols, that's fine, but it should do them as a > >> group, not via Consensus Water Torture. > > > > > > I think this is the right way to think about it. We should get = consensus on a > policy rather than discussing each and every port individually. "Ports > assigned to historic protocols will be marked historic without = requiring > additional community consultation" seems like a good policy to me. > > > > It's worth noting that there has already been some groundwork done = here; > and although community feedback indicates a need for changes to its > contents, draft-kuehlewind-system-ports seems like a good place to add = this > general policy (along with the other changes that community feedback = has > indicated). It's also worth noting that this document does exactly = what John > proposes: it proposes to mark a group of ports (including 109) as = Historic. > > > > /a > > From nobody Thu May 7 17:31:48 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97903A0834; Thu, 7 May 2020 17:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q0qTjZaKjA96; Thu, 7 May 2020 17:31:42 -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 870A23A082A; Thu, 7 May 2020 17:31:42 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jWqvT-000D5I-FZ; Thu, 07 May 2020 20:31:39 -0400 Date: Thu, 07 May 2020 20:31:33 -0400 From: John C Klensin To: Jay Daley , Michael StJohns cc: rfced-future@iab.org Message-ID: <8919270B1208E353BD1E8AB6@PSB> In-Reply-To: <46C0178A-F68E-4DF8-AAF2-A8406064B4E8@ietf.org> References: <374d33dc-2cb3-324d-8489-4a7d258dbb62@nthpermutation.com> <67D587A2-31D6-404A-AD47-0CF2DB7C30C9@ietf.org> <692ee4bb-47d3-f231-b995-22e07b94afad@nthpermutation.com> <46C0178A-F68E-4DF8-AAF2-A8406064B4E8@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-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Poll Faux Pas X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 May 2020 00:31:46 -0000 --On Friday, May 8, 2020 07:57 +1200 Jay Daley wrote: >... > And I managed to edit my response - and I note that they > don't have a "ok if you must, but don't expect me to be in > a good mood" icon. Jay, I think that, for most of us, the yellow-check can be assumed to mean "may not be in a good mood", "may not be fully awake and coherent", and/or "may be stressed by other commitments either just before or just after the slot". Sometimes I've added comments to differentiate among those when the poll permits but it is probably rarely worth the trouble in practice. best, john From nobody Fri May 8 10:40: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 4023E3A0B8D for ; Fri, 8 May 2020 10:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2_HfsP0vQMl for ; Fri, 8 May 2020 10:40:01 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 D1DD83A0B76 for ; Fri, 8 May 2020 10:40:00 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id g16so1191266qtp.11 for ; Fri, 08 May 2020 10:40:00 -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=P/C9tA+9VVOn3eOR8jmLkfd6T1uIMmWbAqzXrwZlyzg=; b=lstYfIo52xRwGc/H1ymP+LXYSSilAfEoUY2CG4JUH0ZIRCmZdW/SMWERieBKaLKADg +4boCTUSvd8V2lkEQHbwQ5K7hsEErS+t+RzFpsnUSno1nFKnt2+gTsUFKaIJMc0yqvmH S7Nmt9PpaTEyJGrtQD0bWruZIaWK1QOd65UG8QCo0VdxDPuFa7owoRNaQEYuyd4shly2 V44KikzjNeJXu5fxrhl1U9Bv4gk/u3tPA50VyPtGkhbP+ry+d9coVerU2RKv4+B98PBG LRAPn+ltCyQx8rc/tpfpZdR6r/ftMn6+YuOE07uMC5TZG6lfQOhh1UiNPyBpKv5Oc613 2OPw== 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=P/C9tA+9VVOn3eOR8jmLkfd6T1uIMmWbAqzXrwZlyzg=; b=W/E/RYBELIWSEc+9vEcuLSdfwRvvmbL3vOFW83e1R5a4buokz0qwl+0mGHi7S/dyeX 02NtujC/8yO3kXJ/hSeluSQg5s9b8t0jixiPu4C9Je7wESuNRDnUy05NJgGgqfUVk2UJ UMmbBI0ojhBiDXifzaiK3IwS+56PiiM7v77GMN2hCTKlgdnhllgvNU5ycqYK0dlpz5Fw GPv6UDHCflA5D9LbPQi+Dbph/4HVC4xdCP8PI5Eo1WO1mlUfkcy1aNn0p1HwxuYciT5S JjyAVSn4y2vUFfhfPSgAPkjgIUfa6+zqmVfFY60X8wA/ABQdJEBp57sscqP8bpNRiXm9 QCfQ== X-Gm-Message-State: AGi0Pua04HfqBRp+Dk4fSm5eZRIrrtueKyFHuWGCtTSboG+Q6DCpIVtQ zFZNa6qgdBSJw2PHVBq/aSoXsh3bXFBDxw== X-Google-Smtp-Source: APiQypLh0XoKWmFVi6X5T4G4SWCsIgGAZQAUoogcJlAFymaZxNT04mVBlGuz7FbijqeoMBaenPwgwg== X-Received: by 2002:aed:3b75:: with SMTP id q50mr4352309qte.23.1588959599036; Fri, 08 May 2020 10:39:59 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id q17sm1661873qkq.111.2020.05.08.10.39.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 10:39:58 -0700 (PDT) To: rfced-future@iab.org References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> From: Michael StJohns Message-ID: <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> Date: Fri, 8 May 2020 13:39:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> Content-Type: multipart/alternative; boundary="------------4D1C1DFBE76A65C8FEB95299" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 May 2020 17:40:04 -0000 This is a multi-part message in MIME format. --------------4D1C1DFBE76A65C8FEB95299 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Eliot - Three things.  First,  please make sure this meeting gets announced and added to the IETF calendar as well as the second one when we settle on a date/time.  I'd suggest doing that sooner than later. Second, I really hate the form of this survey.   Many of these topics are important - just not right now.  I suggested and now reiterate a 1-5 scale of "Work on now" to "defer until later"  rather than "not important" to "very important".  For the purposes of the current form, "not important" means "let's defer" and "important" means "lets talk about it". Too many of the questions read like push polls - especially the "who" questions.    e.g. "Who provides recommendations to make the series more accessible to various audiences?" comes with the assumption that "making the series more accessible" is an agreed upon goal. Lastly, what's the progress in bringing a second chair on board? Mike On 5/7/2020 7:34 AM, Eliot Lear wrote: > Hi everyone, > > As a reminder, our first virtual meeting will take place at 9:00pm GMT > on the 14th of May.  Information is below.  As we have been > discussing, in order to use that time efficiently, I invite you to > indicate what you think are the most important questions to answer.  I > expect we’ll get to discuss at most 3-4 of them. > > I have created a surveymonkey poll here. > > https://www.surveymonkey.com/r/9XGKS89 > > I will close the poll on the 11th of March so we have a day or two > just to agenda bash on list, if necessary. > > Also, I am looking for volunteers to capture in Etherpad some notes. >  If you can help, please unicast as it will speed the discussion. > > Duration: 90 minutes > > Webex Information: > https://ietf.webex.com/ietf/j.php?MTID=m6e894a38b5cf6c139af7eca0891907ca > Meeting number (access code): 618 351 526 > Meeting password: DSnNT3piK67 > > Thanks, > > Eliot > > --------------4D1C1DFBE76A65C8FEB95299 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Eliot -

Three things.  First,  please make sure this meeting gets announced and added to the IETF calendar as well as the second one when we settle on a date/time.  I'd suggest doing that sooner than later.

Second, I really hate the form of this survey.   Many of these topics are important - just not right now.  I suggested and now reiterate a 1-5 scale of "Work on now" to "defer until later"  rather than "not important" to "very important".  For the purposes of the current form, "not important" means "let's defer" and "important" means "lets talk about it".

Too many of the questions read like push polls - especially the "who" questions.    e.g. "Who provides recommendations to make the series more accessible to various audiences?" comes with the assumption that "making the series more accessible" is an agreed upon goal.

Lastly, what's the progress in bringing a second chair on board? 

Mike


On 5/7/2020 7:34 AM, Eliot Lear wrote:
Hi everyone,

As a reminder, our first virtual meeting will take place at 9:00pm GMT on the 14th of May.  Information is below.  As we have been discussing, in order to use that time efficiently, I invite you to indicate what you think are the most important questions to answer.  I expect we’ll get to discuss at most 3-4 of them.

I have created a surveymonkey poll here.

https://www.surveymonkey.com/r/9XGKS89

I will close the poll on the 11th of March so we have a day or two just to agenda bash on list, if necessary.

Also, I am looking for volunteers to capture in Etherpad some notes.  If you can help, please unicast as it will speed the discussion.

Duration: 90 minutes

Webex Information: 
https://ietf.webex.com/ietf/j.php?MTID=m6e894a38b5cf6c139af7eca0891907ca
Meeting number (access code): 618 351 526
Meeting password: DSnNT3piK67

Thanks,

Eliot



--------------4D1C1DFBE76A65C8FEB95299-- From nobody Fri May 8 10:54: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 68F593A0E6E for ; Fri, 8 May 2020 10:54:25 -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 teZet7fRqIOs for ; Fri, 8 May 2020 10:54:23 -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 764233A101B for ; Fri, 8 May 2020 10:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1382; q=dns/txt; s=iport; t=1588960430; x=1590170030; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2wb6jN4dwZ0JWiACarUc+pZwgPGZfzgeu4PlTLLRJ/Q=; b=DvUNqu4J4uqYxocEXKKtiLMIvj/AA8XPrWqK0uhkzPzdgemr494Fr7yL FfqmIfRSIzVxEhZmMWOr8g6s3DUeSR+Q8p+jErQ6iXiKTraCmY7vxXxu7 Q66FkZNe3qklw1BoJu2QSEJKR5XnqtqBIqnFxLMD0miUaCjbBlSVDWKco s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AADQm7Ve/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTUFAQELAYNsASASLIQkiQGIC5lmgXsLAQEBDAEBLwQBAYR?= =?us-ascii?q?EAoIyNgcOAgMBAQsBAQUBAQECAQUEbYVihXEBAQEBAgEYC1YFCwsYAgImAgJ?= =?us-ascii?q?XBhODJoJdIK8idoEyhVGFIIEOKgGMXYIAgTgcgh8uPoEEg0qDFDOCLQSya4J?= =?us-ascii?q?UgnGVNx2CXIhnhFqNHaoCg0UCBAYFAhWBWAEygVYzGggbFWUBgj4+EhgNkEw?= =?us-ascii?q?MC44nPwMwNwIGAQcBAQMJkhkBAQ?= X-IronPort-AV: E=Sophos;i="5.73,368,1583193600"; d="scan'208";a="26012560" 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; 08 May 2020 17:53:46 +0000 Received: from [10.61.249.146] ([10.61.249.146]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 048HrjCP008024 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 May 2020 17:53:46 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> Date: Fri, 8 May 2020 19:53:45 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.249.146, [10.61.249.146] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 May 2020 17:54:26 -0000 Hi Mike > On 8 May 2020, at 19:39, Michael StJohns = wrote: >=20 > Hi Eliot -=20 >=20 > Three things. First, please make sure this meeting gets announced = and added to the IETF calendar as well as the second one when we settle = on a date/time. I'd suggest doing that sooner than later. The last one was announced through normal channels. This is an IAB = activity and there are tooling integration issues re the IETF tools. = This having been said, I=E2=80=99ve been thinking about sending around a = calendar invite. Is that something people would like? >=20 > Second, I really hate the form of this survey. Many of these topics = are important - just not right now. I suggested and now reiterate a 1-5 = scale of "Work on now" to "defer until later" rather than "not = important" to "very important". For the purposes of the current form, = "not important" means "let's defer" and "important" means "lets talk = about it". Next time around I will happily tap you to work with me to design the = survey. I am sorry if it felt like a push poll to you. When others are = answering, please keep in mind the goal is just to figure out what to = talk about for one meeting.=20 >=20 > Lastly, what's the progress in bringing a second chair on board? =20 That=E2=80=99s not a question for me, right? Eliot From nobody Fri May 8 10:59: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 30A1A3A0E92 for ; Fri, 8 May 2020 10:59:34 -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, 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 jZZaiNVBy4Pi for ; Fri, 8 May 2020 10:59:32 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5EE3A0E74 for ; Fri, 8 May 2020 10:59:32 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id t3so2169180qkg.1 for ; Fri, 08 May 2020 10:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=9h2WgEKvUkGaRh1nXeURX6sNHrCUWLUNHiftntIsqSE=; b=VO+e2irbpJRbKuHBqvAGhZqEe+aC7buu4PZjPtZq39RexiT6GMS+Xpy60msulrzftP 9X7K0b5Ubyu2Jf9XHmE9sPEO5J73cj1svOnwN+hfUqBAtTngiM5aa+ik07wjI57j+FEg aJ/8bFHq5WtzFaybZmPFHuHvNzbQhSug3pUuG7IbCGBL0mqcoC2UStyoHiHj73npKuaA hCmhDdxzca4yIqp0YHgqjLVOgTBG0D+XR57VE68VHxTmT97exEJT73/y1SiG+Fmm5Kd1 6Jk87Km+s25VmZChyI5jaB2QrFMJHuVJQo+iiC8QxI6h6hOX+UfcFNQikbthS4YjmxqE pnGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=9h2WgEKvUkGaRh1nXeURX6sNHrCUWLUNHiftntIsqSE=; b=WZGOufkjD7UjtIlRIXRYC6Wb6M0MCADBY9uWOQRKfDa6p+QVwXqjY4NDwHa5ReBuLA ujFeAVpBzCdppOrF0oz9mB06Bz0rd1KRodaTkDgVyC1f5JmokFgax1oGlnayWkz71UF4 qNOIc9KANOllbRFnVAJ9GpwLr/sCk+17V0K+DWcHHxejmhVfcMZWsYoJRRx+CJOeN6t8 2dn4NvbJHefYv1oVIroLAjCOEFFb+dSeXTTNUrUJwmF6hkENuTMKcgBuzCMvAAHjv0vq APK+Z9Sinb+DWDME1Vn/W9CgT95Ux5ep8n6UzJkmK9a/ikLLQNUPX1pyZJ8bWpV9IgVg y1vw== X-Gm-Message-State: AGi0PubSimA6e0PTMyUJrcLDpyECuDkt6RVdLKCiNYDRByk81F2hv9GV rCd/g4qh5KUzmqVFxNptN8MPlSI5HkIISDx0 X-Google-Smtp-Source: APiQypL9RiVw4XplTS7tf9qJu2Tnl1Rpz0HVFZqFVPK4+YTAKNbE7e09pACiq9ukKqI5IJ7kgLI/zA== X-Received: by 2002:a37:a649:: with SMTP id p70mr3927343qke.255.1588960770984; Fri, 08 May 2020 10:59:30 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id l186sm1703713qkf.89.2020.05.08.10.59.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 10:59:30 -0700 (PDT) To: Eliot Lear Cc: rfced-future@iab.org References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> From: Michael StJohns Message-ID: <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> Date: Fri, 8 May 2020 13:59:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 May 2020 17:59:34 -0000 On 5/8/2020 1:53 PM, Eliot Lear wrote: > Hi Mike > >> On 8 May 2020, at 19:39, Michael StJohns wrote: >> >> Hi Eliot - >> >> Three things. First, please make sure this meeting gets announced and added to the IETF calendar as well as the second one when we settle on a date/time. I'd suggest doing that sooner than later. > The last one was announced through normal channels. This is an IAB activity and there are tooling integration issues re the IETF tools. This having been said, I’ve been thinking about sending around a calendar invite. Is that something people would like? I'm sure it wouldn't be all that hard to announce this as an interim of some sort.  And yes, the calendar invite would be helpful. > >> Second, I really hate the form of this survey. Many of these topics are important - just not right now. I suggested and now reiterate a 1-5 scale of "Work on now" to "defer until later" rather than "not important" to "very important". For the purposes of the current form, "not important" means "let's defer" and "important" means "lets talk about it". > Next time around I will happily tap you to work with me to design the survey. I am sorry if it felt like a push poll to you. When others are answering, please keep in mind the goal is just to figure out what to talk about for one meeting. I believe I provided you the critical input of "let's talk now" to "let's wait" prior to you sending out the survey?   With respect to the questions, I do understand that you took them from the list, but they made me cringe. > >> Lastly, what's the progress in bringing a second chair on board? > That’s not a question for me, right? Actually  - it is.  I would expect that you would be interfacing with the IAB asking the self-same question rather than have all of us nudging them.   Feel free to pass the responsibility on to the liaisons. Later, mike > > Eliot > From nobody Fri May 8 17:13: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 4CCA43A02BE for ; Fri, 8 May 2020 17:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgr-0ocIEpAM for ; Fri, 8 May 2020 17:13:06 -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 D0CD63A02BD for ; Fri, 8 May 2020 17:13:06 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 2ADAB21599; Fri, 8 May 2020 17:13:06 -0700 (PDT) From: Wes Hardaker To: Michael StJohns Cc: Eliot Lear , rfced-future@iab.org References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> Date: Fri, 08 May 2020 17:13:06 -0700 In-Reply-To: <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> (Michael StJohns's message of "Fri, 8 May 2020 13:59:29 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 00:13:10 -0000 Michael StJohns writes: > > That=E2=80=99s not a question for me, right? >=20 > Actually=C2=A0 - it is.=C2=A0 I would expect that you would be interfacin= g with > the IAB asking the self-same question rather than have all of us > nudging them.=C2=A0=C2=A0 Feel free to pass the responsibility on to the > liaisons. Hi Mike, The timeline sent under the call for future chairs can be found here: https://mailarchive.ietf.org/arch/msg/ietf-announce/qNLbJ8FF7dxLvlQSWJVCDRO= 5q9E/ In that announcement you'll find that the call for volunteers ends on 2020-05-12, which is early next week. --=20 Wes Hardaker USC/ISI From nobody Fri May 8 17:27: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 D983A3A0062 for ; Fri, 8 May 2020 17:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzkJweYiZE-c for ; Fri, 8 May 2020 17:27:32 -0700 (PDT) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 7F5A83A005C for ; Fri, 8 May 2020 17:27:32 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id v23so901486vke.13 for ; Fri, 08 May 2020 17:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jn7WUwUTX9+iGZTB8bOJm/fkpQ7PEImdn5UqbNvYRBQ=; b=ATtBelek05Qr3QcMIviiwGgCxnaQVY6PZusvPBQmgSMA7j3vmdfcs9YlqIU8DCdgSj xmvp8sklBIREb6BzfxLI8yOHBlSPylg8PC/di9w5IWIBnPBVVieqGDmsR7vhu1rfNBqf SX6APPyB7P3wCqKVqjV1BC5cFviXId+9qMq8nLYqgOls/q+k8lGVS0tYKxqFEmct5BFA yaFzHWkHY4FRYCchjrwvapVzYw8pbC6Ftm3P5fPZWshMldfFeZlqqT53+kpvPgw/Xsr8 ZXa5eRVUrNrkAjr9qfbNr2fPFeBkanABaJ4E7za+tpzJDntTsqhLFLc20FTCG97cGBGa RaUQ== 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=jn7WUwUTX9+iGZTB8bOJm/fkpQ7PEImdn5UqbNvYRBQ=; b=lUt2g3Wji1EYGnvpOn7z+iSn1A3zB1i4Dh9GPsMJ8gcXe9HCnsh2nwU/7/rk24gdNI VSsshHp73+8NAPe2hSPClX+1STM6LR702V2MoeapAkhZ+N56+BFB/rF4FMs94rdO/Z+m Bb5U4ZmchKBBDdLD7//CcgrZqL5GjU53JsNMcbpBYQlOv8O8wGkedbDprlTKGE9PAQGP oN7IEEMhG6uipJa96yQoslBXs8kmM9qypiyuffrZx/PzcaKwwgpQw10RzCoZgLnCfgeT qPGcB7XsdJB3z0QEagUxdpnEtShoBGYKDxbw2sF78As1N27iR/ErbGiws2JdAo1a/DLD b/2g== X-Gm-Message-State: AGi0PuZmlb+eKk7hu7C0M7vo6iuBqXuWku5xQ9R5BB2x6pNt6BXA35nJ 8DJivWpHX9V3kYCBskrks6li1yTCTGeeaxut43Cjkg== X-Google-Smtp-Source: APiQypK4Q5srnp4V7CUCO4lDqF5zoHROW6fWkNltpdBgXQoYqJMWP+WH9ab3EExBL5QnjOwEfJ+9nhfg6USgrJXJTM0= X-Received: by 2002:a1f:cd83:: with SMTP id d125mr4488199vkg.35.1588984050738; Fri, 08 May 2020 17:27:30 -0700 (PDT) MIME-Version: 1.0 References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> In-Reply-To: From: "StJohns, Michael" Date: Fri, 8 May 2020 20:27:19 -0400 Message-ID: To: Wes Hardaker Cc: Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000e5fe8505a52c2da5" Archived-At: Subject: Re: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 00:27:37 -0000 --000000000000e5fe8505a52c2da5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yup - and I assume you=E2=80=99ll tell us if you need more volunteers in or= before that date? On Fri, May 8, 2020 at 20:13 Wes Hardaker wrote: > Michael StJohns writes: > > > > That=E2=80=99s not a question for me, right? > > > > Actually - it is. I would expect that you would be interfacing with > > the IAB asking the self-same question rather than have all of us > > nudging them. Feel free to pass the responsibility on to the > > liaisons. > > Hi Mike, > > The timeline sent under the call for future chairs can be found here: > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/qNLbJ8FF7dxLvlQSWJVCD= RO5q9E/ > > In that announcement you'll find that the call for volunteers ends on > 2020-05-12, which is early next week. > -- > Wes Hardaker > USC/ISI > --000000000000e5fe8505a52c2da5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yup - and I assume you=E2=80=99ll tel= l us if you need more volunteers in or before that date? =C2=A0=C2=A0
=
On Fri= , May 8, 2020 at 20:13 Wes Hardaker <wjhns1@hardakers.net> wrote:
Michael StJohns <msj@nthpermutation.com> writes:

> > That=E2=80=99s not a question for me, right?
>
> Actually=C2=A0 - it is.=C2=A0 I would expect that you would be interfa= cing with
> the IAB asking the self-same question rather than have all of us
> nudging them.=C2=A0=C2=A0 Feel free to pass the responsibility on to t= he
> liaisons.

Hi Mike,

The timeline sent under the call for future chairs can be found here:

https://mailarchive.= ietf.org/arch/msg/ietf-announce/qNLbJ8FF7dxLvlQSWJVCDRO5q9E/

In that announcement you'll find that the call for volunteers ends on 2020-05-12, which is early next week.
--
Wes Hardaker
USC/ISI
--000000000000e5fe8505a52c2da5-- From nobody Fri May 8 20:22:59 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AB23A086E for ; Fri, 8 May 2020 20:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc7KF-YCaJPC for ; Fri, 8 May 2020 20:22:57 -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 49F953A086D for ; Fri, 8 May 2020 20:22:57 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 384E93283E; Fri, 8 May 2020 20:22:56 -0700 (PDT) From: Wes Hardaker To: "StJohns\, Michael" Cc: Wes Hardaker , Eliot Lear , rfced-future@iab.org References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> Date: Fri, 08 May 2020 20:22:56 -0700 In-Reply-To: (Michael StJohns's message of "Fri, 8 May 2020 20:27:19 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 03:22:59 -0000 "StJohns, Michael" writes: > Yup - and I assume you=E2=80=99ll tell us if you need more volunteers in = or > before that date? =C2=A0=C2=A0 The IAB always benefits from as many volunteers as possible for positions it needs to fill, just like the IETF and the nomcom benefit for a wide set of candidates as well. So certainly, if any one else is interested in volunteering to serve with Eliot as an additional chair(s), we'd love to hear from them. --=20 Wes Hardaker USC/ISI From nobody Fri May 8 21:58:53 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C873A0747 for ; Fri, 8 May 2020 21:58:51 -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, 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 4fjKxGHumgjF for ; Fri, 8 May 2020 21:58:49 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 64D5B3A0743 for ; Fri, 8 May 2020 21:58:49 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id n14so4127721qke.8 for ; Fri, 08 May 2020 21:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=AhDmP0AOF2mbrwiKQi9YO82RiaU04K7ChC2uIT98Twc=; b=RvrQqBsjhoLJjQplez8KHG6jF/2lH3sck4K2BdohUR6raC+RTM6VgGUxyBQMPvAc23 RDuIVDO+ob1izbvsnKPe0xsnAlvHqk+42pHcK0nOPkj64PqDlx61p4atUNUgEwg9aAcv cF+dyTezGoeNkNQCaArdOCRbFr73hS0vsD2pTZN+PyAwKJtMKAQiDoMsDX0Z0ckiUgr1 4u9VCSfCT/U3X0Id7iWajQmNdwITzvfy1D+wRlFaDQVpQyGe9FY8K64mU3jBsv+663RF T8aVDJqj476PIb8ELIU4wLrYRAJ5mDgRyoIc+T+ca0c3x7nDxyLTx1cS7zFeSupNitEn ZYdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=AhDmP0AOF2mbrwiKQi9YO82RiaU04K7ChC2uIT98Twc=; b=oHvQPI2r+HRVbzoV6gancl+0+JjLurHNFxPF/bL2X7vPM56b7e2/lGXfBhL4PPR5SY Wksq9m18BtxZDgzX0qDtwqjtgSpR7Ix/ConkKv+ph06hUQii0n7usyJ/+RyeiZix4i8c 84ThdVSR/9FOCSIttpUQPpzhJ+uO5U+HhfoiSfZSEo5fg4Q2enuTw8Ea2rEsrKiiOkUW w1tOrx4M1tFgf0C7+vO3HJW+DxvnURDyo/yezowDj8Jp9zC+K9ImGwg2Womn0q4ZrtUR UrNnUaqCCJtPL0jQEJLqZ89kxzjnVYIna99cgD7d+E+g3EjMpaHUV3VgP7js2U/GNq/y V9rg== X-Gm-Message-State: AGi0PuaMzVSXaZ7P7TJYkS4YpjZSW7EM7o37qaA9pE5LZGcGNal4rWyp NbxvBspmA30216O+fyftSA7f8g== X-Google-Smtp-Source: APiQypKPuVXvpJA5ETr7/CzdHoWNezjeS5iiXcWVQYKhBCKALCkErT+JcAy6Qjwn2oKQJPzbXikI2g== X-Received: by 2002:a37:6145:: with SMTP id v66mr6132945qkb.458.1589000327688; Fri, 08 May 2020 21:58:47 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id x24sm3359392qth.80.2020.05.08.21.58.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 21:58:46 -0700 (PDT) To: Wes Hardaker Cc: Eliot Lear , rfced-future@iab.org, iab@iab.org References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> From: Michael StJohns Message-ID: <02ac1c76-6aa3-7765-bd8e-ffd12cc86109@nthpermutation.com> Date: Sat, 9 May 2020 00:58:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 04:58:52 -0000 On 5/8/2020 11:22 PM, Wes Hardaker wrote: > "StJohns, Michael" writes: > >> Yup - and I assume you’ll tell us if you need more volunteers in or >> before that date? > The IAB always benefits from as many volunteers as possible for > positions it needs to fill, just like the IETF and the nomcom benefit > for a wide set of candidates as well. So certainly, if any one else is > interested in volunteering to serve with Eliot as an additional > chair(s), we'd love to hear from them. > Nope, but nice try.   Community said 2 or 3 chairs.  IAB-the-last didn't follow the community direction.  IAB-current  should be well on its way to having people to fill a second or third chair role, even if they need to dragoon someone or twist arms.  If we get to 12 May without sufficient volunteers, or with another rejection of Nevil and/or John (and if the IAB didn't consider them as nominees for the role, consider this my nomination - and I've cc'd the IAB for that purpose) that seems to be a problem that the IAB should be involving the community in earlier rather than later.  If you tell me that you've got a few good candidates and don't expect to have to reopen calls for volunteers, that would be sufficient and surprisingly refreshing.  I would be very disappointed if on the 12th of May we're where we were when the call went out the first time. Later, Mike From nobody Fri May 8 22:13: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 3FC663A0766 for ; Fri, 8 May 2020 22:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i1QQb1hWK1d for ; Fri, 8 May 2020 22:12:56 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53033A0763 for ; Fri, 8 May 2020 22:12:56 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id p25so2068693pfn.11 for ; Fri, 08 May 2020 22:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=oQZoIdjWRtBbh0/ojmhNSlCvZzaFjhwlHLlGfA9s3fQ=; b=fb4Q7FFMKiZSPjHFag38YvZpRAfnu5lPiAVix2KpVQjySo70E3r7owdrq9+ndWDMph vrnLqCejFu2lb975NECVdDyPPRrrP3cJaVsBSqsvPBahqsSiSACQWZjj2pGlmcZADKf4 ykG+Xm8G59NzSedE1RisN1wNQbvKY7syCHodwv8UzDjbBxFvcm4ys3yctNnM+ilNULAE EsbqoNpYKWHyBJk/JimSszXB/tw+VUM6r2cnoM/2nAkP+yx5oqBPaJDQu75JYVkMeSnE vaRyKrxxAzvTb8ckcjLODYMAzDMorB21Z0HY1vLQPvYrPCL6VTBKy5X5GzMBbcp/KwBt zaiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oQZoIdjWRtBbh0/ojmhNSlCvZzaFjhwlHLlGfA9s3fQ=; b=cjWn5VqYqScfhcF/FYBvfwFphyRtazq4dHIJd7PsteFNsUyIxZkgjOkljrAPoQZV/p m5vibwysX3cws7lcTFljRpUPwBlsRGqecidPFz93VNzJDnYKNO9qFfcshNM3DXzib7iE zdCZ/oe+qQDNea9ufpiWOqAK2HcMrQ6klMWk/vKDzwifvBQSnC9JrXmoBV0j55NCQJfW HD1HXhrM1pJYAV95AS/WUNXMF8KZha2y+nk6LBRfpMV/CJDMT0eeX7e34XzFHgQZsmmp lPoW7sBUahTR6PwKyzci+aoPgra7h1JSmQoK58L8DSKMWSD0ROEs/S5UahkAplPXyCaG NlaA== X-Gm-Message-State: AGi0PuaqDy50EH6fnZJqZWHNxSTdqELGj6BYwjYwKaI9lf2JvhB5j5Dp 3RxEkx8fvPgRFE9S+nh7pv9uNceD X-Google-Smtp-Source: APiQypLhG3J7QvPP6V91Wj8N0zntdMsniZS2fZZSKeY2XSE8n5UgfrMwzbUDx4k2rvdio3YdP/zcLw== X-Received: by 2002:a63:1e22:: with SMTP id e34mr5319993pge.427.1589001175764; Fri, 08 May 2020 22:12:55 -0700 (PDT) Received: from [192.168.178.30] (207.252.69.111.dynamic.snap.net.nz. [111.69.252.207]) by smtp.gmail.com with ESMTPSA id i72sm3702796pfe.104.2020.05.08.22.12.54 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 May 2020 22:12:55 -0700 (PDT) References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> To: rfced-future@iab.org From: Brian E Carpenter X-Forwarded-Message-Id: <158900073744.13624.17132280974290551869@ietfa.amsl.com> Message-ID: <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> Date: Sat, 9 May 2020 17:12: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: <158900073744.13624.17132280974290551869@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] Fwd: I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 05:12:58 -0000 Hi, This draft is intended as background material for ongoing discussions about the role of the Request for Comments (RFC) Series Editor (the RSE). This version is purely personal opinion. I welcome comments, best sent to rfc-interest@rfc-editor.org if they concern the RFC Series in general, or to rfced-future@iab.org if they concern the role of the RSE specifically. I advise reading the pretty HTML version since this draft is in v3 format: https://www.ietf.org/id/draft-carpenter-rfc-principles-00.html Regards, Brian -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-rfc-principles-00.txt Date: Fri, 08 May 2020 22:05:37 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Principles of the Request for Comments Series Author : Brian Carpenter Filename : draft-carpenter-rfc-principles-00.txt Pages : 9 Date : 2020-05-08 Abstract: This document discusses the underlying principles of the Internet technical community's Request for Comments document Series. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-rfc-principles/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-rfc-principles-00 https://datatracker.ietf.org/doc/html/draft-carpenter-rfc-principles-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sat May 9 01:01:51 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDFA3A08CA for ; Sat, 9 May 2020 01:01:48 -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 qEb_GUxdfjL9 for ; Sat, 9 May 2020 01:01:43 -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 196893A0848 for ; Sat, 9 May 2020 01:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6849; q=dns/txt; s=iport; t=1589011303; x=1590220903; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=zO9ANkNe8AUQAslEV6zvgfZYhEksDp+wfqy8PwAgH7g=; b=h/WdyZSw4wYjs35qyuY8UgUvlzVSPHKJ+62yJLDpXbX8TzSCcx8uoemb V+fR1sebEr9Q4ZYefUdcnG36omFVMq85hEMMV570eJrMvNBMTCu9GhwVa yEV0duiUilueNzu+vL5JoOl6UJc+KcnE63oxECI+2+PUqxxCKolBl+WhG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAACOYrZe/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBdQUBAQsBgSSCSAEgEoRQiQGIC5NVhhGBewsBAQEMAQEvBAE?= =?us-ascii?q?BhEQCgjI2Bw4CAwEBCwEBBQEBAQIBBQRthWKFcgEEARgLVgULC0ICAlcGgzm?= =?us-ascii?q?CXSCuCnaBMoVRhSSBOAGMXYIAgTgcgh8uPoEEhl4zgi0EsmuCVIJxlTcdgly?= =?us-ascii?q?IZ4RajR2qAoNFAgQGBQIVgVkMJoFWMxoIGxU7KgGCPz0SGA2QTAwLjic/A2c?= =?us-ascii?q?CBgEHAQEDCY5GAQE?= X-IronPort-AV: E=Sophos; i="5.73,371,1583193600"; d="scan'208,217"; a="26027863" 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; 09 May 2020 08:01:39 +0000 Received: from [10.61.248.55] ([10.61.248.55]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 04981djP006888 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 May 2020 08:01:39 GMT From: Eliot Lear Message-Id: <95710E23-8FC8-4D81-A23B-326B080DC1A7@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9ADD4567-5975-4251-9ED6-D8D3DBEF8CF5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 9 May 2020 10:01:38 +0200 In-Reply-To: <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.248.55, [10.61.248.55] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 08:01:49 -0000 --Apple-Mail=_9ADD4567-5975-4251-9ED6-D8D3DBEF8CF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good morning, Mike. > I'm sure it wouldn't be all that hard to announce this as an interim = of some sort. And yes, the calendar invite would be helpful. The last meeting did get announced both on the -Announce list and here. = See the archives from the 30th of April. I=E2=80=99ll be happy to send = out the calendar invite so long as nobody objects. The next meeting = will be announced shortly in a similar fashion. All are welcome. >=20 >>=20 >>> Second, I really hate the form of this survey. Many of these = topics are important - just not right now. I suggested and now = reiterate a 1-5 scale of "Work on now" to "defer until later" rather = than "not important" to "very important". For the purposes of the = current form, "not important" means "let's defer" and "important" means = "lets talk about it". >> Next time around I will happily tap you to work with me to design the = survey. I am sorry if it felt like a push poll to you. When others are = answering, please keep in mind the goal is just to figure out what to = talk about for one meeting. >=20 > I believe I provided you the critical input of "let's talk now" to = "let's wait" prior to you sending out the survey? With respect to the = questions, I do understand that you took them from the list, but they = made me cringe. Ok. Again, happy to work with you on the next time around. Eliot --Apple-Mail=_9ADD4567-5975-4251-9ED6-D8D3DBEF8CF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Good morning, Mike.

I'm sure it wouldn't be all that hard to announce this as an = interim of some sort.  And yes, the calendar invite would be = helpful.

The last meeting did get announced both on the = -Announce list and here.   See the archives from the 30th of April. =  I=E2=80=99ll be happy to send out the calendar invite so long as = nobody objects.  The next meeting will be announced shortly in a = similar fashion.  All are welcome.




Second, I really hate the form of this survey. =   Many of these topics are important - just not right now. =  I suggested and now reiterate a 1-5 scale of "Work on now" to = "defer until later"  rather than "not important" to "very = important".  For the purposes of the current form, "not important" = means "let's defer" and "important" means "lets talk about it".
Next time around I will happily tap you to work = with me to design the survey.  I am sorry if it felt like a push = poll to you. When others are answering, please keep in mind the goal is = just to figure out what to talk about for one meeting.

I believe I provided you the critical input of "let's talk = now" to "let's wait" prior to you sending out the survey?   = With respect to the questions, I do understand that you took them from = the list, but they made me cringe.

Ok.  Again, happy to work with you on the next = time around.

Eliot

= --Apple-Mail=_9ADD4567-5975-4251-9ED6-D8D3DBEF8CF5-- From nobody Sat May 9 12:41: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 F04143A0FA5 for ; Sat, 9 May 2020 12:41:40 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjwZfcylY9RX for ; Sat, 9 May 2020 12:41:39 -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 82B703A0FA7 for ; Sat, 9 May 2020 12:41:39 -0700 (PDT) Received: (qmail 97585 invoked from network); 9 May 2020 19:41:38 -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=17d2d.5eb70772.k2005; bh=v3TkDoEZjpN43+9b2s8FTYojCJ3fJcnJ9lVUH+KH7YY=; b=GnO473sBKZwOU5eqP1Y8fyqPpSeNuAfqNp2qGCZwKRmfZ93IRnDJeqrdPDWPsIvz6ro5Xg9x5WTTRWC1VrssKyginPbjNbhmtc/VjUObgB/Fmv7YLLfZqFzgI7SwveQ/OmQT6gG3mQCC4rFRGumXAKavJNlP2ldjc+aFnFMc1Hcle+wTsEM0fRH83l9YD2+pqeRbT6zxP87IxpDtOcXZD1m/qILiUxDncyjVw7l3m0VrrB1iXXINFnwV7bqHm2RZ Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 09 May 2020 19:41:37 -0000 Received: by ary.qy (Postfix, from userid 501) id AA84818F423E; Sat, 9 May 2020 15:41:37 -0400 (EDT) Date: 9 May 2020 15:41:37 -0400 Message-Id: <20200509194137.AA84818F423E@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: msj@nthpermutation.com, iab@iab.org In-Reply-To: <02ac1c76-6aa3-7765-bd8e-ffd12cc86109@nthpermutation.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] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 19:41:41 -0000 In article <02ac1c76-6aa3-7765-bd8e-ffd12cc86109@nthpermutation.com> you write: >sufficient volunteers, or with another rejection of Nevil and/or John >(and if the IAB didn't consider them as nominees for the role, consider >this my nomination - Thanks, but no. As I think I've said before, It would be too much of a conflict with my paid role. R's, John From nobody Sat May 9 13:14: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 AB2683A07FB for ; Sat, 9 May 2020 13:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQaMOLox4-Jt for ; Sat, 9 May 2020 13:14:22 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 B766F3A07F6 for ; Sat, 9 May 2020 13:14:22 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id v23so1331391vke.13 for ; Sat, 09 May 2020 13:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zf/SGvpvW6OzyMWiDgT6KTZGvvgvaCvMmMDzW+KoYhk=; b=lskIDrjrV7/UkgZlwBMj1lu+TcmIRX0/vjC/mXsX6zMCoC3S3uKj8ABBn55jBGhi96 6465ReLLFWT7YSx7u/jRh4Pa4euAoNZHwLJpF4Q6t0Psgt19KoIcF6Stm6pb+nTVoIuj 9awGR1B6uGZ1X0mHQTfUVtV2b7gdztwdLaEX6SSQbPFFLGj0dbaXH5r5Ea4MaEKkbmnE J6MIrrrR5mruyQWyEnU2Mt27mCFI2K+1F3fgJl5XcDpY9eVv+nUQCMp293lCcQoU4tht Vkh78ohqwmQeePkah2paWbXJGAud7hcmXQCM6qnxBCc5F3kFN5MnbacQgy4/qXu47rFW BHgA== 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=zf/SGvpvW6OzyMWiDgT6KTZGvvgvaCvMmMDzW+KoYhk=; b=E1PFhVzkMH5667A2jgEb/Gqr2mwm6eTd2w52qSewdDrqgtIlOJRP1LgpWiOX7dUAbD U7PjvzegaQiLM7TCoE/k9hKT7sSQs+ikExFTd5uxgLFWK8vjjECi8UqYfMicIP4YUlPE mC87FBbJ16q/AXxXwe6An8qY96SRFdbwLuSKYcU82KH1pYwWqtaAUi5HpXtPDFBrA2Pl 4+VEBSEZxfOWMBUVNhvSsNez7WNl9vtqeetJUdqKW3RxVZR+7s7+WVmVobF/UzvK8G2E 9qKvw1IXr7gwfnLVr951MM5+nmvPe/0WCAgRsoBPExwAPMrwgNN92Xn4TEz+iLALtzty 81KQ== X-Gm-Message-State: AGi0PublA4dlp1vWCXXJe5gw/oSLc2zDjwbukY5iNd5bcGAAjrBwdRZb drvz4lLFDQvMWm/VAuT12yMB9/BXRAewcm88h4zTlQ== X-Google-Smtp-Source: APiQypIbC5nhfiPPEfTBk64fdwfoBXs2G90ORFptaOnzCmNiw2S10f4Jmom/Bcs6Q+muu+amtx8/VeRsDpoUU9iJgIA= X-Received: by 2002:a1f:cd83:: with SMTP id d125mr6608985vkg.35.1589055261319; Sat, 09 May 2020 13:14:21 -0700 (PDT) MIME-Version: 1.0 References: <02ac1c76-6aa3-7765-bd8e-ffd12cc86109@nthpermutation.com> <20200509194137.AA84818F423E@ary.qy> In-Reply-To: <20200509194137.AA84818F423E@ary.qy> From: "StJohns, Michael" Date: Sat, 9 May 2020 16:14:10 -0400 Message-ID: To: John Levine Cc: iab@iab.org, rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000613dfc05a53cc2a0" Archived-At: Subject: Re: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 20:14:25 -0000 --000000000000613dfc05a53cc2a0 Content-Type: text/plain; charset="UTF-8" Klensin On Sat, May 9, 2020 at 15:41 John Levine wrote: > In article <02ac1c76-6aa3-7765-bd8e-ffd12cc86109@nthpermutation.com> you > write: > >sufficient volunteers, or with another rejection of Nevil and/or John > >(and if the IAB didn't consider them as nominees for the role, consider > >this my nomination - > > Thanks, but no. As I think I've said before, It would be too much of > a conflict with my paid role. > > R's, > John > --000000000000613dfc05a53cc2a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Klensin=C2=A0

On Sat, May 9, 2020 at 15:41= John Levine <johnl@iecc.com> w= rote:
In article <02ac1c76-6aa3-7765-bd8e-ffd12cc86109@nthpermutation.com> you wri= te:
>sufficient volunteers, or with another rejection of Nevil and/or John <= br> >(and if the IAB didn't consider them as nominees for the role, cons= ider
>this my nomination -

Thanks, but no.=C2=A0 As I think I've said before, It would be too much= of
a conflict with my paid role.

R's,
John
--000000000000613dfc05a53cc2a0-- From nobody Sat May 9 13:53: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 D84203A099F; Sat, 9 May 2020 13:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMAGQXXHFgzM; Sat, 9 May 2020 13:53:38 -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 D0B213A0998; Sat, 9 May 2020 13:53:37 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 0465E20687; Sat, 9 May 2020 13:53:36 -0700 (PDT) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , Eliot Lear , rfced-future@iab.org, iab@iab.org References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> <02ac1c76-6aa3-7765-bd8e-ffd12cc86109@nthpermutation.com> Date: Sat, 09 May 2020 13:53:35 -0700 In-Reply-To: <02ac1c76-6aa3-7765-bd8e-ffd12cc86109@nthpermutation.com> (Michael StJohns's message of "Sat, 9 May 2020 00:58:45 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 20:53:40 -0000 Michael StJohns writes: > On 5/8/2020 11:22 PM, Wes Hardaker wrote: > > "StJohns, Michael" writes: > > > >> Yup - and I assume you=E2=80=99ll tell us if you need more volunteers = in or > >> before that date? > > > > The IAB always benefits from as many volunteers as possible for > > positions it needs to fill, just like the IETF and the nomcom benefit > > for a wide set of candidates as well. So certainly, if any one else is > > interested in volunteering to serve with Eliot as an additional > > chair(s), we'd love to hear from them. > > >=20 > Nope, but nice try. FYI, I wasn't "trying" for anything (and am a bit confused). One important consideration (IMHO) when opening a time window with a call for nominations is that if half way through you state how many nominations you have, it will end up changing the candidate pool. If the number seems low to people, then people may get scared off from submitting their name, assuming the job is too hard (unlikely, but possible). If the number seems sufficiently large, then they may not apply because "there are already enough volunteers" or "I'd never be chosen". [again: speaking only from my point of view; others may disagree with me about this line of thinking] After the call is over on the 12th, and the IAB meets on the 13th I expect we'll have an announcement for the next step, which will include collecting feedback, per item 2 in the minutes from Apr 08: https://www.iab.org/documents/minutes/minutes-2020/iab-minutes-2020-04-08/ > If we get to 12 May without sufficient volunteers, or with another > rejection of Nevil and/or John (and if the IAB didn't consider them as > nominees for the role, consider this my nomination - and I've cc'd the > IAB for that purpose) Thanks for nominating them. We considered only those that were willing. I know I personally wrote both of them and asked them to please consider putting their names forward again. --=20 Wes Hardaker USC/ISI From nobody Sat May 9 15:41: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 372093A0BFB for ; Sat, 9 May 2020 15:41: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zs9fAcJXUQfD for ; Sat, 9 May 2020 15:41:04 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 561B33A0C1B for ; Sat, 9 May 2020 15:41:04 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id x13so806106qvr.2 for ; Sat, 09 May 2020 15:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ENkS4XGNYoZV1efNOpL4hBXkq+thv6TSnPKgogg844E=; b=rI5EO08YxfqDU7GkYsBhbV0POHyXDB+OaezTW/nETkReYLaq8K3mV++VYDK631i8a5 IEOmFAHcvT1JEyxu7E/F9+zsvgrof9kwo9J62EPqcAkDwv/5ndhT2SI8REmzpStp/mAk cpxBoq8Dgv5RgNw6DdoYq87JCSnFOR5dvJVWauKx4U9NXKON5NXnY+h1nClTRSmA3+OZ 2zqazMRZVtiOJsCUtfxDgpZJbgKc5bqaKLgPj8GQ4Z6vlx81Bzq2UMGKUyX5uSEXnJrd yyMF74kznV18JtyuqWQoYHHQJ93ocqFlwiZri9J5HsysEL90EBqLG4T5XI2vNHTEJP2f 8jnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ENkS4XGNYoZV1efNOpL4hBXkq+thv6TSnPKgogg844E=; b=rM9HWnLT0Bmacs0YnsxckQaF3ky6b3vS2I2WDQvs92/q5xH7eGvHF82K2PIn2z+OO6 zebKBAHlLUgTWXnMCJ4G1cqedXtOBCTqSN3IEY69LOAA70gYUs9Yz0kdk3Kr3d9ziLW+ 6eSEnKmMMdfCpzeA9RYGsf+h5zgElJYzK7NaqnbTGNe2NXvN5WdAIqzJp7+AdsDln4gv JxfC4EB3IA7iFGykRpi2XXbcIdnd7lP+S4+MZDAUQ89tge7yaO8D7EpXyXrmiSsmq82k e75QQsba/gDSN0S6AmP0O6S7iYr4Q0aecMmml8WpaDG8NQb/AURX/7PBaAAtdyIbxq8z R3/Q== X-Gm-Message-State: AGi0PuZ+tlAI1iFgJL805J2owXYfh7StDeMy+qEjpGyR86pnRSVghSqs YfFrlCipVOi7z7eerWpYf164Jg== X-Google-Smtp-Source: APiQypJVVKU/KhH5Je79wvU0KEbVJ5uBqpVxju++TfqCG+7moHkZ43kgKBTBjNIBUUw8ro0s6MlWFw== X-Received: by 2002:a0c:cdc9:: with SMTP id a9mr8955695qvn.243.1589064062865; Sat, 09 May 2020 15:41:02 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id 23sm4489451qkk.11.2020.05.09.15.41.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 15:41:02 -0700 (PDT) To: Wes Hardaker Cc: Eliot Lear , rfced-future@iab.org, iab@iab.org References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> <02ac1c76-6aa3-7765-bd8e-ffd12cc86109@nthpermutation.com> From: Michael StJohns Message-ID: <01882a23-bc17-8aeb-8546-d6f30356488f@nthpermutation.com> Date: Sat, 9 May 2020 18:40:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 22:41:07 -0000 On 5/9/2020 4:53 PM, Wes Hardaker wrote: > Michael StJohns writes: > >> On 5/8/2020 11:22 PM, Wes Hardaker wrote: >>> "StJohns, Michael" writes: >>> >>>> Yup - and I assume you’ll tell us if you need more volunteers in or >>>> before that date? >>> The IAB always benefits from as many volunteers as possible for >>> positions it needs to fill, just like the IETF and the nomcom benefit >>> for a wide set of candidates as well. So certainly, if any one else is >>> interested in volunteering to serve with Eliot as an additional >>> chair(s), we'd love to hear from them. >>> >> Nope, but nice try. > FYI, I wasn't "trying" for anything (and am a bit confused). Apologies - that was a bit snarky - even for me.   However you basically said "the more the merrier" which didn't answer the question I asked.  So deflection.  The paragraph below actually does answer what I asked - (To paraphrase: "Not yet - but wait for it") but unfortunately does not comfort my concerns. > > One important consideration (IMHO) when opening a time window with a > call for nominations is that if half way through you state how many > nominations you have, it will end up changing the candidate pool. If halfway through the period you send another reminder announcement you might also end up changing the candidate pool - what's your point?  Also, I did not indicate any requirement to state "we have X nominations, but we need Y more". In fact the original announcement was sent on the 16th of April and no follow up has been made even though that's best practice for such solicitations. > If > the number seems low to people, then people may get scared off from > submitting their name, assuming the job is too hard (unlikely, but > possible). Sorry - I'm having problems buying this argument.  This is a chair for a limited time/specific goal task group who is supposed to have no plenary authority, and no role other than cat herder and participant.   I'm pretty sure that anyone in the category you describe probably wouldn't be volunteering in any case. > If the number seems sufficiently large, then they may not > apply because "there are already enough volunteers" or "I'd never be > chosen". [again: speaking only from my point of view; others may > disagree with me about this line of thinking] Again, this is not a selection for an IESG position, nor is it a job that anyone really wants - but it's a job that needs to be done.  The IAB should be actively recruiting a capable candidate rather than just waiting for them to present themselves.  The criteria provided by the community was clear and the set of folks that meet that criteria are somewhat finite.   If at this point in time you have say 2 candidates, and the IAB feels neither is capable you should either be twisting arms or getting someone like a past IETF chair or two to twist arms. I'm not actually sure how we got into a nomcom-like selection process here.   This probably would have made a lot more sense being done the way the ISOC selects the Nomcom chair. > > After the call is over on the 12th, and the IAB meets on the 13th I > expect we'll have an announcement for the next step, which will include > collecting feedback, per item 2 in the minutes from Apr 08: > > https://www.iab.org/documents/minutes/minutes-2020/iab-minutes-2020-04-08/ As I indicated I'll be pretty disappointed in the IAB if we get to the same point of "re-opening" nominations then dismissing candidates as we did previously.     If we follow the same relative time line as last time, we'll get a new chair somewhere around the end of June or beginning of July.   (+2 weeks for more candidates, +2 weeks for public comment, +2-3 weeks until an announcement is made). Mike > >> If we get to 12 May without sufficient volunteers, or with another >> rejection of Nevil and/or John (and if the IAB didn't consider them as >> nominees for the role, consider this my nomination - and I've cc'd the >> IAB for that purpose) > Thanks for nominating them. We considered only those that were willing. > I know I personally wrote both of them and asked them to please consider > putting their names forward again. From nobody Sat May 9 15:47: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 6E8D33A0C26 for ; Sat, 9 May 2020 15:47: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, 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 UEpZf3eCy2hM for ; Sat, 9 May 2020 15:47:12 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 76F5F3A0C00 for ; Sat, 9 May 2020 15:47:12 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id r3so2792746qvm.1 for ; Sat, 09 May 2020 15:47:12 -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=Qro7Cc8/Y8xNopnkmPvIhM0jkqW62xNnkRukgv4vVCo=; b=Rm02pdTroHaOk8L56kQoD+IpZqy+6F4pVX9h4DnfWy/awq1Pjy36tZv5FdsxWS1xrJ QuZWQJJMnwF4aJUe5QWZ1lRIblQsKqgcO7G9hGci1EQZzBhCdSLD8pYz+QsyGipFzFGx bxUMxfOyQO4/jzgeSOjsDoSYwUPe6ztm8AQvFqbDGObwCBpHRbiMjzdZP2odzfKpH2u5 +BwI87AMlE4dLeNzrbIUwiDyjbZOHwgm/x/XeIuhmEAWK2hcU9GZUV+9BIgbyoXf7G2X 2wk83JpPJu5I9dUrTTEsNhutZU2CBqDcfDusAWfOUw6XOHwVrCgb5MMcJDkm//91sOXW 4Bqg== 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=Qro7Cc8/Y8xNopnkmPvIhM0jkqW62xNnkRukgv4vVCo=; b=BGV4xC/9pd+kJp5cIvPZKNgFLcVRJP9aToJ8sCE84j5O7K9zOSbgVg2RfSdv4DxWr0 Hl6s/6WfCWGkyRfRzCu9fHyk2o7nXLTLNlR67MDShqgindXOFfAmY+fF5rw4ZjXTgwC8 l3VYvEP2sT+8dK83JzojH9ya738mjtGkh+KqDebDPfsoqnV1Y444RK07TjB/U0TVISui 5GZ3PMjn9kdWtEYr/9GdMG/1pL6qdej0IN6iyRRpOEuY/0SfYY2ud1fCXlAk/A9p67up G71NgQoG+blutnVNwcuaXjRdDHK7idQUaHsKK/pQwl+DSxn05o1MO5EelJg5zhudXBHQ /KKg== X-Gm-Message-State: AGi0PuYfo/PXpRzdrcpdRqPRnHdXLOJGG+p9r/QcwaC8dFfTgJ/5q0lS thPZjOJEHEI3uI9ALsHGDNRXLxBZD0jsyg== X-Google-Smtp-Source: APiQypLnVgdrMobHJFbUeluT/6H/rER4tlB9JQB8cPGnCRQtVJ7FPIjctu5yz8U68/kTog9m/vReJA== X-Received: by 2002:ad4:568a:: with SMTP id bc10mr8946051qvb.148.1589064431130; Sat, 09 May 2020 15:47:11 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id n8sm5402118qtn.12.2020.05.09.15.47.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 15:47:10 -0700 (PDT) To: Eliot Lear Cc: rfced-future@iab.org References: <7E76A967-3106-44B5-BB2A-8B430ADEBEDE@cisco.com> <12fe77cd-2d80-b881-0267-7e6d22d9e1ec@nthpermutation.com> <555f9ebd-f591-b835-74fd-d1b460287447@nthpermutation.com> <95710E23-8FC8-4D81-A23B-326B080DC1A7@cisco.com> From: Michael StJohns Message-ID: Date: Sat, 9 May 2020 18:47:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <95710E23-8FC8-4D81-A23B-326B080DC1A7@cisco.com> Content-Type: multipart/alternative; boundary="------------4DEC3B5D2AE37748D929D822" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Logistics and the agenda for the 14/15 May call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2020 22:47:16 -0000 This is a multi-part message in MIME format. --------------4DEC3B5D2AE37748D929D822 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/9/2020 4:01 AM, Eliot Lear wrote: > Good morning, Mike. > >> I'm sure it wouldn't be all that hard to announce this as an interim >> of some sort.  And yes, the calendar invite would be helpful. > > The last meeting did get announced both on the -Announce list and > here.   See the archives from the 30th of April.  I’ll be happy to > send out the calendar invite so long as nobody objects.  The next > meeting will be announced shortly in a similar fashion.  All are welcome. The context was in the response of "there's a technical problem with doing this"  hence - make it a fake WG with an interim as community guidance was IAB program masquerading as a WG like thing.   With respect to the calendar invite - all I want is that this (and all future sessions) be added to the general IETF calendar which includes WG meetings and appears magically in my calendar without having to remember to click on something.  With the large number of virtual meetings taking place, this is really the only sane way of managing things.   The calendar invite would be helpful, but manual, but way too easy to miss if no one is looking for it. > > >> >>> >>>> Second, I really hate the form of this survey.   Many of these >>>> topics are important - just not right now.  I suggested and now >>>> reiterate a 1-5 scale of "Work on now" to "defer until later" >>>>  rather than "not important" to "very important".  For the purposes >>>> of the current form, "not important" means "let's defer" and >>>> "important" means "lets talk about it". >>> Next time around I will happily tap you to work with me to design >>> the survey.  I am sorry if it felt like a push poll to you. When >>> others are answering, please keep in mind the goal is just to figure >>> out what to talk about for one meeting. >> >> I believe I provided you the critical input of "let's talk now" to >> "let's wait" prior to you sending out the survey?   With respect to >> the questions, I do understand that you took them from the list, but >> they made me cringe. > > Ok.  Again, happy to work with you on the next time around. Thanks - Mike > > Eliot > --------------4DEC3B5D2AE37748D929D822 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/9/2020 4:01 AM, Eliot Lear wrote:
Good morning, Mike.

I'm sure it wouldn't be all that hard to announce this as an interim of some sort.  And yes, the calendar invite would be helpful.

The last meeting did get announced both on the -Announce list and here.   See the archives from the 30th of April.  I’ll be happy to send out the calendar invite so long as nobody objects.  The next meeting will be announced shortly in a similar fashion.  All are welcome.

The context was in the response of "there's a technical problem with doing this"  hence - make it a fake WG with an interim as community guidance was IAB program masquerading as a WG like thing.   With respect to the calendar invite - all I want is that this (and all future sessions) be added to the general IETF calendar which includes WG meetings and appears magically in my calendar without having to remember to click on something.  With the large number of virtual meetings taking place, this is really the only sane way of managing things.   The calendar invite would be helpful, but manual, but way too easy to miss if no one is looking for it.





Second, I really hate the form of this survey.   Many of these topics are important - just not right now.  I suggested and now reiterate a 1-5 scale of "Work on now" to "defer until later"  rather than "not important" to "very important".  For the purposes of the current form, "not important" means "let's defer" and "important" means "lets talk about it".
Next time around I will happily tap you to work with me to design the survey.  I am sorry if it felt like a push poll to you. When others are answering, please keep in mind the goal is just to figure out what to talk about for one meeting.

I believe I provided you the critical input of "let's talk now" to "let's wait" prior to you sending out the survey?   With respect to the questions, I do understand that you took them from the list, but they made me cringe.

Ok.  Again, happy to work with you on the next time around.

Thanks - Mike



Eliot


--------------4DEC3B5D2AE37748D929D822-- From nobody Sun May 10 01:25: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 F14773A07D5 for ; Sun, 10 May 2020 01:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LMhcDsVZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=R1mEyLHr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT5pIVS0B7mr for ; Sun, 10 May 2020 01:25:31 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801E13A07D0 for ; Sun, 10 May 2020 01:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4578; q=dns/txt; s=iport; t=1589099131; x=1590308731; h=from:to:subject:date:message-id:mime-version; bh=X4gmFHjm4aOmpwjRj3QNmzQkF5Audp7cmVA/lb6ne0A=; b=LMhcDsVZDYtwDU7pih1HWTWp6Uk4PHMgA0Hy1nZovXFGTdFN5S/d+brQ OQ1LXCgm2KaC4GorM98LcuVbP17EtcTTwjUKIeypXWZNap9GwQay5oDbA OwHwlyo0kV6cVpOlUz90is8Sq0CAwgj1OIq0sR6/jCKFdLXmba5mzFN+1 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AnLALbRX2vfszBT5MKW5f1H0Qb9TV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyDufNNgazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlTY5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuBgAvubde/4sNJK1MGoEJgUeBVFE?= =?us-ascii?q?Fb1gvLAqEGliCbgOLMZpIgS6BJANUCwEBAQkDAQElCAIEAQGERAIXgXckNAk?= =?us-ascii?q?OAgMBAQsBAQUBAQECAQUEbYVWAQuFdBYRHQEBLAwRASwMDAYCBDAmAQQbGoM?= =?us-ascii?q?FgksDLgEDCzyiHAKBOYhhdAKBMoMBAQEFRW0BhAQYggcHAwaBOIJjiWEagUE?= =?us-ascii?q?/gRFDhXIEGn1OTYIaKzOCEhuRUoYegSqZVQqCSogbiUGGaYJciGeRd5AdiVq?= =?us-ascii?q?TUAIEAgQFAg4BAQWBUjmBVnAVO4JpUBgNVY93F4NPilZ0AjUCBggBAQMJfIt?= =?us-ascii?q?1gQ8BgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,374,1583193600"; d="scan'208";a="476309478" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 May 2020 08:25:30 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 04A8PUQv001112 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 10 May 2020 08:25:30 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 10 May 2020 03:25:30 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 10 May 2020 03:25:29 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 10 May 2020 04:25:29 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cIFv3I8qjxAP6hfdA0fHCY7EiZUrLWXaO7gog0RXDfyHs+xi5GsSK7u9wR3hqbVedvN1jMVa4b6+EvglksEpGC1gZk+n4NMWU8ar5FZgoSGIAGD4qcK4akwxE7g25Vsc9NjcXZO+vB1+7cMsSY5MfvzHCnag+aD8APuSFtf1oU5aWbWFxSG7GA7OEf5XB0EC6gtKC2bVuVT+pAniebRDcoRBu0klOHS/y4f2cn+X5C2BERksVXVS9Lc7EG1k2ywJGK6V1RnLC8JGJ5pB6u7DPi58hVJCefvkIgjCC5CgO/Q5AOSLHgnuS0D/R41aBuxjbQmjk68wEZBKetHJWc91pg== 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=wPu7Hz6+mHGjlJCPNiFsnMXnES2MHhMyzYqeO4PUnvc=; b=kCzeWnqVsZWSlR6mydb7q5q7nBRpTuYS5CR9r+0xYI3m8CaIZ5XKTsqdsr++aZYmrW1PftoGdWbDu75wIuOLDrjeoHgqIzGjuk7bnxrdCUJxBfW+t9BR6cpk71amXDj9YE9bkWddEvHx0z5Ndb4s9pNrDjQ0j/sAvPewsz2Hg+bAwfQI1C1iQJ1Hqs4PWOPnO9exz5FkhTQsRbAdViHSkdM16232Zp99kK/Lr1rUSrm5mFApwg/6JG8OwsX1XBf43xGuzUUsmgRyc6seFCO0A7PyPy8XAhqeaT80TrajkkSEeL/JDVwEtbXc9AGI8l0mYrjvuCJAMgkC9y8UyHishg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wPu7Hz6+mHGjlJCPNiFsnMXnES2MHhMyzYqeO4PUnvc=; b=R1mEyLHrXTn7mkk4QWMmls8ULgHjMPtgHKQcUcCHt0IgKSsGNIixy95xjTcdx1mL/t9iRAVuLgoEXYP8CMUsGFxys7kcSVLz8NFeCmUFyXP6PiEhGmKsxsJaae2KqQc69M8h5nrofp0fg/QXf6Pwp3SIUTKedMTbxZeQRXJmb9c= Received: from BY5PR11MB4211.namprd11.prod.outlook.com (2603:10b6:a03:1ba::10) by BY5PR11MB4152.namprd11.prod.outlook.com (2603:10b6:a03:191::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29; Sun, 10 May 2020 08:25:28 +0000 Received: from BY5PR11MB4211.namprd11.prod.outlook.com ([fe80::8469:6bad:8c5d:f4c9]) by BY5PR11MB4211.namprd11.prod.outlook.com ([fe80::8469:6bad:8c5d:f4c9%6]) with mapi id 15.20.2979.033; Sun, 10 May 2020 08:25:28 +0000 From: "Eliot Lear (elear)" To: "rfced-future@iab.org" Thread-Topic: RFC Editor Futures Program Meeting Thread-Index: AdYkYkcN0N2w44EDQUKLV/aqZabLZw== Date: Sun, 10 May 2020 08:25:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=cisco.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAAEE4Q0Y2RUI4LTRFMDctNDc4RS1BRTY2LTg4Q0VFNzczM0EwOAA= x-originating-ip: [31.10.155.197] x-ms-office365-filtering-correlation-id: 7f27c7c5-3b49-4b73-c564-08d7f4bbb255 x-ms-traffictypediagnostic: BY5PR11MB4152:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 039975700A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tDLrWU3oJAlPSd2fv6nEj3TDG47twzmnWEtm1TlfEVUj2UXQg+n6Hlf8NUQRU8zaWrZMZgeia28SoQQg6mIOKLyAjboxhhOEgs7Nvi5XsqbZhaaj3QmiIlmzVa4h7yoWmgm3A2UztlqVlcHZ1/YgSGNgIPzJ6M48OUMpVi2RWklxjqnVEJzwDcMJ/l+dlzpjxbWET01X9ErEpSCc28RJ+NU69KDvnIBBOqUnk11OGWuIID8QD7AbdxHL43OeRoeaw2vycl/1kAV4xWuzskn68W6fjMYEhEbBwx91z5Yhcmf4lHzey8WYKD6wgWQMPOjDOqWiNwfWOWpvj08Ip8h0MYzjDRKSqktm5z3rWEKfIrzNFKZxxQcu1GYp/ngx63WAsYNhT8RjRLZDWZELSYFpmKaKQaO/ItchdfLllYnn+A7SrV41mw1b9pAPIfdS/gACkpp+7P7+onWaewQOLyv6ofBO8yEwpR0/QT0z8nmUQiGNrmJlbOIeXXeSi7fit7fTIBgHGU+erZHKU65JiQvt0F6crk3arBerPnL88DJivjcrEj8WareHXU2S9BtBdA8Njke19agmQ/uUo5sQaqiLZyMzPEF/L02UDD5vQjNcmfM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4211.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(136003)(396003)(39860400002)(346002)(33430700001)(9686003)(66446008)(86362001)(76116006)(91956017)(66476007)(186003)(71200400001)(33656002)(66556008)(26005)(966005)(64756008)(66946007)(478600001)(5660300002)(6916009)(52536014)(33440700001)(55016002)(2906002)(4744005)(316002)(16799955002)(8676002)(7696005)(8936002)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: dwprJTXWLI3JlrrV6IYE0OWrlZkDjd/ziMzu95xUsEBMYDxdBK3k7zQVS1Cah8t3VtmClnSJXCqCTue9Jw2+1ZME5ynI+sO6qxu+in2xT8/J2ajYwzVo40+J//Zaj1mt3cmrQUoEe4x6z5d1E6O7FJTMqNfz2ebMwv919BU17GG9TzGZBornrDOhohWX0ag2XYHpTpmyeNssK1a5sMgfLEUVs76SN9b1FB81fDBIMBLtmkQUYHrPOdY38u0cOeSzX63qFBEQRRyJ9QuS2hi2A4Z3KKyZXYWVEqDPWdX0R8THTRBjNvclGqUfUH6g0XtqGXfwAPgtAvQ0fPhR/63scZmoC56QXGcsgTd5lSE3SxLuupN+yo1tny4n4j3KHv6UpDdQNYuhNSzG6rZqdWOgozpTtIWTwO/LyouecGgoZ2SsfrgCqtyq7PEHrPavz/rZ03gFpNroka99Qz45SB75v8eMJgL8Re9V7HtahVuEGsE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_002_BY5PR11MB4211D663623CBEC69C2B5421BFA00BY5PR11MB4211namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7f27c7c5-3b49-4b73-c564-08d7f4bbb255 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2020 08:25:28.2262 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 57iJQN8FkkWkwVnn42aT8Qzs5Rsr/72N3i6P2oKRzpT7pbGwwaoPs8pYQGrVartT X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4152 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: [Rfced-future] RFC Editor Futures Program Meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 08:25:38 -0000 --_002_BY5PR11MB4211D663623CBEC69C2B5421BFA00BY5PR11MB4211namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Webex Information: =0A= https://ietf.webex.com/ietf/j.php?MTID=3Dm6e894a38b5cf6c139af7eca0891907ca= =0A= Meeting number (access code): 618 351 526=0A= Meeting password: DSnNT3piK67=0A= =0A= **PLEASE COMPLETE SURVEYMONKEY POLL BY MONDAY: =0A= =0A= https://www.surveymonkey.com/r/9XGKS89=0A= =0A= Reminder: this is just about how important it is to talk abou an issue, for= agenda setting purposes.=0A= =0A= Provisional Agenda:=0A= =0A= Elaborate and discuss the issues that have been raised on the rfced-=0A= future mailing list relating to goals of evolving the RSE and related =0A= functions. We will refine this agenda on the rfced-future mailing list, = =0A= to which anyone is welcome to subscribe at the link below. The meeting =0A= will be recorded for those not able to attend.= --_002_BY5PR11MB4211D663623CBEC69C2B5421BFA00BY5PR11MB4211namp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpXLiBFdXJv cGUgU3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDMwMDAw DQpUWk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClJSVUxFOkZSRVE9WUVBUkxZ O0lOVEVSVkFMPTE7QllEQVk9LTFTVTtCWU1PTlRIPTEwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9G RlNFVFRPOiswMjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllN T05USD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5J WkVSO0NOPUVsaW90IExlYXIgKGVsZWFyKTptYWlsdG86ZWxlYXJAY2lzY28uY29tDQpBVFRFTkRF RTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NO PXJmY2VkLWZ1dHUNCiByZUBpYWIub3JnOm1haWx0bzpyZmNlZC1mdXR1cmVAaWFiLm9yZw0KREVT Q1JJUFRJT047TEFOR1VBR0U9ZW4tVVM6V2ViZXggSW5mb3JtYXRpb246IFxuaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmDQogL2oucGhwP01USUQ9bTZlODk0YTM4YjVjZjZjMTM5YWY3ZWNhMDg5 MTkwN2NhXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUNCiApOiA2MTggMzUxIDUyNlxuTWVl dGluZyBwYXNzd29yZDogRFNuTlQzcGlLNjdcblxuKipQTEVBU0UgQ09NUExFVEUgU1VSVkVZTQ0K IE9OS0VZIFBPTEwgQlkgTU9OREFZOiBcblxuIGh0dHBzOi8vd3d3LnN1cnZleW1vbmtleS5jb20v ci85WEdLUzg5XG5cblJlbWluDQogZGVyOiB0aGlzIGlzIGp1c3QgYWJvdXQgaG93IGltcG9ydGFu dCBpdCBpcyB0byB0YWxrIGFib3UgYW4gaXNzdWVcLCBmb3IgYWcNCiBlbmRhIHNldHRpbmcgcHVy cG9zZXMuXG5cblByb3Zpc2lvbmFsIEFnZW5kYTpcblxuRWxhYm9yYXRlIGFuZCBkaXNjdXNzIHRo ZQ0KICBpc3N1ZXMgdGhhdCBoYXZlIGJlZW4gcmFpc2VkIG9uIHRoZSByZmNlZC1cbmZ1dHVyZSBt YWlsaW5nIGxpc3QgcmVsYXRpbmcgDQogdG8gZ29hbHMgb2YgZXZvbHZpbmcgdGhlIFJTRSBhbmQg cmVsYXRlZCBcbmZ1bmN0aW9ucy4gIFdlIHdpbGwgcmVmaW5lIHRoaXMNCiAgYWdlbmRhIG9uIHRo ZSByZmNlZC1mdXR1cmUgbWFpbGluZyBsaXN0XCwgXG50byB3aGljaCBhbnlvbmUgaXMgd2VsY29t ZSB0bw0KICBzdWJzY3JpYmUgYXQgdGhlIGxpbmsgYmVsb3cuICBUaGUgbWVldGluZyBcbndpbGwg YmUgcmVjb3JkZWQgZm9yIHRob3NlIG5vDQogdCBhYmxlIHRvIGF0dGVuZC4NClVJRDpBOENGNkVC OC00RTA3LTQ3OEUtQUU2Ni04OENFRTc3MzNBMDgNClNVTU1BUlk7TEFOR1VBR0U9ZW4tVVM6UkZD IEVkaXRvciBGdXR1cmVzIFByb2dyYW0gTWVldGluZw0KRFRTVEFSVDtUWklEPVcuIEV1cm9wZSBT dGFuZGFyZCBUaW1lOjIwMjAwNTE0VDIzMDAwMA0KRFRFTkQ7VFpJRD1XLiBFdXJvcGUgU3RhbmRh cmQgVGltZToyMDIwMDUxNVQwMDMwMDANCkNMQVNTOlBVQkxJQw0KUFJJT1JJVFk6NQ0KRFRTVEFN UDoyMDIwMDUxMFQwODI1MjVaDQpUUkFOU1A6T1BBUVVFDQpTVEFUVVM6Q09ORklSTUVEDQpTRVFV RU5DRTowDQpMT0NBVElPTjtMQU5HVUFHRT1lbi1VUzpodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tNmU4OTRhMzhiNWMNCiBmNmMxMzlhZjdlY2EwODkxOTA3Y2ENClgtTUlD Uk9TT0ZULUNETy1BUFBULVNFUVVFTkNFOjANClgtTUlDUk9TT0ZULUNETy1PV05FUkFQUFRJRDoy MTE4NDY2NDc3DQpYLU1JQ1JPU09GVC1DRE8tQlVTWVNUQVRVUzpURU5UQVRJVkUNClgtTUlDUk9T T0ZULUNETy1JTlRFTkRFRFNUQVRVUzpCVVNZDQpYLU1JQ1JPU09GVC1DRE8tQUxMREFZRVZFTlQ6 RkFMU0UNClgtTUlDUk9TT0ZULUNETy1JTVBPUlRBTkNFOjENClgtTUlDUk9TT0ZULUNETy1JTlNU VFlQRTowDQpYLU1JQ1JPU09GVC1ET05PVEZPUldBUkRNRUVUSU5HOkZBTFNFDQpYLU1JQ1JPU09G VC1ESVNBTExPVy1DT1VOVEVSOkZBTFNFDQpYLU1JQ1JPU09GVC1MT0NBVElPTlM6W3siRGlzcGxh eU5hbWUiOiJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVQNCiBJRD1tNmU4OTRh MzhiNWNmNmMxMzlhZjdlY2EwODkxOTA3Y2EiXCwiTG9jYXRpb25Bbm5vdGF0aW9uIjoiIlwsIkxv Y2F0aW9uVQ0KIHJpIjoiIlwsIkxvY2F0aW9uU3RyZWV0IjoiIlwsIkxvY2F0aW9uQ2l0eSI6IiJc LCJMb2NhdGlvblN0YXRlIjoiIlwsIkxvY2F0DQogaW9uQ291bnRyeSI6IiJcLCJMb2NhdGlvblBv c3RhbENvZGUiOiIiXCwiTG9jYXRpb25GdWxsQWRkcmVzcyI6IiJ9XQ0KRU5EOlZFVkVOVA0KRU5E OlZDQUxFTkRBUg0K --_002_BY5PR11MB4211D663623CBEC69C2B5421BFA00BY5PR11MB4211namp_-- From nobody Sun May 10 05:30: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 C61503A0930 for ; Sun, 10 May 2020 05:29:56 -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 ivZZOuyJ0oa4 for ; Sun, 10 May 2020 05:29:54 -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 70C203A0929 for ; Sun, 10 May 2020 05:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5268; q=dns/txt; s=iport; t=1589113794; x=1590323394; h=from:mime-version:subject:message-id:date:to; bh=jnCzEem5+HgKU14feVgMcejLaUe20+JO/N5Omk/GEwk=; b=JnQAavn1ViAQsPWYjRZ/N2z9FUgZiyJame4um8pVYUlVpETrMxcMCgT0 247uTLC0C8eShTcYsb+SaKg8dks1D0JErFBuEm0MbGByEi597HPsD2ESA 5TQASJsWEY77E7RUxyAMBe8+qeGcJBcB9pajLTCvbMkRi3AgLrmWuoSBU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKBgCa87de/xbLJq1mglCDGVUgEiy?= =?us-ascii?q?EJIkBh2aTeYgMCwEBAQwBASUKBAEBhng3Bg4CAwEBCwEBBQEBAQIBBQRthVY?= =?us-ascii?q?Mhht1PgKEGAGCfA+eNo4QdoEyhDoBgRaFFAaBOIxeggCBOAwQghgHAQEsgyU?= =?us-ascii?q?ChHkzgi0EsmuCVASCbYUqkA0dkB2NHZl3kAuDRQIEBgUCFYFoI4FWMxoIGxU?= =?us-ascii?q?7KgGCPj4SGA1Vk12KWD8DMDcCBgEHAQEDCY8QAQE?= X-IronPort-AV: E=Sophos; i="5.73,375,1583193600"; d="scan'208,217"; a="25988978" 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; 10 May 2020 12:29:26 +0000 Received: from [10.61.222.109] ([10.61.222.109]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 04ACTPW2027389 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 10 May 2020 12:29:26 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_B0599EDF-639F-45F3-96D8-1AEA429C1261" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <68EC643E-2DE6-4170-8AF1-53F0621583CE@cisco.com> Date: Sun, 10 May 2020 14:29:25 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.222.109, [10.61.222.109] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Reminders and meeting logistics for this week X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2020 12:29:57 -0000 --Apple-Mail=_B0599EDF-639F-45F3-96D8-1AEA429C1261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, I am looking forward to spending some time with you virtually this week. Just a reminder, a poll is open to decide which topics the agenda will = cover. I invite you to participate at = https://www.surveymonkey.com/r/9XGKS89 = . The poll will close tomorrow (May 11th) at approximately 4:00pm GMT so = that I can publish out the results and the agenda. Another reminder: It will be helpful for people to have reviewed the reading list and be = familiar with the content as we go through our discussion. You can find = the reading list at = https://github.com/intarchboard/rfced-future/blob/master/SuggestedReading.= md = . A third reminder: the call will be recorded. I propose that we "round robin=E2=80=9D[*] on these calls, so that = everyone who attends who wants to, will have an opportunity to put forth = a view on each topic, and for people to ask clarifying questions about = that view. If someone has expressed a view that is consistent with your = own, it would be good to know that too, simply so that everyone has a = feel for where everyone else stands, and all come away with food for = thought. As the topic list comes out tomorrow, folk may wish to give a bit of = thought about what they want to say, prior to the call. Finally, I am seeking a scribe or two to help capture people=E2=80=99s = views. If you are interested, this will save time is preferable to me = having to dragoon people ;-) Eliot [*] By round robin, I mean that each person will have a single = opportunity to state their views and answer clarifying questions, and = that time be apportioned in a fair manner. Oddly, I=E2=80=99ve = discovered that there are a good number of meanings to the term.= --Apple-Mail=_B0599EDF-639F-45F3-96D8-1AEA429C1261 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi everyone,

I am looking forward to = spending some time with you virtually this week.

Just a reminder, a poll is open to = decide which topics the agenda will cover.  I invite you to = participate at https://www.surveymonkey.com/r/9XGKS89.

The poll will close = tomorrow (May 11th) at approximately 4:00pm GMT so that I can publish = out the results and the agenda.

Another reminder:

It will be helpful for = people to have reviewed the reading list and be familiar with the = content as we go through our discussion.  You can find the reading = list at https://github.com/intarchboard/rfced-future/blob/master/Sugges= tedReading.md.

A third reminder: the call will be recorded.

I propose that we "round = robin=E2=80=9D[*] on these calls, so that everyone who attends who wants = to, will have an opportunity to put forth a view on each topic, and for = people to ask clarifying questions about that view.  If someone has = expressed a view that is consistent with your own, it would be good to = know that too, simply so that everyone has a feel for where everyone = else stands, and all come away with food for thought.

As the topic list comes = out tomorrow, folk may wish to give a bit of thought about what they = want to say, prior to the call.

Finally, I am seeking a scribe or two = to help capture people=E2=80=99s views.  If you are interested, = this will save time is preferable to me having to dragoon people = ;-)

Eliot

[*] By round robin, I mean that each person will have a = single opportunity to state their views and answer clarifying questions, = and that time be apportioned in a fair manner.  Oddly, I=E2=80=99ve = discovered that there are a good number of meanings to the = term.
= --Apple-Mail=_B0599EDF-639F-45F3-96D8-1AEA429C1261-- From nobody Mon May 11 08:32: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 B71703A0784 for ; Mon, 11 May 2020 08:32:18 -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 lLF1dTtHpD1y for ; Mon, 11 May 2020 08:32: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 68B763A0769 for ; Mon, 11 May 2020 08:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7276; q=dns/txt; s=iport; t=1589211133; x=1590420733; h=from:mime-version:subject:message-id:date:to; bh=avTcH+37RxzqfcU8w/rFhd/f83qQnpdYPf+ouwykjqc=; b=fgjQK4tZFmczliDxxDXfBktRsjxVFiOcy7iEy7fSuMNXvmF15SdhZtYG nnys3HM1IdMJHRuAGx1n8b0oX+duKIt4F+aRcZwhuye2Zu0XBN0LXE4O8 GGxyeSoyiUXM8DDnBWiWvcmloBYMQtN7SiEU5F5uqqdrjqfW+6QNhEyer g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAQBmb7le/xbLJq1MGh0BAQEBCQE?= =?us-ascii?q?SAQUFAYF2BQELAYMYVSASLIQkiQGHZJN5iAwLAQEBDAEBJQoEAQGGeDcGDgI?= =?us-ascii?q?DAQELAQEFAQEBAgEFBG2FVgyGG09SDAYChBgBgnwPPJ9BjhB2gTKDTYIEhQs?= =?us-ascii?q?GgTgBjF2CAIERJwwQgh8BAYNRAQECGoIYghorM4ISGwSya4JUBIJthSqQDR2?= =?us-ascii?q?QHY0dmXeQC4NFAgQGBQIVgWgjgVYzGggbFTsqAYI+Hx8SGA2QTBeDT4UUhUQ?= =?us-ascii?q?/AzACNQIGAQcBAQMJjGSCHwEB?= X-IronPort-AV: E=Sophos; i="5.73,380,1583193600"; d="scan'208,217"; a="26083969" 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; 11 May 2020 15:32:09 +0000 Received: from [10.61.170.56] ([10.61.170.56]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04BFW83W022411 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 May 2020 15:32:09 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_2AD57EA8-370C-4AFC-8441-BAAF2702EB4F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <4EB36083-3302-47AF-84D0-7CF8BDA64368@cisco.com> Date: Mon, 11 May 2020 17:32:08 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.170.56, [10.61.170.56] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Agenda for our first virtual meeting and homework X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2020 15:32:20 -0000 --Apple-Mail=_2AD57EA8-370C-4AFC-8441-BAAF2702EB4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone and thanks to those who participated in the poll. = Unsurprisingly(?) the two questions people really want to discuss are = these: What do we want from the series? What roles are defined and what is their relationship to one another? This is our agenda, subject to your bashing of course. The latter question was slightly more popular than the former. It=E2=80=99= s pretty clear (a) that my polling skills could use some sharpening up, = because many of the other questions support the above two. For = instance, a runner up was =E2=80=9CTo whom is [each role] = accountable?=E2=80=9D I don=E2=80=99t think one could opine on the = roles and relationships without talking about accountability. = Similarly, when it comes to what we want from the series, it=E2=80=99s = pretty clear that one possible thing we could want is timeliness. To this end, as people share their views on the call, it seems entirely = fair to bring in these points to support one=E2=80=99s view. I would like to thank Nevil and Tim who have volunteered to take notes = in Etherpad. I will see about getting a Jabber side room (I have to get = back to you on that). My request of participants is as follows: Give some thoughts to these two questions Review the reading list[1] and Github summary[2] just to get the juices = flowing, and perhaps even write out a paragraph or two to organize your = thoughts. Think about what you do and don=E2=80=99t like about the way things are = now with relation to these two questions. Coordinates for the call are below: When: =20 Thursday, 14 May 2020: 21:00 UTC, 17:00 America/New York, 14:00 America/Los Angeles Friday, 15 May 2020: 07:00 Australia/Sydney, 09:00 Pacific/Auckland Duration: 90 minutes Webex Information:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm6e894a38b5cf6c139af7eca0891907ca= = Meeting number (access code): 618 351 526 Meeting password: DSnNT3piK67 NOTE WELL: Participation in this and other events relating to this = program are governed by https://ietf.org/about/note-well/ = . Eliot [1] = https://github.com/intarchboard/rfced-future/blob/master/SuggestedReading.= md = [2] = https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandP= ointsMade.md = --Apple-Mail=_2AD57EA8-370C-4AFC-8441-BAAF2702EB4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone and thanks to those who participated in the poll. =  Unsurprisingly(?) the two questions people really want to discuss = are these:

  • What do we want from the = series?
  • What roles are defined and what is their = relationship to one another?

This is our agenda, subject to = your bashing of course.

The latter question was slightly more popular than the = former.  It=E2=80=99s pretty clear (a) that my polling skills could = use some sharpening up, because many of the other questions support the = above two.  For instance, a runner up was =E2=80=9CTo whom is [each = role] accountable?=E2=80=9D  I don=E2=80=99t think one could opine = on the roles and relationships without talking about accountability. =  Similarly, when it comes to what we want from the series, it=E2=80=99= s pretty clear that one possible thing we could want is = timeliness.

To = this end, as people share their views on the call, it seems entirely = fair to bring in these points to support one=E2=80=99s view.

I would like to thank = Nevil and Tim who have volunteered to take notes in Etherpad.  I = will see about getting a Jabber side room (I have to get back to you on = that).

My = request of participants is as follows:
  • Give some thoughts to these two = questions
  • Review the reading list[1] and Github = summary[2] just to get the juices flowing, and perhaps even write out a = paragraph or two to organize your thoughts.
  • Think = about what you do and don=E2=80=99t like about the way things are now = with relation to these two questions.

Coordinates for the call are = below:

When: =  
Thursday, 14 May 2020:
21:00 = UTC, 17:00 America/New York,  14:00 America/Los Angeles
= Friday, 15 May 2020:
07:00 Australia/Sydney, 09:00 = Pacific/Auckland

Duration: 90 minutes

Webex Information: 
https://ietf.webex.com/ietf/j.php?MTID=3Dm6e894a38b5cf6c139af7e= ca0891907ca
Meeting number (access code): 618 351 = 526
Meeting password: DSnNT3piK67

NOTE WELL: =  Participation in this and other events relating to this program = are governed by https://ietf.org/about/note-well/.
Eliot

[1] https://github.com/intarchboard/rfced-future/blob/master/Sugges= tedReading.md
[2] https://github.com/intarchboard/rfced-future/blob/master/Possib= leGoalsandPointsMade.md

= --Apple-Mail=_2AD57EA8-370C-4AFC-8441-BAAF2702EB4F-- From nobody Mon May 11 08:53:50 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1A3A082A for ; Mon, 11 May 2020 08:53:47 -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 Cev1LvUtMBTY for ; Mon, 11 May 2020 08:53:45 -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 2C9C83A0858 for ; Mon, 11 May 2020 08:53:17 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id x8so8242282qtr.2 for ; Mon, 11 May 2020 08:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=XNFb1hHOLgTeIpb1/3HfDRViSQ8xExNJMvLCO/4d/jI=; b=zzYfW+QQEbyXoG/OIeClsT3iANbadZlpKsGWMN2JWOOVAsDOwivg0R11SVjgJ61xZ+ AnGb2lNH/FRasexapnBnQxQ4Oo/WwOjB8zvxR2KHQ2V8I+ZEd51AxK34UBCiGN/8AmP/ 2z500aJHoZDaztmAKVXjG00Kxkv5otzKRv/2Gu1B240BDEwexyvydnW9WR9NPnv38V34 9vKQOy55AbUI88itnTTFt4GTa3mWhePV9QOgmkOLhSZQhaoQQTEm6lmYivlT9/JtA1gM pUM33VHoTmDFy5veybrVlvjS1HpIIO6juf1UDSeiXThCVjqPVeClc2WrsnPSlmaVYRQi CKbw== 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=XNFb1hHOLgTeIpb1/3HfDRViSQ8xExNJMvLCO/4d/jI=; b=nEAWK5fqaYX7x73hVUOlOzqQ5VAF3ggIwMPoPa1GQd4iPxyKBvoEu8mg/yoDn88hy3 xI/6kUIss2n/9xR8nz7lyi3OJtot/S0higoP0B0sOqmyBws0AV7O9reztCZpRoaUpAob Q2r7Y5pvHecp7e9GYhmhSJc92+IxepTXXbbo+QSsr675NvQe7IJcmzDZ27sLPRLkZRIl 00aC3tA4J3p46nOkswx9kT5Y238rIT7HBGtREtLoAaOArzTgmu7stdlNWc6NIZwvAaXI CassPixH5e0A5JlloqTha3ICQT8mqS0MdCRTRq21pghVnCzy06TT9NmPbGUJv8TbaezR WxpA== X-Gm-Message-State: AGi0Pub53TcbghBT/qeYiXPBd3+E/BrnpKJji9sYOv8FrQ7zMXLCh6Yi XoAgtUobVObBiUkfR93godjK5KrTylU6cw== X-Google-Smtp-Source: APiQypIVHhYJvh7W2lLY8DMGGnNnuixVUgYEQOKF2WFDEY7amSR211EFPJG0LEeu76a2g5zrYZOQHA== X-Received: by 2002:ac8:6b09:: with SMTP id w9mr17729506qts.263.1589212395817; Mon, 11 May 2020 08:53:15 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id h12sm2526876qte.31.2020.05.11.08.53.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 08:53:15 -0700 (PDT) To: rfced-future@iab.org References: <68EC643E-2DE6-4170-8AF1-53F0621583CE@cisco.com> From: Michael StJohns Message-ID: Date: Mon, 11 May 2020 11:53:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <68EC643E-2DE6-4170-8AF1-53F0621583CE@cisco.com> Content-Type: multipart/alternative; boundary="------------0DAA423E0BBDB23186116E91" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Reminders and meeting logistics for this week X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2020 15:53:48 -0000 This is a multi-part message in MIME format. --------------0DAA423E0BBDB23186116E91 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/10/2020 8:29 AM, Eliot Lear wrote: > I propose that we "round robin”[*] on these calls, so that everyone > who attends who wants to, will have an opportunity to put forth a view > on each topic, and for people to ask clarifying questions about that > view.  If someone has expressed a view that is consistent with your > own, it would be good to know that too, simply so that everyone has a > feel for where everyone else stands, and all come away with food for > thought. > > As the topic list comes out tomorrow, folk may wish to give a bit of > thought about what they want to say, prior to the call. > > Finally, I am seeking a scribe or two to help capture people’s views. >  If you are interested, this will save time is preferable to me having > to dragoon people ;-) > > Eliot > > [*] By round robin, I mean that each person will have a single > opportunity to state their views and answer clarifying questions, and > that time be apportioned in a fair manner.  Oddly, I’ve discovered > that there are a good number of meanings to the term. > I'm having problems with the above plenary style.  This is supposed to be a discussion, not people standing in line waiting to bloviate.   If we want a Q&A on a particular view, we have email.   Also, given that we don't even know the topics or how many as of yet - I'm guessing we could blow the time on one topic and make little or no progress.   From my part I'd rather cancel the teleconf, and spend a week discussing the results of the survey on the list before figuring out what we want to spend "real time" on. Eliot - I appreciate you're taking the role of chair seriously, but doing it this way probably isn't a good use of our time. Later, Mike --------------0DAA423E0BBDB23186116E91 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/10/2020 8:29 AM, Eliot Lear wrote:
I propose that we "round robin”[*] on these calls, so that everyone who attends who wants to, will have an opportunity to put forth a view on each topic, and for people to ask clarifying questions about that view.  If someone has expressed a view that is consistent with your own, it would be good to know that too, simply so that everyone has a feel for where everyone else stands, and all come away with food for thought.

As the topic list comes out tomorrow, folk may wish to give a bit of thought about what they want to say, prior to the call.

Finally, I am seeking a scribe or two to help capture people’s views.  If you are interested, this will save time is preferable to me having to dragoon people ;-)

Eliot

[*] By round robin, I mean that each person will have a single opportunity to state their views and answer clarifying questions, and that time be apportioned in a fair manner.  Oddly, I’ve discovered that there are a good number of meanings to the term.


I'm having problems with the above plenary style.  This is supposed to be a discussion, not people standing in line waiting to bloviate.   If we want a Q&A on a particular view, we have email.   Also, given that we don't even know the topics or how many as of yet - I'm guessing we could blow the time on one topic and make little or no progress.   From my part I'd rather cancel the teleconf, and spend a week discussing the results of the survey on the list before figuring out what we want to spend "real time" on.

Eliot - I appreciate you're taking the role of chair seriously, but doing it this way probably isn't a good use of our time.

Later, Mike


--------------0DAA423E0BBDB23186116E91-- From nobody Mon May 11 10:34: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 3B40D3A0854 for ; Mon, 11 May 2020 10:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFBN7qbIAa6A for ; Mon, 11 May 2020 10:33:52 -0700 (PDT) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 E9D133A0BD3 for ; Mon, 11 May 2020 10:33:50 -0700 (PDT) Received: by mail-oo1-xc31.google.com with SMTP id c83so2111152oob.6 for ; Mon, 11 May 2020 10:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ewH40A9US6SI5UmBX4nhFC3nMt4rFNyRqQhW/2frMyk=; b=FHfKfDh9GNLEoaS+CgDf0uj/PEcSfQmxbRisY0C5mGl/Zb/61vYYnCbtACXiu8idcm VpjzpRM8ecYiI2NebAI/eOfnSne8qzmx/jiYG3F8CBU7AeDUzz1xTFmyTyXo+dj5SpB7 cJQTtehhu9O4MQgwniz7c41jMctbZdi+QHxKkxFuIIKQ9qBAV2PGYVUNN8QekaM6xDtX W2UdQldRnBzTfReqjJjdE+mFAbtzOiq7f9J9qBcHIgqAvYRPFY3hLqBvnLqUYkPVOD38 b6fkUBNT66qb6+iBgo+mDH5tjB5FpSM1c7PwFa8v5lYApYJPUw4R4hHwroKgxhxdK6tx opCQ== 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=ewH40A9US6SI5UmBX4nhFC3nMt4rFNyRqQhW/2frMyk=; b=T21l2IvhP/uC1pm1QVwqjEDTYScw3BAr/eGl+tgsB2QwX7i/gM2Db3Vph3V40dXDmh XOX0shRRm7X+LFkicre5pJOhmVLPZd+enpb6uvg+Qh8D89oMLCtUUztWPmYURlRC8lL1 2m0DYaTCLNmvHz4LsC5bYpNY6rM8XVWrZfI9Paaorh13eRC9XsRo/ac5IzoNUBiXhYSv t52g4Xq+j3J4d2K+5qvRk6sah97PqifmsuA5v6GreOgLAG2UpzMK7hdneapuyQBoswnJ hisjLtuzSTh1Gdkq8o2v5A7krsXEq/DTfU2OGEN+kfiYfMkCZH629BIzmiYmrElFxf7r T68w== X-Gm-Message-State: AGi0PuaBLGrL+h9VLY8TiTSCbfcphF85CvDR9pgOmqfEoB+TXViWI/hE 8+6C0CGb6UlDIamQbeXuWpCBqqirYqUWx7fNn3e6heV0UH0= X-Google-Smtp-Source: APiQypIiddFax/HNtx6yjUEpMqHzHbDFab2vKzRmndK8aEg6NdftsPE8dS9/dninkpz/mPdR0pB8O8JIltlzWZiMI2M= X-Received: by 2002:a4a:a54a:: with SMTP id s10mr14896266oom.73.1589218430121; Mon, 11 May 2020 10:33:50 -0700 (PDT) MIME-Version: 1.0 References: <68EC643E-2DE6-4170-8AF1-53F0621583CE@cisco.com> In-Reply-To: From: Tim Wicinski Date: Mon, 11 May 2020 13:33:39 -0400 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000ff7ec705a562bf7a" Archived-At: Subject: Re: [Rfced-future] Reminders and meeting logistics for this week X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2020 17:34:07 -0000 --000000000000ff7ec705a562bf7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was thinking better than the survey was some sort of ranked choice voting using the three broad categories Eliot broke things down into (Roles, What We Want, Relationships) here: https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPo= intsMade.md or else we'll be arguing about which topic has more importance. On Mon, May 11, 2020 at 11:53 AM Michael StJohns wrote: > On 5/10/2020 8:29 AM, Eliot Lear wrote: > > I propose that we "round robin=E2=80=9D[*] on these calls, so that everyo= ne who > attends who wants to, will have an opportunity to put forth a view on eac= h > topic, and for people to ask clarifying questions about that view. If > someone has expressed a view that is consistent with your own, it would b= e > good to know that too, simply so that everyone has a feel for where > everyone else stands, and all come away with food for thought. > > As the topic list comes out tomorrow, folk may wish to give a bit of > thought about what they want to say, prior to the call. > > Finally, I am seeking a scribe or two to help capture people=E2=80=99s vi= ews. If > you are interested, this will save time is preferable to me having to > dragoon people ;-) > > Eliot > > [*] By round robin, I mean that each person will have a single opportunit= y > to state their views and answer clarifying questions, and that time be > apportioned in a fair manner. Oddly, I=E2=80=99ve discovered that there = are a good > number of meanings to the term. > > > I'm having problems with the above plenary style. This is supposed to be > a discussion, not people standing in line waiting to bloviate. If we wa= nt > a Q&A on a particular view, we have email. Also, given that we don't ev= en > know the topics or how many as of yet - I'm guessing we could blow the ti= me > on one topic and make little or no progress. From my part I'd rather > cancel the teleconf, and spend a week discussing the results of the surve= y > on the list before figuring out what we want to spend "real time" on. > > Eliot - I appreciate you're taking the role of chair seriously, but doing > it this way probably isn't a good use of our time. > > Later, Mike > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000ff7ec705a562bf7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I= was thinking better than the survey was some sort of ranked choice voting<= /div>
using the= three broad categories Eliot broke things
down into (Roles, What We Want, Relations= hips) here:

<= a href=3D"https://github.com/intarchboard/rfced-future/blob/master/Possible= GoalsandPointsMade.md">https://github.com/intarchboard/rfced-future/blob/ma= ster/PossibleGoalsandPointsMade.md

or else we'll be arguing about which topi= c has more importance.=C2=A0




On Mon, May 11, 2020 at 11:53 AM Michael StJohns <= msj@nthpermutation.com> wr= ote:
=20 =20 =20
On 5/10/2020 8:29 AM, Eliot Lear wrote:
I propose that we "round robin=E2=80=9D[*] on these calls, so that everyone who attends who wants to, will have an opportunity to put forth a view on each topic, and for people to ask clarifying questions about that view.=C2=A0 If someone has expressed a view that is consistent with your own, it would be good to know that too, simply so that everyone has a feel for where everyone else stands, and all come away with food for thought.

As the topic list comes out tomorrow, folk may wish to give a bit of thought about what they want to say, prior to the call.

Finally, I am seeking a scribe or two to help capture people=E2=80=99s views.=C2=A0 If you are interested, th= is will save time is preferable to me having to dragoon people ;-)

Eliot

[*] By round robin, I mean that each person will have a single opportunity to state their views and answer clarifying questions, and that time be apportioned in a fair manner.=C2=A0 Oddly, I=E2=80=99ve discovered that there are a g= ood number of meanings to the term.


I'm having problems with the above plenary style.=C2=A0 This is supposed to be a discussion, not people standing in line waiting to bloviate.=C2=A0=C2=A0 If we want a Q&A on a particular view, w= e have email.=C2=A0=C2=A0 Also, given that we don't even know the topics= or how many as of yet - I'm guessing we could blow the time on one topic and make little or no progress.=C2=A0=C2=A0 From my part I'd rath= er cancel the teleconf, and spend a week discussing the results of the survey on the list before figuring out what we want to spend "re= al time" on.

Eliot - I appreciate you're taking the role of chair seriously, but doing it this way probably isn't a good use of our time.

Later, Mike


--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000ff7ec705a562bf7a-- From nobody Mon May 11 10:41:59 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0AE3A0C05 for ; Mon, 11 May 2020 10:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 lMsu0WUiWeNa for ; Mon, 11 May 2020 10:40:03 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 D34E93A0C44 for ; Mon, 11 May 2020 10:39:53 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id m18so8200294otq.9 for ; Mon, 11 May 2020 10:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kh690uZjiUJNPHEP+Jfu5EwjYHO0yf5eJEBAFardIs8=; b=VheCX/sZjRuty6AZCz/4bjE0/heVNhyZTyCSeTtIXxqie9LtXQhF3EiN2EYXRM4rMf lNOCdQ1mOaVqZmWHSpL6lRQEAxOVi0hKIspop23gTBQ+SzuRRfoj6AKzlIyQDUbJMFKh p/yBwQGycZDfXZSzsklEqzVJFb1eB+4QMqCiRCG8cpTloY2EFkRzkN2Md1Oq/CKTODCz yvhmWQWfToTzBhiVRZXRDWHQs+7VsQVeNPtka8DdrWEc+jbLhhcv8HpQ2tEQy1L/YhSB KdPbRTpOZFU5KYKD5FuhGPKuDS1oYlHpPa+1nWgp9wMV437oPSJsl5FKCL8a0p1vceJl tL2w== 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=kh690uZjiUJNPHEP+Jfu5EwjYHO0yf5eJEBAFardIs8=; b=uGG+8di7FvrhWua3ljA2rmwDAbmFHbz3zZaETEvnKIH71hoayAygn8822fTMn1NW2U X+RrZ4fGmYp7d/igG+MMFaM3hNUBTm2vNxEaZwvYQHIegmQuZoQugfTwYvqBKYlFSCRM bjgqMcyQ5XiYcfowaYkKk1W9NfzYGn3EJAwFBSrJEiPDbefLzeDatUFXu3wx7Asvf3R4 Q6KpTDXz9xoVrkePDSZ0dGyxVWZDvkWWsbzT/6Pud6NywYuZnMYSwxi1KmJvLUJWXPxJ O++H/ZJvNoxpsPjFcb+UBkXZ1YdmZRFLZPnINExPZrEMvJWJ19A2GXbTBthqRScfQJRw US5g== X-Gm-Message-State: AGi0PuZEIOOTOyhqrh0oOiZBU2LtHF4ZZWhdOOEzXLZIjaxDErcggQP+ Vv93ALQBB8M62XoAeZ78T0geTzPllHtM4pivq5c= X-Google-Smtp-Source: APiQypK2TxPvr+iuqlUWmXj/SNCiQM57zM6aXKvCjyxEfHrxetLgeo8X6zPVatvgi0CdsGhyOJQYeqM8xpULuU4JtdY= X-Received: by 2002:a9d:620c:: with SMTP id g12mr13811654otj.158.1589218791709; Mon, 11 May 2020 10:39:51 -0700 (PDT) MIME-Version: 1.0 References: <4EB36083-3302-47AF-84D0-7CF8BDA64368@cisco.com> In-Reply-To: <4EB36083-3302-47AF-84D0-7CF8BDA64368@cisco.com> From: Tim Wicinski Date: Mon, 11 May 2020 13:39:40 -0400 Message-ID: To: Eliot Lear Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000008ce04005a562d59f" Archived-At: Subject: Re: [Rfced-future] Agenda for our first virtual meeting and homework X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2020 17:40:16 -0000 --0000000000008ce04005a562d59f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Etherpad link I put together than Eliot failed to share with folks https://etherpad.ietf.org:9009/p/notes-interim-2020-rfced-01?useMonospaceFo= nt=3Dtrue You're Welcome Eliot On Mon, May 11, 2020 at 11:32 AM Eliot Lear wrote: > Hi everyone and thanks to those who participated in the poll. > Unsurprisingly(?) the two questions people really want to discuss are the= se: > > > - What do we want from the series? > - What roles are defined and what is their relationship to one another= ? > > > This is our agenda, subject to your bashing of course. > > The latter question was slightly more popular than the former. It=E2=80= =99s > pretty clear (a) that my polling skills could use some sharpening up, > because many of the other questions support the above two. For instance,= a > runner up was =E2=80=9CTo whom is [each role] accountable?=E2=80=9D I do= n=E2=80=99t think one > could opine on the roles and relationships without talking about > accountability. Similarly, when it comes to what we want from the series= , > it=E2=80=99s pretty clear that one possible thing we could want is timeli= ness. > > To this end, as people share their views on the call, it seems entirely > fair to bring in these points to support one=E2=80=99s view. > > I would like to thank Nevil and Tim who have volunteered to take notes in > Etherpad. I will see about getting a Jabber side room (I have to get bac= k > to you on that). > > My request of participants is as follows: > > - Give some thoughts to these two questions > - Review the reading list[1] and Github summary[2] just to get the > juices flowing, and perhaps even write out a paragraph or two to organ= ize > your thoughts. > - Think about what you do and don=E2=80=99t like about the way things = are now > with relation to these two questions. > > > Coordinates for the call are below: > > When: > Thursday, 14 May 2020: > 21:00 UTC, 17:00 America/New York, 14:00 America/Los Angeles > Friday, 15 May 2020: > 07:00 Australia/Sydney, 09:00 Pacific/Auckland > > Duration: 90 minutes > > Webex Information: > https://ietf.webex.com/ietf/j.php?MTID=3Dm6e894a38b5cf6c139af7eca0891907c= a > Meeting number (access code): 618 351 526 > Meeting password: DSnNT3piK67 > > NOTE WELL: Participation in this and other events relating to this > program are governed by https://ietf.org/about/note-well/. > > Eliot > > [1] > https://github.com/intarchboard/rfced-future/blob/master/SuggestedReading= .md > [2] > https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsand= PointsMade.md > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000008ce04005a562d59f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

E= therpad link I put together than Eliot failed to share with folks


You're Welcome Eliot

On Mon, May 11, 2020 at 11:32 AM Eliot L= ear <lear=3D40cisco.com@dm= arc.ietf.org> wrote:
Hi everyone and thank= s to those who participated in the poll.=C2=A0 Unsurprisingly(?) the two qu= estions people really want to discuss are these:

    What do we want from the series?
  • What roles are defined and what i= s their relationship to one another?

Thi= s is our agenda, subject to your bashing of course.

The latter question was slightly more popular than the former.=C2=A0 It= =E2=80=99s pretty clear (a) that my polling skills could use some sharpenin= g up, because many of the other questions support the above two.=C2=A0 For = instance, a runner up was =E2=80=9CTo whom is [each role] accountable?=E2= =80=9D =C2=A0I don=E2=80=99t think one could opine on the roles and relatio= nships without talking about accountability.=C2=A0 Similarly, when it comes= to what we want from the series, it=E2=80=99s pretty clear that one possib= le thing we could want is timeliness.

To this end,= as people share their views on the call, it seems entirely fair to bring i= n these points to support one=E2=80=99s view.

I wo= uld like to thank Nevil and Tim who have volunteered to take notes in Ether= pad.=C2=A0 I will see about getting a Jabber side room (I have to get back = to you on that).

My request of participants is as = follows:
  • Give some thoughts to these two questions
    • Review the reading list[1] and Github summary[2] just to get the juices f= lowing, and perhaps even write out a paragraph or two to organize your thou= ghts.
  • Think about what you do and don=E2=80=99t like about the way = things are now with relation to these two questions.
Coordinates for the call are below:

W= hen: =C2=A0
Thursday, 14 Ma= y 2020:
21:00 UTC, 17:00 Am= erica/New York, =C2=A014:00 America/Los Angeles
Friday, 15 May 2020:
07:00 Australia/Sydney, 09:00 Pacific/Auckland

Durati= on: 90 minutes

Webex Information:=C2=A0
https://ietf.webex.com/ietf/j.php?MTID=3Dm6e894a38b5cf6c139af7eca08919= 07ca
Meeting number (access code): 618 351 526
Meeting password: = DSnNT3piK67

NOTE WELL: =C2=A0Participation in = this and other events relating to this program are governed by=C2=A0https://ietf.org/a= bout/note-well/.

Eliot

[1]=C2=A0https://github.com/intarchboard/= rfced-future/blob/master/SuggestedReading.md

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000008ce04005a562d59f-- From nobody Mon May 11 11:12:15 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 172173A08E1; Mon, 11 May 2020 11:12:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IAB Executive Administrative Manager To: "IETF Announcement List" Cc: rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rfced-future@iab.org Message-ID: <158922073357.16246.16854029162770313933@ietfa.amsl.com> Date: Mon, 11 May 2020 11:12:14 -0700 Archived-At: Subject: [Rfced-future] RFC Editor Future Development Program Virtual Meeting: 2020-05-27 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: Mon, 11 May 2020 18:12:14 -0000 The RFC Editor Future Development Program will hold a virtual meeting. When: 27 May 2020 06:00 UTC Local times: Pacific/Auckland; 27 May 18:00 Australia/Sydney: 27 May 16:00 Asia/Kolkata: 27 May 11:30am Europe/Berlin: 27 May 8:00am Europe/London: 27 May 7:00am North America/New York: 27 May 02:00 North America/Chicago: 27 May 01:00 North America/Los Angeles: 26 May 23:00 Duration: 90 minutes Webex Information: https://ietf.webex.com/ietf/j.php?MTID=m1dd4253db4bdf3a30ef9f3aabc64ac75 Meeting number (access code): 618 437 612 Meeting password: rfcefdp Agenda: We will continue a roundtable exchange of people’s views on the future of the RFC Series Editor. We will further develop the agenda there. All are invited to participate, and to join the list, which can be found at https://www.iab.org/mailman/listinfo/rfced-future. The meeting will be recorded. Current information on the program can be found at https://github.com/intarchboard/rfced-future. From nobody Mon May 11 11:36: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 5626E3A0B0E for ; Mon, 11 May 2020 11:36:40 -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 krlVsyCk5_lQ for ; Mon, 11 May 2020 11:36:39 -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 2455F3A0BD4 for ; Mon, 11 May 2020 11:36:38 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 190so5294425qki.1 for ; Mon, 11 May 2020 11:36:38 -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=qSSD4dlg8W8ivXqXp6gfW74pZ9uJuuRjb4IKf/0wg0M=; b=v/Clh8WTX3uep9YPUE3ZJvrLFTgnvENHUhEpnBzPLEd5moTQZJecC7EUMwwT7vUa6U Pe03VdZbblP7bitaKItcT3sjBzgVxN7xjIslslvlZ1Gdgv7RT7gwn/zKFLaEisbDrLr5 BOpFxZBawp6j+zFytC7tYwP1ZG357BdnYcHvlRANabQG7Dx6qfkhY3HfgvbV8cAVlemU WlDx9L/lbZ838wQRlvR3WvE7HtIx2IVO5nGNNFnt3kUmXo1H/L20NZ2r7RcBd1SGoPXC 0I5mGK8WNX5wx6Yoy7/DUWfbpXwErMrlBRP/jeC8o0+9nt2c0/Ar+HoXlOYkCOXdmGfu wu7A== 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=qSSD4dlg8W8ivXqXp6gfW74pZ9uJuuRjb4IKf/0wg0M=; b=LEV7uk1gJ5RVPwkUmUk9vnXArYYgAZQAucLKQyzc2IHcz9fsXO3iqdpCsKG610F6f2 nydgGPNiOvRZZkqjFYvvdBim/whk5dQhFvJSdmN9/+KjC7ASAJYStbVIeYkGn5cbl2Ns 7G99nxsrEjGRXjuQRJQYHfJ7BUfHLn3j/4u/dUGrm8pq/woP8pcF0+Mwf01yPgPC8hBQ zslsh18fTs/x3mye4Wxol/sh4K6h5U67pN2X4TUu4UOl9vltBPQU89P7yg5oaRGm4aL9 lLwqN7b414Io0s+AvfQ29VKhPWMCnAYiMNRLayZ8jRemp2vP8ZuDXlFILu21hqBnT554 tlDw== X-Gm-Message-State: AGi0PubhuCI851MrjYt5cSrbt/xT7LEBNOonFI6K4ka+RkyNRhruRb3E BbdZQH4gjAHpd5NWMNTQ5Mk5JicKlcODWA== X-Google-Smtp-Source: APiQypJNw1mNgQglVdLXoHbROGm0yiyXRiPO/+wGbf6keKEprmczxUjTj9hd9q2rLuVsWkpJg3zWBg== X-Received: by 2002:a37:a417:: with SMTP id n23mr16675331qke.480.1589222197437; Mon, 11 May 2020 11:36:37 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id h6sm6327073qkf.61.2020.05.11.11.36.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 11:36:35 -0700 (PDT) To: rfced-future@iab.org References: <4EB36083-3302-47AF-84D0-7CF8BDA64368@cisco.com> From: Michael StJohns Message-ID: Date: Mon, 11 May 2020 14:36:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <4EB36083-3302-47AF-84D0-7CF8BDA64368@cisco.com> Content-Type: multipart/alternative; boundary="------------BE581AF16A92FBA737144F67" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Agenda for our first virtual meeting and homework X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2020 18:36:40 -0000 This is a multi-part message in MIME format. --------------BE581AF16A92FBA737144F67 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/11/2020 11:32 AM, Eliot Lear wrote: > Hi everyone and thanks to those who participated in the poll. >  Unsurprisingly(?) the two questions people really want to discuss are > these: > > * What do we want from the series? > * What roles are defined and what is their relationship to one another? > Hi Eliot - Would you mind posting the link to the poll results please?   I think all of us are curious about relative interests as well as any comments that might have been made. Thanks - Mike --------------BE581AF16A92FBA737144F67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/11/2020 11:32 AM, Eliot Lear wrote:
Hi everyone and thanks to those who participated in the poll.  Unsurprisingly(?) the two questions people really want to discuss are these:

  • What do we want from the series?
  • What roles are defined and what is their relationship to one another?

Hi Eliot -

Would you mind posting the link to the poll results please?   I think all of us are curious about relative interests as well as any comments that might have been made.

Thanks - Mike


--------------BE581AF16A92FBA737144F67-- From nobody Mon May 11 12:03: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 8DA1F3A0C4D for ; Mon, 11 May 2020 12:03: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 ud7K37mNqLBx for ; Mon, 11 May 2020 12:03:43 -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 20FBF3A0C42 for ; Mon, 11 May 2020 12:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20480; q=dns/txt; s=iport; t=1589223821; x=1590433421; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=USPF0Lde4Zybu0Hbb9SRpcx+tqgmOk+K1r8yZIMkla0=; b=XEPYAMjbkZbor1lP0OFrS9/be8pVq4fajWTx2hpPrOC65wj+imGrG4YQ wiKAFeWTqecr05P944g5lL8Lu3idqiPy095tHn31lCkTk263IV4f9w12s czOgPrm1aLKGvybl2OkMrv/wyw7+fFAvlcSTOHnQJRBlmCQRmlPmKSwRE M=; X-Files: Survey Responses.xlsx : 11464 X-IPAS-Result: =?us-ascii?q?A0BgAAANoble/xbLJq1mGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBNgMBAQELAYMYKyogEiyEJIkBiAqTVIgMBAcBAQEJAQIBARgBCgwEA?= =?us-ascii?q?QGERAKCMjcGDgIDAQEBAwIDAQEBAQUBAQECAQUEbYVWDIVoCQEBAQECAQEBF?= =?us-ascii?q?gtLBAcFCwsDAQISKgICAiUwBhODJgGCXBEPD65ddAKBMoUVPIR+CgaBOAGBU?= =?us-ascii?q?osLggCBOByCHy4+gmcBgX2CfTOCLQSOcIonmVSCVIJxgSWCTJFGHYJciGeEW?= =?us-ascii?q?od9hSCqAoNFAgQGBQIVgWgjgVYzGggbFTsqAYI+PQESGA2ZRoVEPwMwNwIGA?= =?us-ascii?q?QcBAQMJjwMBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.73,381,1583193600"; d="xml'?xlsx'72,48?scan'72,48,72,48,208,217?rels'72,48,72,48,208,217"; a="23759044" 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; 11 May 2020 19:03:37 +0000 Received: from [10.61.170.56] ([10.61.170.56]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 04BJ3a2M000874 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 May 2020 19:03:36 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C7E0AEF2-568A-4364-85B8-8CCC6BC69B81" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 11 May 2020 21:03:36 +0200 In-Reply-To: Cc: rfced-future@iab.org To: Michael StJohns References: <4EB36083-3302-47AF-84D0-7CF8BDA64368@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.170.56, [10.61.170.56] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Agenda for our first virtual meeting and homework X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2020 19:03:46 -0000 --Apple-Mail=_C7E0AEF2-568A-4364-85B8-8CCC6BC69B81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good afternoon Mike, It=E2=80=99s not as pretty as what I see on survey monkey, but it=E2=80=99= s readable. See attached. Also, I=E2=80=99m pondering your earlier = note. Perhaps we can reform the agenda to talk about the poll as one of = the items, if that is what people want? We are meant to agenda bash... Eliot > On 11 May 2020, at 20:36, Michael StJohns = wrote: >=20 > On 5/11/2020 11:32 AM, Eliot Lear wrote: >> Hi everyone and thanks to those who participated in the poll. = Unsurprisingly(?) the two questions people really want to discuss are = these: >>=20 >> What do we want from the series? >> What roles are defined and what is their relationship to one another? > Hi Eliot -=20 >=20 > Would you mind posting the link to the poll results please? I think = all of us are curious about relative interests as well as any comments = that might have been made. >=20 > Thanks - Mike >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_C7E0AEF2-568A-4364-85B8-8CCC6BC69B81 Content-Type: multipart/mixed; boundary="Apple-Mail=_8A8B33E8-91FB-4340-8F57-5079B2B16C2C" --Apple-Mail=_8A8B33E8-91FB-4340-8F57-5079B2B16C2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Good afternoon Mike,

It=E2=80=99s not as pretty as what I see on survey = monkey, but it=E2=80=99s readable.  See attached.  Also, I=E2=80= =99m pondering your earlier note.  Perhaps we can reform the agenda = to talk about the poll as one of the items, if that is what people want? =  We are meant to agenda bash...

Eliot


On 11 May 2020, at 20:36, = Michael StJohns <msj@nthpermutation.com> wrote:

=20
On 5/11/2020 11:32 AM, Eliot Lear wrote:
Hi everyone and thanks to those who participated in the poll.  Unsurprisingly(?) the two questions people really want to = discuss are these:

  • What do we want from the series?
  • What roles are defined and what is their relationship to one another?

Hi Eliot -

Would you mind posting the link to the poll = results please?   I think all of us are curious about relative interests as well as any comments that might have been made.

Thanks - = Mike


--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future
= --Apple-Mail=_8A8B33E8-91FB-4340-8F57-5079B2B16C2C Content-Disposition: attachment; filename="Survey Responses.xlsx" Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; x-unix-mode=0644; name="Survey Responses.xlsx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBi7p1oXgEAAJAEAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtOwzAQRfdI/EPkLUrcskAINe2CxxIqUT7AxJPGqmNbnmlp/56J+xBCoRVqN7ESz9x7MvHNaLJu bbaCiMa7UgyLgcjAVV4bNy/Fx+wlvxcZknJaWe+gFBtAMRlfX41mmwCYcbfDUjRE4UFKrBpoFRY+ gOOd2sdWEd/GuQyqWqg5yNvB4E5W3hE4yqnTEOPRE9RqaSl7XvPjLUkEiyJ73BZ2XqVQIVhTKWJS uXL6l0u+cyi4M9VgYwLeMIaQvQ7dzt8Gu743Hk00GrKpivSqWsaQayu/fFx8er8ojov0UPq6NhVo Xy1bnkCBIYLS2ABQa4u0Fq0ybs99xD8Vo0zL8MIg3fsl4RMcxN8bZLqej5BkThgibSzgpceeRE85 NyqCfqfIybg4wE/tYxx8bqbRB+QERfj/FPYR6brzwEIQycAhJH2H7eDI6Tt77NDlW4Pu8ZbpfzL+ BgAA//8DAFBLAwQUAAYACAAAACEAtVUwI/QAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyS TU/DMAyG70j8h8j31d2QEEJLd0FIuyFUfoBJ3A+1jaMkG92/JxwQVBqDA0d/vX78ytvdPI3qyCH2 4jSsixIUOyO2d62Gl/pxdQcqJnKWRnGs4cQRdtX11faZR0p5KHa9jyqruKihS8nfI0bT8USxEM8u VxoJE6UchhY9mYFaxk1Z3mL4rgHVQlPtrYawtzeg6pPPm3/XlqbpDT+IOUzs0pkVyHNiZ9mufMhs IfX5GlVTaDlpsGKecjoieV9kbMDzRJu/E/18LU6cyFIiNBL4Ms9HxyWg9X9atDTxy515xDcJw6vI 8MmCix+o3gEAAP//AwBQSwMEFAAGAAgAAAAhAIE+lJfzAAAAugIAABoACAF4bC9fcmVscy93b3Jr Ym9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKxSTUvEMBC9 C/6HMHebdhUR2XQvIuxV6w8IybQp2yYhM3703xsqul1Y1ksvA2+Gee/Nx3b3NQ7iAxP1wSuoihIE ehNs7zsFb83zzQMIYu2tHoJHBRMS7Orrq+0LDppzE7k+ksgsnhQ45vgoJRmHo6YiRPS50oY0as4w dTJqc9Adyk1Z3su05ID6hFPsrYK0t7cgmilm5f+5Q9v2Bp+CeR/R8xkJSTwNeQDR6NQhK/jBRfYI 8rz8Zk15zmvBo/oM5RyrSx6qNT18hnQgh8hHH38pknPlopm7Ve/hdEL7yim/2/Isy/TvZuTJx9Xf AAAA//8DAFBLAwQUAAYACAAAACEAWjV4EFUDAAAoCAAADwAAAHhsL3dvcmtib29rLnhtbKxVXW+j OBR9X2n/A/I7BRPzEVQ6CgG0laajqu10HkcumGIVcNaYJlU1/32vTUjb6WiV7WxEbGxfDufce2xO P+261npkcuCiTxA+cZHF+lJUvL9P0Nebwo6QNSjaV7QVPUvQExvQp7M//zjdCvlwJ8SDBQD9kKBG qU3sOEPZsI4OJ2LDelipheyogqG8d4aNZLQaGsZU1zqe6wZOR3mPJoRYHoMh6pqXLBPl2LFeTSCS tVQB/aHhm2FG68pj4DoqH8aNXYpuAxB3vOXqyYAiqyvj8/teSHrXguwd9q2dhCuAP3ah8eY3wdK7 V3W8lGIQtToBaGci/U4/dh2M36Rg9z4HxyERR7JHrmt4YCWDD7IKDljBCxh2fxsNg7WMV2JI3gfR /AM3D52d1rxlt5N1LbrZfKGdrlSLrJYOKq+4YlWCQhiKLXszIcdNOvIWVrFL8AI5Zwc7X0qrYjUd W3UDRp7hITAIlp6vI8EYq1Yx2VPF1qJX4MO9rt/1nMFeNwIcbl2xv0cuGWws8BdohZaWMb0bLqlq rFG2CXK+DiDeYS2j0nnlRvre+v/Bj7TUIh1QOTGZ7n9WDIRkPHvuUkkL7s+zz5D3a/oIVYBaV/tN eq7TvPjelzLG359xFK4KUnj2EhNihwuC7RUmru3htRd5JM3ylf8DxMggLgUdVbMvsIZOEPF/sXRB d/MKduORVy80nt39z9b9T8289kML1kfZLWfb4cUKemjtvvG+EtsERREBUU/zkOAAhluz+I1XqkmQ F7k6ZJr7i/H7BhjjkOhJsLxmlqDnLEx9rwgyO3SDhR1mZGVHZB3Yabby86Dw8jRYGUbOK0rm0ARq prd6Y/RrfZBiOJ11b5KMLBnrd8jzCpsizo+VtC3B2LozgRF2vaWOYDv1eVCmB09xoAe1WIXukthu vvBtEi09oLfw7DXJvNwP8yxPTX30oR//H0efsXY8f000y4ZKdSNp+QDfoCtWp3QAQ02CgO9rsqkf pe4CKJICFzbBS9dO04DYflYs/BBn69wvtJkmslp+/cGDJ3LM04yqETal3o9mHOu22M8eJutpYl+n N3svvsp03vdP/1vgNahv2ZHBxe2RgesvFzcXxhu/FOCYBOvW2MKZy3L2DwAAAP//AwBQSwMEFAAG AAgAAAAhAJWSDrLmAgAAswcAAA0AAAB4bC9zdHlsZXMueG1spFVbb5swFH6ftP9g+Z1yKWRJBFRN U6RKXTWpmbRXB0xi1RdkTEo27b/vGBJC1WlrmxewD8ffuXyfD/FVKzjaUV0zJRPsX3gYUZmrgslN gr+vMmeKUW2ILAhXkiZ4T2t8lX7+FNdmz+njllKDAELWCd4aU81dt863VJD6QlVUwpdSaUEMbPXG rStNSVHbQ4K7gedNXEGYxD3CXORvARFEPzWVkytREcPWjDOz77AwEvn8biOVJmsOqbZ+SHLU+hMd oFYfg3TWV3EEy7WqVWkuANdVZcly+jrdmTtzSX5CAuSPIfmR6wUvam/1B5FCV9Mds/ThNC6VNDXK VSMNkAmJ2hbMn6R6lpn9ZI29VxrXP9GOcLAE2E3jXHGlkQHqoHO+tUgiaO9xQzhba2aNJRGM73tz d65j++AnGPTeerk2j8OrhkOM8yGrwCYAhjQG+gzVMoMNOqxX+wrCS1BaD9P5/cd7o8neD6LRAbcL mMZrpQtQ9qkfR1Mac1oaSFSzzda+jarguVbGAPtpXDCyUZJwW0oPMiygnJxy/mjV/6N8gd2WSDYi E+auSDDcI9uE4xIKOSx7vH5j8cdoPfYINoRmvR8WteWAf8ZpRKqK768520hBe0GlMUih36JnTaoV bTuh2ULa8qxcz43mv6njQ2v6cA+NWFOddSOquzDvL7kjECgb6eKFKgZ+kb1QCX6wwThczQNHaN0w bpj8iyIAs2hPGvOsxI2dbZ36hihQeEFL0nCzGj4m+LT+SgvWiGDw+sZ2ynQQCT6t7+1V8Cc2BpB6 X8P9hTdqNEvwr9vFl9nyNgucqbeYOuEljZxZtFg6UXizWC6zmRd4N79HE/aM+dr9EEBJfjivOUxh fSj2UOLjyZbg0aZPvxsCkPY491kw8a4j33OyS893wgmZOtPJZeRkkR8sJ+HiNsqiUe7RB+ew5/p+ P9Ft8tHcMEE5k0eujgyNrUASbP9RhHtkwj39bdM/AAAA//8DAFBLAwQUAAYACAAAACEAwRcQvk4H AADGIAAAEwAAAHhsL3RoZW1lL3RoZW1lMS54bWzsWc2LGzcUvxf6Pwxzd/w1448l3uDPbJPdJGSd lBy1tuxRVjMykrwbEwIlOfVSKKSll0JvPZTSQAMNvfSPCSS06R/RJ83YI63lJJtsSlp2DYtH/r2n p/eefnrzdPHSvZh6R5gLwpKWX75Q8j2cjNiYJNOWf2s4KDR8T0iUjBFlCW75Cyz8S9uffnIRbckI x9gD+URsoZYfSTnbKhbFCIaRuMBmOIHfJozHSMIjnxbHHB2D3pgWK6VSrRgjkvhegmJQe30yISPs DZVKf3upvE/hMZFCDYwo31eqsSWhsePDskKIhehS7h0h2vJhnjE7HuJ70vcoEhJ+aPkl/ecXty8W 0VYmROUGWUNuoP8yuUxgfFjRc/LpwWrSIAiDWnulXwOoXMf16/1av7bSpwFoNIKVprbYOuuVbpBh DVD61aG7V+9Vyxbe0F9ds7kdqo+F16BUf7CGHwy64EULr0EpPlzDh51mp2fr16AUX1vD10vtXlC3 9GtQRElyuIYuhbVqd7naFWTC6I4T3gyDQb2SKc9RkA2r7FJTTFgiN+VajO4yPgCAAlIkSeLJxQxP 0AiyuIsoOeDE2yXTCBJvhhImYLhUKQ1KVfivPoH+piOKtjAypJVdYIlYG1L2eGLEyUy2/Cug1Tcg L549e/7w6fOHvz1/9Oj5w1+yubUqS24HJVNT7tWPX//9/RfeX7/+8OrxN+nUJ/HCxL/8+cuXv//x OvWw4twVL7598vLpkxffffXnT48d2tscHZjwIYmx8K7hY+8mi2GBDvvxAT+dxDBCxJJAEeh2qO7L yAJeWyDqwnWw7cLbHFjGBbw8v2vZuh/xuSSOma9GsQXcY4x2GHc64Kqay/DwcJ5M3ZPzuYm7idCR a+4uSqwA9+czoFfiUtmNsGXmDYoSiaY4wdJTv7FDjB2ru0OI5dc9MuJMsIn07hCvg4jTJUNyYCVS LrRDYojLwmUghNryzd5tr8Ooa9U9fGQjYVsg6jB+iKnlxstoLlHsUjlEMTUdvotk5DJyf8FHJq4v JER6iinz+mMshEvmOof1GkG/CgzjDvseXcQ2kkty6NK5ixgzkT122I1QPHPaTJLIxH4mDiFFkXeD SRd8j9k7RD1DHFCyMdy3CbbC/WYiuAXkapqUJ4j6Zc4dsbyMmb0fF3SCsItl2jy22LXNiTM7OvOp ldq7GFN0jMYYe7c+c1jQYTPL57nRVyJglR3sSqwryM5V9ZxgAWWSqmvWKXKXCCtl9/GUbbBnb3GC eBYoiRHfpPkaRN1KXTjlnFR6nY4OTeA1AuUf5IvTKdcF6DCSu79J640IWWeXehbufF1wK35vs8dg X9497b4EGXxqGSD2t/bNEFFrgjxhhggKDBfdgogV/lxEnatabO6Um9ibNg8DFEZWvROT5I3Fz4my J/x3yh53AXMGBY9b8fuUOpsoZedEgbMJ9x8sa3pontzAcJKsc9Z5VXNe1fj/+6pm014+r2XOa5nz Wsb19vVBapm8fIHKJu/y6J5PvLHlMyGU7ssFxbtCd30EvNGMBzCo21G6J7lqAc4i+Jo1mCzclCMt 43EmPycy2o/QDFpDZd3AnIpM9VR4MyagY6SHdSsVn9Ct+07zeI+N005nuay6mqkLBZL5eClcjUOX SqboWj3v3q3U637oVHdZlwYo2dMYYUxmG1F1GFFfDkIUXmeEXtmZWNF0WNFQ6pehWkZx5QowbRUV eOX24EW95YdB2kGGZhyU52MVp7SZvIyuCs6ZRnqTM6mZAVBiLzMgj3RT2bpxeWp1aaq9RaQtI4x0 s40w0jCCF+EsO82W+1nGupmH1DJPuWK5G3Iz6o0PEWtFIie4gSYmU9DEO275tWoItyojNGv5E+gY w9d4Brkj1FsXolO4dhlJnm74d2GWGReyh0SUOlyTTsoGMZGYe5TELV8tf5UNNNEcom0rV4AQPlrj mkArH5txEHQ7yHgywSNpht0YUZ5OH4HhU65w/qrF3x2sJNkcwr0fjY+9AzrnNxGkWFgvKweOiYCL g3LqzTGBm7AVkeX5d+JgymjXvIrSOZSOIzqLUHaimGSewjWJrszRTysfGE/ZmsGh6y48mKoD9r1P 3Tcf1cpzBmnmZ6bFKurUdJPphzvkDavyQ9SyKqVu/U4tcq5rLrkOEtV5Srzh1H2LA8EwLZ/MMk1Z vE7DirOzUdu0MywIDE/UNvhtdUY4PfGuJz/IncxadUAs60qd+PrK3LzVZgd3gTx6cH84p1LoUEJv lyMo+tIbyJQ2YIvck1mNCN+8OSct/34pbAfdStgtlBphvxBUg1KhEbarhXYYVsv9sFzqdSoP4GCR UVwO0+v6AVxh0EV2aa/H1y7u4+UtzYURi4tMX8wXteH64r5c2Xxx7xEgnfu1yqBZbXZqhWa1PSgE vU6j0OzWOoVerVvvDXrdsNEcPPC9Iw0O2tVuUOs3CrVyt1sIaiVlfqNZqAeVSjuotxv9oP0gK2Ng 5Sl9ZL4A92q7tv8BAAD//wMAUEsDBBQABgAIAAAAIQCAUDIOOwoAALs9AAAYAAAAeGwvd29ya3No ZWV0cy9zaGVldDEueG1snFtbb+O6EX4v0P9g+D2ydfEtSHJgW5echwJFz2n7rDhKYqxtuZKS7KLo f++QlGTOkCIlLc7ZTTjfjKThp+GnEfXw28/zafKVFeUxvzxOXWc+nWSXQ/56vLw/Tv/5Z3y3nk7K Kr28pqf8kj1Of2Xl9Lenv/7l4TsvfpQfWVZNIMKlfJx+VNX1fjYrDx/ZOS2d/JpdwPKWF+e0gl+L 91l5LbL0lTudTzNvPl/OzunxMhUR7os+MfK3t+MhC/PD5zm7VCJIkZ3SCs6//Dheyyba+dAn3Dkt fnxe7w75+QohXo6nY/WLB51Ozof7398veZG+nOC6f7pBepj8LOA/D/73m8PwceVI5+OhyMv8rXIg 8kycs3r5m9lmlh7aSOr19wrjBrMi+zqyCbyF8sadkrtoY3m3YP7IYMs2GEtXcf95fH2c/tf3wnm4 j+K71XI1v9utA/duHe1Xd/Fyt90G83A730T/mz49vB5hhtlVTYrs7XG6de+fg8109vTACfSvY/Zd Sj9PqvTlj+yUHaoMDuJOJ4yfL3n+gwF/h6E5hCw5gIVMD9XxK9tnp9PjNIFLLf/DDwI/wgFm7RHk n5ujxZzRfy8mL2mZ7fPTv4+v1QccEu6c1+wt/TxV/8i/n7Pj+0cFo0u4ckad+9dfYVYegLNwKg4/ zCE/QUz4e3I+snsPKJf+FOcuQnoLx/e9ue96C3YT/mI8hHM9fJZVfm4Oy064jQFWHgP+/a5Py3fc ZTBf9g4BU8VDwIk3IebOWj0NlidxBTxbYVqlTw9F/j0BGsOllNeUFQX3HuoHS4QfdCQCzp657JgP vzwAlzBXX0/e4mH2xY5SQ/YayBJDQg1khSGRBrLGkFgD2WBIokJ8F0OeNZB5C5lBqtp8MQJK+dIS pk7ClmF5hm95CvCBdwLi8yTejsjTvDfYQmRzPDfwNvIfkkeMZmCSRQxYAmAu/fH1qQD69U4Fw7JU sDuAc0gMeNoLN9hC2XY7Lx4zkm0euULZRgki0u+SuXkWw4ETdFw/3Cb01nFX5ltny3zwrUNmfScQ ekbItpWzXKM5X0Z35KLDgfgIHdvx/PlapgG5aWKMXroLXz6fW0VA9w8rjwPrzZb54KSRU9k1CFaL 6G0k24hfaLBFso0wLZZtpCIlC85pl7g8i+HA8W94lBgo4oPZxHzMbBKImk2OeufvEYBUaJtzhAGW KhRjdAc/4AYazA/mQ9YjUmYbBF+ryFIl2wh3QoNfJNsoP2QbWdSSleAHrTZi2Hc2HdWGiXty41ir DfMx80MgBD/Wjo9XkY1SUfYyniZrYKwIxXIWa9+Xqw3JT4zRkuBAd9FmRJaYD84Smc5dg2D0ISVk L9toRgx+kWwjFIllGzmXZCPoQ0r9sxgG+twMKDFM8w7mD3cyE6iG6NcrbNSUn5Ag/MVqLi8iiiBk VwEKVcgGm+6JSXRvDeGlP7epxKkaoYm3riohqdZrIbpVChnpOo6MRGpHyEgLETKSE0rAyBlNS1E9 7jvLmwVniKhg/vhkkz6uEJnwdyuHqfapIWJ6V8AXebbmC7UcIQd4VjPr4JDA1eUwGhYwJvBu+uL0 EeXcL32Ngr2ljzBh58oil9YpZCQ0CZGRsC8yecbISE4oAaOeYGLcdxa3GxxnaIy2du3iuoYMIBiW 0FZGhugIc8da0IjkNhM4JtH7FjSN6F5AvTI+vLqq6iZP8LsWolsXTcYQGZWCZlLeyFMpaLX2Vgqa GDfwbYz6Zg0ji7yqIQb9jRA9Sl5oDRkRhIWCMYH35ZRGqC9Bo5k5pSp1ssLvmKblSdVJdWSkz3Im zwgZCeFiZFQ41aHXwYmdooFTYxS7a5fsNcTEKZNKJ+7d0y16KsPgcW84Lvca2W7rQm5dVbeTR/Fd C9GSyaTckSehRGQyxiZjAkb9gtjI964F0Rsj37mTWb7XkI4GJFbb0OBZGbqMIY4FjY6ALBgRQdga TL3huEOrke/W1c5T5TvpEu5aiE6+IyOV78hIVztkpPLdZEzAyMlEO031OFSmDvnujZHv3MlCJrmN 3Ee+1zG7S1lIELZqReC2pc90fMwpjWK3FihPVewufeJpMToJhYwKqWSxTysU8qTLnSlsAkZtharH fce/3dQ4RWMku2eX7DWkv2RHDvZnwmHwiMCtDMP6Hj1x4vSN0ej8TSHpjNPWeIvRMswgtUPkSd+1 IKPCMDksIW4CnnqGNSJdejuFUzRGpHt2kV5DBjBsUN87RPGthIwI3MowQ5cep29Ma91TFbtLJnTX YrQMM7TJQ+SpMEz2VBhmeExIIKyeYY1k72TYGMnu2SV7DWnblp19yPrFr0m/D4sVDYPHBG6oVxrJ bldZqmSn78l2nizLybq2R0babTd5RiZjjIxKverQ7ODEHwA7Xo6PEey+ENymFmkNaahkqQ57Arc1 SAlc0yDFCPqSnbTn+/XbfY1gt7YSuBNZ+mjDvcWweaI7VJCR9kORkfZDkZGQMEZG2ksAo7Yw1eNe Z8PdH6PYuZNZsdeQnu9T9hRurmPhMHiE4D0eH2ISv7tY+Rr5bmeYRr7TjjsPzFKMK4Eo48hIqBCa jBEy0m0XyEiLFRj1DBPjBoaNke/sEcjSAa0hfZc+Cre80CFwXb0iDXYzZWMU0MxBJK78MfKdO5Ea RnvsLYZNK10OkVGpYQYRHpnCxshI6JeAUc8wMW5g2Bj57tvlew3pzTDbrpZwWMBoGDzG8A7xoJHq 1s0evkaq0+56i9GyyaCpQ5NnZDLGyEiWywSMejaJca/zDaE/RqpzJ8uKSPaZWKR6HdHQwSII2wtB a8AYIYaUqDF7Y3yNYqdd9hajJZUs52kPC3nSxigyKts5DVtrEvDUk0qMd5MqGCPauZNlTyfWxTbR XkfsqcpCAtcsggjRR1n1PgO0CAZjNs5wJ7II0tZ7i9EJeWSkiyAyUiGPjMru1uaNgEbaJeCpZVg9 bmDYGCEf2HfO1JCGMvRhB5vJNk/ia+uxU7hly0LHoTFxxrTXA1Wfe8pmarlJThbDfRuATSVtJiAj ba8jI31nYwqbgFFPnEafex2b0oIx+pw7WUoT1scBzL78jo/U+n0dsXdpGrS9JULRe9Wp/ttzMOHG bEMP1B0x0myJzxpaDJtlouX3yKhUKkMrPkKeSqUy7GJPwFNPuEauS5894BSNkeuBXa7XkIZB3d+a iIdoBO+zP4bE162G8hNAL5b1d8ApHNNxD1QZ79GOe4thU0sWyz0y0k0yyKish/IDgMIygzGBsHqW 1ePOuuOtYTBGxnMnS1nDMt7KMgxXSRPWx+wW+hFC9KKVvs2PKTRmZwx8e6l8EEG3tLcYLYVMoh15 KhQy6PIYedInQTDqKVSPq71R8e2n+JrxnBXv/BvRcnLIP9mXm0yhtaP1d6ne/dbnX43e4E8P1/Q9 +1tavB8v5eSUvfGPPoHrhfgqdO7Az1V+ZZ+CrqDQvuQVfNHZ/PYBH0ln8EkkbPScTt7yvGp+YZ9c tp9dP/0fAAD//wMAUEsDBBQABgAIAAAAIQAL/ztCTAMAAKsHAAAUAAAAeGwvc2hhcmVkU3RyaW5n cy54bWyMVctuIzcQvAfYf2jMPStnkw2CQJIPxhprIFgEthOfKU5LJMLHLMmRVrf8Q/4wX5JqUvI6 mjGSwxw47GdVdXN5/cU72nPKNoZV993bq4446NjbsFt1vz3efvtTR7mo0CsXA6+6I+fuev3mm2XO heAb8qozpQw/LxZZG/Yqv40DB9xsY/Kq4Jh2izwkVn02zMW7xburqx8XXtnQkY5jKKvu/Q8djcF+ Hvmm/fj+XbdeZrtelvXff/61XJT1ciHH9uvJqEJ9pAPTQYVC2xQ9FcOUOVnO15f2jzA1MLGZWGlD Ste8auN4YvtkIsKUjK6TKrw7zlgg+zBunM0GMBF/GSRt0CwJpIz7hw/1ry7cU4lk1H4+UTyE5vFK 4VKMUc1EjcXEZMtRIlo/xMzkbbB+9CeGUp8JqBP3tkhhcQuQdJ6iB/9MifMQQ7YAoXqh6eoFrsmG PCYJoaMfnFXS28EW87LtpgrknAD0MR4aEsDpGWrrpHRghbyZ+3lUC2sTrFaOtBrURnzAJ2UTRwck T9Bu+P+hK8g9d9nyCzw1zK83VBsF0Zux33GZFHSXYQFV9hgOGYAToippY/eosMTociUi4RoiPIcG +Sm+oiwpKWLclGsBJOi/S5wHxvGenRDKW+QpZ0QwAKI+XUQTArWwlSFwhIdxMXbKjmiK0VHVL8AV GKSkzDjUoXU0pKiFJigvUs+FE5TGFTm0PrIEv7+9qdc5astC0+woIdLe9giUGNV5xiIpWDXV06s/ ziNLPiaWDpC1KhJ5hae9SjaOKHLs64TNJYHKjBqwdDKmnIP4SSx8Ooats7rKOvHn0SZGBUI5lwM3 U5lzVn5maVjP7tgUr2vRkwbv0VPqSe0St8ATi4emXFlUMaUjqU0cCzneKT1dLHVuMNhNT3VZYcYB dVB7u5sv4WsCNItGwQ2gG+G3kfkGwKJTyGxeV2fgTnC3NURWpMN09+HxlnqbBVyVZvbIC+RPAarL yf0U7D8CyKiAX7DV8xYiA5wQ5EE2fNumNkE7rqnG2EHaw0sEqyhEXy63T7HQ3TOGsoCcu7T5BSL7 anR5+xA91/TPYS4tXr34nUHxq7dPbHdGXoT7tnl5+kwV7JXz7Qu8F3hs1/8AAAD//wMAUEsDBBQA BgAIAAAAIQA3NSFLRQEAAGUCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMkl9vwiAUxd+X7Ds0vLdQTZ2Stib745MmS+ayZW8ErkpWoAE2 9duPttrVuIc9cs/hxzk35PODqqJvsE4aXaA0ISgCzY2Qelug1/UinqLIeaYFq4yGAh3BoXl5e5Pz mnJj4dmaGqyX4KJA0o7yukA772uKseM7UMwlwaGDuDFWMR+Odotrxj/ZFvCIkAlW4JlgnuEGGNc9 EZ2QgvfI+stWLUBwDBUo0N7hNEnxr9eDVe7PC60ycCrpj3XodIo7ZAveib374GRv3O/3yX7cxgj5 U/y+Wr60VWOpm11xQGUuOOUWmDe2fKqk8dESmM3xYNyssGLOr8K2NxLE/fHCea0GZluhA4OIQija VTgrb+OHx/UClSMyIjHJ4jRdp1OaTWh299E8fnG/CdkN1CnCP4kzSgjNZgPiGVDm+OpjlD8AAAD/ /wMAUEsDBBQABgAIAAAAIQDCXlkIkAEAABsDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySTW/bMAyG7wP6HwzdGzltUQyBrGJIV/SwYgGS dmdOpmOhsiSIrJHs10+20dTZdtqNHy9ePqKo7g6dK3pMZIOvxHJRigK9CbX1+0o87x4uP4uCGHwN LnisxBFJ3OmLT2qTQsTEFqnIFp4q0TLHlZRkWuyAFrntc6cJqQPOadrL0DTW4H0wbx16lldleSvx wOhrrC/jyVBMjque/9e0Dmbgo5fdMWZgrb7E6KwBzq/UT9akQKHh4gmM9RyoLb4eDDol5zKVObdo 3pLloy6VnKdqa8DhOo/QDThCJT8K6hFhWN8GbCKtel71aDikguyvvMArUfwEwgGsEj0kC54z4CCb kjF2kTjpHyG9UovIpGQWTMUxnGvnsb3Ry1GQg3PhYDCB5MY54s6yQ/rebCDxP4iXc+KRYeKdcLYD 3zRzzjc+OU/6w3sdugj+mBun6Jv1r/Qcd+EeGN/XeV5U2xYS1vkHTus+FdRj3mRyg8m6Bb/H+l3z d2M4g5fp1vXydlFel/lfZzUlP65a/wYAAP//AwBQSwECLQAUAAYACAAAACEAYu6daF4BAACQBAAA EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj 9AAAAEwCAAALAAAAAAAAAAAAAAAAAJcDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCBPpSX 8wAAALoCAAAaAAAAAAAAAAAAAAAAALwGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQIt ABQABgAIAAAAIQBaNXgQVQMAACgIAAAPAAAAAAAAAAAAAAAAAO8IAAB4bC93b3JrYm9vay54bWxQ SwECLQAUAAYACAAAACEAlZIOsuYCAACzBwAADQAAAAAAAAAAAAAAAABxDAAAeGwvc3R5bGVzLnht bFBLAQItABQABgAIAAAAIQDBFxC+TgcAAMYgAAATAAAAAAAAAAAAAAAAAIIPAAB4bC90aGVtZS90 aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAIBQMg47CgAAuz0AABgAAAAAAAAAAAAAAAAAARcAAHhs L3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQAL/ztCTAMAAKsHAAAUAAAAAAAA AAAAAAAAAHIhAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAAIQA3NSFLRQEAAGUC AAARAAAAAAAAAAAAAAAAAPAkAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQDCXlkI kAEAABsDAAAQAAAAAAAAAAAAAAAAAGwnAABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAAKAAoAgAIA ADIqAAAAAA== --Apple-Mail=_8A8B33E8-91FB-4340-8F57-5079B2B16C2C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_8A8B33E8-91FB-4340-8F57-5079B2B16C2C-- --Apple-Mail=_C7E0AEF2-568A-4364-85B8-8CCC6BC69B81-- From nobody Mon May 11 19:04: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 A2AE73A0E5D for ; Mon, 11 May 2020 19:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=1JVeZlfE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ClhQQVCY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id angOQfqgLmN7 for ; Mon, 11 May 2020 19:04:01 -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 421563A0E59 for ; Mon, 11 May 2020 19:04:01 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7606C5C0103; Mon, 11 May 2020 22:04:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 11 May 2020 22:04:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=1 6oZ/2e6XeiocdnAUb1zhy2b8GgsdtcMZoUnMTm5Wuk=; b=1JVeZlfEdOCJSf9rC 3CsZOZ55RdO2MJyYrZjoYeWgypZBP8LgjKeUrYf7UIJlsOBZlYDgvJrFhIPDWNNC +XSdJxzqXhXtqAFJaOQG67YUAl18/OIjQtSOqwCSkXq0vnza8CTvCtimJJKlnFxi lYpx0niJrgIF3n1VxHgZpK3S1PSJG2ijy7gCzSZDd6OQU03DiJnCyFbucH8ss4Hx 8hNmlVBVZShvOqxhEcInFvMleIuaczsgEKR4743MsnDiKqix22fEtEzxDQbMCbC1 ORc6LyvoROOwh7p0Eoqm5sKvjtVIOjEVQRk5AUzeVY2DZ3xWX/tSFLJQuyHJpofg TiHfQ== 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=fm2; bh=16oZ/2e6XeiocdnAUb1zhy2b8GgsdtcMZoUnMTm5W uk=; b=ClhQQVCYarRXggJMp2XewG3QyAOIXzRvd6tTlgFDwJx3+1dF8uzlm/4qm 9g4dlCZ1d7XLJdwQtmDInkWA4OrtJjhEpCKP46vkPWrEEL5KLIQPXRxrWKPWuS5D daaVZgcZr2PCs/rAjHI8OESiWY7tFUyfxrwJj3iOhD04fRFNVTa7dU6m1GRwyS9A Ih1bzyRauzr7QTvroDQSFukxC3+y2j3xgMRicuuHxycDuOI8VH9uopvPYQ7etmO/ H+VLoJw9SZEyA59hstY3Y+aqBxC6Q6hqaoqKeWNLig92+qDOMCRMde6DdnJALZI1 GJXuK8Lbzq0afKiRMQvWRMBgqGVMw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrledugdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepfeegvdfgjeegvdetuedukeevfefhheelieevjeejkefhffehkeejieekjedtheej necuffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtnecukfhppeduudelrd dujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 36CE23280059; Mon, 11 May 2020 22:03:57 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> Date: Tue, 12 May 2020 12:03:48 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 02:04:04 -0000 Hi Brian, > On 9 May 2020, at 3:12 pm, Brian E Carpenter = wrote: >=20 > Hi, >=20 > This draft is intended as background material for ongoing discussions = about the role of the Request for Comments (RFC) Series Editor (the = RSE). This version is purely personal opinion. I welcome comments, best = sent to rfc-interest@rfc-editor.org if they concern the RFC Series in = general, or to rfced-future@iab.org if they concern the role of the RSE = specifically. >=20 > I advise reading the pretty HTML version since this draft is in v3 = format: > https://www.ietf.org/id/draft-carpenter-rfc-principles-00.html Very helpful document. Some feedback on the proposed principles / = suggestions on how we can use this as a springboard for work: > =E2=80=A2 The RFC Series is the archival Series that documents = Internet technical specifications, descriptions, and commentaries, = including general contributions from the Internet research and = engineering community, as well as standards documents. It also includes = some organisational documents from the same community. Clarity on what 'archival' means -- and doesn't mean -- would be = immensely helpful. In particular, if there's an agreed set of properties = that are desirable, that might help us / the future rfced find ways to = meet the differing needs in the community without breaking 'archival'. > =E2=80=A2 RFCs come from various streams, i.e. originating = organisations. Each stream has its own policy on change control and = copyright, with the IETF Trust generally acting as a repository for = intellectual property rights that are not retained by the authors. This begs the question of under what conditions a new stream can be = created. I suspect we could write down and agree to some guidelines as = part of this work. > =E2=80=A2 The RFC Series is community property and must operate = on behalf of the community as a whole. >=20 > =E2=80=A2 The exact definition of the relevant community = is open for debate. One definition is: the IETF, the IRTF, the IAB and = the many other people who have contributed to, or made use of, the RFC = Series over the last fifty years. >=20 > =E2=80=A2 Major decisions about the future of the RFC Series = must be taken by a rough consensus of this very broad community. >=20 > =E2=80=A2 How to reach out to this community and judge = its consensus is in itself a big question. I think it's widely agreed that your conclusions about the series not = being 'owned' by any of the I* are correct. However, I'd suggest that we = can reach out to and judge consensus of that community just like we do = in any other area -- establish a venue (e.g., a WG) and make it known = that if you're a stakeholder who's interested, that's the appropriate = place to contribute. Doubtless some people will not choose to come, but = that's their choice. Others might advocate on their behalf; we already = see that with civil society organisations being involved in the IETF's = work. The difference is going to be that the oversight structure / appeal = chain of that effort needs to consider that the IESG and IAB have = conflicts of interest, in the sense that they're both stream owners. = This is where we should focus attention; we might decide that we need a = separate appeal chain, or we might decide that the sword of recall = hanging over those bodies is sufficient, if we make the expectations = clear. > The RFC Series Editor is an independent professional editor, serving a = much wider community than just the IETF. Given the economic and social = importance of the Internet, this is a serious responsibility, comparable = to the editorship of a major newspaper of record. I've heard this asserted by a few different people, and I don't see the = evidence to back it up (having been educated and employed as a = journalist much, much earlier in my career). Yes, we need someone who understands some aspects of publishing; just = anointing a network engineer from our community (as we do with so many = roles) is not sufficient. Much more relevant is having someone who = understands project management and consensus building.=20 This does not equate to "editorship of a major newspaper of record" -- = if folks think that it does, we need to have a series talk about = expectations, because that phrase implies the ability to hire and fire = writers (document authors) and subeditors (which would be stream = managers here?), give them directions, determine content, refuse = publication, and so forth. It's also not clear that they need to be independent in the sense that = they have absolute control over the series. If we're able to balance the = conflicts of interest mentioned above, there's no reason that they = couldn't be overseen successfully by the IESG, IAB, some combination of = them (or some other body if not). I know that at one time, the RFC Editor did have significantly more = power than the role has now, and this characterisation might have been = appropriate. If folks honestly think that is still the case, the powers = should be enumerated and put to the community, because it would be a = drastic change in the nature of the IETF's work, and I don't think it = would be acceptable to many. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 11 19:41: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 6A7563A07B9 for ; Mon, 11 May 2020 19:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9Fr2sBdYBOc for ; Mon, 11 May 2020 19:41:23 -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 3BF483A07BD for ; Mon, 11 May 2020 19:41:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2F568BE2C; Tue, 12 May 2020 03:41:20 +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 tfrI_P4rq11L; Tue, 12 May 2020 03:41:10 +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 9FFE6BE20; Tue, 12 May 2020 03:41:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1589251270; bh=c8ALAcpoQMOivZI66TWKzdqWm55Ua2zjKVeWUbeHs+U=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=MbeHOk/uizlW1E4zk61zw7lJou3z9nvbFqs8AOOODL0gdHrlNz6IPLU28z9lt5mVi ynkVhTwnLXUIi0qOAphjS1pvvfMkA8JJKJa4myZWmdnK9ZqfKoJ5csqButDHh2LldP WTHD3i1QI5hJAwSt0AVo8g3TINUqte69op37DmEE= To: Mark Nottingham , Brian E Carpenter Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.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: <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> Date: Tue, 12 May 2020 03:41:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XGNZ552ju0XMwo93EMjE00JzKtWyiHNqD" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 02:41:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XGNZ552ju0XMwo93EMjE00JzKtWyiHNqD Content-Type: multipart/mixed; boundary="kSYjXvxrXenXhYiEzoEdWHzgL6HxvPpn8"; protected-headers="v1" From: Stephen Farrell To: Mark Nottingham , Brian E Carpenter Cc: rfced-future@iab.org Message-ID: <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> In-Reply-To: --kSYjXvxrXenXhYiEzoEdWHzgL6HxvPpn8 Content-Type: multipart/mixed; boundary="------------ABFB1AF5B05434FC4528EB5C" Content-Language: en-US This is a multi-part message in MIME format. --------------ABFB1AF5B05434FC4528EB5C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Mostly just a query... On 12/05/2020 03:03, Mark Nottingham wrote: > Much more relevant is having someone who understands project=20 > management and consensus building. I don't understand why those features are "much more relevant" than other things. Can you explain? IIUC, you may be reacting to: "The RFC Series Editor is an independent professional editor, serving a much wider community than just the IETF. Given the economic and social importance of the Internet, this is a serious responsibility, comparable to the editorship of a major newspaper of record." FWIW, I also figure I separately disagree with Brian's NYT/WaPo "editor" concept - while that does seem attractive for someone (like me) who adolesced in the post-Watergate era, I'm very struck by a recent COVID-19 survey here in Ireland that found that <2% got real news from print newspapers, so the newspapers of record are also changing. The "winning" 36% source btw was the public TV broadcaster, and while the online equivalents of incumbent print newspapers did figure a lot, weird Internet sources didn't feature much. Ta, S. --------------ABFB1AF5B05434FC4528EB5C 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----- --------------ABFB1AF5B05434FC4528EB5C-- --kSYjXvxrXenXhYiEzoEdWHzgL6HxvPpn8-- --XGNZ552ju0XMwo93EMjE00JzKtWyiHNqD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl66DMUACgkQWrL68XsX K+rK1w/+ISfwQenxGYwYqIenKNgmIFyKk2WBCV7IEb2WH6907GhBQJuDSzmOSdvu r/c3IH++2NosYRQUIDitUvI8mmXt9FXzPa7pVRtPvmqDhBzR6YtEHt3W+ebgpeU9 911jcJ7f7S/1HhVoevHTszDsmBG6rovgXQiaZZN4dLrj+JcxSw5KSpmqQNc5VYwC kr5+mqm3SxSU2tGfo7xGnFktOtFKvPK7qR5+eUylbV44GCcsGeKAav+UVVPMRt9V a1Z9mLSp4sP7I5BKF+SXQvb0yThuT6sSwiqYIvfeUwpPuHVDHxmecfVkuG5h244W MSPnbNWagBqxfYATrXPVoQBjA/rV6btWcdn0OucyWY9uVvwEi9y37xF3qH10PyCz ZUyp+mxe2DCLZE06LxX8FGkSCgAnlU8qLwm7VnEoArDetDE24ByC3TGh0PjLEsxb WWbvy4IuORQwP0PBZ1P+dYtRAOGTDTh7P5dU2cp/Oznkgge15tIJ1A1HkO6LZo/P 5EACoicQzMtbARI+IjBRy8fDmeo0uVre0hFaemqvolh+B3JmtZDRVzVJt5BRBqGM 0zUQ3lDwfduwEN63NaidB4RStB/TVEE+5/mVgzTc3tuPsRmcpBY6ZgA86+okQS6i L4/bePnyrc0NJExSCeYCDC1Xcjt9JUExhpuQhZZW7wBH3fbHvPQ= =8c96 -----END PGP SIGNATURE----- --XGNZ552ju0XMwo93EMjE00JzKtWyiHNqD-- From nobody Mon May 11 22:12: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 024743A0C0E for ; Mon, 11 May 2020 22:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjvYSu8IKEbC for ; Mon, 11 May 2020 22:12:14 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0C23A0C0D for ; Mon, 11 May 2020 22:12:13 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id u22so4860976plq.12 for ; Mon, 11 May 2020 22:12:13 -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=AYwWQOQtxB3SBLfMOAptOGDS4raywLMPBBI0cG9ltFA=; b=jw3UyKrlLSneFLI6Ncep9Ncv4FX7B+n1FzTl561C3mD8/ziRtJh6dbtimNBElEh+hc zkqaSu6RKI29oIb/lLlS5tAdsQaMRQFDt5NHjdtKUZzSjNSVGHga6U0Dhiun5hogNROt b48YADGuC2AH4gsLKqQmG6vLDn8gMDQicL/Igtkxg0Tjl2K5pWiZgCPNIwVY2P9ct0ev ZWPmBy6R6uBh/r+j7wiH+MAIHUu0mllI+EteRH23TVN3RteLTPiFX10sGG4jiLiiu7KH 6YNdnRwu/bHo2ynH9SY0W0Pa6FN45ORIAQh98HN/3YvgGuMAIgQpPgVODMJEuj37bRcq BDDA== 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=AYwWQOQtxB3SBLfMOAptOGDS4raywLMPBBI0cG9ltFA=; b=Vnd1FzOYZi0+SkFOEz1yLhFvF4x0vIY4BQ4MxL9Bl2L8Scw5IDir8H69ncHQJfPY8d l+RHUtV/N0rZNH0e+2GBDnqDk8gVeWaVHJDld7uSrwx2av/nNT/bdUnnC616OLFhbj5A AlJUjvgb82RAI4c+292ihBI8M1xefYibjKJlVFO7FzNviVz45M9fJODz+6+MJDsDUqop fD52FSlcu/jRJxWAWJ68FrXnN9gbLeU7giSpDD6/KyIJbDtz5fcAWudYt5VktkcZPUHq OEB2xs6d5tlPTwvW/CYJu15o77At/z1/XGE/NC0DhzBl+lwwl4RjidiynwwbuuEyqpHk 675A== X-Gm-Message-State: AGi0PubqEpfNaDunMkHJCciNJMa957L0VwN6oZmJcNRNgoksMJM1GCpm ps4BscgIdX7NNDYTlpCNAz4+Dctj X-Google-Smtp-Source: APiQypKMDI8pns0iB8JcTgK+WMVyfl16e1SBzsxhvSyilJ9mDe2nOnpSDcQLBoXZmCC5wcTSRXRjrA== X-Received: by 2002:a17:90a:6343:: with SMTP id v3mr26922106pjs.127.1589260332913; Mon, 11 May 2020 22:12:12 -0700 (PDT) Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id bg6sm11653386pjb.21.2020.05.11.22.12.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 22:12:12 -0700 (PDT) To: Mark Nottingham Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> From: Brian E Carpenter Message-ID: <93012f0c-7012-62b2-474d-ae92d8ad83ee@gmail.com> Date: Tue, 12 May 2020 17:12:08 +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] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 05:12:16 -0000 >=20 >> The RFC Series Editor is an independent professional editor, serving a= much wider community than just the IETF. Given the economic and social i= mportance of the Internet, this is a serious responsibility, comparable t= o the editorship of a major newspaper of record. >=20 >=20 > I've heard this asserted by a few different people, and I don't see the= evidence to back it up (having been educated and employed as a journalis= t much, much earlier in my career). >=20 > Yes, we need someone who understands some aspects of publishing; just a= nointing a network engineer from our community (as we do with so many rol= es) is not sufficient. Much more relevant is having someone who understan= ds project management and consensus building.=20 >=20 > This does not equate to "editorship of a major newspaper of record"... You're right, my phrase is hyperbolic. I'll think about how to make my po= int more accurately. I appreciate all the comments received and I will do an update, but proba= bly not this week. Brian Regards Brian Carpenter On 12-May-20 14:03, Mark Nottingham wrote: > Hi Brian, >=20 >> On 9 May 2020, at 3:12 pm, Brian E Carpenter wrote: >> >> Hi, >> >> This draft is intended as background material for ongoing discussions = about the role of the Request for Comments (RFC) Series Editor (the RSE).= This version is purely personal opinion. I welcome comments, best sent t= o rfc-interest@rfc-editor.org if they concern the RFC Series in general,= or to rfced-future@iab.org if they concern the role of the RSE specifica= lly. >> >> I advise reading the pretty HTML version since this draft is in v3 for= mat: >> https://www.ietf.org/id/draft-carpenter-rfc-principles-00.html >=20 > Very helpful document. Some feedback on the proposed principles / sugge= stions on how we can use this as a springboard for work: >=20 >> =E2=80=A2 The RFC Series is the archival Series that documents Intern= et technical specifications, descriptions, and commentaries, including ge= neral contributions from the Internet research and engineering community,= as well as standards documents. It also includes some organisational doc= uments from the same community. >=20 > Clarity on what 'archival' means -- and doesn't mean -- would be immens= ely helpful. In particular, if there's an agreed set of properties that a= re desirable, that might help us / the future rfced find ways to meet the= differing needs in the community without breaking 'archival'. >=20 >> =E2=80=A2 RFCs come from various streams, i.e. originating organisati= ons. Each stream has its own policy on change control and copyright, with= the IETF Trust generally acting as a repository for intellectual propert= y rights that are not retained by the authors. >=20 > This begs the question of under what conditions a new stream can be cre= ated. I suspect we could write down and agree to some guidelines as part = of this work. >=20 >> =E2=80=A2 The RFC Series is community property and must operate on be= half of the community as a whole. >> >> =E2=80=A2 The exact definition of the relevant community is open for= debate. One definition is: the IETF, the IRTF, the IAB and the many othe= r people who have contributed to, or made use of, the RFC Series over the= last fifty years. >> >> =E2=80=A2 Major decisions about the future of the RFC Series must be = taken by a rough consensus of this very broad community. >> >> =E2=80=A2 How to reach out to this community and judge its consensus= is in itself a big question. >=20 > I think it's widely agreed that your conclusions about the series not b= eing 'owned' by any of the I* are correct. However, I'd suggest that we c= an reach out to and judge consensus of that community just like we do in = any other area -- establish a venue (e.g., a WG) and make it known that i= f you're a stakeholder who's interested, that's the appropriate place to = contribute. Doubtless some people will not choose to come, but that's the= ir choice. Others might advocate on their behalf; we already see that wit= h civil society organisations being involved in the IETF's work. >=20 > The difference is going to be that the oversight structure / appeal cha= in of that effort needs to consider that the IESG and IAB have conflicts = of interest, in the sense that they're both stream owners. This is where = we should focus attention; we might decide that we need a separate appeal= chain, or we might decide that the sword of recall hanging over those bo= dies is sufficient, if we make the expectations clear. >=20 >> The RFC Series Editor is an independent professional editor, serving a= much wider community than just the IETF. Given the economic and social i= mportance of the Internet, this is a serious responsibility, comparable t= o the editorship of a major newspaper of record. >=20 >=20 > I've heard this asserted by a few different people, and I don't see the= evidence to back it up (having been educated and employed as a journalis= t much, much earlier in my career). >=20 > Yes, we need someone who understands some aspects of publishing; just a= nointing a network engineer from our community (as we do with so many rol= es) is not sufficient. Much more relevant is having someone who understan= ds project management and consensus building.=20 >=20 > This does not equate to "editorship of a major newspaper of record" -- = if folks think that it does, we need to have a series talk about expectat= ions, because that phrase implies the ability to hire and fire writers (d= ocument authors) and subeditors (which would be stream managers here?), g= ive them directions, determine content, refuse publication, and so forth.= >=20 > It's also not clear that they need to be independent in the sense that = they have absolute control over the series. If we're able to balance the = conflicts of interest mentioned above, there's no reason that they couldn= 't be overseen successfully by the IESG, IAB, some combination of them (o= r some other body if not). >=20 > I know that at one time, the RFC Editor did have significantly more pow= er than the role has now, and this characterisation might have been appro= priate. If folks honestly think that is still the case, the powers should= be enumerated and put to the community, because it would be a drastic ch= ange in the nature of the IETF's work, and I don't think it would be acce= ptable to many. >=20 > Cheers, >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 From nobody Tue May 12 00:04: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 BC44D3A07D5 for ; Tue, 12 May 2020 00:04:09 -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 Nqah0tMRR3KE for ; Tue, 12 May 2020 00:04:08 -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 157853A0819 for ; Tue, 12 May 2020 00:04:08 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jYOxP-000KDe-A2; Tue, 12 May 2020 03:04:03 -0400 Date: Tue, 12 May 2020 03:03:57 -0400 From: John C Klensin To: Mark Nottingham , Brian E Carpenter cc: rfced-future@iab.org Message-ID: <25F32505CBC1C1AF2841AF9A@PSB> In-Reply-To: References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 07:04:10 -0000 --On Tuesday, May 12, 2020 12:03 +1000 Mark Nottingham wrote: > Hi Brian, >=20 >> On 9 May 2020, at 3:12 pm, Brian E Carpenter >> wrote: >>=20 >> Hi, >>=20 >> This draft is intended as background material for ongoing >> discussions about the role of the Request for Comments (RFC) >> Series Editor (the RSE). This version is purely personal >> opinion. I welcome comments, best sent to >> rfc-interest@rfc-editor.org if they concern the RFC Series in >> general, or to rfced-future@iab.org if they concern the role >> of the RSE specifically. >>=20 >> I advise reading the pretty HTML version since this draft is >> in v3 format: >> = https://www.ietf.org/id/draft-carpenter-rfc-principles-00.html >=20 > Very helpful document. I certainly agree so far. > Some feedback on the proposed > principles / suggestions on how we can use this as a > springboard for work: =20 >> =E2=80=A2 The RFC Series is the archival Series that = documents >> Internet technical specifications, descriptions, and >> commentaries, including general contributions from the >> Internet research and engineering community, as well as >> standards documents. It also includes some organisational >> documents from the same community. =20 > Clarity on what 'archival' means -- and doesn't mean -- would > be immensely helpful. In particular, if there's an agreed set > of properties that are desirable, that might help us / the > future rfced find ways to meet the differing needs in the > community without breaking 'archival'. Mark, I fear that takes us around in a bit of a circle, albeit an important one. I was forcefully educated (one might say "beaten up") some years ago by an Archivist (his job title) associated with a national repository library in the north of Europe. He explained that it was very hard to have a conversation about what was "archival" or about the meaning of the closely-related term "permanent" with people in computer fields (especially web-related ones) because we tended to think of "permanence" as 10 - 20 years. He claimed that most people he had encountered from North America or the South Pacific had similar problems with believing permanence, in practice, could be considered a few centuries but that he and his colleagues needed to work in terms of at least several millennia and that those differences put an entirely different spin on things. That story is important in the current context for two reasons: * While I consider the decision made and hence not part of the current RFC Editor Futures discussion (even though I, and apparently others, have growing doubts about how we are implementing it), a conversation with almost any (I don't know of exceptions, but maybe there are some) professional archivist about treating a source format that requires considerable compilation and reference to external sources and mechanisms to get to a form people are comfortable reading as an archival form will typically be greeted with laughter and/or comments to the effect that we should come back in a hundred years and show them that XML is still around and that it is the same, or at least completely backward-compatible, XML. If they, and their considerations, are to be taken seriously as we talk about "archival", things are broken already and comments about the merits of continuing to dig when one finds oneself in a deep hole may be relevant. * There have been several discussions in recent years about treating IETF specifications as living documents or with some other arrangement in which issues are folded in as soon as they are detected and at least tentative conclusions reached about how to proceed. I don't know whether we need to resolve those proposals before moving forward with discussions about the future of the RFC Series and its management and organization (I hope we don't because the community seems quite divided to me). However, I think we need to understand that moving in that direction, even if we make periodic snapshots and publish them as RFCs, would profoundly change the character of the series as providing a clearly-identifiable (and "archival") record of the evolution of Internet technology and standards. >... >> =E2=80=A2 The RFC Series is community property and must = operate on >> behalf of the community as a whole. >>=20 >> =E2=80=A2 The exact definition of the relevant community is = open >> for debate. One definition is: the IETF, the IRTF, the IAB >> and the many other people who have contributed to, or made >> use of, the RFC Series over the last fifty years. >>=20 >> =E2=80=A2 Major decisions about the future of the RFC Series = must >> be taken by a rough consensus of this very broad community. >>=20 >> =E2=80=A2 How to reach out to this community and judge its >> consensus is in itself a big question. >=20 > I think it's widely agreed that your conclusions about the > series not being 'owned' by any of the I* are correct. > However, I'd suggest that we can reach out to and judge > consensus of that community just like we do in any other area > -- establish a venue (e.g., a WG) and make it known that if > you're a stakeholder who's interested, that's the appropriate > place to contribute. Doubtless some people will not choose to > come, but that's their choice. Others might advocate on their > behalf; we already see that with civil society organisations > being involved in the IETF's work. One problem is that one important audience for the Series, or at least the documents we claim are standards (or to which assorted parties claim conformance) are people writing procurement documents (RFPs, contracts, SLAs, etc.). The odds that we will get a reliable representation from that community even if we could reach them are, I think, pretty small. The odds that we could get them to participate in a WG-like arrangement? Probably much lower. But, at least if one were to assume a free market in which alternatives exist, those people are key to determine if our standards go anywhere. Indeed, when they write contracts that require conformance and try to enforce them, they are actually the closest we get to actually having a Protocol Police. And, by the way, they, and the kinds of documents they are willing to work with, interact with the "living document" ideas as well: IMO at least, we dare not ignore them because we cannot get their participation on our normal terms. >... Stopping here more because it is late here and I'm tired than because I'm in complete agreement with all of your other comments. best, john From nobody Tue May 12 00:16: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 289743A0CA0 for ; Tue, 12 May 2020 00:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZsknPCjZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bB3F8FHM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8AekGftejDF for ; Tue, 12 May 2020 00:15:58 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E752A3A0C9F for ; Tue, 12 May 2020 00:15:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2A8FF5C0090; Tue, 12 May 2020 03:15:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 12 May 2020 03:15:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=Z oc16UNUWNbtWJhJJrtfbv3VYn6RFLzvhUevdzMxQHI=; b=ZsknPCjZNYIcHJnAB GdrmhWWr8V3zia4sIqt0z6xgTeAZC/f9NpHGEYOD/AOWPXQJZCGGAAqGpf34XNT5 LqneT8M9gekqMnfsSCSetMrFVO8caWhQGG57EO5a5HShCE0Lp39BRqGbKkS0djvG GLM8VVkBNySgpJEPUHtA5ND3TsBJ4haGx9KdblVu20KEoMHFhdGHeUrgNlOPkxtX d7iYBuVvRnW4wW0YeEmLq0L2/cE0rAnJdQ6KSPce7EeGLMB2gXg5PEQMLhwsdRm9 LCz43tuhtuoRQRYFzKdIyhLyiNAz0gI1TYDsUBM09trLFes0cTEqAzBiF8rZle6f wGoYw== 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=fm2; bh=Zoc16UNUWNbtWJhJJrtfbv3VYn6RFLzvhUevdzMxQ HI=; b=bB3F8FHM1UVtkh/NcLAxOs8n+PFLnVAR+7GI5b5lV7uHOgjHKg8sOkM/x XLVrieVMZfq8wIv2UMQhYZYxu6kRH9IyoNf2eItGfoBYra79rQgGu8zXBo32I919 p8EwIqwzqUxQnJm8VDCHgbKvmns3eIhx7pJYqpJF7NLe7ToLLhZ1Z9LVLsZjK+V/ yJ6NjHJuZ8SZwlFPPE7eWOWqw3zpYlUoZzKNEkZEz8piSLCHgydgw7eR4646aUi9 IxtAS7R6meNs9St9rrpRvIJuvvJjtHEdJNDTEEGghhMl7NI0zZQItJoL0zJe2Hq0 pZ2d/qKQKgrRijMnrAf8xPAKOsPFQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrledugdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeetfeelffejfffhheehfeefgedulefgueejudekieegvdeghefffedvheffieel keenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 43784328005A; Tue, 12 May 2020 03:15:54 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <25F32505CBC1C1AF2841AF9A@PSB> Date: Tue, 12 May 2020 17:15:43 +1000 Cc: Brian E Carpenter , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 07:16:00 -0000 Hi John, > On 12 May 2020, at 5:03 pm, John C Klensin wrote: >=20 > Mark, I fear that takes us around in a bit of a circle, albeit > an important one. I was forcefully educated (one might say > "beaten up") some years ago by an Archivist (his job title) > associated with a national repository library in the north of > Europe. He explained that it was very hard to have a > conversation about what was "archival" or about the meaning of > the closely-related term "permanent" with people in computer > fields (especially web-related ones) because we tended to think > of "permanence" as 10 - 20 years. He claimed that most people > he had encountered from North America or the South Pacific had > similar problems with believing permanence, in practice, could > be considered a few centuries but that he and his colleagues > needed to work in terms of at least several millennia and that > those differences put an entirely different spin on things. This does not shock me, but then I've interned in an art museum, where = the challenges of conservatorship were painfully obvious. > That story is important in the current context for two reasons: >=20 > * While I consider the decision made and hence not part of the > current RFC Editor Futures discussion (even though I, and > apparently others, have growing doubts about how we are > implementing it), a conversation with almost any (I don't know > of exceptions, but maybe there are some) professional archivist > about treating a source format that requires considerable > compilation and reference to external sources and mechanisms to > get to a form people are comfortable reading as an archival form > will typically be greeted with laughter and/or comments to the > effect that we should come back in a hundred years and show them > that XML is still around and that it is the same, or at least > completely backward-compatible, XML. If they, and their > considerations, are to be taken seriously as we talk about > "archival", things are broken already and comments about the > merits of continuing to dig when one finds oneself in a deep > hole may be relevant. I tend to agree; if I'd been more involved in the IETF when this = decision was made, I would have fought it (based upon my early = experiences with XML, more than anything). > * There have been several discussions in recent years about > treating IETF specifications as living documents or with some > other arrangement in which issues are folded in as soon as they > are detected and at least tentative conclusions reached about > how to proceed. I don't know whether we need to resolve those > proposals before moving forward with discussions about the > future of the RFC Series and its management and organization (I > hope we don't because the community seems quite divided to me). > However, I think we need to understand that moving in that > direction, even if we make periodic snapshots and publish them > as RFCs, would profoundly change the character of the series as > providing a clearly-identifiable (and "archival") record of the > evolution of Internet technology and standards. I think that people are becoming slightly absolutist when they talk = about this subject, but worse, they perceive those on "the other side" = as *really* absolutist. I hope no one seriously thinks that "archival" means that we can't = change _any_ aspect of the series, ever -- that it's a machine that must = run on in its current form until its doom. I also hope that no one = thinks that changing things means that it must be possible to change any = character / bit in any RFC at any time. If we can put those extremes safely out of the way and focus on what the = needs of the archival and other communities are, we might make some = progress.=20 Maybe we could give some guidance here, but I agree we do have some = other issues to dispose of first. >> ... >>> =E2=80=A2 The RFC Series is community property and must operate = on >>> behalf of the community as a whole. >>>=20 >>> =E2=80=A2 The exact definition of the relevant community = is open >>> for debate. One definition is: the IETF, the IRTF, the = IAB >>> and the many other people who have contributed to, or = made >>> use of, the RFC Series over the last fifty years. >>>=20 >>> =E2=80=A2 Major decisions about the future of the RFC Series = must >>> be taken by a rough consensus of this very broad community. >>>=20 >>> =E2=80=A2 How to reach out to this community and judge = its >>> consensus is in itself a big question. >>=20 >> I think it's widely agreed that your conclusions about the >> series not being 'owned' by any of the I* are correct. >> However, I'd suggest that we can reach out to and judge >> consensus of that community just like we do in any other area >> -- establish a venue (e.g., a WG) and make it known that if >> you're a stakeholder who's interested, that's the appropriate >> place to contribute. Doubtless some people will not choose to >> come, but that's their choice. Others might advocate on their >> behalf; we already see that with civil society organisations >> being involved in the IETF's work. >=20 > One problem is that one important audience for the Series, or at > least the documents we claim are standards (or to which assorted > parties claim conformance) are people writing procurement > documents (RFPs, contracts, SLAs, etc.). The odds that we will > get a reliable representation from that community even if we > could reach them are, I think, pretty small. The odds that we > could get them to participate in a WG-like arrangement? > Probably much lower. But, at least if one were to assume a free > market in which alternatives exist, those people are key to > determine if our standards go anywhere. Indeed, when they write > contracts that require conformance and try to enforce them, they > are actually the closest we get to actually having a Protocol > Police. And, by the way, they, and the kinds of documents they > are willing to work with, interact with the "living document" > ideas as well: IMO at least, we dare not ignore them because we > cannot get their participation on our normal terms. Thank you; this is exactly how things sit already in many WGs, e.g., = HTTP. The decisions we make impact many people who don't even know we = exist on a daily basis. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue May 12 05:53: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 052123A089C for ; Tue, 12 May 2020 05:53: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 mb3exi6r10yX for ; Tue, 12 May 2020 05:53:02 -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 B67DD3A0899 for ; Tue, 12 May 2020 05:53:01 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jYUP0-000LgC-Vz; Tue, 12 May 2020 08:52:54 -0400 Date: Tue, 12 May 2020 08:52:48 -0400 From: John C Klensin To: Stephen Farrell , Mark Nottingham , Brian E Carpenter cc: rfced-future@iab.org Message-ID: In-Reply-To: <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> 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] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 12:53:03 -0000 --On Tuesday, May 12, 2020 03:41 +0100 Stephen Farrell wrote: > IIUC, you may be reacting to: > > "The RFC Series Editor is an independent professional > editor, serving a much wider community than just the > IETF. Given the economic and social importance of the > Internet, this is a serious responsibility, comparable > to the editorship of a major newspaper of record." > > FWIW, I also figure I separately disagree with Brian's > NYT/WaPo "editor" concept - while that does seem attractive > for someone (like me) who adolesced in the post-Watergate > era, I'm very struck by a recent COVID-19 survey here in > Ireland that found that <2% got real news from print > newspapers, so the newspapers of record are also changing. > The "winning" 36% source btw was the public TV broadcaster, > and while the online equivalents of incumbent print > newspapers did figure a lot, weird Internet sources didn't > feature much. The example I have used on a few occasions and which I like better after thinking about the above would be the publisher staff member or executive responsible for one or more substantive and well-recognized professional scientific or technical journals. Both traditional for-profit scientific and technical publications would count, but so would senior editorial staff for journals of record from major professional societies as would those responsible for publications strategy and style at major standards bodies. And, borrowing your words, weird Internet sources don't count. That change would pick up something else, which is the need to work with and adapt to some very specialized subject matter vocabulary. In the case of both a definition along those lines and Brian's, I home we could move forward without precise definitions of terms like "major", "substantive", "well-recognized", etc. All, in all cases, there is a difference between responsibility for strategy and spending one's days with the possibly-virtual equivalent of a blue pencil. john From nobody Tue May 12 06: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 D5E703A08C9 for ; Tue, 12 May 2020 06:00:48 -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 cAdqzrgNSLgu for ; Tue, 12 May 2020 06:00:47 -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 0AD7B3A08C5 for ; Tue, 12 May 2020 06:00:45 -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 04CD0ipc006631 for ; Tue, 12 May 2020 14:00:44 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C123122044 for ; Tue, 12 May 2020 14:00:43 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id ABDDA22042 for ; Tue, 12 May 2020 14:00:43 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04CD0g72006632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 12 May 2020 14:00:43 +0100 Reply-To: From: "Adrian Farrel" To: References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> In-Reply-To: Date: Tue, 12 May 2020 14:00:42 +0100 Organization: Old Dog Consulting Message-ID: <023601d6285d$587bdb70$09739250$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIXd1lDfRLMUyCB5gsDzs94bJ6JOwGEMjC/AkGllpkB77/TMgK8IeqVp948U+A= X-Originating-IP: 84.93.26.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25414.006 X-TM-AS-Result: No--9.354-10.0-31-10 X-imss-scan-details: No--9.354-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25414.006 X-TMASE-Result: 10--9.354000-10.000000 X-TMASE-MatchedRID: Ync95tbzDRlor4mPA3EMtnFPUrVDm6jtP9lbOpiWOGagR0A8JazWe01o NpRtMImzvPMVjcfoyDEll1O8R78W1kjDa/GHVs1n7hxHV9Y5rKCo/+BPLond/r/SxMC6n4L4GD1 tPZth2FmJbnWiPQEtzwAn1sW4ctwC1xQ2OgXti5XZulfZck3CobfHCp+e+coeUmrBgJDUGKwkwl cMmOSp1IzJZ0bwy7lwj1sd/ENaiJvZTCXiB8pF0nuIhJWJ5u1hicLx7t2B7IgjQVhmUJBUfEQBD VDzvZj1zogSaVJZzALh69ASiCwEPPJrU+I+8hTATPsVRSNcbWOaUZn+wI/0DC6tRzC7Nk0Tcx7M sdO4uhdRMT949JbJET6cNVhFYCc05dzmTP+HdQz0hv/rD7WVZKxT+JfQDbCPrw3oyQjKFq4R2+S 3PSIAYt+wcRTj7GJhpKtzbC0E7ug15JWIYrm8OG0WRq7KHlv4ElLH7tCb90pXXbZeMl1WD+cMSM soUYnjWA4l9bcBHhirPWUblX1Hye6Qlt5x1Dh7OctXWsNe0qWjISEe13lmJT8SRTV9+ShP0DIXT 3Gx4wU+BSIXDizg4F9Uw62BNvyfCXUTYBf5b3siMpIfyuUBO8tEPnVvPlFkRa6o/VMx/cdW07Sa RvTAQVNiBYQg19urN6Ek0bBNb/HbywJqSteCbFBSWz5Zgb/DgMLeOhIhBoQjRiu1AuxJTOQSCMu 2pzo2Sv/VDo+hq2ClugrXm5IKcMNOo16VCf1yx/Stmah0FpZ9LQinZ4QefL6qvLNjDYTwC+Cmxf KmwAwMyrfP9j+C1d934/rDAK3zUpXqgxV1N6n17fnh0wUN008EDQpctTkknd3SdtdZGp8ovtMA6 6WdG4q51qUPNGWPftwZ3X11IV0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 13:00:49 -0000 FWIW, I don't like the "comparable to" formulation in any way because it brings accidental baggage with it. A newspaper editor sets direction for the content, decides what will and won't be published, hires and fires writers. Let's simply not go there. Describe the job for what it is, not for how it compares or doesn't compare with other jobs. Adrian -----Original Message----- From: Rfced-future On Behalf Of John C Klensin Sent: 12 May 2020 13:53 To: Stephen Farrell ; Mark Nottingham ; Brian E Carpenter Cc: rfced-future@iab.org Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt --On Tuesday, May 12, 2020 03:41 +0100 Stephen Farrell wrote: > IIUC, you may be reacting to: > > "The RFC Series Editor is an independent professional > editor, serving a much wider community than just the > IETF. Given the economic and social importance of the > Internet, this is a serious responsibility, comparable > to the editorship of a major newspaper of record." > > FWIW, I also figure I separately disagree with Brian's > NYT/WaPo "editor" concept - while that does seem attractive > for someone (like me) who adolesced in the post-Watergate > era, I'm very struck by a recent COVID-19 survey here in > Ireland that found that <2% got real news from print > newspapers, so the newspapers of record are also changing. > The "winning" 36% source btw was the public TV broadcaster, > and while the online equivalents of incumbent print > newspapers did figure a lot, weird Internet sources didn't > feature much. The example I have used on a few occasions and which I like better after thinking about the above would be the publisher staff member or executive responsible for one or more substantive and well-recognized professional scientific or technical journals. Both traditional for-profit scientific and technical publications would count, but so would senior editorial staff for journals of record from major professional societies as would those responsible for publications strategy and style at major standards bodies. And, borrowing your words, weird Internet sources don't count. That change would pick up something else, which is the need to work with and adapt to some very specialized subject matter vocabulary. In the case of both a definition along those lines and Brian's, I home we could move forward without precise definitions of terms like "major", "substantive", "well-recognized", etc. All, in all cases, there is a difference between responsibility for strategy and spending one's days with the possibly-virtual equivalent of a blue pencil. john -- Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue May 12 07:24: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 9C51C3A0B1A for ; Tue, 12 May 2020 07:24:32 -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 0zCyxmYxLPH9 for ; Tue, 12 May 2020 07:24:31 -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 E5CD33A0AF3 for ; Tue, 12 May 2020 07:24:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jYVpa-000M2B-WE; Tue, 12 May 2020 10:24:27 -0400 Date: Tue, 12 May 2020 10:24:21 -0400 From: John C Klensin To: adrian@olddog.co.uk, rfced-future@iab.org Message-ID: In-Reply-To: <023601d6285d$587bdb70$09739250$@olddog.co.uk> References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 14:24:33 -0000 Adrian, I actually agree. However, I cannot speak to Brian's intent, but I was trying to get at a skill set or desiderata for the position, not to make a comparison. From that perspective this position is, IMO, very much not like a newspaper editor (for the reasons you cite) and much more like the skills and experience required to effectively perform a publications strategy role for a technical publisher. Drawing further on your newspaper editor comment, I think we are looking for someone who has a significant professional role (even if not a unilateral one) in setting criteria for what is acceptable for publication but not for making decisions about individual drafts. thanks for your clarification. john --On Tuesday, May 12, 2020 14:00 +0100 Adrian Farrel wrote: > FWIW, I don't like the "comparable to" formulation in any way > because it brings accidental baggage with it. > A newspaper editor sets direction for the content, decides > what will and won't be published, hires and fires writers. > > Let's simply not go there. > > Describe the job for what it is, not for how it compares or > doesn't compare with other jobs. > > Adrian > > -----Original Message----- > From: Rfced-future On Behalf Of > John C Klensin > Sent: 12 May 2020 13:53 > To: Stephen Farrell ; Mark > Nottingham ; Brian E Carpenter > Cc: rfced-future@iab.org > Subject: Re: [Rfced-future] I-D Action: > draft-carpenter-rfc-principles-00.txt > > > > --On Tuesday, May 12, 2020 03:41 +0100 Stephen Farrell > wrote: > >> IIUC, you may be reacting to: >> >> "The RFC Series Editor is an independent professional >> editor, serving a much wider community than just the >> IETF. Given the economic and social importance of the >> Internet, this is a serious responsibility, comparable >> to the editorship of a major newspaper of record." >> >> FWIW, I also figure I separately disagree with Brian's >> NYT/WaPo "editor" concept - while that does seem attractive >> for someone (like me) who adolesced in the post-Watergate >> era, I'm very struck by a recent COVID-19 survey here in >> Ireland that found that <2% got real news from print >> newspapers, so the newspapers of record are also changing. >> The "winning" 36% source btw was the public TV broadcaster, >> and while the online equivalents of incumbent print >> newspapers did figure a lot, weird Internet sources didn't >> feature much. > > The example I have used on a few occasions and which I like > better after thinking about the above would be the publisher > staff member or executive responsible for one or more > substantive and well-recognized professional scientific or > technical journals. Both traditional for-profit scientific and > technical publications would count, but so would senior > editorial staff for journals of record from major professional > societies as would those responsible for publications strategy > and style at major standards bodies. And, borrowing your > words, weird Internet sources don't count. That change would > pick up something else, which is the need to work with and > adapt to some very specialized subject matter vocabulary. > > In the case of both a definition along those lines and Brian's, > I home we could move forward without precise definitions of > terms like "major", "substantive", "well-recognized", etc. > All, in all cases, there is a difference between > responsibility for strategy and spending one's days with the > possibly-virtual equivalent of a blue pencil. > > john > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue May 12 10:55: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 CBD933A086A for ; Tue, 12 May 2020 10:55: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9FlkOKhnYO0M for ; Tue, 12 May 2020 10:55:36 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 4D6F03A085B for ; Tue, 12 May 2020 10:55:36 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id n14so14565621qke.8 for ; Tue, 12 May 2020 10:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=7ahX1focFJLi0YhyfrYT6sHjVD8gAgB96FWwjn4jWbg=; b=digLdP4t/HX0wRy/+rsrFIlOaNsICXxtia823PUmzSN7wgUZ4boD5jg88JEZI4Z1mA SkQPMqVWfVfHx9tXc9lTmx9roZUtpovFstHqSgDXA7+mKMxpRaLSW5dkb5eiirZgkcEl n6znS/Cx2cvqhSalcIRrzUZqbqe1F4/6ptMUlHZDld3qfUyLnldWVtTCZ3gi2cB9w4j7 vE9l7LkuhiN2WIxK3rwY0WrzwNw52OY1q5yekSkrbtXHkL9WSAcnqfNSRwHHoZih62QQ NamcXvDqwXlL1T0/WFtcYhRtqzUQ6CG4GQ+vQPnvhwRIaQtMiN9LKWhail+YZ3IW4qiV leBQ== 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=7ahX1focFJLi0YhyfrYT6sHjVD8gAgB96FWwjn4jWbg=; b=DNkQblIBa5LPJFyFmSid9WtTyqJh3IZOhPkV0DcvZvhatfb1ZdKiK7TRTalPyufGb+ TrTqyxqgZmHO+T37SsJYE9VCEbGQhpB+OrzpMJpBEtJFYI+OSAPzIWbVMTjZX2i9OLrj vdunooUMzBxGZJuIO0YOA2udodSwQw4H1tMGz99TW1OW5q+BDtU9dEar1npoKb4hnJJi ZD4u0Hmj05WS2WJq+62k/jpirlOUemq475NAguhOQ5qKS2NYmgJqhSy4DswuOC7ovVD4 8rM2qwHzT2nRZ1wkNn/nZWMfFtTGxci2vb4CtRwXRbxFuJnjzhI4SMCQI9VposHSR6hZ 7tEg== X-Gm-Message-State: AGi0PubypRrQeMhBObEQAhBX1nWI386fu8dekE3ptEiKrc7xzqbRz5J7 M7XUCdImKJEXYcTfwYE6llYS08zfCrKfvg== X-Google-Smtp-Source: APiQypJ4+t9ktvBxzNyfFUHDrmkr/8s3wp8+bPCt/CcWFW4E+8e93byugT3skEIAeSgskdGOjge1iA== X-Received: by 2002:a37:5846:: with SMTP id m67mr20013834qkb.78.1589306134859; Tue, 12 May 2020 10:55:34 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id h188sm11758810qke.82.2020.05.12.10.55.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 10:55:34 -0700 (PDT) To: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> From: Michael StJohns Message-ID: Date: Tue, 12 May 2020 13:55:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <023601d6285d$587bdb70$09739250$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 17:55:38 -0000 On 5/12/2020 9:00 AM, Adrian Farrel wrote: > FWIW, I don't like the "comparable to" formulation in any way because it > brings accidental baggage with it. > A newspaper editor sets direction for the content, decides what will and > won't be published, hires and fires writers. > > Let's simply not go there. > > Describe the job for what it is, not for how it compares or doesn't compare > with other jobs. Let me slide sideways a little bit and suggest that those models are useful places to dig for ideas, rather than just being taken up in their entirety. For example, most publication entities have a bifurcated (not - NOT matrix) management structure:  the business side and the editorial side.  At the top on the business side is usually a board of directors of the corporation.  They tend to approve/hire the publisher.  On the other side at the top is generally the editor in chief usually advised, assisted, collaborative with or responsible to an editorial board.  In some instances, the publisher is also the editor in chief.   The business side deals with circulation, advertising, and the process of bringing the material to print (printing/distribution).  The editorial side deals with content, format and generally look and feel. None of these are independent in a completely unrestrained way, but each does have substantial independence within their own wheel house.   I think Brian's (and for that matter my) view of an appropriate independence model is that we hire the best person we can, and leave them alone to do the job.   We look for competence and then we honor it.    The existing model somehow lost track of that. Mark (in another email) is correct that the level of independence of the current RSE is not the same as in the past - but I consider that a bug rather than a feature as it means that its possible for a small subset of the IETF community to affect the culture of the RFC series in ways that may not represent the interests of the broader community. Later, Mike > Adrian > > -----Original Message----- > From: Rfced-future On Behalf Of John C > Klensin > Sent: 12 May 2020 13:53 > To: Stephen Farrell ; Mark Nottingham > ; Brian E Carpenter > Cc: rfced-future@iab.org > Subject: Re: [Rfced-future] I-D Action: > draft-carpenter-rfc-principles-00.txt > > > > --On Tuesday, May 12, 2020 03:41 +0100 Stephen Farrell > wrote: > >> IIUC, you may be reacting to: >> >> "The RFC Series Editor is an independent professional >> editor, serving a much wider community than just the >> IETF. Given the economic and social importance of the >> Internet, this is a serious responsibility, comparable >> to the editorship of a major newspaper of record." >> >> FWIW, I also figure I separately disagree with Brian's >> NYT/WaPo "editor" concept - while that does seem attractive >> for someone (like me) who adolesced in the post-Watergate >> era, I'm very struck by a recent COVID-19 survey here in >> Ireland that found that <2% got real news from print >> newspapers, so the newspapers of record are also changing. >> The "winning" 36% source btw was the public TV broadcaster, >> and while the online equivalents of incumbent print >> newspapers did figure a lot, weird Internet sources didn't >> feature much. > The example I have used on a few occasions and which I like > better after thinking about the above would be the publisher > staff member or executive responsible for one or more > substantive and well-recognized professional scientific or > technical journals. Both traditional for-profit scientific and > technical publications would count, but so would senior > editorial staff for journals of record from major professional > societies as would those responsible for publications strategy > and style at major standards bodies. And, borrowing your words, > weird Internet sources don't count. That change would pick up > something else, which is the need to work with and adapt to some > very specialized subject matter vocabulary. > > In the case of both a definition along those lines and Brian's, > I home we could move forward without precise definitions of > terms like "major", "substantive", "well-recognized", etc. All, > in all cases, there is a difference between responsibility for > strategy and spending one's days with the possibly-virtual > equivalent of a blue pencil. > > john > From nobody Tue May 12 13:17: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 19C803A0AD0 for ; Tue, 12 May 2020 13:16:57 -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 clg6gLJiAu97 for ; Tue, 12 May 2020 13:16:55 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CFB03A0AAA for ; Tue, 12 May 2020 13:16:55 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id c21so7056079lfb.3 for ; Tue, 12 May 2020 13:16: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=bXnS9oAPYhPukt3h459lLr3TlPFUZBszmSnSUCFvsdo=; b=vo7LDtIFefDpW9eSABAZ0koN07ceJmNKh2oFu4QgIYTHlcrLj8zgU2FYbflQU0ypXM bnZ65/wwvN3Wn7/I69un807DJLod0wJGfsoA2HW8m7zqg/NozIPclBLODjTh6bESPJU6 WkUIQWjNEjyDlXJ+bnjtJbaMlcg0hDOoo6+hyG6MLkRHOXnT/eq3Qg7roPl0ez6Bnkeo wpbbTvXZZJiSi4nruaDJotNyFdNnGQbitgFMSsrUdjOD3DqY/wO6naYCrOyFPrksHUAQ EuZVuBMYe1KtYgWgr3H6WL3bXxCVfo+FYloXJaB3eoauT7MEjdhOr75oH97XUmzfXwIR yoYg== 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=bXnS9oAPYhPukt3h459lLr3TlPFUZBszmSnSUCFvsdo=; b=MQngBgDY1nE/Yp+dPtu+tuuTZItwF5phuHXyUThZk4LiTRqp2XJXZPyG7pbSRnTGab 2jSxCD/bCKcosvLWc/Bp6aNPFVb6Oda9hEddlGRD5MC9fmx/WANDXxkhVWMCSZUYbn6S EeNb172oX4Lt7sQ2fbaMHOru1pFftPkSQOdBQBSpC3hyZJ7qQ/jWNH4FzW70220Yu03I jslKhIquZrpQpR5+zK7x+KJMDfbduxzRPcUXDlMBv8Kuc3y22WvlbWKxf29GdxKDO6to cZ8TVWhiK6XEGlSrKF8P5cmycDw61GW2hSS0gbGkmy0G6HkYnZYOtQUWQoXLdov/JCdJ S7UQ== X-Gm-Message-State: AOAM531GHX06ID1dZ1hPLtWKkwMyQPzX8JJeH40eAz7gc2NwRoeEAQK1 M7gFHjLbgV16FfXgq9mP+xvqIk/tU9f9qqviLzpRXamaElZoew== X-Google-Smtp-Source: ABdhPJxIeROB9L8zEtHIvY6RWfCG9qz13QjyAt+GwBh+jVDQ2ySkXVYag90DgmBJu0ilE5hAAfuEwrNQcw7f0w8vTnQ= X-Received: by 2002:a19:8d3:: with SMTP id 202mr15597253lfi.201.1589314613395; Tue, 12 May 2020 13:16:53 -0700 (PDT) MIME-Version: 1.0 References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> In-Reply-To: From: Eric Rescorla Date: Tue, 12 May 2020 13:16:17 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000f7dafb05a57924ed" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:17:03 -0000 --000000000000f7dafb05a57924ed Content-Type: text/plain; charset="UTF-8" In Tue, May 12, 2020 at 10:55 AM Michael StJohns wrote: > Mark (in another email) is correct that the level of independence of the > current RSE is not the same as in the past - but I consider that a bug > rather than a feature as it means that its possible for a small subset > of the IETF community to affect the culture of the RFC series in ways > that may not represent the interests of the broader community. I want to zero in on this point, because I think it's useful to scope out people's views of "independence". Let me try to start with what's hopefully a simple case: suppose that the IETF produces and the IESG approves a document to be published as RFC that the RSE believes is harmful to the Internet for technical reasons (it redefines IPv6 to have an 8 bit address, say). Do you believe that the RSE should be able to refuse to publish such a document? -Ekr --000000000000f7dafb05a57924ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In Tue, May 12, 2020 at 10:55 AM Michael StJohns <msj@nthpermutation.com> wrote:<= br>
> Mark (in another email) is correct = that the level of independence of the
> current RSE is not the same a= s in the past - but I consider that a bug
> rather than a feature as = it means that its possible for a small subset
> of the IETF community= to affect the culture of the RFC series in ways
> that may not repre= sent the interests of the broader community.

I want to zero in on th= is point, because I think it's useful to scope
out people's view= s of "independence".

Let me try to start with what's h= opefully a simple case: suppose
that the IETF produces and the IESG appr= oves a document to be
published as RFC that the RSE believes is harmful = to the Internet
for technical reasons (it redefines IPv6 to have an 8 bi= t address,
say). Do you believe that the RSE should be able to refuse to=
publish such a document?

-Ekr
--000000000000f7dafb05a57924ed-- From nobody Tue May 12 13:25: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 678B53A0AA1 for ; Tue, 12 May 2020 13:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEt8qGGX8N-q for ; Tue, 12 May 2020 13:25:18 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 6FFE03A0AA7 for ; Tue, 12 May 2020 13:25:18 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id z9so5000250qvi.12 for ; Tue, 12 May 2020 13:25:18 -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=uy0dOh9bSdZqPOvVLvVP1MGw/I6rqfma6bER2P30+SQ=; b=FC4B7Dv2NMrimV+QUm2tBS+TKF+p9YKaU+gBFC4AkzODyf/ttS0FFSL5TdIcURPnBr MACxXzJI29cRvmYAhDhh63v9IsUk5u/GrdxJQb5K4k4ffV/CyWtWTvxEnRWI2tvFDs8D yUBKAVMYbVM0SD5k8OljktARrdwPrZ302RjhAuTuHg2D60jKydqN/kOUyMMU74JJnoR/ HZGpplTiD5GJPYdLKVOQgoQY2EC5hCDXgW3LApEkknxWYqiViJbLK69F3sSpYjdUbORq 6cXTgPL+hZthRNc953LKGtTPl5/Uhu2nEK4jR6X83V8nJHiIxMxdUrS7g0es0irY+lp7 8I7A== 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=uy0dOh9bSdZqPOvVLvVP1MGw/I6rqfma6bER2P30+SQ=; b=PQwWN8jQuq82OQMzNxVHdVRsrpwnvNDTzUYe3fTlX5xnPZxmeWpn8FmWJRlxbqfl5/ A9EPu+xo6K2PzRcnlYvn2Pv1MzKg77Xld6Bhr8PMpssEI255tjNEqPFzHLMPx/K5Ma7A UhKug2Ll9LRReNvXn5SRxcgNTf6KDlhhsROv/Qf33e3yBsRsD94JGRPtluzbm3Smc3mY YG2cfdVhVh6szVrm7QtEFH9O30xvJVilCxe9ZPL0KqiNba7SMbnIFg6Gbd7acIlOUxEh WzMTLsr0acM0rTUg512HKYnwhrvej/++rXjvwsN73oaG4/ox9+clJl9zr4FnWs2wiCJ6 AiSQ== X-Gm-Message-State: AGi0Pubm+J96XoZacr/RSxgYCtDbelTD7y+fdG/b53r3lPtH12Uj/kl7 uQE0CNJRiYrk2ZcD8p1YKrLMsDAN2d9KLA== X-Google-Smtp-Source: APiQypLH5YYaneQ5DmjqILhVBAUAUBfdAnAialWyH37EKeoRobtidkMURBUwnasO4pf7VZzlTe/U2w== X-Received: by 2002:a05:6214:146b:: with SMTP id c11mr22043853qvy.191.1589315116907; Tue, 12 May 2020 13:25:16 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id d50sm6481210qtb.13.2020.05.12.13.25.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 13:25:16 -0700 (PDT) To: Eric Rescorla Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> From: Michael StJohns Message-ID: <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> Date: Tue, 12 May 2020 16:25:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------54067C40EB59F38862880E2E" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:25:20 -0000 This is a multi-part message in MIME format. --------------54067C40EB59F38862880E2E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/12/2020 4:16 PM, Eric Rescorla wrote: > In Tue, May 12, 2020 at 10:55 AM Michael StJohns > > wrote: > > Mark (in another email) is correct that the level of independence of the > > current RSE is not the same as in the past - but I consider that a bug > > rather than a feature as it means that its possible for a small subset > > of the IETF community to affect the culture of the RFC series in ways > > that may not represent the interests of the broader community. > > I want to zero in on this point, because I think it's useful to scope > out people's views of "independence". > > Let me try to start with what's hopefully a simple case: suppose > that the IETF produces and the IESG approves a document to be > published as RFC that the RSE believes is harmful to the Internet > for technical reasons (it redefines IPv6 to have an 8 bit address, > say). Do you believe that the RSE should be able to refuse to > publish such a document? > > -Ekr Oooh   tricky.   I'd either have the RSE refer it to the ISE as publication as an April Fool's RFC, or I'd probably be the first to sign on to a petition to recall the entire IESG.     In any case, the answer is probably yes, the RSE should refuse to publish the document as an Internet standard.   That assumes that the RSE - with the appropriate technical advisors - has the skillset to determine said document is "harmful to the Internet". Mike --------------54067C40EB59F38862880E2E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/12/2020 4:16 PM, Eric Rescorla wrote:
In Tue, May 12, 2020 at 10:55 AM Michael StJohns <msj@nthpermutation.com> wrote:
> Mark (in another email) is correct that the level of independence of the
> current RSE is not the same as in the past - but I consider that a bug
> rather than a feature as it means that its possible for a small subset
> of the IETF community to affect the culture of the RFC series in ways
> that may not represent the interests of the broader community.

I want to zero in on this point, because I think it's useful to scope
out people's views of "independence".

Let me try to start with what's hopefully a simple case: suppose
that the IETF produces and the IESG approves a document to be
published as RFC that the RSE believes is harmful to the Internet
for technical reasons (it redefines IPv6 to have an 8 bit address,
say). Do you believe that the RSE should be able to refuse to
publish such a document?

-Ekr

Oooh   tricky.   I'd either have the RSE refer it to the ISE as publication as an April Fool's RFC, or I'd probably be the first to sign on to a petition to recall the entire IESG.     In any case, the answer is probably yes, the RSE should refuse to publish the document as an Internet standard.   That assumes that the RSE - with the appropriate technical advisors - has the skillset to determine said document is "harmful to the Internet".

Mike


--------------54067C40EB59F38862880E2E-- From nobody Tue May 12 13:30: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 86B7E3A0BD5 for ; Tue, 12 May 2020 13:30:10 -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 DRfnHdnrkvOv; Tue, 12 May 2020 13:30:09 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 84F403A0B17; Tue, 12 May 2020 13:30:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Jay Daley In-Reply-To: <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> Date: Wed, 13 May 2020 08:29:59 +1200 Cc: Eric Rescorla , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:30:11 -0000 > On 13/05/2020, at 8:25 AM, Michael StJohns = wrote: >=20 > On 5/12/2020 4:16 PM, Eric Rescorla wrote: >> In Tue, May 12, 2020 at 10:55 AM Michael StJohns = wrote: >> > Mark (in another email) is correct that the level of independence = of the >> > current RSE is not the same as in the past - but I consider that a = bug >> > rather than a feature as it means that its possible for a small = subset >> > of the IETF community to affect the culture of the RFC series in = ways >> > that may not represent the interests of the broader community. >>=20 >> I want to zero in on this point, because I think it's useful to scope >> out people's views of "independence". >>=20 >> Let me try to start with what's hopefully a simple case: suppose >> that the IETF produces and the IESG approves a document to be >> published as RFC that the RSE believes is harmful to the Internet >> for technical reasons (it redefines IPv6 to have an 8 bit address, >> say). Do you believe that the RSE should be able to refuse to >> publish such a document? >>=20 >> -Ekr=20 > Oooh tricky. I'd either have the RSE refer it to the ISE as = publication as an April Fool's RFC, or I'd probably be the first to sign = on to a petition to recall the entire IESG. In any case, the answer = is probably yes, the RSE should refuse to publish the document as = an Internet standard. That assumes that the RSE - with the appropriate = technical advisors >=20 Isn't the IETF consensus by definition the appropriate technical = advisors to the RSE or are you suggesting a separate and parallel = structure that the RSE controls that all IETF consensus documents need = to pass through? Jay > - has the skillset to determine said document is "harmful to the = Internet". >=20 > Mike >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Tue May 12 13:30: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 7244D3A0C1B for ; Tue, 12 May 2020 13:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bQ6k7Br9P1xW for ; Tue, 12 May 2020 13:30:20 -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 CBAD23A0C66 for ; Tue, 12 May 2020 13:30:06 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jYbXQ-000MmL-Lr; Tue, 12 May 2020 16:30:04 -0400 Date: Tue, 12 May 2020 16:29:58 -0400 From: John C Klensin To: Michael StJohns , rfced-future@iab.org Message-ID: <25FCBC5C031FCB6206268709@PSB> In-Reply-To: References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> 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] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:30:26 -0000 --On Tuesday, May 12, 2020 13:55 -0400 Michael StJohns wrote: >... > None of these are independent in a completely unrestrained > way, but each does have substantial independence within their > own wheel house.=C2=A0=C2=A0 I think Brian's (and for that = matter my) > view of an appropriate independence model is that we hire the > best person we can, and leave them alone to do the = job.=C2=A0=C2=A0 We > look for competence and then we honor it.=C2=A0=C2=A0=C2=A0 = The existing > model somehow lost track of that. Agreed -- both the "best person" part and the existing model (or at least it interpretation and implementation in the last couple of years) having lost that. > Mark (in another email) is correct that the level of > independence of the current RSE is not the same as in the past > - but I consider that a bug rather than a feature as it means > that its possible for a small subset of the IETF community to > affect the culture of the RFC series in ways that may not > represent the interests of the broader community. While I agree, I don't think it would be wise to go all the way back. I think the notion of semi-independent streams was a good idea even though I sometimes think that we should have established a separate stream for the RFC Editor function itself (the IAB's having to sign off on things like style manuals and RFC Editor Function historical materials and perspectives may be one of the things that led to losing track of that independence). While I don't have any idea how often if was formally exercised (as distinct from, e.g., being turned into rather firm feedback), Jon clearly had the authority to reject documents presented for publication on grounds involving content). I think stream approval and the RFC Editor's being able to insist on a "published over objections" disclaimer (at least for the IETF Stream) is an improvement=20 The question is finding the right balance. What I'm fairly sure of is that the RSE needs much more independence and needs to be treated much more like a professional by the community (and any oversight or contracting bodies) than, to use an analogy I think I used in Montreal, a function that we can procure and swap out as we could probably procure supplies of barrels of nails. john From nobody Tue May 12 13:32: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 7119E3A0AB2 for ; Tue, 12 May 2020 13:32:29 -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 pv6Hk55b_Of3 for ; Tue, 12 May 2020 13:32:28 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 86A093A09D2 for ; Tue, 12 May 2020 13:32:27 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id g4so15243812ljl.2 for ; Tue, 12 May 2020 13:32:27 -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=N1mJvWqzKW6DXoay312bvelNqaSpvRH5gTutncy7KL0=; b=dbxND+JtaSdwfbfAWK6poOz2XDlCNsjsP8OuDya8DfdtNk0dGn6IJkYZUlDvKoBq/4 XaSaPqVErInb6m2ebBzUVWo7fYMJz+gPvoDRlyUlI7obmjR21WoI3X2unYmwOPfo0J0F jHQtfA136Nqc5AvHzs4v/udQV9EFVjewImACfxQCgWYN5czrMC1Y7Dmci+4beawpah59 bOa3COAfSbqyT33fnm6vZP4k3Gb8KLjfpDSYKnJmz9FdmRqQXfkZG5tWYIEIxPfFWkF7 G0nsMjaycAYjWKW9D5Tqq4BiIDFIcwe20KHSpzRNLme1Doteawzi7EYoSbQZVXRh1+hr 2HlQ== 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=N1mJvWqzKW6DXoay312bvelNqaSpvRH5gTutncy7KL0=; b=cZS8PIAroclaqUwDa37tsCHOdzyr1xcVZw1HhzvOKiqjJ3zPE06GRO/8vRho8nsClO D3TNnv2M5bH+ZimBivkuMBJv23HNgXfD7KlDbu/pvpcqSrHQoTanCCgtH1WubZn9Xc12 MpJbkxGA2L6a5LNjXK09Of6QppsfGLm8W2dr1KrTLp8sd/coEza/qa1m1BU5vzefaIcV 2C6zz97aebmqP9Bd0RYl1/h3mvcLN30rJBQgbvLfcTn1VKy8Wm1lfjRRnjXYw2PkaeK/ WVqK81SOVYmkJPylXTWOYPjIf09lSG2b+RqqptXyRDBeAE4HyCwmDhnxot9Y6jiUqrsq 2FMQ== X-Gm-Message-State: AOAM530dZpIgyB7CJ2kn0JbaJwRObyWMOKOiaVM7N917+1Ywsz7BDxTx kTr8g16qmKM47hPC+Nlb9aAanKDjCSdgb2Z9pe6d3Q== X-Google-Smtp-Source: ABdhPJyYkj0AkwFH5KFNG7R4HrvQDjfEXU8cTyZh/RMu7x7kOn39UqpTwt0ox0E2Y5Lx3VmI0m8IRNegN7vFUZYrvfs= X-Received: by 2002:a2e:87d3:: with SMTP id v19mr14113232ljj.176.1589315545280; Tue, 12 May 2020 13:32:25 -0700 (PDT) MIME-Version: 1.0 References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> In-Reply-To: <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> From: Eric Rescorla Date: Tue, 12 May 2020 13:31:49 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000083452905a5795c30" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:32:30 -0000 --00000000000083452905a5795c30 Content-Type: text/plain; charset="UTF-8" On Tue, May 12, 2020 at 1:25 PM Michael StJohns wrote: > On 5/12/2020 4:16 PM, Eric Rescorla wrote: > > In Tue, May 12, 2020 at 10:55 AM Michael StJohns > wrote: > > Mark (in another email) is correct that the level of independence of the > > current RSE is not the same as in the past - but I consider that a bug > > rather than a feature as it means that its possible for a small subset > > of the IETF community to affect the culture of the RFC series in ways > > that may not represent the interests of the broader community. > > I want to zero in on this point, because I think it's useful to scope > out people's views of "independence". > > Let me try to start with what's hopefully a simple case: suppose > that the IETF produces and the IESG approves a document to be > published as RFC that the RSE believes is harmful to the Internet > for technical reasons (it redefines IPv6 to have an 8 bit address, > say). Do you believe that the RSE should be able to refuse to > publish such a document? > > -Ekr > > Oooh tricky. I'd either have the RSE refer it to the ISE as > publication as an April Fool's RFC, or I'd probably be the first to sign on > to a petition to recall the entire IESG. In any case, the answer is > probably yes, the RSE should refuse to publish the document as an Internet > standard. That assumes that the RSE - with the appropriate technical > advisors - has the skillset to determine said document is "harmful to the > Internet". > Thanks for the quick answer. I'm thinking maybe I made this too easy in that such a document has a "is the IESG on drugs" kind of flavor where any sane person would probably think they should throw a flag on the play. But let's take a case where it's not a comically wrong decision but one that the RSE nevertheless strongly feels is harmful to the Internet. What then? -Ekr --00000000000083452905a5795c30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 12, 2020 at 1:25 PM Micha= el StJohns <= msj@nthpermutation.com> wrote:
=20 =20 =20
On 5/12/2020 4:16 PM, Eric Rescorla wrote:
=20
In Tue, May 12, 2020 at 10:55 AM Michael StJohns <msj= @nthpermutation.com> wrote:
> Mark (in another email) is correct that the level of independence of the
> current RSE is not the same as in the past - but I consider that a bug
> rather than a feature as it means that its possible for a small subset
> of the IETF community to affect the culture of the RFC series in ways
> that may not represent the interests of the broader community.

I want to zero in on this point, because I think it's usefu= l to scope
out people's views of "independence".

Let me try to start with what's hopefully a simple case: suppose
that the IETF produces and the IESG approves a document to be
published as RFC that the RSE believes is harmful to the Internet
for technical reasons (it redefines IPv6 to have an 8 bit address,
say). Do you believe that the RSE should be able to refuse to
publish such a document?

-Ekr

Oooh=C2=A0=C2=A0 tricky.=C2=A0=C2=A0 I'd either have the RSE ref= er it to the ISE as publication as an April Fool's RFC, or I'd probably be the fi= rst to sign on to a petition to recall the entire IESG.=C2=A0=C2=A0=C2=A0= =C2=A0 In any case, the answer is probably yes, the RSE should refuse to publish the document as an Internet standard.=C2=A0=C2=A0 That assumes that t= he RSE - with the appropriate technical advisors - has the skillset to determine said document is "harmful to the Internet".

Thanks for the quick answer.

I'm thinking maybe I made this too easy in that such a document has a= "is the IESG on drugs" kind of flavor where any sane person woul= d probably think they should throw a flag on the play.

<= /div>
But let's take a case where it's not a comically wrong de= cision but one that the RSE nevertheless strongly feels is harmful to the I= nternet. What then?

-Ekr

=

--00000000000083452905a5795c30-- From nobody Tue May 12 13:42: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 B73673A0ACB; Tue, 12 May 2020 13:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E1xU8pqfUD3; Tue, 12 May 2020 13:42:05 -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 967023A0AC7; Tue, 12 May 2020 13:42:03 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04CKg1ei028509; Tue, 12 May 2020 21:42:01 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 481272204A; Tue, 12 May 2020 21:42:01 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 3231B22048; Tue, 12 May 2020 21:42:01 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04CKfx6Z016847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 May 2020 21:42:00 +0100 Reply-To: From: "Adrian Farrel" To: "'Jay Daley'" , "'Michael StJohns'" Cc: , "'Eric Rescorla'" References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> In-Reply-To: Date: Tue, 12 May 2020 21:41:59 +0100 Organization: Old Dog Consulting Message-ID: <031901d6289d$c99af300$5cd0d900$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIXd1lDfRLMUyCB5gsDzs94bJ6JOwGEMjC/AkGllpkB77/TMgK8IeqVApdLMSwCgGpGkgFsEpYKAaqDk3YCUQoCBaeKwf6A X-Originating-IP: 84.93.26.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25416.002 X-TM-AS-Result: No--1.603-10.0-31-10 X-imss-scan-details: No--1.603-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25416.002 X-TMASE-Result: 10--1.603100-10.000000 X-TMASE-MatchedRID: VPleTT1nwdRor4mPA3EMtnFPUrVDm6jt69aS+7/zbj+qvcIF1TcLYL5/ 4tOWyf5GepQj42hSNcifKjlghujglx2mQZVcW1xa1a9nQumsfmoCC8zqHvcG2i81M7jus3iJtXe PrWsnB+zIw09GasHyZvyFCF8dAluiPsJbF6TG7RJuyDGIvvwW0kH25SKd6AXRmyiLZetSf8nJ4y 0wP1A6AGP1xUvrlhy1F8hs8W5tMc9q8/xv2Um1avoLR4+zsDTtrXT/QMyU2Nxs8jSs/7cYiq4O8 SXZcr2+pXY/+Y/qS3cVqwROH4K4Y67vkEy6CpyAWAEAxUq7Q2eeQjQ1t7doFcU2IPBAmHJxHNV7 5dfleKeHx/3593XRE+S+ZTuCPZ+tPifujgI13dqh071fQj6NysC+ksT6a9fy X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:42:07 -0000 Jay wrote: > Isn't the IETF consensus by definition the appropriate > technical advisors to the RSE or are you suggesting a > separate and parallel structure that the RSE controls > that all IETF consensus documents need to pass through? Not at all, Jay. The RSE listens to the stream heads for documents for publication. One of those stream heads gauges IETF consensus for most cases. I believe the RSE should be able to very strongly question publication, but not over-rule the stream heads. If the RSE noticed something that might be a ghastly mistake, I would expect them to mention it. That might not be a technical thing (unlikely that the RSE would be qualified) but might be socio-political. And I believe that the community has mechanisms to censure/recall each stream head. Thanks, Adrian From nobody Tue May 12 13:44: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 07DA03A0ACB; Tue, 12 May 2020 13:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeARdSrwU41U; Tue, 12 May 2020 13:44:22 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14FF3A0AD0; Tue, 12 May 2020 13:44:20 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04CKiJCJ000841; Tue, 12 May 2020 21:44:19 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EA4992203A; Tue, 12 May 2020 21:44:18 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id D53DC22032; Tue, 12 May 2020 21:44:18 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04CKiG3v003700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 May 2020 21:44:17 +0100 Reply-To: From: "Adrian Farrel" To: "'Jay Daley'" , "'Michael StJohns'" Cc: , "'Eric Rescorla'" References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> In-Reply-To: Date: Tue, 12 May 2020 21:44:16 +0100 Organization: Old Dog Consulting Message-ID: <031a01d6289e$1b8827a0$529876e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIXd1lDfRLMUyCB5gsDzs94bJ6JOwGEMjC/AkGllpkB77/TMgK8IeqVApdLMSwCgGpGkgFsEpYKAaqDk3YCUQoCBaeKwf6AgAACoqA= X-Originating-IP: 84.93.26.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25416.002 X-TM-AS-Result: No--7.051-10.0-31-10 X-imss-scan-details: No--7.051-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25416.002 X-TMASE-Result: 10--7.050600-10.000000 X-TMASE-MatchedRID: hls5oAVArl9or4mPA3EMtnFPUrVDm6jt+ccIIOk4Y47fUZT83lbkEH3c RMkBdaS2a1eAS4arM1SgE9yIKMOyFHx8EDQqTtoDbnNT+QUGvxwr6FuM5wm9HcxWo/NgqhfZ0Ec ky7DHFgz/J7/cdz0rWonep0HjTtt8kXeZrSSbPjLFW296Y1uTJ9sqfZFGDh7HsLigDA/FpvVU4a iNmCnrsonXHse/xd1l84g8SJFPtB1G2Se0pSNw0AUYKjHdPK7glNvc8oDChH+cbR0ET4MQTX01s 4Z8kE2B5F2cRfWsj9WRk6XtYogiarQ/aqQZTRfKBEAUhu52t8h/A75FGmxK1Sq2rl3dzGQ1Z1Hj Vg2WQoT8FVExRzWJEIgwidlnlvk6sjXmiBwj9G2tINpwI5OiX8C+ksT6a9fy X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:44:24 -0000 But, maybe, I should have added... Who defines the stream heads? Who creates new streams? Who closes existing streams? Adrian -----Original Message----- From: Adrian Farrel Sent: 12 May 2020 21:42 To: 'Jay Daley' ; 'Michael StJohns' Cc: 'rfced-future@iab.org' ; 'Eric Rescorla' Subject: RE: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt Jay wrote: > Isn't the IETF consensus by definition the appropriate > technical advisors to the RSE or are you suggesting a > separate and parallel structure that the RSE controls > that all IETF consensus documents need to pass through? Not at all, Jay. The RSE listens to the stream heads for documents for publication. One of those stream heads gauges IETF consensus for most cases. I believe the RSE should be able to very strongly question publication, but not over-rule the stream heads. If the RSE noticed something that might be a ghastly mistake, I would expect them to mention it. That might not be a technical thing (unlikely that the RSE would be qualified) but might be socio-political. And I believe that the community has mechanisms to censure/recall each stream head. Thanks, Adrian From nobody Tue May 12 13:45:17 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2702E3A0ADE for ; Tue, 12 May 2020 13:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jCbguV8G2yHB; Tue, 12 May 2020 13:45: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 3DF4F3A0AD0; Tue, 12 May 2020 13:45:13 -0700 (PDT) From: Jay Daley Message-Id: <308BC114-D9B3-4E4B-972C-AE17E6927578@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_E1B25A5A-D81A-458A-80E6-1C95056DDE0C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 13 May 2020 08:45:10 +1200 In-Reply-To: <031901d6289d$c99af300$5cd0d900$@olddog.co.uk> Cc: Michael StJohns , rfced-future@iab.org, Eric Rescorla To: adrian@olddog.co.uk References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <031901d6289d$c99af300$5cd0d900$@olddog.co.uk> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:45:16 -0000 --Apple-Mail=_E1B25A5A-D81A-458A-80E6-1C95056DDE0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13/05/2020, at 8:41 AM, Adrian Farrel wrote: >=20 > Jay wrote: >=20 >> Isn't the IETF consensus by definition the appropriate >> technical advisors to the RSE or are you suggesting a >> separate and parallel structure that the RSE controls >> that all IETF consensus documents need to pass through? >=20 > Not at all, Jay. The RSE listens to the stream heads for documents for > publication. > One of those stream heads gauges IETF consensus for most cases.=20 >=20 > I believe the RSE should be able to very strongly question = publication, but > not over-rule the stream heads. > If the RSE noticed something that might be a ghastly mistake, I would = expect > them to mention it. That might not be a technical thing (unlikely that = the > RSE would be qualified) but might be socio-political. >=20 > And I believe that the community has mechanisms to censure/recall each > stream head. Thanks, very useful. That does seem quite different from what Mike was = suggesting, which is that the RSE could reject based on the advice of a = separate set of technical advisors, thereby over-ruling the stream = heads. Jay >=20 > Thanks, > Adrian >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_E1B25A5A-D81A-458A-80E6-1C95056DDE0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 13/05/2020, at 8:41 AM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Jay wrote:

Isn't the IETF consensus by definition the = appropriate
technical advisors to the RSE or are you = suggesting a
separate and parallel structure that the RSE = controls
that all IETF consensus documents need to pass = through?

Not at all, Jay. The = RSE listens to the stream heads for documents for
publication.
One of those stream heads gauges = IETF consensus for most cases.

I believe = the RSE should be able to very strongly question publication, but
not over-rule the stream heads.
If the RSE = noticed something that might be a ghastly mistake, I would expect
them to mention it. That might not be a technical thing = (unlikely that the
RSE would be qualified) but might be = socio-political.

And I believe that the = community has mechanisms to censure/recall each
stream = head.

Thanks, very useful.  That does seem quite = different from what Mike was suggesting, which is that the RSE could = reject based on the advice of a separate set of technical advisors, = thereby over-ruling the stream heads.

Jay


Thanks,
Adrian


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


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

= --Apple-Mail=_E1B25A5A-D81A-458A-80E6-1C95056DDE0C-- From nobody Tue May 12 13:46: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 476633A0AD0 for ; Tue, 12 May 2020 13:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nghGoHAUpJAN for ; Tue, 12 May 2020 13:46:18 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE153A0BE1 for ; Tue, 12 May 2020 13:46:09 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id f189so9478689qkd.5 for ; Tue, 12 May 2020 13:46:09 -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=Bx8+CCiDr+IFo8AFJFuS2IG+iHIKxXizGsbQGd1q928=; b=d+3gnjCUnhmDxnFv2bhHfEndOzNh4TFOGS7vP+rfQdZApxHjyh1wtQRpixzzUafm7x J0o5t4jmXvQrnKguVtYROEmR4Rv2tgzW5DwZ/1HtbGsdtiscM99an8pnpXHyde/ZXeKn af/9m0xoTbyXNfB/UeXl4CL1TZkV/7VRnLtFbfBPc+/10gXJpur8MLpthJ5/pb+oeAmn cz8CDbRr7gSPJ9tL+5RCXnCKQdJE4QgepRQSWFandPSxdJ51/teRWrlvhkVU02cUwuYi a7SS1zfxKz359cg/uVtiqk+hQg3q6LBTHbQ3/AnqLUA64PW9UhHkSAjcBMJ0/R/UFz8p Chbw== 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=Bx8+CCiDr+IFo8AFJFuS2IG+iHIKxXizGsbQGd1q928=; b=MGOgKwtqOP4hMyLSEBa7NISw+lsb9X6muZhunLbkx5eVVoHc05hENlf4K+YE6uIopU w6Sm7F33+V4lUkxQKllRriOvxJXqYAwrJFnfREDm+EhHLS4WD0CIUIkC88hZ0yDRsqP7 ssJu5VoqRU2QgP0x6B8KwyryMP/S2GqYF98tnfU1f8OSOGvU7x3PSccO6YTd9lNFguWl YRazwdtqiCV/CSmusg2TntSq8hyVs5e7VBYeC2fQyADV9yrsRfPjkj32hIU2xXfarFCL V7Oure17sxI4K2eFi+6nvdIcBCXeRYceJq3KpqpZbsOvubzzJcxP/HTbpDCE+xS3VeKm CQWA== X-Gm-Message-State: AGi0Pub7tajp53H5qcRZT2pSHIuKflVyykLdJ/gMuHpysOesxW0Lo/OA BAGtl2LGB9BF93LPrWXYe2gv9C/kIElm3A== X-Google-Smtp-Source: APiQypL4ClN1e20OWxRQ/pZ3MGsjlUxTYMOFezu+YYSRd/TYOLjNRGkQUkprlYbxhK+oc+UJ+u0inw== X-Received: by 2002:a37:a292:: with SMTP id l140mr21804391qke.306.1589316368269; Tue, 12 May 2020 13:46:08 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id o136sm7888582qke.78.2020.05.12.13.46.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 13:46:07 -0700 (PDT) To: Eric Rescorla Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> From: Michael StJohns Message-ID: Date: Tue, 12 May 2020 16:46:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DC0C8245BBAA82DF6DC9437C" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:46:20 -0000 This is a multi-part message in MIME format. --------------DC0C8245BBAA82DF6DC9437C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/12/2020 4:31 PM, Eric Rescorla wrote: > > > On Tue, May 12, 2020 at 1:25 PM Michael StJohns > > wrote: > > On 5/12/2020 4:16 PM, Eric Rescorla wrote: >> In Tue, May 12, 2020 at 10:55 AM Michael StJohns >> > wrote: >> > Mark (in another email) is correct that the level of >> independence of the >> > current RSE is not the same as in the past - but I consider >> that a bug >> > rather than a feature as it means that its possible for a small >> subset >> > of the IETF community to affect the culture of the RFC series >> in ways >> > that may not represent the interests of the broader community. >> >> I want to zero in on this point, because I think it's useful to scope >> out people's views of "independence". >> >> Let me try to start with what's hopefully a simple case: suppose >> that the IETF produces and the IESG approves a document to be >> published as RFC that the RSE believes is harmful to the Internet >> for technical reasons (it redefines IPv6 to have an 8 bit address, >> say). Do you believe that the RSE should be able to refuse to >> publish such a document? >> >> -Ekr > > Oooh   tricky.   I'd either have the RSE refer it to the ISE as > publication as an April Fool's RFC, or I'd probably be the first > to sign on to a petition to recall the entire IESG.     In any > case, the answer is probably yes, the RSE should refuse to publish > the document as an Internet standard.   That assumes that the RSE > - with the appropriate technical advisors - has the skillset to > determine said document is "harmful to the Internet". > > Thanks for the quick answer. > > I'm thinking maybe I made this too easy in that such a document has a > "is the IESG on drugs" kind of flavor where any sane person would > probably think they should throw a flag on the play. > > But let's take a case where it's not a comically wrong decision but > one that the RSE nevertheless strongly feels is harmful to the > Internet. What then? > > -Ekr > > Let me refer you to an act in history where the IAB decided to make CMOT and SNMP co-standards.   That triggered the Kobe uprising and a complete reformation of the structure of the I*. Jon was on the IAB at the time, and for policy reasons agreed with the designation.     That's sort of the reverse of what you mentioned, but it's also the same.   The community reacted badly to a bad decision by the deciding body and took action.  In the above instance, the RSE is still responsible to the community and they're going to be the final arbiters of whether or not the decision not to publish should stand. For your example you didn't give any additional details - e.g. during last call were the IESG strung up in effigy?  Was there sufficient community push back to invalidate the IESG action? Was there no last call?  Did the IESG refuse to add RSE directed black box warnings and text? Basically, what you've proposed is a strawman to be knocked down.   My guess is that any RSE that lets through something that *is* harmful to the internet (rather than just thinks it might be) will not have had a long tenure to start with.    What I think you're asking is similar to the problems that editors of wide circulation publishers go through all the time - to print or not to print.  In their case it might be "do we have enough evidence that politician A has actually committed adultery with staffer B" or "does printing C put D and E into danger"?  The business side may say - Lawyers are fine with it and it will make us money, but no editor worth their salt will let that be the only decision criteria.   So yes, the RSE absolutely can prevent publication, and yes absolutely the community (NOT the IESG, not the IAB etc) can arrange to replace the RSE for cause if such cause exists. The RSE is not a rubber stamp.  If you want one, got to a body shop and hire one. Later, Mike --------------DC0C8245BBAA82DF6DC9437C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/12/2020 4:31 PM, Eric Rescorla wrote:


On Tue, May 12, 2020 at 1:25 PM Michael StJohns <msj@nthpermutation.com> wrote:
On 5/12/2020 4:16 PM, Eric Rescorla wrote:
In Tue, May 12, 2020 at 10:55 AM Michael StJohns <msj@nthpermutation.com> wrote:
> Mark (in another email) is correct that the level of independence of the
> current RSE is not the same as in the past - but I consider that a bug
> rather than a feature as it means that its possible for a small subset
> of the IETF community to affect the culture of the RFC series in ways
> that may not represent the interests of the broader community.

I want to zero in on this point, because I think it's useful to scope
out people's views of "independence".

Let me try to start with what's hopefully a simple case: suppose
that the IETF produces and the IESG approves a document to be
published as RFC that the RSE believes is harmful to the Internet
for technical reasons (it redefines IPv6 to have an 8 bit address,
say). Do you believe that the RSE should be able to refuse to
publish such a document?

-Ekr

Oooh   tricky.   I'd either have the RSE refer it to the ISE as publication as an April Fool's RFC, or I'd probably be the first to sign on to a petition to recall the entire IESG.     In any case, the answer is probably yes, the RSE should refuse to publish the document as an Internet standard.   That assumes that the RSE - with the appropriate technical advisors - has the skillset to determine said document is "harmful to the Internet".

Thanks for the quick answer.

I'm thinking maybe I made this too easy in that such a document has a "is the IESG on drugs" kind of flavor where any sane person would probably think they should throw a flag on the play.

But let's take a case where it's not a comically wrong decision but one that the RSE nevertheless strongly feels is harmful to the Internet. What then?

-Ekr


Let me refer you to an act in history where the IAB decided to make CMOT and SNMP co-standards.   That triggered the Kobe uprising and a complete reformation of the structure of the I*.   Jon was on the IAB at the time, and for policy reasons agreed with the designation.     That's sort of the reverse of what you mentioned, but it's also the same.   The community reacted badly to a bad decision by the deciding body and took action.  In the above instance, the RSE is still responsible to the community and they're going to be the final arbiters of whether or not the decision not to publish should stand.

For your example you didn't give any additional details - e.g. during last call were the IESG strung up in effigy?  Was there sufficient community push back to invalidate the IESG action?   Was there no last call?  Did the IESG refuse to add RSE directed black box warnings and text? 

Basically, what you've proposed is a strawman to be knocked down.   My guess is that any RSE that lets through something that *is* harmful to the internet (rather than just thinks it might be) will not have had a long tenure to start with.    What I think you're asking is similar to the problems that editors of wide circulation publishers go through all the time - to print or not to print.  In their case it might be "do we have enough evidence that politician A has actually committed adultery with staffer B" or "does printing C put D and E into danger"?  The business side may say - Lawyers are fine with it and it will make us money, but no editor worth their salt will let that be the only decision criteria.   So yes, the RSE absolutely can prevent publication, and yes absolutely the community (NOT the IESG, not the IAB etc) can arrange to replace the RSE for cause if such cause exists.

The RSE is not a rubber stamp.  If you want one, got to a body shop and hire one.

Later, Mike



--------------DC0C8245BBAA82DF6DC9437C-- From nobody Tue May 12 13:49: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 E9EFF3A0AE9 for ; Tue, 12 May 2020 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43Sgd8BFcw1L for ; Tue, 12 May 2020 13:48:56 -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 CEE4E3A0ADE for ; Tue, 12 May 2020 13:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C359CBE20; Tue, 12 May 2020 21:48:53 +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 pCa072WpvVAC; Tue, 12 May 2020 21:48:48 +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 E7A8BBDCF; Tue, 12 May 2020 21:48:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1589316528; bh=tlX7DToUepbFcxWhhHU8v9Tt+OAVNy4las/3Qvcp32E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NBWZ8yNBxM4CObTlbeFvKA6kqz/w7etMIB02ykObqLc8XPb6Pe2DIqJHdrY7u5fTc Ug+e1mzVNN47vAXrfSFCIIoT3KkVXqx6avQZ3o3a5nQX6Q1PmIaUvsQCtkHVGmiCZ8 KFk4/qPZHF5KobzL9e7/oDQeKX3yR/+kHEWRxpBI= To: Eric Rescorla , Michael StJohns Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> 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: Tue, 12 May 2020 21:48:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="66KQcMEGwUrVo8KtcudIKgyUqYj5WTlJH" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:48:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --66KQcMEGwUrVo8KtcudIKgyUqYj5WTlJH Content-Type: multipart/mixed; boundary="noosawPNeyAelMUGWBFSYNvvWqERCAmH2"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , Michael StJohns Cc: rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> In-Reply-To: --noosawPNeyAelMUGWBFSYNvvWqERCAmH2 Content-Type: multipart/mixed; boundary="------------9AE06557595610D06169C522" Content-Language: en-US This is a multi-part message in MIME format. --------------9AE06557595610D06169C522 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/05/2020 21:16, Eric Rescorla wrote: > In Tue, May 12, 2020 at 10:55 AM Michael StJohns > wrote: >> Mark (in another email) is correct that the level of independence of t= he >> current RSE is not the same as in the past - but I consider that a bug= >> rather than a feature as it means that its possible for a small subset= >> of the IETF community to affect the culture of the RFC series in ways >> that may not represent the interests of the broader community. >=20 > I want to zero in on this point, because I think it's useful to scope > out people's views of "independence". >=20 > Let me try to start with what's hopefully a simple case: suppose > that the IETF produces and the IESG approves a document to be > published as RFC that the RSE believes is harmful to the Internet > for technical reasons (it redefines IPv6 to have an 8 bit address, > say). Do you believe that the RSE should be able to refuse to > publish such a document? FWIW, I think the RSE ought not be able to block publication of IETF stream documents. The RSE could publish a document opining that the IESG must be on drugs I guess. I'd also be ok with other forms of puhshback (e.g. mailing ietf@ietf asking WTF) but I'd stop short of the RSE being able to block. S. >=20 > -Ekr >=20 >=20 --------------9AE06557595610D06169C522 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----- --------------9AE06557595610D06169C522-- --noosawPNeyAelMUGWBFSYNvvWqERCAmH2-- --66KQcMEGwUrVo8KtcudIKgyUqYj5WTlJH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl67C68ACgkQWrL68XsX K+rMOhAAxeMwctvyOCKE2CLKQjIvH849CBQR1pl0bxTZW0sK4za5M6oEEyKRbbwC 0k+pYkkTgXDL+tj2Hzw08Hla+1v8KFzTHhHPmthODB7NwHo6thBCWS1zaImydWJa iB2xCKcBSiQFKC7IgeaGlp8z8rGEadI2XAL60P9bzxfZD7FFvCWaMJMfHB5zpmAj cAWrEL/HVRupDkjDesAsy/QSwtTxSMq5WdQg0qJSkQ5J8jRoHjaBSWVmfWBRDwU6 CCs0/iQ6SZg8frLd1DwSvnLxtkU3sM/j1703ZsMmIhL11QfznLJctd6PQ4oC4wKP N1UsBm/gfhD5JUlD9Q6Zbgz6LoXDS2aNccp9A56elkJlRCif6fMQk2b3EOtkwXAA DtBzQxnzPKJ8ocyZvwg66PwIoFOgXPKBNvczhnLST/AsvGUbY2vN62x3XQuG7sP0 0qe+mMuWYdTDGLZJf15htRvjsJmTBzvNuswJdCDVlzvTCOVdU2QDD133jg1tP2ZF 7DKl13JcaPfGNSZNGJOldDRm28WD8jZviJiMoCE70ChwTxSy2UvvE2VaogOy31Qk 7yuLtLSFFH4CyF203zhZGODARPxZcNmFsH+3zeqCc44fgTfDusKTJGikXWnZE3Kb xW8En0FFgCiNgAkN7D86Wyxo03VS0dr+p8SI1WnbZ9tmKoP8xdc= =SgDe -----END PGP SIGNATURE----- --66KQcMEGwUrVo8KtcudIKgyUqYj5WTlJH-- From nobody Tue May 12 14:01: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 3A1073A0B88; Tue, 12 May 2020 14:01:00 -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 8QwY0d2gcikH; Tue, 12 May 2020 14:00:58 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33643A0B84; Tue, 12 May 2020 14:00:57 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04CL0tOl004670; Tue, 12 May 2020 22:00:55 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5B48422048; Tue, 12 May 2020 22:00:55 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 45DBE22042; Tue, 12 May 2020 22:00:55 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04CL0rIu031855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 May 2020 22:00:54 +0100 Reply-To: From: "Adrian Farrel" To: "'Jay Daley'" Cc: "'Michael StJohns'" , , "'Eric Rescorla'" References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <031901d6289d$c99af300$5cd0d900$@olddog.co.uk> <308BC114-D9B3-4E4B-972C-AE17E6927578@ietf.org> In-Reply-To: <308BC114-D9B3-4E4B-972C-AE17E6927578@ietf.org> Date: Tue, 12 May 2020 22:00:53 +0100 Organization: Old Dog Consulting Message-ID: <032a01d628a0$6d9f4080$48ddc180$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032B_01D628A8.CF63A880" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIXd1lDfRLMUyCB5gsDzs94bJ6JOwGEMjC/AkGllpkB77/TMgK8IeqVApdLMSwCgGpGkgFsEpYKAaqDk3YCUQoCBQEEOYCEAiUoqQqncXvegA== X-Originating-IP: 84.93.26.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25416.002 X-TM-AS-Result: No--22.675-10.0-31-10 X-imss-scan-details: No--22.675-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25416.002 X-TMASE-Result: 10--22.675100-10.000000 X-TMASE-MatchedRID: /77LoUQXvQ9or4mPA3EMtnFPUrVDm6jtIiTd2l7lf6EHWPn2mj7oRIGr DT0aZhxXX7GqbX7yADXMdqKz1jxx8VypVJFmh6sL8KGJCiV+3/JfgaB+CZwiBmu9/l5WAy7sGqp iSTozomglZV7m1z/D3HSlVfH0sn02m6736xdq3zKMrB0waNjVKyNDBbAifICjEGS09JGzNKBZZT Ml93vPDnoJ/8U5IVNaFAeiKOlP17mMcenel/LSenloCSzaMB3VJQSryPTViF8VO5ChMqIWZO8ke 9FM2hzh/3WCZWNVrmKrPWUblX1HyXPN02UpO1cf71Wx2uUbPLf9sV9Tla1qi1cbfIj2Ta9sh80v sP8cwQ7EJbgsghXOAtk9T5vlFwdofOtaHACD6bDJ1E/nrJFED9BO21OxlsovA08Y80okScEBfQG EwJVCl9LDwRBa0SIdAf/oIhDrMcyfRSghnfviF+a55w05lWyqy733NwuklsJ/GXao7FChFWWYR5 By/7zHkklFR/TZlNEkhV0S2olMbO5NCr61QzTwlVHM/F6YkvQl3afZehJEWQ4XFGWwo66I3yZ/G Jmw8EZtWublu9A27NOypt/08xti8SfOLQ+4zH+eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6 HN6d7M+9+OQ9U/5f7ni+GTUS+xEgbhiVsIMQK7ebCOc2vNHrlwpucc8jEWKqnBNK0tw+XhJ7+76 VvznvdXmcsslG+jiUTGVAhB5EbQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:01:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_032B_01D628A8.CF63A880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think you were over-reading "independent". A From: Jay Daley Sent: 12 May 2020 21:45 To: adrian@olddog.co.uk Cc: Michael StJohns ; rfced-future@iab.org; Eric Rescorla Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt On 13/05/2020, at 8:41 AM, Adrian Farrel > wrote: Jay wrote: Isn't the IETF consensus by definition the appropriate technical advisors to the RSE or are you suggesting a separate and parallel structure that the RSE controls that all IETF consensus documents need to pass through? Not at all, Jay. The RSE listens to the stream heads for documents for publication. One of those stream heads gauges IETF consensus for most cases. I believe the RSE should be able to very strongly question publication, but not over-rule the stream heads. If the RSE noticed something that might be a ghastly mistake, I would expect them to mention it. That might not be a technical thing (unlikely that the RSE would be qualified) but might be socio-political. And I believe that the community has mechanisms to censure/recall each stream head. Thanks, very useful. That does seem quite different from what Mike was suggesting, which is that the RSE could reject based on the advice of a separate set of technical advisors, thereby over-ruling the stream heads. Jay Thanks, Adrian -- Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future -- Jay Daley IETF Executive Director jay@ietf.org ------=_NextPart_000_032B_01D628A8.CF63A880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think you = were over-reading “independent”.

 

A

 

From: Jay Daley = <jay@ietf.org>
Sent: 12 May 2020 21:45
To: = adrian@olddog.co.uk
Cc: Michael StJohns = <msj@nthpermutation.com>; rfced-future@iab.org; Eric Rescorla = <ekr@rtfm.com>
Subject: Re: [Rfced-future] I-D Action: = draft-carpenter-rfc-principles-00.txt

 

 



On 13/05/2020, at 8:41 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Jay wrote:


Isn't the IETF consensus by definition the = appropriate
technical advisors to the RSE or are you suggesting = a
separate and parallel structure that the RSE controls
that all = IETF consensus documents need to pass = through?


Not at all, = Jay. The RSE listens to the stream heads for documents = for
publication.
One of those stream heads gauges IETF consensus = for most cases.

I believe the RSE should be able to very = strongly question publication, but
not over-rule the stream = heads.
If the RSE noticed something that might be a ghastly mistake, = I would expect
them to mention it. That might not be a technical = thing (unlikely that the
RSE would be qualified) but might be = socio-political.

And I believe that the community has mechanisms = to censure/recall each
stream = head.

 

Thanks, very useful.  That does seem quite = different from what Mike was suggesting, which is that the RSE could = reject based on the advice of a separate set of technical advisors, = thereby over-ruling the stream heads.

 

Jay




Thanks,
Adrian


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

 

-- 
Jay = Daley

IETF Executive Director
jay@ietf.org

=

 

------=_NextPart_000_032B_01D628A8.CF63A880-- From nobody Tue May 12 14:05: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 9B21E3A0BBE for ; Tue, 12 May 2020 14:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU0_if44wN1Z for ; Tue, 12 May 2020 14:05:03 -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 907F13A0BA3 for ; Tue, 12 May 2020 14:05:03 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id u35so3755394pgk.6 for ; Tue, 12 May 2020 14:05: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=JkoUkO+5VnUXyVhxHdlRAUqkIyST+pFGhYeOYsqZfd4=; b=SGA6ejoK9G/dq5MKGwf5CQA12EuhMQhEDgcCnfwoatn2y0WYtTg6zM2VkzjfGokHDU x/ZgSgY3Zf7Y+eTAjt8mtdtTOms+gR5RJ/IQMx/X23fXi0OciBmBoEPus7CStMqBS8AO IFrIbm8UM3yuACwinb6V0xdka9YnfJXuAaaUe5Lh8TY8Vo0Z5f6ADNT9M2eYMtlfrjka Cq8R0uWkWM2t/+tzWKwCPA56yAp5qWd4zGy1m8RvMZaQT6km7jozBOHBSucc9sa4e5HU sKF3pDZ8zbGPgbWnyYZ/zy3XGtlHAENv5lOTes5Avk2s2ntbaY950T9fVcGOz5+YjRgp 32pQ== 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=JkoUkO+5VnUXyVhxHdlRAUqkIyST+pFGhYeOYsqZfd4=; b=gvDPg6QZD68N0usPhVkYLrucNoNzQhJwRs6Jr+2tJzUZ/EbX7Z0R8s4r2Is4YbW7O3 EBEMKbtgaE1Tp+rF9OsOheQ+S08gZRZVvKzPwT3oxosdW5quQYuHhZWCw7NPxUIWLfB8 CotCRs5i1b+Hr7yPXgTEe9qHtlWe7V9EAxQ10rz6vyAWrGlc1GlStYOGQQt/R7+yg3dg QqOejdiXpyDWJm+ZLF1Rkl1JWtgBX81W/bx3AMF9FoQMh5h0OngxfhpQZDuIA+DOY2YG QPebhAUlqJGpaMsMxQJGc9f8pTppNrbzkHHM+rDbFGg5eypdSEGVrR5aF2NtWNZjUyJ4 gB6Q== X-Gm-Message-State: AGi0PuYQT2MBC7ySHFteUIq0Iguqm7UlyHQLQyhdtDtgcklagrniuove mI1UazjMebs2JQ0aaZCtrE29R5DB X-Google-Smtp-Source: APiQypJJtkuDuA1tZ7Vmn7YMzxCs0QZABRG2nDXgnNJv7lZV1Z38AxL9pW7FphCJ4CqZNu63Weq44A== X-Received: by 2002:a63:f707:: with SMTP id x7mr21840741pgh.374.1589317502469; Tue, 12 May 2020 14:05:02 -0700 (PDT) Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id d184sm12531944pfc.130.2020.05.12.14.05.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2020 14:05:01 -0700 (PDT) To: Mark Nottingham , John C Klensin Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> From: Brian E Carpenter Message-ID: <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> Date: Wed, 13 May 2020 09:04: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: <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Rfced-future] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:05:07 -0000 I note that RFC7990 says: > Canonical format: the authorized, recognized, accepted, and > archived version of the document This could well be an error. Making our XML dialect the *canonical* format was what most of us thought about. Maybe a specified rendering that could, in theory, be drawn on parchment should be the *archival* format. Since RFC7990 is a request for comments, we can choose to update it. This should go on the next RSE's "to do" list, I think. Regards Brian Carpenter On 12-May-20 19:15, Mark Nottingham wrote: > Hi John, >=20 >> On 12 May 2020, at 5:03 pm, John C Klensin wrote: >> >> Mark, I fear that takes us around in a bit of a circle, albeit >> an important one. I was forcefully educated (one might say >> "beaten up") some years ago by an Archivist (his job title) >> associated with a national repository library in the north of >> Europe. He explained that it was very hard to have a >> conversation about what was "archival" or about the meaning of >> the closely-related term "permanent" with people in computer >> fields (especially web-related ones) because we tended to think >> of "permanence" as 10 - 20 years. He claimed that most people >> he had encountered from North America or the South Pacific had >> similar problems with believing permanence, in practice, could >> be considered a few centuries but that he and his colleagues >> needed to work in terms of at least several millennia and that >> those differences put an entirely different spin on things. >=20 > This does not shock me, but then I've interned in an art museum, where = the challenges of conservatorship were painfully obvious. >=20 >=20 >> That story is important in the current context for two reasons: >> >> * While I consider the decision made and hence not part of the >> current RFC Editor Futures discussion (even though I, and >> apparently others, have growing doubts about how we are >> implementing it), a conversation with almost any (I don't know >> of exceptions, but maybe there are some) professional archivist >> about treating a source format that requires considerable >> compilation and reference to external sources and mechanisms to >> get to a form people are comfortable reading as an archival form >> will typically be greeted with laughter and/or comments to the >> effect that we should come back in a hundred years and show them >> that XML is still around and that it is the same, or at least >> completely backward-compatible, XML. If they, and their >> considerations, are to be taken seriously as we talk about >> "archival", things are broken already and comments about the >> merits of continuing to dig when one finds oneself in a deep >> hole may be relevant. >=20 > I tend to agree; if I'd been more involved in the IETF when this decisi= on was made, I would have fought it (based upon my early experiences with= XML, more than anything). >=20 >=20 >> * There have been several discussions in recent years about >> treating IETF specifications as living documents or with some >> other arrangement in which issues are folded in as soon as they >> are detected and at least tentative conclusions reached about >> how to proceed. I don't know whether we need to resolve those >> proposals before moving forward with discussions about the >> future of the RFC Series and its management and organization (I >> hope we don't because the community seems quite divided to me). >> However, I think we need to understand that moving in that >> direction, even if we make periodic snapshots and publish them >> as RFCs, would profoundly change the character of the series as >> providing a clearly-identifiable (and "archival") record of the >> evolution of Internet technology and standards. >=20 > I think that people are becoming slightly absolutist when they talk abo= ut this subject, but worse, they perceive those on "the other side" as *r= eally* absolutist. >=20 > I hope no one seriously thinks that "archival" means that we can't chan= ge _any_ aspect of the series, ever -- that it's a machine that must run = on in its current form until its doom. I also hope that no one thinks tha= t changing things means that it must be possible to change any character = / bit in any RFC at any time. >=20 > If we can put those extremes safely out of the way and focus on what th= e needs of the archival and other communities are, we might make some pro= gress.=20 >=20 > Maybe we could give some guidance here, but I agree we do have some oth= er issues to dispose of first. >=20 >=20 >>> ... >>>> =E2=80=A2 The RFC Series is community property and must operate on >>>> behalf of the community as a whole. >>>> >>>> =E2=80=A2 The exact definition of the relevant community is open >>>> for debate. One definition is: the IETF, the IRTF, the IAB >>>> and the many other people who have contributed to, or made >>>> use of, the RFC Series over the last fifty years. >>>> >>>> =E2=80=A2 Major decisions about the future of the RFC Series must >>>> be taken by a rough consensus of this very broad community. >>>> >>>> =E2=80=A2 How to reach out to this community and judge its >>>> consensus is in itself a big question. >>> >>> I think it's widely agreed that your conclusions about the >>> series not being 'owned' by any of the I* are correct. >>> However, I'd suggest that we can reach out to and judge >>> consensus of that community just like we do in any other area >>> -- establish a venue (e.g., a WG) and make it known that if >>> you're a stakeholder who's interested, that's the appropriate >>> place to contribute. Doubtless some people will not choose to >>> come, but that's their choice. Others might advocate on their >>> behalf; we already see that with civil society organisations >>> being involved in the IETF's work. >> >> One problem is that one important audience for the Series, or at >> least the documents we claim are standards (or to which assorted >> parties claim conformance) are people writing procurement >> documents (RFPs, contracts, SLAs, etc.). The odds that we will >> get a reliable representation from that community even if we >> could reach them are, I think, pretty small. The odds that we >> could get them to participate in a WG-like arrangement? >> Probably much lower. But, at least if one were to assume a free >> market in which alternatives exist, those people are key to >> determine if our standards go anywhere. Indeed, when they write >> contracts that require conformance and try to enforce them, they >> are actually the closest we get to actually having a Protocol >> Police. And, by the way, they, and the kinds of documents they >> are willing to work with, interact with the "living document" >> ideas as well: IMO at least, we dare not ignore them because we >> cannot get their participation on our normal terms. >=20 > Thank you; this is exactly how things sit already in many WGs, e.g., HT= TP. The decisions we make impact many people who don't even know we exist= on a daily basis. >=20 > Cheers, >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > . >=20 From nobody Tue May 12 14:12: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 CA4A93A0BD4; Tue, 12 May 2020 14:12:14 -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 4HnF4BnKbPeH; Tue, 12 May 2020 14:12:13 -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 6B0973A0BCF; Tue, 12 May 2020 14:12:13 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jYcC9-000Mqq-Ty; Tue, 12 May 2020 17:12:09 -0400 Date: Tue, 12 May 2020 17:12:03 -0400 From: John C Klensin To: adrian@olddog.co.uk, 'Jay Daley' , 'Michael StJohns' cc: rfced-future@iab.org, 'Eric Rescorla' Message-ID: <2FC1F909BEC2D1E181C65897@PSB> In-Reply-To: <031901d6289d$c99af300$5cd0d900$@olddog.co.uk> References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <031901d6289d$c99af300$5cd0d900$@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] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:12:15 -0000 --On Tuesday, May 12, 2020 21:41 +0100 Adrian Farrel wrote: > Jay wrote: > >> Isn't the IETF consensus by definition the appropriate >> technical advisors to the RSE or are you suggesting a >> separate and parallel structure that the RSE controls >> that all IETF consensus documents need to pass through? > > Not at all, Jay. The RSE listens to the stream heads for > documents for publication. > One of those stream heads gauges IETF consensus for most > cases. > > I believe the RSE should be able to very strongly question > publication, but not over-rule the stream heads. > If the RSE noticed something that might be a ghastly mistake, > I would expect them to mention it. That might not be a > technical thing (unlikely that the RSE would be qualified) but > might be socio-political. I would expect the RSE to push back. Especially if it were even partially a technical issue, I would expect there would be no restrictions (contractual or otherwise) on the RSE, as a member of the community, pushing back either privately to the IESG or on an appropriate IETF mailing list. Another way to express such pushback would be an appeal of the IESG's approval action (and the RSE should not be barred from doing that either). However, if the IESG believes the document should be published as-is (and, if the community agreed with the RSE but was unsuccessful in persuading the IESG), we already have a mechanism for that, which is for the IESG to ask that the document be published anyway, even if the RRE wants to insert a note that the document was published over the objections of the RFC Editor Function. While that mechanism was, IIR, designed for documents the RFC Editor concludes are incomprehensible and/or editorially too difficult to deal with, I don't see any reason why it could not also be applied to a technical objection if the RSE believed that such an objection was in order. So, while the question is interesting, I wonder if there is a problem in that area which is worth extensive discussion or that needs a solution. > And I believe that the community has mechanisms to > censure/recall each stream head. And that is where I disagree because the evidence is that we have no such mechanisms that are usable in practice. The only mechanism we have that is of (sometimes) demonstrable effectiveness is waiting for the next Nomcom and hoping its membership is sufficiently representative of the community to remove the individual(s) in question. Presumably (and as threatened in the past with seemingly good effect) offers to pelt the IESG with overripe fruit during a plenary might also be effective. If the latter is the best mechanism we have, we need to be working aggressively on a transport protocol for such fruit over the Internet. Or we might notice that draft-moonesamy-recall-rev expired today and start thinking about how to prioritize such work. best, john From nobody Tue May 12 14:30: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 2BA683A0BF3 for ; Tue, 12 May 2020 14:30:47 -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 TYh8c6vngZEl for ; Tue, 12 May 2020 14:30:45 -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 917C93A0BF2 for ; Tue, 12 May 2020 14:30:45 -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.15.2/8.15.2) with ESMTPSA id 04CLUgVI098598 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 May 2020 16:30:43 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589319044; bh=v/rSKtp1V1Gl+qrJKnu+b6StXC6NRGWdZsOoCD+ZsgA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=qLqygFVGCm+pAuogTCqQtjbhPgu69m+rXpwmifb+lnAIxTQDimDOupcHhxraFDWZf Z7FNMROSk9dPA++QFUDYz2cZHLVk8O//YjHigzmfrJE/2HOph2EGt1VfVKVxVvjS7B YJlXQ0q9YMsjqxyFZFGR8EqSV2/U9o4Gg0rknVD8= 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: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> From: Adam Roach Message-ID: <77479725-3b0c-8a5f-d15d-aee54abdae7d@nostrum.com> Date: Tue, 12 May 2020 16:30:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> Content-Type: multipart/alternative; boundary="------------4B324C0C2562B1D2BB540684" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:30:47 -0000 This is a multi-part message in MIME format. --------------4B324C0C2562B1D2BB540684 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/12/2020 3:25 PM, Michael StJohns wrote: > On 5/12/2020 4:16 PM, Eric Rescorla wrote: >> In Tue, May 12, 2020 at 10:55 AM Michael StJohns >> > wrote: >> > Mark (in another email) is correct that the level of independence >> of the >> > current RSE is not the same as in the past - but I consider that a bug >> > rather than a feature as it means that its possible for a small subset >> > of the IETF community to affect the culture of the RFC series in ways >> > that may not represent the interests of the broader community. >> >> I want to zero in on this point, because I think it's useful to scope >> out people's views of "independence". >> >> Let me try to start with what's hopefully a simple case: suppose >> that the IETF produces and the IESG approves a document to be >> published as RFC that the RSE believes is harmful to the Internet >> for technical reasons (it redefines IPv6 to have an 8 bit address, >> say). Do you believe that the RSE should be able to refuse to >> publish such a document? >> >> -Ekr > > Oooh   tricky.   I'd either have the RSE refer it to the ISE as > publication as an April Fool's RFC, or I'd probably be the first to > sign on to a petition to recall the entire IESG.     In any case, the > answer is probably yes, the RSE should refuse to publish the document > as an Internet standard.   That assumes that the RSE - with the > appropriate technical advisors - has the skillset to determine said > document is "harmful to the Internet". > I think we can appreciate that the example was chosen to be fantastical so as to not focus discussion on the technical matter as much as the degree of control the RSE is afforded over the technical contents of a document. Now, I do recall a recent anecdote about Postel himself heatedly refusing to publish a specification he felt was technically misguided [1], so this authority did exist with the position at some point. Although never explicitly revoked, RFC 4844, section 4.1 et seq makes it pretty clear that the RSE has approval authority over precisely one stream (the Independent Submission stream). To the extent that the IAB had authority to publish RFC 4844, I think it makes it clear that the scope of authority had been pared back substantially since the "I am not going to publish a faulty specification as an RFC" days of 1991. I'm not entirely sure my analysis above is all that useful, though, as this is the "rfced-future" discussion rather than the "rfced-history" discussion, and so it seems more sensible to focus on meeting the needs of the Internet community in 2020 and beyond than is is to lean on the historical narrative. And so more to the point: I think that the IETF community writ large would be floored if a working group produced a document, the IETF found consensus on it during last call, the IESG approved it, and then the RSE refused to publish it (or imposed technical changes on its contents). Ditto for the IRTF and their documents. So, if we're matching authority with community expectations -- at least for a large swath of the relevant community -- I think the answer above of "the RSE should refuse to publish the document" is exactly wrong. /a ____ [1] https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/ --------------4B324C0C2562B1D2BB540684 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/12/2020 3:25 PM, Michael StJohns wrote:
On 5/12/2020 4:16 PM, Eric Rescorla wrote:
In Tue, May 12, 2020 at 10:55 AM Michael StJohns <msj@nthpermutation.com> wrote:
> Mark (in another email) is correct that the level of independence of the
> current RSE is not the same as in the past - but I consider that a bug
> rather than a feature as it means that its possible for a small subset
> of the IETF community to affect the culture of the RFC series in ways
> that may not represent the interests of the broader community.

I want to zero in on this point, because I think it's useful to scope
out people's views of "independence".

Let me try to start with what's hopefully a simple case: suppose
that the IETF produces and the IESG approves a document to be
published as RFC that the RSE believes is harmful to the Internet
for technical reasons (it redefines IPv6 to have an 8 bit address,
say). Do you believe that the RSE should be able to refuse to
publish such a document?

-Ekr

Oooh   tricky.   I'd either have the RSE refer it to the ISE as publication as an April Fool's RFC, or I'd probably be the first to sign on to a petition to recall the entire IESG.     In any case, the answer is probably yes, the RSE should refuse to publish the document as an Internet standard.   That assumes that the RSE - with the appropriate technical advisors - has the skillset to determine said document is "harmful to the Internet".


I think we can appreciate that the example was chosen to be fantastical so as to not focus discussion on the technical matter as much as the degree of control the RSE is afforded over the technical contents of a document.

Now, I do recall a recent anecdote about Postel himself heatedly refusing to publish a specification he felt was technically misguided [1], so this authority did exist with the position at some point. Although never explicitly revoked, RFC 4844, section 4.1 et seq makes it pretty clear that the RSE has approval authority over precisely one stream (the Independent Submission stream). To the extent that the IAB had authority to publish RFC 4844, I think it makes it clear that the scope of authority had been pared back substantially since the "I am not going to publish a faulty specification as an RFC" days of 1991.

I'm not entirely sure my analysis above is all that useful, though, as this is the "rfced-future" discussion rather than the "rfced-history" discussion, and so it seems more sensible to focus on meeting the needs of the Internet community in 2020 and beyond than is is to lean on the historical narrative.

And so more to the point: I think that the IETF community writ large would be floored if a working group produced a document, the IETF found consensus on it during last call, the IESG approved it, and then the RSE refused to publish it (or imposed technical changes on its contents). Ditto for the IRTF and their documents. So, if we're matching authority with community expectations -- at least for a large swath of the relevant community -- I think the answer above of "the RSE should refuse to publish the document" is exactly wrong.

/a

____
[1] https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/

--------------4B324C0C2562B1D2BB540684-- From nobody Tue May 12 14:33: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 095B73A0C02 for ; Tue, 12 May 2020 14:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N85SXgxMVsPA for ; Tue, 12 May 2020 14:33:22 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 19D9F3A0BED for ; Tue, 12 May 2020 14:33:22 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id f189so9614756qkd.5 for ; Tue, 12 May 2020 14:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=XTbcqE2LXasFdalTIWS3xChBK7jABdsFBLi/mMMupig=; b=igQUOVZ+oHKTdDNJ4IfjtpSU24U0Zri+jLviujZrM/yvTQq+uDl6CRLhK2Z7XLwvmb 2tThZe7jAKyaMWOZTGpUP6nDilAzJJ7mFxctu5PRRDhfS+kUck3nzTYZJk6ixcbkox7g fT83rlB84iQzBZA/IhHbxbDsTYKB6A3/uZTNQTmpZXqQYsewbG8OSaTM0K1RAUOGAc7Z PRssBnl/DvqglNnNz/VA6tJW9U1tFseZDOW21txgHiWdHSuUSk02p2B1Bc6/46Al92IZ e4vfdAM8kMGyv3no4JuEQf22ktGHbG4OeoIgp3epn9KciEJRElCLBOnBR1jPf4xn1rJB z/sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=XTbcqE2LXasFdalTIWS3xChBK7jABdsFBLi/mMMupig=; b=lOPcaaqbEZJXBqIYNLjZZO6gbNcZbgEQeP0+cmHOmnF+jbXB1f6sz+q9sMjRZVQcXv pKIAFRZ6FlaHR8RZyKatnJVO5goD7WbVTwz+Jda67oBtCWBzQ7bTwDAUhWBPEeUU4z8k jqBC6A164sLM2k2u9iO/9mLlR1CjRZzVBiuKBtZxJU7ycLioP6pX6axZidl4msBQcZnA g8SjkyNWIrMCG8sj7gwamXtvvLxrVdglxbhBUZXvu5msUmxeJ/bKTT5tTBRUV83uHz1N az03SDB9OunriX57teAMkGKiwEzr6vPFEWx+Ti6+N9OkRBKJ4assThorw18ieXil1nP1 wTGg== X-Gm-Message-State: AGi0PuYsukWqYHMZI/RYNabDDOH6KRhQ1mtDKlQpfTn3yHE5TK/GFG4H Nu4S2fMUhX3X1KZ6MLC3w5LgKxZSDWsPwQ== X-Google-Smtp-Source: APiQypIxx4l4g6aaXhmBRIhNanP2V5/BPXyCfcrVTEDZ3ODY8nUN1SXym+uDSs44GkeFh8h4OXUjSA== X-Received: by 2002:a05:620a:951:: with SMTP id w17mr23893420qkw.371.1589319200425; Tue, 12 May 2020 14:33:20 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id a29sm12942385qka.90.2020.05.12.14.33.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 14:33:19 -0700 (PDT) From: Michael StJohns To: Eric Rescorla Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> Message-ID: <36d38a87-0212-15c2-4d33-4dde29db59d9@nthpermutation.com> Date: Tue, 12 May 2020 17:33:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------94D46C18C78893FE6901C5FC" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:33:24 -0000 This is a multi-part message in MIME format. --------------94D46C18C78893FE6901C5FC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sorry for the top post - and Q for EKR but I started thinking about reverse strawman arguments.   Of the last 100-200 RFCs approved by the IESG, what percentage have had more than the mininum Yes votes?  I ask because you (EKR) framed this as the "IESG" approving a document, when in reality it could be that only one person is actually in favor of the document. Approvals require at least one yes vote and at least 2/3 of the non recused to vote yes or no objection.  No Objections mean: * I read it, and I have no problem with it. * _*I read the protocol action, and I trust the sponsoring AD so have no problem.*_ * I listened to the discussion, and I have no problem. So we're theoretically (at the extreme) balancing the judgement of one person on the IESG against one other person (the RSE). If the argument is "that can't happen" then that argument applies equally well to the RSE getting a document so poorly written or so technically flawed that the RSE would fall on their sword to prevent publication. Later, Mike On 5/12/2020 4:46 PM, Michael StJohns wrote: > On 5/12/2020 4:31 PM, Eric Rescorla wrote: >> >> >> On Tue, May 12, 2020 at 1:25 PM Michael StJohns >> > wrote: >> >> On 5/12/2020 4:16 PM, Eric Rescorla wrote: >>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns >>> > wrote: >>> > Mark (in another email) is correct that the level of >>> independence of the >>> > current RSE is not the same as in the past - but I consider >>> that a bug >>> > rather than a feature as it means that its possible for a >>> small subset >>> > of the IETF community to affect the culture of the RFC series >>> in ways >>> > that may not represent the interests of the broader community. >>> >>> I want to zero in on this point, because I think it's useful to >>> scope >>> out people's views of "independence". >>> >>> Let me try to start with what's hopefully a simple case: suppose >>> that the IETF produces and the IESG approves a document to be >>> published as RFC that the RSE believes is harmful to the Internet >>> for technical reasons (it redefines IPv6 to have an 8 bit address, >>> say). Do you believe that the RSE should be able to refuse to >>> publish such a document? >>> >>> -Ekr >> >> Oooh   tricky.   I'd either have the RSE refer it to the ISE as >> publication as an April Fool's RFC, or I'd probably be the first >> to sign on to a petition to recall the entire IESG.     In any >> case, the answer is probably yes, the RSE should refuse to >> publish the document as an Internet standard.   That assumes that >> the RSE - with the appropriate technical advisors - has the >> skillset to determine said document is "harmful to the Internet". >> >> Thanks for the quick answer. >> >> I'm thinking maybe I made this too easy in that such a document has a >> "is the IESG on drugs" kind of flavor where any sane person would >> probably think they should throw a flag on the play. >> >> But let's take a case where it's not a comically wrong decision but >> one that the RSE nevertheless strongly feels is harmful to the >> Internet. What then? >> >> -Ekr >> >> > Let me refer you to an act in history where the IAB decided to make > CMOT and SNMP co-standards.   That triggered the Kobe uprising and a > complete reformation of the structure of the I*.   Jon was on the IAB > at the time, and for policy reasons agreed with the designation.     > That's sort of the reverse of what you mentioned, but it's also the > same.   The community reacted badly to a bad decision by the deciding > body and took action.  In the above instance, the RSE is still > responsible to the community and they're going to be the final > arbiters of whether or not the decision not to publish should stand. > > For your example you didn't give any additional details - e.g. during > last call were the IESG strung up in effigy?  Was there sufficient > community push back to invalidate the IESG action? Was there no last > call?  Did the IESG refuse to add RSE directed black box warnings and > text? > > Basically, what you've proposed is a strawman to be knocked down.   My > guess is that any RSE that lets through something that *is* harmful to > the internet (rather than just thinks it might be) will not have had a > long tenure to start with.    What I think you're asking is similar to > the problems that editors of wide circulation publishers go through > all the time - to print or not to print.  In their case it might be > "do we have enough evidence that politician A has actually committed > adultery with staffer B" or "does printing C put D and E into > danger"?  The business side may say - Lawyers are fine with it and it > will make us money, but no editor worth their salt will let that be > the only decision criteria.   So yes, the RSE absolutely can prevent > publication, and yes absolutely the community (NOT the IESG, not the > IAB etc) can arrange to replace the RSE for cause if such cause exists. > > The RSE is not a rubber stamp.  If you want one, got to a body shop > and hire one. > > Later, Mike > > > --------------94D46C18C78893FE6901C5FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Sorry for the top post - and Q for EKR  but I started thinking about reverse strawman arguments.   Of the last 100-200 RFCs approved by the IESG, what percentage have had more than the mininum Yes votes?  I ask because you (EKR) framed this as the "IESG" approving a document, when in reality it could be that only one person is actually in favor of the document.  Approvals require at least one yes vote and at least 2/3 of the non recused to vote yes or no objection.  No Objections mean:

  • I read it, and I have no problem with it.
  • I read the protocol action, and I trust the sponsoring AD so have no problem.
  • I listened to the discussion, and I have no problem.

So we're theoretically (at the extreme) balancing the judgement of one person on the IESG against one other person (the RSE).   If the argument is "that can't happen" then that argument applies equally well to the RSE getting a document so poorly written or so technically flawed that the RSE would fall on their sword to prevent publication.

Later, Mike


On 5/12/2020 4:46 PM, Michael StJohns wrote:
On 5/12/2020 4:31 PM, Eric Rescorla wrote:


On Tue, May 12, 2020 at 1:25 PM Michael StJohns <msj@nthpermutation.com> wrote:
On 5/12/2020 4:16 PM, Eric Rescorla wrote:
In Tue, May 12, 2020 at 10:55 AM Michael StJohns <msj@nthpermutation.com> wrote:
> Mark (in another email) is correct that the level of independence of the
> current RSE is not the same as in the past - but I consider that a bug
> rather than a feature as it means that its possible for a small subset
> of the IETF community to affect the culture of the RFC series in ways
> that may not represent the interests of the broader community.

I want to zero in on this point, because I think it's useful to scope
out people's views of "independence".

Let me try to start with what's hopefully a simple case: suppose
that the IETF produces and the IESG approves a document to be
published as RFC that the RSE believes is harmful to the Internet
for technical reasons (it redefines IPv6 to have an 8 bit address,
say). Do you believe that the RSE should be able to refuse to
publish such a document?

-Ekr

Oooh   tricky.   I'd either have the RSE refer it to the ISE as publication as an April Fool's RFC, or I'd probably be the first to sign on to a petition to recall the entire IESG.     In any case, the answer is probably yes, the RSE should refuse to publish the document as an Internet standard.   That assumes that the RSE - with the appropriate technical advisors - has the skillset to determine said document is "harmful to the Internet".

Thanks for the quick answer.

I'm thinking maybe I made this too easy in that such a document has a "is the IESG on drugs" kind of flavor where any sane person would probably think they should throw a flag on the play.

But let's take a case where it's not a comically wrong decision but one that the RSE nevertheless strongly feels is harmful to the Internet. What then?

-Ekr


Let me refer you to an act in history where the IAB decided to make CMOT and SNMP co-standards.   That triggered the Kobe uprising and a complete reformation of the structure of the I*.   Jon was on the IAB at the time, and for policy reasons agreed with the designation.     That's sort of the reverse of what you mentioned, but it's also the same.   The community reacted badly to a bad decision by the deciding body and took action.  In the above instance, the RSE is still responsible to the community and they're going to be the final arbiters of whether or not the decision not to publish should stand.

For your example you didn't give any additional details - e.g. during last call were the IESG strung up in effigy?  Was there sufficient community push back to invalidate the IESG action?   Was there no last call?  Did the IESG refuse to add RSE directed black box warnings and text? 

Basically, what you've proposed is a strawman to be knocked down.   My guess is that any RSE that lets through something that *is* harmful to the internet (rather than just thinks it might be) will not have had a long tenure to start with.    What I think you're asking is similar to the problems that editors of wide circulation publishers go through all the time - to print or not to print.  In their case it might be "do we have enough evidence that politician A has actually committed adultery with staffer B" or "does printing C put D and E into danger"?  The business side may say - Lawyers are fine with it and it will make us money, but no editor worth their salt will let that be the only decision criteria.   So yes, the RSE absolutely can prevent publication, and yes absolutely the community (NOT the IESG, not the IAB etc) can arrange to replace the RSE for cause if such cause exists.

The RSE is not a rubber stamp.  If you want one, got to a body shop and hire one.

Later, Mike




--------------94D46C18C78893FE6901C5FC-- From nobody Tue May 12 14:45: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 6F5E53A0C20 for ; Tue, 12 May 2020 14:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2WzPm_R7ok0 for ; Tue, 12 May 2020 14:45:15 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 616BE3A0C1E for ; Tue, 12 May 2020 14:45:05 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04CLZRsY032683; Tue, 12 May 2020 14:45:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=3esLi3ncoypNvALfy7KgHACW47UBiQZm86LAVvk5sHg=; b=wm1wWXcj6D0tQwzi+bo2+smY6m+UyBvOj+DrpfUpxwNhR+aDpE8W/aCf5c6OJjgp5rn/ CX/+fuBg9wR2xCUXGslrUdMZNNfzp02o2rVoOyI5LRH7VLgLAU/tjv+k0j8nvQNqc8jK wrl68vBnX/9rwFjObraKSnY7b2OIfxtmtj7KgRosSs434INj3Uh6YkYKMdY/JIa+biBM 6ceoas0zbiVZ7ZzJYuKP+VflCbNXvySdKAZ/cn3Ms2d6B417rA57cWIs+F792QvKswxZ +BwK+5EngRBTNr5G6DcocUeJAq9nq70IEV0LETuGSIjLnfog6ugGxNncITpAVClujqax +g== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3103t104uq-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 12 May 2020 14:45:02 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QA80059SN31LY70@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 12 May 2020 14:45:02 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QA800U00MTZRL00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 12 May 2020 14:45:01 -0700 (PDT) X-Va-A: X-Va-T-CD: 0616d83e3aabd716c361d457dd4a4889 X-Va-E-CD: cc53f8bb3ec6d9be4ff9fd47d77a7389 X-Va-R-CD: e7dcbead7f2d929fd35cea94dfc007cd X-Va-CD: 0 X-Va-ID: d9dac2a2-742d-4a25-b507-db15c0684653 X-V-A: X-V-T-CD: 0616d83e3aabd716c361d457dd4a4889 X-V-E-CD: cc53f8bb3ec6d9be4ff9fd47d77a7389 X-V-R-CD: e7dcbead7f2d929fd35cea94dfc007cd X-V-CD: 0 X-V-ID: a4970e09-3267-4c48-af59-03782041e8d9 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-12_08:2020-05-11, 2020-05-12 signatures=0 Received: from [17.235.41.82] (unknown [17.235.41.82]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QA800IENN2XPW00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 12 May 2020 14:44:58 -0700 (PDT) From: Tommy Pauly Message-id: <2D428AC8-D717-4419-A999-D42F0D660606@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_4B9DE854-30F8-41CC-B824-9B7AFE3068A2" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Tue, 12 May 2020 14:44:57 -0700 In-reply-to: Cc: Eric Rescorla , Michael StJohns , rfced-future@iab.org To: Stephen Farrell References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-12_08:2020-05-11, 2020-05-12 signatures=0 Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:45:19 -0000 --Apple-Mail=_4B9DE854-30F8-41CC-B824-9B7AFE3068A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree that the RSE should not be considered able to block the = publication of a document that has followed the correct process for the = IETF stream. The IETF has a process with many steps for a good reason, = and any standards action requires IETF review, IETF Last Call, and IESG = approval (which could presumably be challenged for egregious errors). If = there is a technical error, then we should ensure that this process = should catch it, not rely on the RSE for that function. I=E2=80=99m a bit confused as to what grounds the RSE would have for = blocking publication. Looking back at the RFCs that defined the = standardization process, it seems pretty clear what the relationship is = between the IETF and the RFC editor. RFC 2026 explains =E2=80=9CThe Internet Standards Process=E2=80=9D. = Section 6.1.2 = (https://www.rfc-editor.org/rfc/rfc2026.html#section-6.1.2) explains the = role of the IESG in reviewing and approving standards. The step of = publication (https://www.rfc-editor.org/rfc/rfc2026.html#section-6.1.3) = is not described as a technical review, but as a simple action that the = IESG requests of the editor: If a standards action is approved, notification is sent to the RFC Editor and copied to the IETF with instructions to publish the specification as an RFC. RFC 3932 also provides a good insight into the process. In Section 1, it = lists two ways for a standards track document to be published: o IETF Working Group (WG) to Standards Track: Includes WG consensus, review in the IETF, IETF Last Call, and IESG approval o Area Director (AD) sponsored to Standards Track: Includes review in the IETF, IETF Last Call, and IESG approval The majority of the document explains the change that was made to *no = longer require* the IESG to sign off technically on all RFC Editor = documents that did not belong to the IETF stream. However, the technical = approval of IETF standard documents clearly still lies with IESG. Thanks, Tommy > On May 12, 2020, at 1:48 PM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 12/05/2020 21:16, Eric Rescorla wrote: >> In Tue, May 12, 2020 at 10:55 AM Michael StJohns = >> wrote: >>> Mark (in another email) is correct that the level of independence of = the >>> current RSE is not the same as in the past - but I consider that a = bug >>> rather than a feature as it means that its possible for a small = subset >>> of the IETF community to affect the culture of the RFC series in = ways >>> that may not represent the interests of the broader community. >>=20 >> I want to zero in on this point, because I think it's useful to scope >> out people's views of "independence". >>=20 >> Let me try to start with what's hopefully a simple case: suppose >> that the IETF produces and the IESG approves a document to be >> published as RFC that the RSE believes is harmful to the Internet >> for technical reasons (it redefines IPv6 to have an 8 bit address, >> say). Do you believe that the RSE should be able to refuse to >> publish such a document? >=20 > FWIW, I think the RSE ought not be able to block > publication of IETF stream documents. The RSE could > publish a document opining that the IESG must be > on drugs I guess. I'd also be ok with other forms > of puhshback (e.g. mailing ietf@ietf asking WTF) > but I'd stop short of the RSE being able to block. >=20 > S. >=20 >=20 >>=20 >> -Ekr >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc>--=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_4B9DE854-30F8-41CC-B824-9B7AFE3068A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree that the RSE should not be considered able to block the = publication of a document that has followed the correct process for the = IETF stream. The IETF has a process with many steps for a good reason, = and any standards action requires IETF review, IETF Last Call, and IESG = approval (which could presumably be challenged for egregious errors). If = there is a technical error, then we should ensure that this process = should catch it, not rely on the RSE for that function.
I=E2=80=99m a bit confused as to what = grounds the RSE would have for blocking publication. Looking back at the = RFCs that defined the standardization process, it seems pretty clear = what the relationship is between the IETF and the RFC editor.

RFC 2026 explains =E2=80=9C= The Internet Standards Process=E2=80=9D. Section 6.1.2 (https://www.rfc-editor.org/rfc/rfc2026.html#section-6.1.2) = explains the role of the IESG in reviewing and approving standards. = The step of publication (https://www.rfc-editor.org/rfc/rfc2026.html#section-6.1.3)&= nbsp;is not described as a technical review, = but as a simple action that the IESG requests of the = editor:

If a standards action is approved, = notification is sent to the RFC
   Editor = and copied to the IETF with instructions to publish the
   specification as an RFC.

RFC 3932 also provides a good insight = into the process. In Section 1, it lists two ways for a standards track = document to be published:

   o  IETF Working Group = (WG) to Standards Track: Includes WG consensus,
      review in the IETF, IETF Last Call, and = IESG approval
   o =  Area Director (AD) sponsored to Standards Track: Includes = review
      in the IETF, IETF Last = Call, and IESG approval

The majority of the document explains = the change that was made to *no longer require* the IESG to sign off = technically on all RFC Editor documents that did not belong to the IETF = stream. However, the technical approval of IETF standard documents = clearly still lies with IESG.

Thanks,
Tommy

On May 12, 2020, at 1:48 PM, Stephen Farrell = <stephen.farrell@cs.tcd.ie> wrote:



On 12/05/2020 21:16, Eric Rescorla wrote:
In Tue, May 12, 2020 at = 10:55 AM Michael StJohns <msj@nthpermutation.com>
wrote:
Mark (in another email) = is correct that the level of independence of the
current = RSE is not the same as in the past - but I consider that a bug
rather than a feature as it means that its possible for a = small subset
of the IETF community to affect the culture = of the RFC series in ways
that may not represent the = interests of the broader community.

I want to zero in on this point, because I think it's useful = to scope
out people's views of "independence".

Let me try to start with what's hopefully a = simple case: suppose
that the IETF produces and the IESG = approves a document to be
published as RFC that the RSE = believes is harmful to the Internet
for technical reasons = (it redefines IPv6 to have an 8 bit address,
say). Do you = believe that the RSE should be able to refuse to
publish = such a document?

FWIW, I think = the RSE ought not be able to block
publication of IETF = stream documents. The RSE could
publish a document opining = that the IESG must be
on drugs I guess. I'd also be ok = with other forms
of puhshback (e.g. mailing ietf@ietf = asking WTF)
but I'd stop short of the RSE being able to = block.

S.



-Ekr


<0x5AB2FAF= 17B172BEA.asc>--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

= --Apple-Mail=_4B9DE854-30F8-41CC-B824-9B7AFE3068A2-- From nobody Tue May 12 14:45: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 3B5D33A0C1C for ; Tue, 12 May 2020 14:45:32 -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, 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 OC257sf5N_g2 for ; Tue, 12 May 2020 14:45: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 343E83A0C1E for ; Tue, 12 May 2020 14:45: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.15.2/8.15.2) with ESMTPSA id 04CLjSk7001402 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 May 2020 16:45:30 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589319930; bh=T2/c6nT2lliOQ38JT3Jf6hXAp/pAYrUWtSSXXwTDMNU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=h5jK5jROkNDdi1oLujRYrbVkZaZvDEBlq3WWYL5H/QNvml2BCRSuwDZxV6P9Y1dKq NYjn+NYJyMtcA8eHjL7eOT4t+/4bwnTao4HkvGCQa14DbYy5zH6W5manQ93XHEiVf5 UGQhDVlFMpAtKL7aqJUsGc7QQWZ8nR04LY/ghZjU= 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: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <36d38a87-0212-15c2-4d33-4dde29db59d9@nthpermutation.com> From: Adam Roach Message-ID: Date: Tue, 12 May 2020 16:45:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <36d38a87-0212-15c2-4d33-4dde29db59d9@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:45:32 -0000 On 5/12/2020 4:33 PM, Michael StJohns wrote: > So we're theoretically (at the extreme) balancing the judgement of one > person on the IESG against one other person (the RSE) Even if we accept this fantastically unlikely scenario (I suppose you're envisioning an AD sponsoring and shepherding a document they themselves wrote?), this is only true if you discount the last-call process. I haven't yet seen proposals that would allow skipping it. /a From nobody Tue May 12 14:57: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 094253A0C2B for ; Tue, 12 May 2020 14:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydIt3w384WzF for ; Tue, 12 May 2020 14:57:06 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 0E14A3A0B07 for ; Tue, 12 May 2020 14:57:05 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id s186so13511776qkd.4 for ; Tue, 12 May 2020 14:57:05 -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=iFklQw0v4BWAK7hjJNnEMXrniUO1cr6GaJmG1XlfSI0=; b=LPATkIn7sdjt01vS/26Fps8TciEysUjLJx/75qDsCFBE1zC8zKgGqiH6Az7wrL/Dxo 65lrPY7DxbAzh3V7EI336qbTCJCVTBXdKc5e+/+pxudsg+MWXKs/0gNtuA+5Wga2S9oO t4glKmDTx62aOmGzGl+jsKdAOzD005HTANeXKVoBGPRe9BoDvcaqKTK2xRyRHwznzu0g pItqtf/NST8625r1LSS6OGBrEIrMbYyA7q1EfZry9eXMO9f9PYiB34IfuQ3SecGcXxe5 7ICbbEqfcwXxsrgCb1pUKEW1cxe7PVEFzC18YjlnmHz8Y44Hu/ySP47ieA5WGEGAt0Hs G6BA== 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=iFklQw0v4BWAK7hjJNnEMXrniUO1cr6GaJmG1XlfSI0=; b=RYCXjLGjec8NbsZsv6KaKbKJLFsP7J3RI8Jd5soqgJTnw4emvataAvc0xIOzbhIahd Z28XTeXK/y8FuXiN1TyA1bYP0O0A4DhT3APkRJaAw87mUTYi9gdlMuiSbEESXFMawSKd GNe0LqIqgJfJvnharRq6KPpNwZJqFDBZUKXUiYnVP47mEfenWgrK0wLc02sXvfpKzmBB Si8aOgwfY3gnUS+TdbU3VMg/zpbkVFlEUcgVi7KuLU3UHwD9ZyuWPbRGP5NxtDU9w+Dd s2CTNUFfxrcOu0C85eY4sfdH4DTtvgwRxQm87+4EZBr0JXHMFERgsvThKe4EkGdSWbI9 8IGA== X-Gm-Message-State: AGi0Puagbya2+AF1JWCa5oSasXDlIMYDz2RV3lwQEivAkKOVLe3b48MH I+zWLqXxw2H7MT+8Swz0UNAYoorx88KqWQ== X-Google-Smtp-Source: APiQypJF2hUf58biZIr4IA3vTPOXLectUQk1ixKh4VCVUQ06BTELEsf9sQU0Q4CGE2p2mB/TnZV3IA== X-Received: by 2002:a37:9a41:: with SMTP id c62mr23842959qke.244.1589320624388; Tue, 12 May 2020 14:57:04 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id g66sm9017484qkb.122.2020.05.12.14.57.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 14:57:03 -0700 (PDT) To: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <77479725-3b0c-8a5f-d15d-aee54abdae7d@nostrum.com> From: Michael StJohns Message-ID: Date: Tue, 12 May 2020 17:57:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <77479725-3b0c-8a5f-d15d-aee54abdae7d@nostrum.com> Content-Type: multipart/alternative; boundary="------------FCBCC4A37FE05D6904081A20" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:57:08 -0000 This is a multi-part message in MIME format. --------------FCBCC4A37FE05D6904081A20 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/12/2020 5:30 PM, Adam Roach wrote: > On 5/12/2020 3:25 PM, Michael StJohns wrote: >> On 5/12/2020 4:16 PM, Eric Rescorla wrote: >>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns >>> > wrote: >>> > Mark (in another email) is correct that the level of independence >>> of the >>> > current RSE is not the same as in the past - but I consider that a bug >>> > rather than a feature as it means that its possible for a small subset >>> > of the IETF community to affect the culture of the RFC series in ways >>> > that may not represent the interests of the broader community. >>> >>> I want to zero in on this point, because I think it's useful to scope >>> out people's views of "independence". >>> >>> Let me try to start with what's hopefully a simple case: suppose >>> that the IETF produces and the IESG approves a document to be >>> published as RFC that the RSE believes is harmful to the Internet >>> for technical reasons (it redefines IPv6 to have an 8 bit address, >>> say). Do you believe that the RSE should be able to refuse to >>> publish such a document? >>> >>> -Ekr >> >> Oooh   tricky.   I'd either have the RSE refer it to the ISE as >> publication as an April Fool's RFC, or I'd probably be the first to >> sign on to a petition to recall the entire IESG. In any case, the >> answer is probably yes, the RSE should refuse to publish the document >> as an Internet standard.   That assumes that the RSE - with the >> appropriate technical advisors - has the skillset to determine said >> document is "harmful to the Internet". >> > > I think we can appreciate that the example was chosen to be > fantastical so as to not focus discussion on the technical matter as > much as the degree of control the RSE is afforded over the technical > contents of a document. > > Now, I do recall a recent anecdote about Postel himself heatedly > refusing to publish a specification he felt was technically misguided > [1], so this authority did exist with the position at some point. > Although never explicitly revoked, RFC 4844, section 4.1 et seq makes > it pretty clear that the RSE has approval authority over precisely one > stream (the Independent Submission stream). To the extent that the IAB > had authority to publish RFC 4844, I think it makes it clear that the > scope of authority had been pared back substantially since the "I am > not going to publish a faulty specification as an RFC" days of 1991. > From RFC 4844: 4.4.2 . Operational Implementation The RFC Editor is responsible for ensuring that the RFC Series guidelines are upheld within the RFC Series. That I would argue is the grant of authority allowing an RSE to reject a given document. There are a number of places where documents can be sent back post-approval and pre-publication and are.  I'd also use "The *mission* of the *IETF* is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet." Hmm. Can anyone provide me a pointer to a document that describes the purpose and mission of the RFC series? Especially one without reference to the RSE? I went looking for a combination of "RFC" and "quality" and didn't find any document I'd consider normative using those terms. Mike > I'm not entirely sure my analysis above is all that useful, though, as > this is the "rfced-future" discussion rather than the "rfced-history" > discussion, and so it seems more sensible to focus on meeting the > needs of the Internet community in 2020 and beyond than is is to lean > on the historical narrative. > > And so more to the point: I think that the IETF community writ large > would be floored if a working group produced a document, the IETF > found consensus on it during last call, the IESG approved it, and then > the RSE refused to publish it (or imposed technical changes on its > contents). Ditto for the IRTF and their documents. So, if we're > matching authority with community expectations -- at least for a large > swath of the relevant community -- I think the answer above of "the > RSE should refuse to publish the document" is exactly wrong. > > /a > > ____ > [1] > https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/ > > --------------FCBCC4A37FE05D6904081A20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/12/2020 5:30 PM, Adam Roach wrote:
On 5/12/2020 3:25 PM, Michael StJohns wrote:
On 5/12/2020 4:16 PM, Eric Rescorla wrote:
In Tue, May 12, 2020 at 10:55 AM Michael StJohns <msj@nthpermutation.com> wrote:
> Mark (in another email) is correct that the level of independence of the
> current RSE is not the same as in the past - but I consider that a bug
> rather than a feature as it means that its possible for a small subset
> of the IETF community to affect the culture of the RFC series in ways
> that may not represent the interests of the broader community.

I want to zero in on this point, because I think it's useful to scope
out people's views of "independence".

Let me try to start with what's hopefully a simple case: suppose
that the IETF produces and the IESG approves a document to be
published as RFC that the RSE believes is harmful to the Internet
for technical reasons (it redefines IPv6 to have an 8 bit address,
say). Do you believe that the RSE should be able to refuse to
publish such a document?

-Ekr

Oooh   tricky.   I'd either have the RSE refer it to the ISE as publication as an April Fool's RFC, or I'd probably be the first to sign on to a petition to recall the entire IESG.     In any case, the answer is probably yes, the RSE should refuse to publish the document as an Internet standard.   That assumes that the RSE - with the appropriate technical advisors - has the skillset to determine said document is "harmful to the Internet".


I think we can appreciate that the example was chosen to be fantastical so as to not focus discussion on the technical matter as much as the degree of control the RSE is afforded over the technical contents of a document.

Now, I do recall a recent anecdote about Postel himself heatedly refusing to publish a specification he felt was technically misguided [1], so this authority did exist with the position at some point. Although never explicitly revoked, RFC 4844, section 4.1 et seq makes it pretty clear that the RSE has approval authority over precisely one stream (the Independent Submission stream). To the extent that the IAB had authority to publish RFC 4844, I think it makes it clear that the scope of authority had been pared back substantially since the "I am not going to publish a faulty specification as an RFC" days of 1991.


From RFC 4844:

4.4.2.  Operational Implementation


   The RFC Editor is responsible for ensuring that the RFC Series
   guidelines are upheld within the RFC Series.

That I would argue is the grant of authority allowing an RSE to reject a given document. There are a number of places where documents can be sent back post-approval and pre-publication and are.  I'd also use "The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet."

Hmm. Can anyone provide me a pointer to a document that describes the purpose and mission of the RFC series? Especially one without reference to the RSE? I went looking for a combination of "RFC" and "quality" and didn't find any document I'd consider normative using those terms.


Mike

I'm not entirely sure my analysis above is all that useful, though, as this is the "rfced-future" discussion rather than the "rfced-history" discussion, and so it seems more sensible to focus on meeting the needs of the Internet community in 2020 and beyond than is is to lean on the historical narrative.

And so more to the point: I think that the IETF community writ large would be floored if a working group produced a document, the IETF found consensus on it during last call, the IESG approved it, and then the RSE refused to publish it (or imposed technical changes on its contents). Ditto for the IRTF and their documents. So, if we're matching authority with community expectations -- at least for a large swath of the relevant community -- I think the answer above of "the RSE should refuse to publish the document" is exactly wrong.

/a

____
[1] https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/



--------------FCBCC4A37FE05D6904081A20-- From nobody Tue May 12 14:57: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 ADF363A0C2B for ; Tue, 12 May 2020 14:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.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, MISSING_HEADERS=1.021, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 DxVZ3tXl6Un1 for ; Tue, 12 May 2020 14:57:21 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9763A0B07 for ; Tue, 12 May 2020 14:57:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49MBVT1TDdz6GD56 for ; Tue, 12 May 2020 14:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1589320641; bh=oO+4ud3BbQU0E0QACJ6mPGYlKCbzEPtwIyf8+xxYZXQ=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=a3qSdMHcO4lPm+LbamOMQv2WvDfCXykXJ/7iMfbSPVp3/RasqICQI5KtEsabdJxXK nvVhNz6W5INICvwdDKmVDN9FHetKOo7my3y/2BnUh5h+tS49hWWx/ojy2lL8HVIf5P 9TEDnV3ntzQ71lCfZ6fZ8YXzorou3HsIMiTJHpPw= 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 49MBVS5f47z6GD2Z for ; Tue, 12 May 2020 14:57:20 -0700 (PDT) Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <77479725-3b0c-8a5f-d15d-aee54abdae7d@nostrum.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 12 May 2020 17:57:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <77479725-3b0c-8a5f-d15d-aee54abdae7d@nostrum.com> 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-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:57:23 -0000 Can we step this down? On the one hand, no, I do not think the RSE should have the authority to tell the IESG that the IETF can not publish particular technical content on technical grounds. On the other hand, if a technically competent RSE is that concerned about a document, I think we probably have a whole lot of other problems that need to be addressed. Whether the RSE actually publishes that document or not is probably the least of our worries. And I do think the RSE should have the authority to say to any stream "turn this into proper English before the RPC will process it." Yours, Joel On 5/12/2020 5:30 PM, Adam Roach wrote: > On 5/12/2020 3:25 PM, Michael StJohns wrote: >> On 5/12/2020 4:16 PM, Eric Rescorla wrote: >>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns >>> > wrote: >>> > Mark (in another email) is correct that the level of independence >>> of the >>> > current RSE is not the same as in the past - but I consider that a bug >>> > rather than a feature as it means that its possible for a small subset >>> > of the IETF community to affect the culture of the RFC series in ways >>> > that may not represent the interests of the broader community. >>> >>> I want to zero in on this point, because I think it's useful to scope >>> out people's views of "independence". >>> >>> Let me try to start with what's hopefully a simple case: suppose >>> that the IETF produces and the IESG approves a document to be >>> published as RFC that the RSE believes is harmful to the Internet >>> for technical reasons (it redefines IPv6 to have an 8 bit address, >>> say). Do you believe that the RSE should be able to refuse to >>> publish such a document? >>> >>> -Ekr >> >> Oooh   tricky.   I'd either have the RSE refer it to the ISE as >> publication as an April Fool's RFC, or I'd probably be the first to >> sign on to a petition to recall the entire IESG.     In any case, the >> answer is probably yes, the RSE should refuse to publish the document >> as an Internet standard.   That assumes that the RSE - with the >> appropriate technical advisors - has the skillset to determine said >> document is "harmful to the Internet". >> > > I think we can appreciate that the example was chosen to be fantastical > so as to not focus discussion on the technical matter as much as the > degree of control the RSE is afforded over the technical contents of a > document. > > Now, I do recall a recent anecdote about Postel himself heatedly > refusing to publish a specification he felt was technically misguided > [1], so this authority did exist with the position at some point. > Although never explicitly revoked, RFC 4844, section 4.1 et seq makes it > pretty clear that the RSE has approval authority over precisely one > stream (the Independent Submission stream). To the extent that the IAB > had authority to publish RFC 4844, I think it makes it clear that the > scope of authority had been pared back substantially since the "I am not > going to publish a faulty specification as an RFC" days of 1991. > > I'm not entirely sure my analysis above is all that useful, though, as > this is the "rfced-future" discussion rather than the "rfced-history" > discussion, and so it seems more sensible to focus on meeting the needs > of the Internet community in 2020 and beyond than is is to lean on the > historical narrative. > > And so more to the point: I think that the IETF community writ large > would be floored if a working group produced a document, the IETF found > consensus on it during last call, the IESG approved it, and then the RSE > refused to publish it (or imposed technical changes on its contents). > Ditto for the IRTF and their documents. So, if we're matching authority > with community expectations -- at least for a large swath of the > relevant community -- I think the answer above of "the RSE should refuse > to publish the document" is exactly wrong. > > /a > > ____ > [1] > https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/ > > From nobody Tue May 12 15:01: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 EBF563A0C30 for ; Tue, 12 May 2020 15:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwHjJHQpkxUU for ; Tue, 12 May 2020 15:01:07 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541513A0BED for ; Tue, 12 May 2020 15:01:07 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id y22so2727884qki.3 for ; Tue, 12 May 2020 15:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/PL2GKrFUgjmaOATSkI2eS67i9r9lhKDdid7hYxwNac=; b=a1sS5ZMteovwHF3VxZBFrgloTPjAllsLTpOFCHRROtCyTz21xW4dtTWVms6OhJ/VEI RJgrCvzJuKuQzAMxoLkG7BbjLv9JZ9aDIJ2vP5+U6Gj7/FYtKCdCJXDkKVdMeSmT9BKu 4WQX5MKZOJ04kiorGnBNp6iNaKcHbGQJgMNg5iVecYMSr2lyPD8oATbOdz3LzxFWuxNV 0N2evVT3Dla4SehTO3w4zjCCKKYaYNN7/jFcSTBVLAk6gCAh2FqkBEzrW68vDTUWRMbt UmHNzWHyjSH8VKNrY5//VidSpfuN1EkcHIJ5YuUBZrkGiJCjr/onfARqtJUL+NhfUT+m fwFQ== 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=/PL2GKrFUgjmaOATSkI2eS67i9r9lhKDdid7hYxwNac=; b=Zp0de16VvfuGpib6c+1Vvn7FJv8hKNkKje0g0ImHcyHTyBb/caVSA2AdOU38iTD6IA jVe3PUvAw5be+IYXQdk1Gg7DJI1xEbLcRvpVy6wpQsjIArTrMpAm8vZPGmPau306SThZ Zo2Oq5psFkYwpNYV9lpxwhFZM7vFhk5yIBXNLB7bri5sLouTm2wMrhfFFaDzl/2Eu9d5 1XMZEj1WPbpB0Okz6PRZUw0OmiKzVk9+wtruj+NeMAs2Bgv044K4QEx0vihYkgl9rTKw IS5nFLRj7qPBsguzSE6mxfAMks+bVwuVe5tJ1yFJQcbkxupbkBHX18XOQrUfBa1KgcmL PUSg== X-Gm-Message-State: AGi0PubaSB3UOdLoEeyevF1Uzcv7Wpj47Ln+X4XEreS+Jr3R8kVS72e2 kiG8WN30fQ+kR3aDRgmi0xnCH54WfO2nsx1iW47Xn04F X-Google-Smtp-Source: APiQypKAUF4I4lT3RvuvwT+grJ/YBEGLuG+0BzxMv8J6Q7CoYy7Kg7xcifAhq2YMpMcuQPAClkZhrUrWSw355KmjL/o= X-Received: by 2002:ae9:e80a:: with SMTP id a10mr23719115qkg.192.1589320866276; Tue, 12 May 2020 15:01:06 -0700 (PDT) MIME-Version: 1.0 References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> In-Reply-To: <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> From: "Andrew G. Malis" Date: Tue, 12 May 2020 18:00:55 -0400 Message-ID: To: Brian E Carpenter Cc: Mark Nottingham , John C Klensin , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000ab2d9505a57a99d6" Archived-At: Subject: Re: [Rfced-future] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 22:01:10 -0000 --000000000000ab2d9505a57a99d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian, I think that is an error. In section 5, RFC 7990 also says: The final XML file produced by the RFC Editor will be considered the canonical format for RFCs; it is the lowest common denominator that holds all the information intended for an RFC. PDF/A-3 will be the publication format offered in response to subpoenas for RFCs published through this new process and will be developed with an eye towards long-term archival storage. So this section makes the distinction between "canonical" and "long term archival storage"'. Cheers, Andy On Tue, May 12, 2020 at 5:05 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I note that RFC7990 says: > > > Canonical format: the authorized, recognized, accepted, and > > archived version of the document > > This could well be an error. Making our XML dialect the *canonical* > format was what most of us thought about. Maybe a specified rendering > that could, in theory, be drawn on parchment should be the *archival* > format. > > Since RFC7990 is a request for comments, we can choose to update it. > > This should go on the next RSE's "to do" list, I think. > > Regards > Brian Carpenter > > On 12-May-20 19:15, Mark Nottingham wrote: > > Hi John, > > > >> On 12 May 2020, at 5:03 pm, John C Klensin wrote: > >> > >> Mark, I fear that takes us around in a bit of a circle, albeit > >> an important one. I was forcefully educated (one might say > >> "beaten up") some years ago by an Archivist (his job title) > >> associated with a national repository library in the north of > >> Europe. He explained that it was very hard to have a > >> conversation about what was "archival" or about the meaning of > >> the closely-related term "permanent" with people in computer > >> fields (especially web-related ones) because we tended to think > >> of "permanence" as 10 - 20 years. He claimed that most people > >> he had encountered from North America or the South Pacific had > >> similar problems with believing permanence, in practice, could > >> be considered a few centuries but that he and his colleagues > >> needed to work in terms of at least several millennia and that > >> those differences put an entirely different spin on things. > > > > This does not shock me, but then I've interned in an art museum, where > the challenges of conservatorship were painfully obvious. > > > > > >> That story is important in the current context for two reasons: > >> > >> * While I consider the decision made and hence not part of the > >> current RFC Editor Futures discussion (even though I, and > >> apparently others, have growing doubts about how we are > >> implementing it), a conversation with almost any (I don't know > >> of exceptions, but maybe there are some) professional archivist > >> about treating a source format that requires considerable > >> compilation and reference to external sources and mechanisms to > >> get to a form people are comfortable reading as an archival form > >> will typically be greeted with laughter and/or comments to the > >> effect that we should come back in a hundred years and show them > >> that XML is still around and that it is the same, or at least > >> completely backward-compatible, XML. If they, and their > >> considerations, are to be taken seriously as we talk about > >> "archival", things are broken already and comments about the > >> merits of continuing to dig when one finds oneself in a deep > >> hole may be relevant. > > > > I tend to agree; if I'd been more involved in the IETF when this > decision was made, I would have fought it (based upon my early experience= s > with XML, more than anything). > > > > > >> * There have been several discussions in recent years about > >> treating IETF specifications as living documents or with some > >> other arrangement in which issues are folded in as soon as they > >> are detected and at least tentative conclusions reached about > >> how to proceed. I don't know whether we need to resolve those > >> proposals before moving forward with discussions about the > >> future of the RFC Series and its management and organization (I > >> hope we don't because the community seems quite divided to me). > >> However, I think we need to understand that moving in that > >> direction, even if we make periodic snapshots and publish them > >> as RFCs, would profoundly change the character of the series as > >> providing a clearly-identifiable (and "archival") record of the > >> evolution of Internet technology and standards. > > > > I think that people are becoming slightly absolutist when they talk > about this subject, but worse, they perceive those on "the other side" as > *really* absolutist. > > > > I hope no one seriously thinks that "archival" means that we can't > change _any_ aspect of the series, ever -- that it's a machine that must > run on in its current form until its doom. I also hope that no one thinks > that changing things means that it must be possible to change any charact= er > / bit in any RFC at any time. > > > > If we can put those extremes safely out of the way and focus on what th= e > needs of the archival and other communities are, we might make some > progress. > > > > Maybe we could give some guidance here, but I agree we do have some > other issues to dispose of first. > > > > > >>> ... > >>>> =E2=80=A2 The RFC Series is community property and must operate o= n > >>>> behalf of the community as a whole. > >>>> > >>>> =E2=80=A2 The exact definition of the relevant community = is open > >>>> for debate. One definition is: the IETF, the IRTF, the IA= B > >>>> and the many other people who have contributed to, or mad= e > >>>> use of, the RFC Series over the last fifty years. > >>>> > >>>> =E2=80=A2 Major decisions about the future of the RFC Series must > >>>> be taken by a rough consensus of this very broad community. > >>>> > >>>> =E2=80=A2 How to reach out to this community and judge it= s > >>>> consensus is in itself a big question. > >>> > >>> I think it's widely agreed that your conclusions about the > >>> series not being 'owned' by any of the I* are correct. > >>> However, I'd suggest that we can reach out to and judge > >>> consensus of that community just like we do in any other area > >>> -- establish a venue (e.g., a WG) and make it known that if > >>> you're a stakeholder who's interested, that's the appropriate > >>> place to contribute. Doubtless some people will not choose to > >>> come, but that's their choice. Others might advocate on their > >>> behalf; we already see that with civil society organisations > >>> being involved in the IETF's work. > >> > >> One problem is that one important audience for the Series, or at > >> least the documents we claim are standards (or to which assorted > >> parties claim conformance) are people writing procurement > >> documents (RFPs, contracts, SLAs, etc.). The odds that we will > >> get a reliable representation from that community even if we > >> could reach them are, I think, pretty small. The odds that we > >> could get them to participate in a WG-like arrangement? > >> Probably much lower. But, at least if one were to assume a free > >> market in which alternatives exist, those people are key to > >> determine if our standards go anywhere. Indeed, when they write > >> contracts that require conformance and try to enforce them, they > >> are actually the closest we get to actually having a Protocol > >> Police. And, by the way, they, and the kinds of documents they > >> are willing to work with, interact with the "living document" > >> ideas as well: IMO at least, we dare not ignore them because we > >> cannot get their participation on our normal terms. > > > > Thank you; this is exactly how things sit already in many WGs, e.g., > HTTP. The decisions we make impact many people who don't even know we exi= st > on a daily basis. > > > > Cheers, > > > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > . > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000ab2d9505a57a99d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian,

I think that is an error. In sec= tion 5, RFC 7990 also says:

=C2=A0 =C2=A0The final= XML file produced by the RFC Editor will be considered the
=C2=A0 =C2= =A0canonical format for RFCs; it is the lowest common denominator that
= =C2=A0 =C2=A0holds all the information intended for an RFC.=C2=A0 PDF/A-3 w= ill be the
=C2=A0 =C2=A0publication format offered in response to subpoe= nas for RFCs
=C2=A0 =C2=A0published through this new process and will be= developed with an eye
=C2=A0 =C2=A0towards long-term archival storage.<= br>

So this section makes the distinction between = "canonical" and "long term archival storage"'.

Cheers,
Andy




On Tue, May 12, 2020 at 5:05 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
I n= ote that RFC7990 says:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Canonical format: the authorized, recognized= , accepted, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0archived version of the document

This could well be an error. Making our XML dialect the *canonical*
format was what most of us thought about. Maybe a specified rendering
that could, in theory, be drawn on parchment should be the *archival*
format.

Since RFC7990 is a request for comments, we can choose to update it.

This should go on the next RSE's "to do" list, I think.

Regards
=C2=A0 =C2=A0Brian Carpenter

On 12-May-20 19:15, Mark Nottingham wrote:
> Hi John,
>
>> On 12 May 2020, at 5:03 pm, John C Klensin <john-ietf@jck.com> wrote:
>>
>> Mark, I fear that takes us around in a bit of a circle, albeit
>> an important one. I was forcefully educated (one might say
>> "beaten up") some years ago by an Archivist (his job tit= le)
>> associated with a national repository library in the north of
>> Europe.=C2=A0 =C2=A0He explained that it was very hard to have a >> conversation about what was "archival" or about the mean= ing of
>> the closely-related term "permanent" with people in comp= uter
>> fields (especially web-related ones) because we tended to think >> of "permanence" as 10 - 20 years.=C2=A0 He claimed that = most people
>> he had encountered from North America or the South Pacific had
>> similar problems with believing permanence, in practice, could
>> be considered a few centuries but that he and his colleagues
>> needed to work in terms of at least several millennia and that
>> those differences put an entirely different spin on things.
>
> This does not shock me, but then I've interned in an art museum, w= here the challenges of conservatorship were painfully obvious.
>
>
>> That story is important in the current context for two reasons: >>
>> * While I consider the decision made and hence not part of the
>> current RFC Editor Futures discussion (even though I, and
>> apparently others, have growing doubts about how we are
>> implementing it), a conversation with almost any (I don't know=
>> of exceptions, but maybe there are some) professional archivist >> about treating a source format that requires considerable
>> compilation and reference to external sources and mechanisms to >> get to a form people are comfortable reading as an archival form >> will typically be greeted with laughter and/or comments to the
>> effect that we should come back in a hundred years and show them >> that XML is still around and that it is the same, or at least
>> completely backward-compatible, XML.=C2=A0 If they, and their
>> considerations, are to be taken seriously as we talk about
>> "archival", things are broken already and comments about= the
>> merits of continuing to dig when one finds oneself in a deep
>> hole may be relevant.
>
> I tend to agree; if I'd been more involved in the IETF when this d= ecision was made, I would have fought it (based upon my early experiences w= ith XML, more than anything).
>
>
>> * There have been several discussions in recent years about
>> treating IETF specifications as living documents or with some
>> other arrangement in which issues are folded in as soon as they >> are detected and at least tentative conclusions reached about
>> how to proceed.=C2=A0 I don't know whether we need to resolve = those
>> proposals before moving forward with discussions about the
>> future of the RFC Series and its management and organization (I >> hope we don't because the community seems quite divided to me)= .
>> However, I think we need to understand that moving in that
>> direction, even if we make periodic snapshots and publish them
>> as RFCs, would profoundly change the character of the series as >> providing a clearly-identifiable (and "archival") record= of the
>> evolution of Internet technology and standards.
>
> I think that people are becoming slightly absolutist when they talk ab= out this subject, but worse, they perceive those on "the other side&qu= ot; as *really* absolutist.
>
> I hope no one seriously thinks that "archival" means that we= can't change _any_ aspect of the series, ever -- that it's a machi= ne that must run on in its current form until its doom. I also hope that no= one thinks that changing things means that it must be possible to change a= ny character / bit in any RFC at any time.
>
> If we can put those extremes safely out of the way and focus on what t= he needs of the archival and other communities are, we might make some prog= ress.
>
> Maybe we could give some guidance here, but I agree we do have some ot= her issues to dispose of first.
>
>
>>> ...
>>>>=C2=A0 =C2=A0 =E2=80=A2 The RFC Series is community propert= y and must operate on
>>>>=C2=A0 =C2=A0 behalf of the community as a whole.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 The exa= ct definition of the relevant community is open
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for debate. One d= efinition is: the IETF, the IRTF, the IAB
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and the many othe= r people who have contributed to, or made
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use of, the RFC S= eries over the last fifty years.
>>>>
>>>>=C2=A0 =C2=A0 =E2=80=A2 Major decisions about the future of= the RFC Series must
>>>>=C2=A0 =C2=A0 be taken by a rough consensus of this very br= oad community.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 How to = reach out to this community and judge its
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consensus is in i= tself a big question.
>>>
>>> I think it's widely agreed that your conclusions about the=
>>> series not being 'owned' by any of the I* are correct.=
>>> However, I'd suggest that we can reach out to and judge >>> consensus of that community just like we do in any other area<= br> >>> -- establish a venue (e.g., a WG) and make it known that if >>> you're a stakeholder who's interested, that's the = appropriate
>>> place to contribute. Doubtless some people will not choose to<= br> >>> come, but that's their choice. Others might advocate on th= eir
>>> behalf; we already see that with civil society organisations >>> being involved in the IETF's work.
>>
>> One problem is that one important audience for the Series, or at >> least the documents we claim are standards (or to which assorted >> parties claim conformance) are people writing procurement
>> documents (RFPs, contracts, SLAs, etc.).=C2=A0 The odds that we wi= ll
>> get a reliable representation from that community even if we
>> could reach them are, I think, pretty small.=C2=A0 =C2=A0The odds = that we
>> could get them to participate in a WG-like arrangement?
>> Probably much lower.=C2=A0 But, at least if one were to assume a f= ree
>> market in which alternatives exist, those people are key to
>> determine if our standards go anywhere.=C2=A0 Indeed, when they wr= ite
>> contracts that require conformance and try to enforce them, they >> are actually the closest we get to actually having a Protocol
>> Police.=C2=A0 And, by the way, they, and the kinds of documents th= ey
>> are willing to work with, interact with the "living document&= quot;
>> ideas as well:=C2=A0 IMO at least, we dare not ignore them because= we
>> cannot get their participation on our normal terms.
>
> Thank you; this is exactly how things sit already in many WGs, e.g., H= TTP. The decisions we make impact many people who don't even know we ex= ist on a daily basis.
>
> Cheers,
>
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>
> .
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000ab2d9505a57a99d6-- From nobody Tue May 12 15:05: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 CEBAD3A0C34 for ; Tue, 12 May 2020 15:05:20 -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, 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 x2PwqtWIHx8Z for ; Tue, 12 May 2020 15:05:18 -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 BBF843A0C2B for ; Tue, 12 May 2020 15:05:18 -0700 (PDT) Received: from [10.10.8.53] (mobile-166-177-123-155.mycingular.net [166.177.123.155]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 04CM5GWa005070 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 May 2020 17:05:17 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589321118; bh=gtSzTvNrNov1Tv+fsxXznENmJLkTtxPbNthwLSCDPNI=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=ljg1An4dX6/RWjhG25LPqd5ck2q4/FDCz5VGx5a9kz2IgF+PKfPfSw9dO78CVIrH6 L7Y8pmIQQlrWEL4Ukf7of0ojgePVEXVmFTH1uxSkPkvxfvHMSzUB+9BHMJVk7mblWJ 5ZDKq/CTZ8hWG6/xSFqqCeADm9cXAAXL6dOxrjII= X-Authentication-Warning: raven.nostrum.com: Host mobile-166-177-123-155.mycingular.net [166.177.123.155] claimed to be [10.10.8.53] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ben Campbell Mime-Version: 1.0 (1.0) Date: Tue, 12 May 2020 17:05:11 -0500 Message-Id: References: Cc: rfced-future@iab.org In-Reply-To: To: "Joel M. Halpern" X-Mailer: iPad Mail (17E262) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 22:05:21 -0000 I was mentally composing a reply to the effect of =E2=80=9CThe RSE should no= t be able to veto an IETF stream document approved through normal procedures= on technical grounds, but could conceivably need to do so on editorial grou= nds.=E2=80=9D But Joel beat me to it. Ben. > On May 12, 2020, at 4:57 PM, Joel M. Halpern wrote: >=20 > =EF=BB=BFCan we step this down? >=20 > On the one hand, no, I do not think the RSE should have the authority to t= ell the IESG that the IETF can not publish particular technical content on t= echnical grounds. > On the other hand, if a technically competent RSE is that concerned about a= document, I think we probably have a whole lot of other problems that need t= o be addressed. Whether the RSE actually publishes that document or not is p= robably the least of our worries. >=20 > And I do think the RSE should have the authority to say to any stream "tur= n this into proper English before the RPC will process it." >=20 > Yours, > Joel >=20 >> On 5/12/2020 5:30 PM, Adam Roach wrote: >>> On 5/12/2020 3:25 PM, Michael StJohns wrote: >>> On 5/12/2020 4:16 PM, Eric Rescorla wrote: >>>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns > wrote: >>>> > Mark (in another email) is correct that the level of independence of t= he >>>> > current RSE is not the same as in the past - but I consider that a bu= g >>>> > rather than a feature as it means that its possible for a small subse= t >>>> > of the IETF community to affect the culture of the RFC series in ways= >>>> > that may not represent the interests of the broader community. >>>>=20 >>>> I want to zero in on this point, because I think it's useful to scope >>>> out people's views of "independence". >>>>=20 >>>> Let me try to start with what's hopefully a simple case: suppose >>>> that the IETF produces and the IESG approves a document to be >>>> published as RFC that the RSE believes is harmful to the Internet >>>> for technical reasons (it redefines IPv6 to have an 8 bit address, >>>> say). Do you believe that the RSE should be able to refuse to >>>> publish such a document? >>>>=20 >>>> -Ekr >>>=20 >>> Oooh tricky. I'd either have the RSE refer it to the ISE as publicat= ion as an April Fool's RFC, or I'd probably be the first to sign on to a pet= ition to recall the entire IESG. In any case, the answer is probably yes= , the RSE should refuse to publish the document as an Internet standard. T= hat assumes that the RSE - with the appropriate technical advisors - has the= skillset to determine said document is "harmful to the Internet". >>>=20 >> I think we can appreciate that the example was chosen to be fantastical s= o as to not focus discussion on the technical matter as much as the degree o= f control the RSE is afforded over the technical contents of a document. >> Now, I do recall a recent anecdote about Postel himself heatedly refusing= to publish a specification he felt was technically misguided [1], so this a= uthority did exist with the position at some point. Although never explicitl= y revoked, RFC 4844, section 4.1 et seq makes it pretty clear that the RSE h= as approval authority over precisely one stream (the Independent Submission s= tream). To the extent that the IAB had authority to publish RFC 4844, I thin= k it makes it clear that the scope of authority had been pared back substant= ially since the "I am not going to publish a faulty specification as an RFC"= days of 1991. >> I'm not entirely sure my analysis above is all that useful, though, as th= is is the "rfced-future" discussion rather than the "rfced-history" discussi= on, and so it seems more sensible to focus on meeting the needs of the Inter= net community in 2020 and beyond than is is to lean on the historical narrat= ive. >> And so more to the point: I think that the IETF community writ large woul= d be floored if a working group produced a document, the IETF found consensu= s on it during last call, the IESG approved it, and then the RSE refused to p= ublish it (or imposed technical changes on its contents). Ditto for the IRTF= and their documents. So, if we're matching authority with community expecta= tions -- at least for a large swath of the relevant community -- I think the= answer above of "the RSE should refuse to publish the document" is exactly w= rong. >> /a >> ____ >> [1] https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3Po= gGqh970H0/ >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue May 12 15:10: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 D30353A0C3C for ; Tue, 12 May 2020 15:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5egfCw_k1w2N for ; Tue, 12 May 2020 15:09:58 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 DF3E03A0C3B for ; Tue, 12 May 2020 15:09:58 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id f6so6819750pgm.1 for ; Tue, 12 May 2020 15:09:58 -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=vA+zUuEbczyYm/1LMGOBJFqdqd8zGPqoF51kAA7RCKs=; b=UiOW/JEOzsM5hW0IYz9mMm7RIru9SWxfakDTqxQlkIOv1ey4834oVHnwN877Kdur2k Kk6ejIRb8vtSECLCR+4cBWpsX76Ze9UnNSTU/15ISrzv2Z7wvv8OdVkS3CWtJ7a46N8a nGs2eXD9UkG/rkhKp/JuLbcVJVl0Ds/G5IMGBR/oHYBVTwarTSjhaiDBW86HOUD5/9GS knPFtZHHySaVmU+MDdtHaP3tfuOLkRl8EThiiKDeksdcW9PMtZ+Q2JBWsPooVxMc4wNt +p/Ta9x9YPrDk+PE13e57uAwiNg3jMmwndiUCq7eDaOJIG9PamItIVTyfR97r5PtDf3u 5ffg== 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=vA+zUuEbczyYm/1LMGOBJFqdqd8zGPqoF51kAA7RCKs=; b=Z8Lp7yrMbOIJjBwDfeGAq1XJLg5CnX39DyJMed7xSZXdUnPe5+TIHKirPaslj2UVOx 4T9SYPd9VqaRDPbLkMB377nKg3FG7e3Do4Qb+NDna7qQCkx4dRGac/EAz1FX1wHEVmxW JwoNZ6bjNGpW2a3szrJyC324EKva1ztAVlAtYGZ0bg/3E8oB45STai/Pl0EuqE0CZntU Ub6EPojcdsBF3H1BYrLgr3L9I7zu41X2NRhP9Vv43h+JxfGVzAFIlHBUHus5y2JFIxAm MW5TSksV6wERlu6kyR4OrYnoltk8U1wZygZ6V9tcqS3YQDSlvH9w7u0lAOd3sL12VdhG A9EQ== X-Gm-Message-State: AOAM532m7ZS94lZiyzrzkDGy8ajXyqXGimtZm/dTztm+J7Of8o/Gl29b 99M3GT3T+AM812NQPuaA74KDvxJd X-Google-Smtp-Source: ABdhPJxy9nOBdCHBo+cFfKZ0k1KZ8mfuBNOsbuO8IM74qP3cOkQtkbWV5gxVZWU3876n1XI9QTSHaQ== X-Received: by 2002:a63:5fc8:: with SMTP id t191mr8700514pgb.185.1589321397954; Tue, 12 May 2020 15:09:57 -0700 (PDT) Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id fy21sm13447170pjb.25.2020.05.12.15.09.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2020 15:09:57 -0700 (PDT) To: "Andrew G. Malis" Cc: Mark Nottingham , John C Klensin , rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> From: Brian E Carpenter Message-ID: <2b5d1174-f959-6275-78e3-7cf4eaa86601@gmail.com> Date: Wed, 13 May 2020 10:09:52 +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] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 22:10:02 -0000 On 13-May-20 10:00, Andrew G. Malis wrote: > Brian, >=20 > I think that is an error. In section 5, RFC 7990 also says: >=20 > =C2=A0 =C2=A0The final XML file produced by the RFC Editor will be cons= idered the > =C2=A0 =C2=A0canonical format for RFCs; it is the lowest common denomin= ator that > =C2=A0 =C2=A0holds all the information intended for an RFC.=C2=A0 PDF/A= -3 will be the > =C2=A0 =C2=A0publication format offered in response to subpoenas for RF= Cs > =C2=A0 =C2=A0published through this new process and will be developed w= ith an eye > =C2=A0 =C2=A0towards long-term archival storage. >=20 > So this section makes the distinction between "canonical" and "long ter= m archival storage"'. Oh, right. So that's an internal inconsistency in 7990. Brian >=20 > Cheers, > Andy >=20 >=20 >=20 >=20 > On Tue, May 12, 2020 at 5:05 PM Brian E Carpenter > wrote: >=20 > I note that RFC7990 says: >=20 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Canonical format: the authorized, recog= nized, accepted, and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0archived version of the document >=20 > This could well be an error. Making our XML dialect the *canonical*= > format was what most of us thought about. Maybe a specified renderi= ng > that could, in theory, be drawn on parchment should be the *archiva= l* > format. >=20 > Since RFC7990 is a request for comments, we can choose to update it= =2E >=20 > This should go on the next RSE's "to do" list, I think. >=20 > Regards > =C2=A0 =C2=A0Brian Carpenter >=20 > On 12-May-20 19:15, Mark Nottingham wrote: > > Hi John, > > > >> On 12 May 2020, at 5:03 pm, John C Klensin > wrote: > >> > >> Mark, I fear that takes us around in a bit of a circle, albeit > >> an important one. I was forcefully educated (one might say > >> "beaten up") some years ago by an Archivist (his job title) > >> associated with a national repository library in the north of > >> Europe.=C2=A0 =C2=A0He explained that it was very hard to have a= > >> conversation about what was "archival" or about the meaning of > >> the closely-related term "permanent" with people in computer > >> fields (especially web-related ones) because we tended to think > >> of "permanence" as 10 - 20 years.=C2=A0 He claimed that most peo= ple > >> he had encountered from North America or the South Pacific had > >> similar problems with believing permanence, in practice, could > >> be considered a few centuries but that he and his colleagues > >> needed to work in terms of at least several millennia and that > >> those differences put an entirely different spin on things. > > > > This does not shock me, but then I've interned in an art museum, = where the challenges of conservatorship were painfully obvious. > > > > > >> That story is important in the current context for two reasons: > >> > >> * While I consider the decision made and hence not part of the > >> current RFC Editor Futures discussion (even though I, and > >> apparently others, have growing doubts about how we are > >> implementing it), a conversation with almost any (I don't know > >> of exceptions, but maybe there are some) professional archivist > >> about treating a source format that requires considerable > >> compilation and reference to external sources and mechanisms to > >> get to a form people are comfortable reading as an archival form= > >> will typically be greeted with laughter and/or comments to the > >> effect that we should come back in a hundred years and show them= > >> that XML is still around and that it is the same, or at least > >> completely backward-compatible, XML.=C2=A0 If they, and their > >> considerations, are to be taken seriously as we talk about > >> "archival", things are broken already and comments about the > >> merits of continuing to dig when one finds oneself in a deep > >> hole may be relevant. > > > > I tend to agree; if I'd been more involved in the IETF when this = decision was made, I would have fought it (based upon my early experience= s with XML, more than anything). > > > > > >> * There have been several discussions in recent years about > >> treating IETF specifications as living documents or with some > >> other arrangement in which issues are folded in as soon as they > >> are detected and at least tentative conclusions reached about > >> how to proceed.=C2=A0 I don't know whether we need to resolve th= ose > >> proposals before moving forward with discussions about the > >> future of the RFC Series and its management and organization (I > >> hope we don't because the community seems quite divided to me). > >> However, I think we need to understand that moving in that > >> direction, even if we make periodic snapshots and publish them > >> as RFCs, would profoundly change the character of the series as > >> providing a clearly-identifiable (and "archival") record of the > >> evolution of Internet technology and standards. > > > > I think that people are becoming slightly absolutist when they ta= lk about this subject, but worse, they perceive those on "the other side"= as *really* absolutist. > > > > I hope no one seriously thinks that "archival" means that we can'= t change _any_ aspect of the series, ever -- that it's a machine that mus= t run on in its current form until its doom. I also hope that no one thin= ks that changing things means that it must be possible to change any char= acter / bit in any RFC at any time. > > > > If we can put those extremes safely out of the way and focus on w= hat the needs of the archival and other communities are, we might make so= me progress. > > > > Maybe we could give some guidance here, but I agree we do have so= me other issues to dispose of first. > > > > > >>> ... > >>>>=C2=A0 =C2=A0 =E2=80=A2 The RFC Series is community property an= d must operate on > >>>>=C2=A0 =C2=A0 behalf of the community as a whole. > >>>> > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 The exact d= efinition of the relevant community is open > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for debate. One defin= ition is: the IETF, the IRTF, the IAB > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and the many other pe= ople who have contributed to, or made > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use of, the RFC Serie= s over the last fifty years. > >>>> > >>>>=C2=A0 =C2=A0 =E2=80=A2 Major decisions about the future of the= RFC Series must > >>>>=C2=A0 =C2=A0 be taken by a rough consensus of this very broad = community. > >>>> > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 How to reac= h out to this community and judge its > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consensus is in itsel= f a big question. > >>> > >>> I think it's widely agreed that your conclusions about the > >>> series not being 'owned' by any of the I* are correct. > >>> However, I'd suggest that we can reach out to and judge > >>> consensus of that community just like we do in any other area > >>> -- establish a venue (e.g., a WG) and make it known that if > >>> you're a stakeholder who's interested, that's the appropriate > >>> place to contribute. Doubtless some people will not choose to > >>> come, but that's their choice. Others might advocate on their > >>> behalf; we already see that with civil society organisations > >>> being involved in the IETF's work. > >> > >> One problem is that one important audience for the Series, or at= > >> least the documents we claim are standards (or to which assorted= > >> parties claim conformance) are people writing procurement > >> documents (RFPs, contracts, SLAs, etc.).=C2=A0 The odds that we = will > >> get a reliable representation from that community even if we > >> could reach them are, I think, pretty small.=C2=A0 =C2=A0The odd= s that we > >> could get them to participate in a WG-like arrangement? > >> Probably much lower.=C2=A0 But, at least if one were to assume a= free > >> market in which alternatives exist, those people are key to > >> determine if our standards go anywhere.=C2=A0 Indeed, when they = write > >> contracts that require conformance and try to enforce them, they= > >> are actually the closest we get to actually having a Protocol > >> Police.=C2=A0 And, by the way, they, and the kinds of documents = they > >> are willing to work with, interact with the "living document" > >> ideas as well:=C2=A0 IMO at least, we dare not ignore them becau= se we > >> cannot get their participation on our normal terms. > > > > Thank you; this is exactly how things sit already in many WGs, e.= g., HTTP. The decisions we make impact many people who don't even know we= exist on a daily basis. > > > > Cheers, > > > > > > -- > > Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/ > > > > . > > >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Tue May 12 15:10: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 58C003A0C3B for ; Tue, 12 May 2020 15:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnlDck-KBIh5 for ; Tue, 12 May 2020 15:10:48 -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 D14913A0C38 for ; Tue, 12 May 2020 15:10:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7FFA7BE20; Tue, 12 May 2020 23:10:45 +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 6hZjdfBNGlcx; Tue, 12 May 2020 23:10:43 +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 B5C65BDCF; Tue, 12 May 2020 23:10:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1589321442; bh=2PglM2mX4nuCCIL0bXKK0oHu9geNSHLU8QLVnBhwpjc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=2/XZc2FnCmqhs5SZ/KqZWL1YDWLnKT3Pyav3gECdVeHBXnYbUKxaAuIcBeyE8bum0 vrDhfdipdlrAxN9tDr/SHdmMVdcORtNhBwqenT4S1dADkty7qyQLf1fVFr6FxSWY/d o0klijL6JVhwa+2B3I+/jzcYHVvlwYxj/nmltIeY= To: Ben Campbell , "Joel M. Halpern" Cc: 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: <2c06d794-36ed-f181-8c59-e33958fc21fd@cs.tcd.ie> Date: Tue, 12 May 2020 23:10:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MvZn4O2kuE0TWDpxd5i1YuS0yNfAO3tXd" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 22:10:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MvZn4O2kuE0TWDpxd5i1YuS0yNfAO3tXd Content-Type: multipart/mixed; boundary="X04JGFjjnHXdR4OkjouUM9T1KK0lsrNIN"; protected-headers="v1" From: Stephen Farrell To: Ben Campbell , "Joel M. Halpern" Cc: rfced-future@iab.org Message-ID: <2c06d794-36ed-f181-8c59-e33958fc21fd@cs.tcd.ie> Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt References: In-Reply-To: --X04JGFjjnHXdR4OkjouUM9T1KK0lsrNIN Content-Type: multipart/mixed; boundary="------------7CF4191AA52368ADD98A02A9" Content-Language: en-US This is a multi-part message in MIME format. --------------7CF4191AA52368ADD98A02A9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/05/2020 23:05, Ben Campbell wrote: > I was mentally composing a reply to the effect of =E2=80=9CThe RSE shou= ld not > be able to veto an IETF stream document approved through normal > procedures on technical grounds, but could conceivably need to do so > on editorial grounds.=E2=80=9D But Joel beat me to it. Yeah, that's fair. I guess I at least took it as a given that the RPC do the copy-editing type work to fix the real cases we see of editorial ickyness. (With careful author/AD approval of course.) Having done 6 years on the IESG I can't think of a single case of a document that got to auth-48 that was so bad that the current processes weren't able to fix it sufficient for publication though, so that's maybe as theoretical as ekr's example. S. >=20 > Ben. >=20 >> On May 12, 2020, at 4:57 PM, Joel M. Halpern >> wrote: >>=20 >> =EF=BB=BFCan we step this down? >>=20 >> On the one hand, no, I do not think the RSE should have the >> authority to tell the IESG that the IETF can not publish particular >> technical content on technical grounds. On the other hand, if a >> technically competent RSE is that concerned about a document, I >> think we probably have a whole lot of other problems that need to >> be addressed. Whether the RSE actually publishes that document or >> not is probably the least of our worries. >>=20 >> And I do think the RSE should have the authority to say to any >> stream "turn this into proper English before the RPC will process >> it." >>=20 >> Yours, Joel >>=20 >>> On 5/12/2020 5:30 PM, Adam Roach wrote: >>>> On 5/12/2020 3:25 PM, Michael StJohns wrote: On 5/12/2020 4:16 >>>> PM, Eric Rescorla wrote: >>>>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns >>>>> > >>>>> wrote: >>>>>> Mark (in another email) is correct that the level of >>>>>> independence of the current RSE is not the same as in the >>>>>> past - but I consider that a bug rather than a feature as >>>>>> it means that its possible for a small subset of the IETF >>>>>> community to affect the culture of the RFC series in ways=20 >>>>>> that may not represent the interests of the broader >>>>>> community. >>>>>=20 >>>>> I want to zero in on this point, because I think it's useful >>>>> to scope out people's views of "independence". >>>>>=20 >>>>> Let me try to start with what's hopefully a simple case: >>>>> suppose that the IETF produces and the IESG approves a >>>>> document to be published as RFC that the RSE believes is >>>>> harmful to the Internet for technical reasons (it redefines >>>>> IPv6 to have an 8 bit address, say). Do you believe that the >>>>> RSE should be able to refuse to publish such a document? >>>>>=20 >>>>> -Ekr >>>>=20 >>>> Oooh tricky. I'd either have the RSE refer it to the ISE as >>>> publication as an April Fool's RFC, or I'd probably be the >>>> first to sign on to a petition to recall the entire IESG. >>>> In any case, the answer is probably yes, the RSE should refuse >>>> to publish the document as an Internet standard. That assumes >>>> that the RSE - with the appropriate technical advisors - has >>>> the skillset to determine said document is "harmful to the >>>> Internet". >>>>=20 >>> I think we can appreciate that the example was chosen to be >>> fantastical so as to not focus discussion on the technical matter >>> as much as the degree of control the RSE is afforded over the >>> technical contents of a document. Now, I do recall a recent >>> anecdote about Postel himself heatedly refusing to publish a >>> specification he felt was technically misguided [1], so this >>> authority did exist with the position at some point. Although >>> never explicitly revoked, RFC 4844, section 4.1 et seq makes it >>> pretty clear that the RSE has approval authority over precisely >>> one stream (the Independent Submission stream). To the extent >>> that the IAB had authority to publish RFC 4844, I think it makes >>> it clear that the scope of authority had been pared back >>> substantially since the "I am not going to publish a faulty >>> specification as an RFC" days of 1991. I'm not entirely sure my >>> analysis above is all that useful, though, as this is the >>> "rfced-future" discussion rather than the "rfced-history" >>> discussion, and so it seems more sensible to focus on meeting the >>> needs of the Internet community in 2020 and beyond than is is to >>> lean on the historical narrative. And so more to the point: I >>> think that the IETF community writ large would be floored if a >>> working group produced a document, the IETF found consensus on it >>> during last call, the IESG approved it, and then the RSE refused >>> to publish it (or imposed technical changes on its contents). >>> Ditto for the IRTF and their documents. So, if we're matching >>> authority with community expectations -- at least for a large >>> swath of the relevant community -- I think the answer above of >>> "the RSE should refuse to publish the document" is exactly >>> wrong. /a ____ [1] >>> https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3Po= gGqh970H0/ >> >> >>>=20 --=20 >> Rfced-future mailing list Rfced-future@iab.org=20 >> https://www.iab.org/mailman/listinfo/rfced-future >=20 --------------7CF4191AA52368ADD98A02A9 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----- --------------7CF4191AA52368ADD98A02A9-- --X04JGFjjnHXdR4OkjouUM9T1KK0lsrNIN-- --MvZn4O2kuE0TWDpxd5i1YuS0yNfAO3tXd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl67HuEACgkQWrL68XsX K+oSKA//dDJ5n9WIZln33cVZABnQ/kFAatHNJBOcj19osdyy1z6qlIRF2rNgxG12 j7WpLGs9jdOO8wYAtUPGzhow0J/Gw6bNT809wTbM1Q3aPjx54g35MvUlUAPL+HSI LkrhzeEA4VvHuNWQKshjycI3noUnQuELhz2BhWQhML1CgcSINxd3VMYKwrj0HGwD bhACryYCFgsL0UvM5d6fYNunW3Ssm7ZwesBezwXfkXC/E8oSqUgUf+WqFtpDGc+s xPOZ36a2SLWKN7UwqvFxltmxCzCf0WXYpNAXOXCfreIUkcBhNHwNjYIa3/OOSPKP ThLoRAO61FFlLYpHeSHijsDkE99NAaygk2TuxQQeZcAGYouzzCBpte8fWMazULHT T1RwRcnwcR6T4sdAVkLC5MzuS1V+HJPza9dvVs4iahvHdiBLpRTUY/Cj9PxvO8zM eBtfo5noZG+gvMCW2RwAwTzTRLtEUSxlTRkh5ATmYbTTmGM4CUYPXfNM6kefYBbj APJCn636qHRETQ3COg9hExliCT/aqHJ2kd5dU5+sXO9sz/vKPcjxE6Oz5xy7DBVl p/4gnYDViWG4xuCfsiYnojwo7PC/rXSwOqFkUqSok3EaMba1D4MvJqP9U7QPJ3Ez u3R+5DyByv+5vaPEGcCb+k5gfWMo1sO4clf4cTTWlyAA9AzDwVE= =P+Vf -----END PGP SIGNATURE----- --MvZn4O2kuE0TWDpxd5i1YuS0yNfAO3tXd-- From nobody Tue May 12 15:15:53 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531CF3A0C3D for ; Tue, 12 May 2020 15:15:52 -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, 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 jZOyAspGS85z for ; Tue, 12 May 2020 15:15:49 -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 C77213A0C3B for ; Tue, 12 May 2020 15:15:49 -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.15.2/8.15.2) with ESMTPSA id 04CMFlFk006964 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 May 2020 17:15:48 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589321749; bh=x5FipuMx5TjysVIpbrvFxPEwKqNpzMObNdYuAlvCKHU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=p2cddjh+YNp00H+dioYfOg/SunWUCbZ7TdCIP8tcsjzvmkNQXjxXr9AOLDXy/Itfh TaIT/8OGL6kE9EXTMaL8VJWtDmi0iFbdq1iX8Kle7HAhxWe4qNoABaEuDwTZwm71rw Q6+t0Quz0DB34N/gPA5vU/AEDkctGWUHjWJKd/Q0= 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: Ben Campbell , "Joel M. Halpern" Cc: rfced-future@iab.org References: From: Adam Roach Message-ID: <52c04df7-a629-6109-5e71-ce7e2a68720f@nostrum.com> Date: Tue, 12 May 2020 17:15:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 22:15:52 -0000 Right. I apologize if it was unclear that I was speaking strictly about the technical contents of a document. Personally, I'd be happy if the RSE/RPC were more liberal about sending things back as too poorly written to economically edit. /a On 5/12/2020 5:05 PM, Ben Campbell wrote: > I was mentally composing a reply to the effect of “The RSE should not be able to veto an IETF stream document approved through normal procedures on technical grounds, but could conceivably need to do so on editorial grounds.” But Joel beat me to it. > > Ben. > >> On May 12, 2020, at 4:57 PM, Joel M. Halpern wrote: >> >> Can we step this down? >> >> On the one hand, no, I do not think the RSE should have the authority to tell the IESG that the IETF can not publish particular technical content on technical grounds. >> On the other hand, if a technically competent RSE is that concerned about a document, I think we probably have a whole lot of other problems that need to be addressed. Whether the RSE actually publishes that document or not is probably the least of our worries. >> >> And I do think the RSE should have the authority to say to any stream "turn this into proper English before the RPC will process it." >> >> Yours, >> Joel >> >>> On 5/12/2020 5:30 PM, Adam Roach wrote: >>>> On 5/12/2020 3:25 PM, Michael StJohns wrote: >>>> On 5/12/2020 4:16 PM, Eric Rescorla wrote: >>>>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns > wrote: >>>>>> Mark (in another email) is correct that the level of independence of the >>>>>> current RSE is not the same as in the past - but I consider that a bug >>>>>> rather than a feature as it means that its possible for a small subset >>>>>> of the IETF community to affect the culture of the RFC series in ways >>>>>> that may not represent the interests of the broader community. >>>>> I want to zero in on this point, because I think it's useful to scope >>>>> out people's views of "independence". >>>>> >>>>> Let me try to start with what's hopefully a simple case: suppose >>>>> that the IETF produces and the IESG approves a document to be >>>>> published as RFC that the RSE believes is harmful to the Internet >>>>> for technical reasons (it redefines IPv6 to have an 8 bit address, >>>>> say). Do you believe that the RSE should be able to refuse to >>>>> publish such a document? >>>>> >>>>> -Ekr >>>> Oooh tricky. I'd either have the RSE refer it to the ISE as publication as an April Fool's RFC, or I'd probably be the first to sign on to a petition to recall the entire IESG. In any case, the answer is probably yes, the RSE should refuse to publish the document as an Internet standard. That assumes that the RSE - with the appropriate technical advisors - has the skillset to determine said document is "harmful to the Internet". >>>> >>> I think we can appreciate that the example was chosen to be fantastical so as to not focus discussion on the technical matter as much as the degree of control the RSE is afforded over the technical contents of a document. >>> Now, I do recall a recent anecdote about Postel himself heatedly refusing to publish a specification he felt was technically misguided [1], so this authority did exist with the position at some point. Although never explicitly revoked, RFC 4844, section 4.1 et seq makes it pretty clear that the RSE has approval authority over precisely one stream (the Independent Submission stream). To the extent that the IAB had authority to publish RFC 4844, I think it makes it clear that the scope of authority had been pared back substantially since the "I am not going to publish a faulty specification as an RFC" days of 1991. >>> I'm not entirely sure my analysis above is all that useful, though, as this is the "rfced-future" discussion rather than the "rfced-history" discussion, and so it seems more sensible to focus on meeting the needs of the Internet community in 2020 and beyond than is is to lean on the historical narrative. >>> And so more to the point: I think that the IETF community writ large would be floored if a working group produced a document, the IETF found consensus on it during last call, the IESG approved it, and then the RSE refused to publish it (or imposed technical changes on its contents). Ditto for the IRTF and their documents. So, if we're matching authority with community expectations -- at least for a large swath of the relevant community -- I think the answer above of "the RSE should refuse to publish the document" is exactly wrong. >>> /a >>> ____ >>> [1] https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/ >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue May 12 15:59: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 3BD643A0C58 for ; Tue, 12 May 2020 15:59: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, 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 DtHv-ZpTa2s2 for ; Tue, 12 May 2020 15:59:52 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 CBFC73A0B1E for ; Tue, 12 May 2020 15:59:51 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id a21so15554754ljj.11 for ; Tue, 12 May 2020 15:59:51 -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=jnD7NG42AWodLtkHzyQgQqW9SrxdIaXuMgPlUjbkWPk=; b=rTE1VhNyhtC2PsPmpQVoRj5hO+P9F+Y31ptOxFDL5plwtSujd0E8J7hTd5stNWbPJn XGYC2FXKazVbG7hqC7cs03/Di/jorrKTkpLeuUVxNClLnzjggavDg46R94D2bSQVIFOp qFI7RSqMqnpYRboeM2Lw95c0c3nOV2NIDjZBgcA5sAd1HuJ+tYs/C5Cs8n7wyA3KmILs iUuj6urxO+3snice8qOFbc5DSZzLHDZIiuul1yeFlT/rOybx/EXmZJfSRc8BE9fUVYDx hZsAUQdlsA2zAZdxr++w+RhoEydcsotpnNoRth5bH/mgbWmaZQeQ9KtdsmPDuRGBbw0O r2Tg== 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=jnD7NG42AWodLtkHzyQgQqW9SrxdIaXuMgPlUjbkWPk=; b=kDJKwRBU7l4q+S+IeWPjQSBE+EaIQcRJvhNzV3/rpiC4QF+dISpBj6Tymene2yYubV jT8xeYCgxS3Jp9Md9XJqpWJIL5dPuOTfeRiqw2p2oPtk/n9KBgdBTQWu9FrtaG16juk6 C0bugY8UAIbXKfDeuAX/xIwBn8YWt9SzvI86PVmX8qMXZ5GpEI4NbEDaXUahljJ7+jFM BDiQ9wPTJnqgi44pVNe/ECvaQ0dyLFKu6jlTC/ZfXsucqzRFW9hODBjGIEEVT04v3vOV 0u+F+mYiIlwsiLC3T/Rxg86GW9dyRlctpdIuarZXFmHjc10MfXZCjP7FXedgrd/I4XK0 9qrw== X-Gm-Message-State: AOAM5319fsYaKCE6bH4Lma0gpzLhBBwh5jCdjIgnvPAWT/QbTs/XjWRX U9qDDsTuW8lLCqiD3b4FECZcPXhuFpUunW1OPCK59A== X-Google-Smtp-Source: ABdhPJyu4sygRt4tkshCBcyZnzl6eFPvhn4ocGJVQaQbPwWc3H4CoZQcdbLSXFSj2DPzrtDamLINNQt4fNcTNI1rrSM= X-Received: by 2002:a2e:a552:: with SMTP id e18mr5192362ljn.162.1589324389966; Tue, 12 May 2020 15:59:49 -0700 (PDT) MIME-Version: 1.0 References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> <2b5d1174-f959-6275-78e3-7cf4eaa86601@gmail.com> In-Reply-To: <2b5d1174-f959-6275-78e3-7cf4eaa86601@gmail.com> From: Eric Rescorla Date: Tue, 12 May 2020 15:59:13 -0700 Message-ID: To: Brian E Carpenter Cc: "Andrew G. Malis" , John C Klensin , rfced-future@iab.org, Mark Nottingham Content-Type: multipart/alternative; boundary="000000000000b28c1b05a57b6beb" Archived-At: Subject: Re: [Rfced-future] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 22:59:55 -0000 --000000000000b28c1b05a57b6beb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 12, 2020 at 3:10 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 13-May-20 10:00, Andrew G. Malis wrote: > > Brian, > > > > I think that is an error. In section 5, RFC 7990 also says: > > > > The final XML file produced by the RFC Editor will be considered the > > canonical format for RFCs; it is the lowest common denominator that > > holds all the information intended for an RFC. PDF/A-3 will be the > > publication format offered in response to subpoenas for RFCs > > published through this new process and will be developed with an eye > > towards long-term archival storage. > > > > So this section makes the distinction between "canonical" and "long ter= m > archival storage"'. > > Oh, right. So that's an internal inconsistency in 7990. > I have to admit, I'm a bit fuzzy on what "canonical" and "archival" mean, so maybe we can go back to a more operational definition: 1. As I understand it, the XML is immutable (7990 S 10.2). However, the publication formats can be regenerated as needed. Is that correct? I read the text above as just saying that the PDF should be generated in a way that it is suitable for long-term storage but isn't immutable. 2. In case of conflict, which version is authoritative? For instance, suppose that the XML has a 2 in one place but the PDF renders with a 3. What is the conformance standard? And going back to point (1), if we all agree that we wish the value were 2, do we file an erratum on the PDF or just regenerate it? Conversely, if we all agree that we wish it were 3 then do we file an erratum on the XML and/or do a bis? Would be good to get consensus on what we think these docs say and what we think they ought to say. -Ekr > Brian > > > > > Cheers, > > Andy > > > > > > > > > > On Tue, May 12, 2020 at 5:05 PM Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > I note that RFC7990 says: > > > > > Canonical format: the authorized, recognized, accepted, and > > > archived version of the document > > > > This could well be an error. Making our XML dialect the *canonical* > > format was what most of us thought about. Maybe a specified renderi= ng > > that could, in theory, be drawn on parchment should be the *archiva= l* > > format. > > > > Since RFC7990 is a request for comments, we can choose to update it= . > > > > This should go on the next RSE's "to do" list, I think. > > > > Regards > > Brian Carpenter > > > > On 12-May-20 19:15, Mark Nottingham wrote: > > > Hi John, > > > > > >> On 12 May 2020, at 5:03 pm, John C Klensin > wrote: > > >> > > >> Mark, I fear that takes us around in a bit of a circle, albeit > > >> an important one. I was forcefully educated (one might say > > >> "beaten up") some years ago by an Archivist (his job title) > > >> associated with a national repository library in the north of > > >> Europe. He explained that it was very hard to have a > > >> conversation about what was "archival" or about the meaning of > > >> the closely-related term "permanent" with people in computer > > >> fields (especially web-related ones) because we tended to think > > >> of "permanence" as 10 - 20 years. He claimed that most people > > >> he had encountered from North America or the South Pacific had > > >> similar problems with believing permanence, in practice, could > > >> be considered a few centuries but that he and his colleagues > > >> needed to work in terms of at least several millennia and that > > >> those differences put an entirely different spin on things. > > > > > > This does not shock me, but then I've interned in an art museum, > where the challenges of conservatorship were painfully obvious. > > > > > > > > >> That story is important in the current context for two reasons: > > >> > > >> * While I consider the decision made and hence not part of the > > >> current RFC Editor Futures discussion (even though I, and > > >> apparently others, have growing doubts about how we are > > >> implementing it), a conversation with almost any (I don't know > > >> of exceptions, but maybe there are some) professional archivist > > >> about treating a source format that requires considerable > > >> compilation and reference to external sources and mechanisms to > > >> get to a form people are comfortable reading as an archival form > > >> will typically be greeted with laughter and/or comments to the > > >> effect that we should come back in a hundred years and show them > > >> that XML is still around and that it is the same, or at least > > >> completely backward-compatible, XML. If they, and their > > >> considerations, are to be taken seriously as we talk about > > >> "archival", things are broken already and comments about the > > >> merits of continuing to dig when one finds oneself in a deep > > >> hole may be relevant. > > > > > > I tend to agree; if I'd been more involved in the IETF when this > decision was made, I would have fought it (based upon my early experience= s > with XML, more than anything). > > > > > > > > >> * There have been several discussions in recent years about > > >> treating IETF specifications as living documents or with some > > >> other arrangement in which issues are folded in as soon as they > > >> are detected and at least tentative conclusions reached about > > >> how to proceed. I don't know whether we need to resolve those > > >> proposals before moving forward with discussions about the > > >> future of the RFC Series and its management and organization (I > > >> hope we don't because the community seems quite divided to me). > > >> However, I think we need to understand that moving in that > > >> direction, even if we make periodic snapshots and publish them > > >> as RFCs, would profoundly change the character of the series as > > >> providing a clearly-identifiable (and "archival") record of the > > >> evolution of Internet technology and standards. > > > > > > I think that people are becoming slightly absolutist when they > talk about this subject, but worse, they perceive those on "the other sid= e" > as *really* absolutist. > > > > > > I hope no one seriously thinks that "archival" means that we can'= t > change _any_ aspect of the series, ever -- that it's a machine that must > run on in its current form until its doom. I also hope that no one thinks > that changing things means that it must be possible to change any charact= er > / bit in any RFC at any time. > > > > > > If we can put those extremes safely out of the way and focus on > what the needs of the archival and other communities are, we might make > some progress. > > > > > > Maybe we could give some guidance here, but I agree we do have > some other issues to dispose of first. > > > > > > > > >>> ... > > >>>> =E2=80=A2 The RFC Series is community property and must ope= rate on > > >>>> behalf of the community as a whole. > > >>>> > > >>>> =E2=80=A2 The exact definition of the relevant comm= unity is > open > > >>>> for debate. One definition is: the IETF, the IRTF, > the IAB > > >>>> and the many other people who have contributed to, > or made > > >>>> use of, the RFC Series over the last fifty years. > > >>>> > > >>>> =E2=80=A2 Major decisions about the future of the RFC Serie= s must > > >>>> be taken by a rough consensus of this very broad community. > > >>>> > > >>>> =E2=80=A2 How to reach out to this community and ju= dge its > > >>>> consensus is in itself a big question. > > >>> > > >>> I think it's widely agreed that your conclusions about the > > >>> series not being 'owned' by any of the I* are correct. > > >>> However, I'd suggest that we can reach out to and judge > > >>> consensus of that community just like we do in any other area > > >>> -- establish a venue (e.g., a WG) and make it known that if > > >>> you're a stakeholder who's interested, that's the appropriate > > >>> place to contribute. Doubtless some people will not choose to > > >>> come, but that's their choice. Others might advocate on their > > >>> behalf; we already see that with civil society organisations > > >>> being involved in the IETF's work. > > >> > > >> One problem is that one important audience for the Series, or at > > >> least the documents we claim are standards (or to which assorted > > >> parties claim conformance) are people writing procurement > > >> documents (RFPs, contracts, SLAs, etc.). The odds that we will > > >> get a reliable representation from that community even if we > > >> could reach them are, I think, pretty small. The odds that we > > >> could get them to participate in a WG-like arrangement? > > >> Probably much lower. But, at least if one were to assume a free > > >> market in which alternatives exist, those people are key to > > >> determine if our standards go anywhere. Indeed, when they write > > >> contracts that require conformance and try to enforce them, they > > >> are actually the closest we get to actually having a Protocol > > >> Police. And, by the way, they, and the kinds of documents they > > >> are willing to work with, interact with the "living document" > > >> ideas as well: IMO at least, we dare not ignore them because we > > >> cannot get their participation on our normal terms. > > > > > > Thank you; this is exactly how things sit already in many WGs, > e.g., HTTP. The decisions we make impact many people who don't even know = we > exist on a daily basis. > > > > > > Cheers, > > > > > > > > > -- > > > Mark Nottingham https://www.mnot.net/ > > > > > > . > > > > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000b28c1b05a57b6beb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 12, 2020 at 3:10 PM Brian= E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 13-May-20 10:00, Andrew G. Malis wrote= :
> Brian,
>
> I think that is an error. In section 5, RFC 7990 also says:
>
> =C2=A0 =C2=A0The final XML file produced by the RFC Editor will be con= sidered the
> =C2=A0 =C2=A0canonical format for RFCs; it is the lowest common denomi= nator that
> =C2=A0 =C2=A0holds all the information intended for an RFC.=C2=A0 PDF/= A-3 will be the
> =C2=A0 =C2=A0publication format offered in response to subpoenas for R= FCs
> =C2=A0 =C2=A0published through this new process and will be developed = with an eye
> =C2=A0 =C2=A0towards long-term archival storage.
>
> So this section makes the distinction between "canonical" an= d "long term archival storage"'.

Oh, right. So that's an internal inconsistency in 7990.

I have to admit, I'm a bit fuzzy on what "can= onical" and "archival" mean, so maybe we can go back to a mo= re operational definition:

1. As I understand it, = the XML is immutable (7990 S 10.2). However, the publication formats can be= regenerated as needed. Is that correct? I read the text above as just sayi= ng that the PDF should be generated in a way that it is suitable for long-t= erm storage but isn't immutable.

2. In case of= conflict, which version is authoritative? For instance, suppose that the X= ML has a 2 in one place but the PDF renders with a 3. What is the conforman= ce standard? And going back to point (1), if we all agree that we wish the = value were 2, do we file an erratum on the PDF or just regenerate it? Conve= rsely, if we all agree that we wish it were 3 then do we file an erratum on= the XML and/or do a bis?

Would be good to get= consensus on what we think these docs say and what we think they ought to = say.

-Ekr


=C2=A0 =C2=A0Brian

>
> Cheers,
> Andy
>
>
>
>
> On Tue, May 12, 2020 at 5:05 PM Brian E Carpenter <brian.e.carpenter@gmail.co= m <mailto:brian.e.carpenter@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I note that RFC7990 says:
>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Canonical format: th= e authorized, recognized, accepted, and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0archived version of = the document
>
>=C2=A0 =C2=A0 =C2=A0This could well be an error. Making our XML dialect= the *canonical*
>=C2=A0 =C2=A0 =C2=A0format was what most of us thought about. Maybe a s= pecified rendering
>=C2=A0 =C2=A0 =C2=A0that could, in theory, be drawn on parchment should= be the *archival*
>=C2=A0 =C2=A0 =C2=A0format.
>
>=C2=A0 =C2=A0 =C2=A0Since RFC7990 is a request for comments, we can cho= ose to update it.
>
>=C2=A0 =C2=A0 =C2=A0This should go on the next RSE's "to do&qu= ot; list, I think.
>
>=C2=A0 =C2=A0 =C2=A0Regards
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian Carpenter
>
>=C2=A0 =C2=A0 =C2=A0On 12-May-20 19:15, Mark Nottingham wrote:
>=C2=A0 =C2=A0 =C2=A0> Hi John,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> On 12 May 2020, at 5:03 pm, John C Klensin= <john-ietf@jck.c= om <mailto:jo= hn-ietf@jck.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Mark, I fear that takes us around in a bit= of a circle, albeit
>=C2=A0 =C2=A0 =C2=A0>> an important one. I was forcefully educate= d (one might say
>=C2=A0 =C2=A0 =C2=A0>> "beaten up") some years ago by a= n Archivist (his job title)
>=C2=A0 =C2=A0 =C2=A0>> associated with a national repository libr= ary in the north of
>=C2=A0 =C2=A0 =C2=A0>> Europe.=C2=A0 =C2=A0He explained that it w= as very hard to have a
>=C2=A0 =C2=A0 =C2=A0>> conversation about what was "archival= " or about the meaning of
>=C2=A0 =C2=A0 =C2=A0>> the closely-related term "permanent&q= uot; with people in computer
>=C2=A0 =C2=A0 =C2=A0>> fields (especially web-related ones) becau= se we tended to think
>=C2=A0 =C2=A0 =C2=A0>> of "permanence" as 10 - 20 years= .=C2=A0 He claimed that most people
>=C2=A0 =C2=A0 =C2=A0>> he had encountered from North America or t= he South Pacific had
>=C2=A0 =C2=A0 =C2=A0>> similar problems with believing permanence= , in practice, could
>=C2=A0 =C2=A0 =C2=A0>> be considered a few centuries but that he = and his colleagues
>=C2=A0 =C2=A0 =C2=A0>> needed to work in terms of at least severa= l millennia and that
>=C2=A0 =C2=A0 =C2=A0>> those differences put an entirely differen= t spin on things.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This does not shock me, but then I've inte= rned in an art museum, where the challenges of conservatorship were painful= ly obvious.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> That story is important in the current con= text for two reasons:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> * While I consider the decision made and h= ence not part of the
>=C2=A0 =C2=A0 =C2=A0>> current RFC Editor Futures discussion (eve= n though I, and
>=C2=A0 =C2=A0 =C2=A0>> apparently others, have growing doubts abo= ut how we are
>=C2=A0 =C2=A0 =C2=A0>> implementing it), a conversation with almo= st any (I don't know
>=C2=A0 =C2=A0 =C2=A0>> of exceptions, but maybe there are some) p= rofessional archivist
>=C2=A0 =C2=A0 =C2=A0>> about treating a source format that requir= es considerable
>=C2=A0 =C2=A0 =C2=A0>> compilation and reference to external sour= ces and mechanisms to
>=C2=A0 =C2=A0 =C2=A0>> get to a form people are comfortable readi= ng as an archival form
>=C2=A0 =C2=A0 =C2=A0>> will typically be greeted with laughter an= d/or comments to the
>=C2=A0 =C2=A0 =C2=A0>> effect that we should come back in a hundr= ed years and show them
>=C2=A0 =C2=A0 =C2=A0>> that XML is still around and that it is th= e same, or at least
>=C2=A0 =C2=A0 =C2=A0>> completely backward-compatible, XML.=C2=A0= If they, and their
>=C2=A0 =C2=A0 =C2=A0>> considerations, are to be taken seriously = as we talk about
>=C2=A0 =C2=A0 =C2=A0>> "archival", things are broken al= ready and comments about the
>=C2=A0 =C2=A0 =C2=A0>> merits of continuing to dig when one finds= oneself in a deep
>=C2=A0 =C2=A0 =C2=A0>> hole may be relevant.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I tend to agree; if I'd been more involved= in the IETF when this decision was made, I would have fought it (based upo= n my early experiences with XML, more than anything).
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> * There have been several discussions in r= ecent years about
>=C2=A0 =C2=A0 =C2=A0>> treating IETF specifications as living doc= uments or with some
>=C2=A0 =C2=A0 =C2=A0>> other arrangement in which issues are fold= ed in as soon as they
>=C2=A0 =C2=A0 =C2=A0>> are detected and at least tentative conclu= sions reached about
>=C2=A0 =C2=A0 =C2=A0>> how to proceed.=C2=A0 I don't know whe= ther we need to resolve those
>=C2=A0 =C2=A0 =C2=A0>> proposals before moving forward with discu= ssions about the
>=C2=A0 =C2=A0 =C2=A0>> future of the RFC Series and its managemen= t and organization (I
>=C2=A0 =C2=A0 =C2=A0>> hope we don't because the community se= ems quite divided to me).
>=C2=A0 =C2=A0 =C2=A0>> However, I think we need to understand tha= t moving in that
>=C2=A0 =C2=A0 =C2=A0>> direction, even if we make periodic snapsh= ots and publish them
>=C2=A0 =C2=A0 =C2=A0>> as RFCs, would profoundly change the chara= cter of the series as
>=C2=A0 =C2=A0 =C2=A0>> providing a clearly-identifiable (and &quo= t;archival") record of the
>=C2=A0 =C2=A0 =C2=A0>> evolution of Internet technology and stand= ards.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I think that people are becoming slightly abso= lutist when they talk about this subject, but worse, they perceive those on= "the other side" as *really* absolutist.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I hope no one seriously thinks that "arch= ival" means that we can't change _any_ aspect of the series, ever = -- that it's a machine that must run on in its current form until its d= oom. I also hope that no one thinks that changing things means that it must= be possible to change any character / bit in any RFC at any time.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> If we can put those extremes safely out of the= way and focus on what the needs of the archival and other communities are,= we might make some progress.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Maybe we could give some guidance here, but I = agree we do have some other issues to dispose of first.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>>> ...
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =E2=80=A2 The RFC Ser= ies is community property and must operate on
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 behalf of the communi= ty as a whole.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =E2=80=A2 The exact definition of the relevant community is open
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 for debate. One definition is: the IETF, the IRTF, the IAB
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 and the many other people who have contributed to, or made
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 use of, the RFC Series over the last fifty years.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =E2=80=A2 Major decis= ions about the future of the RFC Series must
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 be taken by a rough c= onsensus of this very broad community.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =E2=80=A2 How to reach out to this community and judge its
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 consensus is in itself a big question.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> I think it's widely agreed that yo= ur conclusions about the
>=C2=A0 =C2=A0 =C2=A0>>> series not being 'owned' by an= y of the I* are correct.
>=C2=A0 =C2=A0 =C2=A0>>> However, I'd suggest that we can r= each out to and judge
>=C2=A0 =C2=A0 =C2=A0>>> consensus of that community just like = we do in any other area
>=C2=A0 =C2=A0 =C2=A0>>> -- establish a venue (e.g., a WG) and = make it known that if
>=C2=A0 =C2=A0 =C2=A0>>> you're a stakeholder who's int= erested, that's the appropriate
>=C2=A0 =C2=A0 =C2=A0>>> place to contribute. Doubtless some pe= ople will not choose to
>=C2=A0 =C2=A0 =C2=A0>>> come, but that's their choice. Oth= ers might advocate on their
>=C2=A0 =C2=A0 =C2=A0>>> behalf; we already see that with civil= society organisations
>=C2=A0 =C2=A0 =C2=A0>>> being involved in the IETF's work.=
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> One problem is that one important audience= for the Series, or at
>=C2=A0 =C2=A0 =C2=A0>> least the documents we claim are standards= (or to which assorted
>=C2=A0 =C2=A0 =C2=A0>> parties claim conformance) are people writ= ing procurement
>=C2=A0 =C2=A0 =C2=A0>> documents (RFPs, contracts, SLAs, etc.).= =C2=A0 The odds that we will
>=C2=A0 =C2=A0 =C2=A0>> get a reliable representation from that co= mmunity even if we
>=C2=A0 =C2=A0 =C2=A0>> could reach them are, I think, pretty smal= l.=C2=A0 =C2=A0The odds that we
>=C2=A0 =C2=A0 =C2=A0>> could get them to participate in a WG-like= arrangement?
>=C2=A0 =C2=A0 =C2=A0>> Probably much lower.=C2=A0 But, at least i= f one were to assume a free
>=C2=A0 =C2=A0 =C2=A0>> market in which alternatives exist, those = people are key to
>=C2=A0 =C2=A0 =C2=A0>> determine if our standards go anywhere.=C2= =A0 Indeed, when they write
>=C2=A0 =C2=A0 =C2=A0>> contracts that require conformance and try= to enforce them, they
>=C2=A0 =C2=A0 =C2=A0>> are actually the closest we get to actuall= y having a Protocol
>=C2=A0 =C2=A0 =C2=A0>> Police.=C2=A0 And, by the way, they, and t= he kinds of documents they
>=C2=A0 =C2=A0 =C2=A0>> are willing to work with, interact with th= e "living document"
>=C2=A0 =C2=A0 =C2=A0>> ideas as well:=C2=A0 IMO at least, we dare= not ignore them because we
>=C2=A0 =C2=A0 =C2=A0>> cannot get their participation on our norm= al terms.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thank you; this is exactly how things sit alre= ady in many WGs, e.g., HTTP. The decisions we make impact many people who d= on't even know we exist on a daily basis.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Cheers,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> --
>=C2=A0 =C2=A0 =C2=A0> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/<= /a>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> .
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=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
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000b28c1b05a57b6beb-- From nobody Tue May 12 16:09: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 CEC793A0C7A for ; Tue, 12 May 2020 16:09:12 -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 MZSWTfU5z6oj for ; Tue, 12 May 2020 16:09:09 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2173A0C78 for ; Tue, 12 May 2020 16:09:09 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id r17so8952224lff.9 for ; Tue, 12 May 2020 16:09:09 -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=pQxlqT4e3i3FPAUn4FIpRmbsdqlGsQApttsurC4riNM=; b=YpSjUwscHOaLwi9d9H/aTn5CN8IOZXpeHJJpAcd9Xka0Z7pTLEOHzI2objhbXx+Vkp 2OQUrJY5KcByC1dq5Hb9Vrl3IwxUG3IyIIbhXeNnopDD8zlU9fC4FdZ7CpQyqZtup+IX hbOJhEPvIXBuaoRaUBbP3kobC0bOjfiAar04G4/c+WLZimV3kxTQ9u0iklaZZzhGNWIy w5YHStijclME9pccU018k1Ih3IiDP9g7VaHobVKmT1NoITtp8KX+GTZ7fLMkdql8wJVr jFMY0N3G1RFM6HSJEhgkT6W/Dshwz2g3+c564YFft/j1bSkpd1D8gUVvoJS1OvACBp6Y vvrg== 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=pQxlqT4e3i3FPAUn4FIpRmbsdqlGsQApttsurC4riNM=; b=Dvfur+8RfhZmCgOWQloF1MfuG73q0gWiuvMWJRKDnLDFC1zBGaYBN+NF44yWSSbPyz DE9i9B3zVnwge74UBqYYvk5GeK65YPGgrQzcDO8r/9diFHt16jHpWCIUsCCtV8BGBsoZ trtoYoewRsaqzwlCJkywR4YCe4NyKhH4sBna5/aHzL6uXmDEpZxWFObEEsCLUphir2pX t794dzpHOAzb6ooaKDiu3EeOPWRlHLGiRJrT0mBd5q01hcxeoR5nn0Fbdk4J+JGqwjdA fNKs9sM4JLUBoawt6SxQ2UUGCuM7G8SY3QAhZuhPgF9ZgYzwCxXQmMab5kSordpIjORI lFBA== X-Gm-Message-State: AOAM533mg98cnUY563c953a3SbZ35gpVu/g8Pl78p/G37Q1xCp93Yp5k ykIs2iF/rwhSZ8472QQEOVV1+DSei4AXV+ikxNoWMw== X-Google-Smtp-Source: ABdhPJwegu/iBImIZugtLJhWNy00vA7z53Kv1z0vp5t70lqTjtJuSZ975pWbGbnXFefF9dYsM9Qu8GUThXDHwm17nnE= X-Received: by 2002:ac2:4436:: with SMTP id w22mr15758198lfl.55.1589324947553; Tue, 12 May 2020 16:09:07 -0700 (PDT) MIME-Version: 1.0 References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> <2b5d1174-f959-6275-78e3-7cf4eaa86601@gmail.com> In-Reply-To: From: Eric Rescorla Date: Tue, 12 May 2020 16:08:31 -0700 Message-ID: To: Brian E Carpenter Cc: "Andrew G. Malis" , John C Klensin , rfced-future@iab.org, Mark Nottingham Content-Type: multipart/alternative; boundary="000000000000ee92de05a57b8c31" Archived-At: Subject: Re: [Rfced-future] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 23:09:13 -0000 --000000000000ee92de05a57b8c31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 12, 2020 at 3:59 PM Eric Rescorla wrote: > > > On Tue, May 12, 2020 at 3:10 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 13-May-20 10:00, Andrew G. Malis wrote: >> > Brian, >> > >> > I think that is an error. In section 5, RFC 7990 also says: >> > >> > The final XML file produced by the RFC Editor will be considered th= e >> > canonical format for RFCs; it is the lowest common denominator that >> > holds all the information intended for an RFC. PDF/A-3 will be the >> > publication format offered in response to subpoenas for RFCs >> > published through this new process and will be developed with an ey= e >> > towards long-term archival storage. >> > >> > So this section makes the distinction between "canonical" and "long >> term archival storage"'. >> >> Oh, right. So that's an internal inconsistency in 7990. >> > > I have to admit, I'm a bit fuzzy on what "canonical" and "archival" mean, > so maybe we can go back to a more operational definition: > > 1. As I understand it, the XML is immutable (7990 S 10.2). However, the > publication formats can be regenerated as needed. Is that correct? I read > the text above as just saying that the PDF should be generated in a way > that it is suitable for long-term storage but isn't immutable. > > 2. In case of conflict, which version is authoritative? For instance, > suppose that the XML has a 2 in one place but the PDF renders with a 3. > What is the conformance standard? And going back to point (1), if we all > agree that we wish the value were 2, do we file an erratum on the PDF or > just regenerate it? Conversely, if we all agree that we wish it were 3 th= en > do we file an erratum on the XML and/or do a bis? > Just to sharpen this point, when I say "we wish" I mean it's completely clear it should be this value, for instance, the approved draft had the agreed upon value in all formats but it got mangled somewhere in RFC processing. -Ekr > Would be good to get consensus on what we think these docs say and what w= e > think they ought to say. > > -Ekr > > >> Brian >> >> > >> > Cheers, >> > Andy >> > >> > >> > >> > >> > On Tue, May 12, 2020 at 5:05 PM Brian E Carpenter < >> brian.e.carpenter@gmail.com > wrote: >> > >> > I note that RFC7990 says: >> > >> > > Canonical format: the authorized, recognized, accepted, an= d >> > > archived version of the document >> > >> > This could well be an error. Making our XML dialect the *canonical= * >> > format was what most of us thought about. Maybe a specified >> rendering >> > that could, in theory, be drawn on parchment should be the >> *archival* >> > format. >> > >> > Since RFC7990 is a request for comments, we can choose to update i= t. >> > >> > This should go on the next RSE's "to do" list, I think. >> > >> > Regards >> > Brian Carpenter >> > >> > On 12-May-20 19:15, Mark Nottingham wrote: >> > > Hi John, >> > > >> > >> On 12 May 2020, at 5:03 pm, John C Klensin > > wrote: >> > >> >> > >> Mark, I fear that takes us around in a bit of a circle, albeit >> > >> an important one. I was forcefully educated (one might say >> > >> "beaten up") some years ago by an Archivist (his job title) >> > >> associated with a national repository library in the north of >> > >> Europe. He explained that it was very hard to have a >> > >> conversation about what was "archival" or about the meaning of >> > >> the closely-related term "permanent" with people in computer >> > >> fields (especially web-related ones) because we tended to think >> > >> of "permanence" as 10 - 20 years. He claimed that most people >> > >> he had encountered from North America or the South Pacific had >> > >> similar problems with believing permanence, in practice, could >> > >> be considered a few centuries but that he and his colleagues >> > >> needed to work in terms of at least several millennia and that >> > >> those differences put an entirely different spin on things. >> > > >> > > This does not shock me, but then I've interned in an art museum, >> where the challenges of conservatorship were painfully obvious. >> > > >> > > >> > >> That story is important in the current context for two reasons: >> > >> >> > >> * While I consider the decision made and hence not part of the >> > >> current RFC Editor Futures discussion (even though I, and >> > >> apparently others, have growing doubts about how we are >> > >> implementing it), a conversation with almost any (I don't know >> > >> of exceptions, but maybe there are some) professional archivist >> > >> about treating a source format that requires considerable >> > >> compilation and reference to external sources and mechanisms to >> > >> get to a form people are comfortable reading as an archival for= m >> > >> will typically be greeted with laughter and/or comments to the >> > >> effect that we should come back in a hundred years and show the= m >> > >> that XML is still around and that it is the same, or at least >> > >> completely backward-compatible, XML. If they, and their >> > >> considerations, are to be taken seriously as we talk about >> > >> "archival", things are broken already and comments about the >> > >> merits of continuing to dig when one finds oneself in a deep >> > >> hole may be relevant. >> > > >> > > I tend to agree; if I'd been more involved in the IETF when this >> decision was made, I would have fought it (based upon my early experienc= es >> with XML, more than anything). >> > > >> > > >> > >> * There have been several discussions in recent years about >> > >> treating IETF specifications as living documents or with some >> > >> other arrangement in which issues are folded in as soon as they >> > >> are detected and at least tentative conclusions reached about >> > >> how to proceed. I don't know whether we need to resolve those >> > >> proposals before moving forward with discussions about the >> > >> future of the RFC Series and its management and organization (I >> > >> hope we don't because the community seems quite divided to me). >> > >> However, I think we need to understand that moving in that >> > >> direction, even if we make periodic snapshots and publish them >> > >> as RFCs, would profoundly change the character of the series as >> > >> providing a clearly-identifiable (and "archival") record of the >> > >> evolution of Internet technology and standards. >> > > >> > > I think that people are becoming slightly absolutist when they >> talk about this subject, but worse, they perceive those on "the other si= de" >> as *really* absolutist. >> > > >> > > I hope no one seriously thinks that "archival" means that we >> can't change _any_ aspect of the series, ever -- that it's a machine tha= t >> must run on in its current form until its doom. I also hope that no one >> thinks that changing things means that it must be possible to change any >> character / bit in any RFC at any time. >> > > >> > > If we can put those extremes safely out of the way and focus on >> what the needs of the archival and other communities are, we might make >> some progress. >> > > >> > > Maybe we could give some guidance here, but I agree we do have >> some other issues to dispose of first. >> > > >> > > >> > >>> ... >> > >>>> =E2=80=A2 The RFC Series is community property and must op= erate on >> > >>>> behalf of the community as a whole. >> > >>>> >> > >>>> =E2=80=A2 The exact definition of the relevant com= munity is >> open >> > >>>> for debate. One definition is: the IETF, the IRTF, >> the IAB >> > >>>> and the many other people who have contributed to, >> or made >> > >>>> use of, the RFC Series over the last fifty years. >> > >>>> >> > >>>> =E2=80=A2 Major decisions about the future of the RFC Seri= es must >> > >>>> be taken by a rough consensus of this very broad community= . >> > >>>> >> > >>>> =E2=80=A2 How to reach out to this community and j= udge its >> > >>>> consensus is in itself a big question. >> > >>> >> > >>> I think it's widely agreed that your conclusions about the >> > >>> series not being 'owned' by any of the I* are correct. >> > >>> However, I'd suggest that we can reach out to and judge >> > >>> consensus of that community just like we do in any other area >> > >>> -- establish a venue (e.g., a WG) and make it known that if >> > >>> you're a stakeholder who's interested, that's the appropriate >> > >>> place to contribute. Doubtless some people will not choose to >> > >>> come, but that's their choice. Others might advocate on their >> > >>> behalf; we already see that with civil society organisations >> > >>> being involved in the IETF's work. >> > >> >> > >> One problem is that one important audience for the Series, or a= t >> > >> least the documents we claim are standards (or to which assorte= d >> > >> parties claim conformance) are people writing procurement >> > >> documents (RFPs, contracts, SLAs, etc.). The odds that we will >> > >> get a reliable representation from that community even if we >> > >> could reach them are, I think, pretty small. The odds that we >> > >> could get them to participate in a WG-like arrangement? >> > >> Probably much lower. But, at least if one were to assume a fre= e >> > >> market in which alternatives exist, those people are key to >> > >> determine if our standards go anywhere. Indeed, when they writ= e >> > >> contracts that require conformance and try to enforce them, the= y >> > >> are actually the closest we get to actually having a Protocol >> > >> Police. And, by the way, they, and the kinds of documents they >> > >> are willing to work with, interact with the "living document" >> > >> ideas as well: IMO at least, we dare not ignore them because w= e >> > >> cannot get their participation on our normal terms. >> > > >> > > Thank you; this is exactly how things sit already in many WGs, >> e.g., HTTP. The decisions we make impact many people who don't even know= we >> exist on a daily basis. >> > > >> > > Cheers, >> > > >> > > >> > > -- >> > > Mark Nottingham https://www.mnot.net/ >> > > >> > > . >> > > >> > >> > -- >> > Rfced-future mailing list >> > Rfced-future@iab.org >> > https://www.iab.org/mailman/listinfo/rfced-future >> > >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> > --000000000000ee92de05a57b8c31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 12, 2020 at 3:59 PM Eric = Rescorla <ekr@rtfm.com= > wrote:
=


=
On Tue, May 12, 2020 at 3:10 PM Brian= E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 13-May-20 10:00, Andrew G. Malis wrote= :
> Brian,
>
> I think that is an error. In section 5, RFC 7990 also says:
>
> =C2=A0 =C2=A0The final XML file produced by the RFC Editor will be con= sidered the
> =C2=A0 =C2=A0canonical format for RFCs; it is the lowest common denomi= nator that
> =C2=A0 =C2=A0holds all the information intended for an RFC.=C2=A0 PDF/= A-3 will be the
> =C2=A0 =C2=A0publication format offered in response to subpoenas for R= FCs
> =C2=A0 =C2=A0published through this new process and will be developed = with an eye
> =C2=A0 =C2=A0towards long-term archival storage.
>
> So this section makes the distinction between "canonical" an= d "long term archival storage"'.

Oh, right. So that's an internal inconsistency in 7990.

I have to admit, I'm a bit fuzzy on what "can= onical" and "archival" mean, so maybe we can go back to a mo= re operational definition:

1. As I understand it, = the XML is immutable (7990 S 10.2). However, the publication formats can be= regenerated as needed. Is that correct? I read the text above as just sayi= ng that the PDF should be generated in a way that it is suitable for long-t= erm storage but isn't immutable.

2. In case of= conflict, which version is authoritative? For instance, suppose that the X= ML has a 2 in one place but the PDF renders with a 3. What is the conforman= ce standard? And going back to point (1), if we all agree that we wish the = value were 2, do we file an erratum on the PDF or just regenerate it? Conve= rsely, if we all agree that we wish it were 3 then do we file an erratum on= the XML and/or do a bis?

=
Just to sharpen this point, when I say "we wish" I mean it&#= 39;s completely clear it should be this value, for instance, the approved d= raft had the agreed upon value in all formats but it got mangled somewhere = in RFC processing.

-Ekr


Would be good to get consensus = on what we think these docs say and what we think they ought to say.
<= div>
-Ekr


=C2=A0 =C2=A0Brian

>
> Cheers,
> Andy
>
>
>
>
> On Tue, May 12, 2020 at 5:05 PM Brian E Carpenter <brian.e.carpenter@gmail.co= m <mailto:brian.e.carpenter@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I note that RFC7990 says:
>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Canonical format: th= e authorized, recognized, accepted, and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0archived version of = the document
>
>=C2=A0 =C2=A0 =C2=A0This could well be an error. Making our XML dialect= the *canonical*
>=C2=A0 =C2=A0 =C2=A0format was what most of us thought about. Maybe a s= pecified rendering
>=C2=A0 =C2=A0 =C2=A0that could, in theory, be drawn on parchment should= be the *archival*
>=C2=A0 =C2=A0 =C2=A0format.
>
>=C2=A0 =C2=A0 =C2=A0Since RFC7990 is a request for comments, we can cho= ose to update it.
>
>=C2=A0 =C2=A0 =C2=A0This should go on the next RSE's "to do&qu= ot; list, I think.
>
>=C2=A0 =C2=A0 =C2=A0Regards
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian Carpenter
>
>=C2=A0 =C2=A0 =C2=A0On 12-May-20 19:15, Mark Nottingham wrote:
>=C2=A0 =C2=A0 =C2=A0> Hi John,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> On 12 May 2020, at 5:03 pm, John C Klensin= <john-ietf@jck.c= om <mailto:jo= hn-ietf@jck.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Mark, I fear that takes us around in a bit= of a circle, albeit
>=C2=A0 =C2=A0 =C2=A0>> an important one. I was forcefully educate= d (one might say
>=C2=A0 =C2=A0 =C2=A0>> "beaten up") some years ago by a= n Archivist (his job title)
>=C2=A0 =C2=A0 =C2=A0>> associated with a national repository libr= ary in the north of
>=C2=A0 =C2=A0 =C2=A0>> Europe.=C2=A0 =C2=A0He explained that it w= as very hard to have a
>=C2=A0 =C2=A0 =C2=A0>> conversation about what was "archival= " or about the meaning of
>=C2=A0 =C2=A0 =C2=A0>> the closely-related term "permanent&q= uot; with people in computer
>=C2=A0 =C2=A0 =C2=A0>> fields (especially web-related ones) becau= se we tended to think
>=C2=A0 =C2=A0 =C2=A0>> of "permanence" as 10 - 20 years= .=C2=A0 He claimed that most people
>=C2=A0 =C2=A0 =C2=A0>> he had encountered from North America or t= he South Pacific had
>=C2=A0 =C2=A0 =C2=A0>> similar problems with believing permanence= , in practice, could
>=C2=A0 =C2=A0 =C2=A0>> be considered a few centuries but that he = and his colleagues
>=C2=A0 =C2=A0 =C2=A0>> needed to work in terms of at least severa= l millennia and that
>=C2=A0 =C2=A0 =C2=A0>> those differences put an entirely differen= t spin on things.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This does not shock me, but then I've inte= rned in an art museum, where the challenges of conservatorship were painful= ly obvious.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> That story is important in the current con= text for two reasons:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> * While I consider the decision made and h= ence not part of the
>=C2=A0 =C2=A0 =C2=A0>> current RFC Editor Futures discussion (eve= n though I, and
>=C2=A0 =C2=A0 =C2=A0>> apparently others, have growing doubts abo= ut how we are
>=C2=A0 =C2=A0 =C2=A0>> implementing it), a conversation with almo= st any (I don't know
>=C2=A0 =C2=A0 =C2=A0>> of exceptions, but maybe there are some) p= rofessional archivist
>=C2=A0 =C2=A0 =C2=A0>> about treating a source format that requir= es considerable
>=C2=A0 =C2=A0 =C2=A0>> compilation and reference to external sour= ces and mechanisms to
>=C2=A0 =C2=A0 =C2=A0>> get to a form people are comfortable readi= ng as an archival form
>=C2=A0 =C2=A0 =C2=A0>> will typically be greeted with laughter an= d/or comments to the
>=C2=A0 =C2=A0 =C2=A0>> effect that we should come back in a hundr= ed years and show them
>=C2=A0 =C2=A0 =C2=A0>> that XML is still around and that it is th= e same, or at least
>=C2=A0 =C2=A0 =C2=A0>> completely backward-compatible, XML.=C2=A0= If they, and their
>=C2=A0 =C2=A0 =C2=A0>> considerations, are to be taken seriously = as we talk about
>=C2=A0 =C2=A0 =C2=A0>> "archival", things are broken al= ready and comments about the
>=C2=A0 =C2=A0 =C2=A0>> merits of continuing to dig when one finds= oneself in a deep
>=C2=A0 =C2=A0 =C2=A0>> hole may be relevant.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I tend to agree; if I'd been more involved= in the IETF when this decision was made, I would have fought it (based upo= n my early experiences with XML, more than anything).
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> * There have been several discussions in r= ecent years about
>=C2=A0 =C2=A0 =C2=A0>> treating IETF specifications as living doc= uments or with some
>=C2=A0 =C2=A0 =C2=A0>> other arrangement in which issues are fold= ed in as soon as they
>=C2=A0 =C2=A0 =C2=A0>> are detected and at least tentative conclu= sions reached about
>=C2=A0 =C2=A0 =C2=A0>> how to proceed.=C2=A0 I don't know whe= ther we need to resolve those
>=C2=A0 =C2=A0 =C2=A0>> proposals before moving forward with discu= ssions about the
>=C2=A0 =C2=A0 =C2=A0>> future of the RFC Series and its managemen= t and organization (I
>=C2=A0 =C2=A0 =C2=A0>> hope we don't because the community se= ems quite divided to me).
>=C2=A0 =C2=A0 =C2=A0>> However, I think we need to understand tha= t moving in that
>=C2=A0 =C2=A0 =C2=A0>> direction, even if we make periodic snapsh= ots and publish them
>=C2=A0 =C2=A0 =C2=A0>> as RFCs, would profoundly change the chara= cter of the series as
>=C2=A0 =C2=A0 =C2=A0>> providing a clearly-identifiable (and &quo= t;archival") record of the
>=C2=A0 =C2=A0 =C2=A0>> evolution of Internet technology and stand= ards.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I think that people are becoming slightly abso= lutist when they talk about this subject, but worse, they perceive those on= "the other side" as *really* absolutist.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I hope no one seriously thinks that "arch= ival" means that we can't change _any_ aspect of the series, ever = -- that it's a machine that must run on in its current form until its d= oom. I also hope that no one thinks that changing things means that it must= be possible to change any character / bit in any RFC at any time.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> If we can put those extremes safely out of the= way and focus on what the needs of the archival and other communities are,= we might make some progress.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Maybe we could give some guidance here, but I = agree we do have some other issues to dispose of first.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>>> ...
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =E2=80=A2 The RFC Ser= ies is community property and must operate on
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 behalf of the communi= ty as a whole.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =E2=80=A2 The exact definition of the relevant community is open
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 for debate. One definition is: the IETF, the IRTF, the IAB
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 and the many other people who have contributed to, or made
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 use of, the RFC Series over the last fifty years.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =E2=80=A2 Major decis= ions about the future of the RFC Series must
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 be taken by a rough c= onsensus of this very broad community.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =E2=80=A2 How to reach out to this community and judge its
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 consensus is in itself a big question.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> I think it's widely agreed that yo= ur conclusions about the
>=C2=A0 =C2=A0 =C2=A0>>> series not being 'owned' by an= y of the I* are correct.
>=C2=A0 =C2=A0 =C2=A0>>> However, I'd suggest that we can r= each out to and judge
>=C2=A0 =C2=A0 =C2=A0>>> consensus of that community just like = we do in any other area
>=C2=A0 =C2=A0 =C2=A0>>> -- establish a venue (e.g., a WG) and = make it known that if
>=C2=A0 =C2=A0 =C2=A0>>> you're a stakeholder who's int= erested, that's the appropriate
>=C2=A0 =C2=A0 =C2=A0>>> place to contribute. Doubtless some pe= ople will not choose to
>=C2=A0 =C2=A0 =C2=A0>>> come, but that's their choice. Oth= ers might advocate on their
>=C2=A0 =C2=A0 =C2=A0>>> behalf; we already see that with civil= society organisations
>=C2=A0 =C2=A0 =C2=A0>>> being involved in the IETF's work.=
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> One problem is that one important audience= for the Series, or at
>=C2=A0 =C2=A0 =C2=A0>> least the documents we claim are standards= (or to which assorted
>=C2=A0 =C2=A0 =C2=A0>> parties claim conformance) are people writ= ing procurement
>=C2=A0 =C2=A0 =C2=A0>> documents (RFPs, contracts, SLAs, etc.).= =C2=A0 The odds that we will
>=C2=A0 =C2=A0 =C2=A0>> get a reliable representation from that co= mmunity even if we
>=C2=A0 =C2=A0 =C2=A0>> could reach them are, I think, pretty smal= l.=C2=A0 =C2=A0The odds that we
>=C2=A0 =C2=A0 =C2=A0>> could get them to participate in a WG-like= arrangement?
>=C2=A0 =C2=A0 =C2=A0>> Probably much lower.=C2=A0 But, at least i= f one were to assume a free
>=C2=A0 =C2=A0 =C2=A0>> market in which alternatives exist, those = people are key to
>=C2=A0 =C2=A0 =C2=A0>> determine if our standards go anywhere.=C2= =A0 Indeed, when they write
>=C2=A0 =C2=A0 =C2=A0>> contracts that require conformance and try= to enforce them, they
>=C2=A0 =C2=A0 =C2=A0>> are actually the closest we get to actuall= y having a Protocol
>=C2=A0 =C2=A0 =C2=A0>> Police.=C2=A0 And, by the way, they, and t= he kinds of documents they
>=C2=A0 =C2=A0 =C2=A0>> are willing to work with, interact with th= e "living document"
>=C2=A0 =C2=A0 =C2=A0>> ideas as well:=C2=A0 IMO at least, we dare= not ignore them because we
>=C2=A0 =C2=A0 =C2=A0>> cannot get their participation on our norm= al terms.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thank you; this is exactly how things sit alre= ady in many WGs, e.g., HTTP. The decisions we make impact many people who d= on't even know we exist on a daily basis.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Cheers,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> --
>=C2=A0 =C2=A0 =C2=A0> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/<= /a>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> .
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=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
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000ee92de05a57b8c31-- From nobody Tue May 12 16:28: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 E76FE3A0A8C for ; Tue, 12 May 2020 16:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzyKAf3GrZaL for ; Tue, 12 May 2020 16:28:26 -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 1C1773A0AEB for ; Tue, 12 May 2020 16:28:25 -0700 (PDT) Received: from xse357.mail2web.com ([66.113.197.103] helo=xse.mail2web.com) by mx36.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jYeJs-0001mf-Rw for rfced-future@iab.org; Wed, 13 May 2020 01:28:21 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49MDWL64JLzvg8 for ; Tue, 12 May 2020 16:28:14 -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 1jYeJq-0000Ws-Nj for rfced-future@iab.org; Tue, 12 May 2020 16:28:14 -0700 Received: (qmail 24619 invoked from network); 12 May 2020 23:28:14 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.109]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 May 2020 23:28:14 -0000 To: Eric Rescorla , Brian E Carpenter Cc: John C Klensin , rfced-future@iab.org, Mark Nottingham , "Andrew G. Malis" References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> <2b5d1174-f959-6275-78e3-7cf4eaa86601@gmail.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> Date: Tue, 12 May 2020 16:28:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DEA1CCED97F013B56E26BAB7" Content-Language: en-US X-Originating-IP: 66.113.197.103 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0RZ/HtDapBdRUZhgsSk2AkqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4ia+OhQrZYxznpmqrnAV1azQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEbSzEO3cdZmZQmWXC/DjJhg7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsexWwqk3bUpQuc6Jp1eh0hhbgayajKz0EKpOFDpPFFlWUHAd8gSAl2L3MzpOR/wL4t+S ax8yVT5LNQc0pviCIZ+V87H2ECndxkpBwp1FkQyHa0qTD2ipD9y2znxCv9uYkc8RFZ4oobg8BBg3 Jq+ntzj0gGRlH7tCZJook71t+bq+8g9mDnaXtu0kZC/OWmUorWi+PsEvlNKwnX1+x1gyDBoHGFNQ aS6jlTygus9uGDe6YHW8TfMUfXZNQGXIjuXCLLrqbUfE89xDCZ+X+vdODnr8z1caQoi44Wcfj1z/ J5tTt7j1ptfltBQnq8NvNwuG6kuhBG0YWFj/7xYZzwR7/PiKfowXlsolACJrkW/vjDp2NmSdEOMf tBjsWb6BDQzjSsG66974nkMwEqjhfSKHlA2Q3p5onVdn12r9xqR15ROHBesyXD9BkbKX7eGI2jGt /RQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 23:28:28 -0000 This is a multi-part message in MIME format. --------------DEA1CCED97F013B56E26BAB7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/12/2020 4:08 PM, Eric Rescorla wrote: > 1. As I understand it, the XML is immutable (7990 S 10.2). > However, the publication formats can be regenerated as needed. Is > that correct? I read the text above as just saying that the PDF > should be generated in a way that it is suitable for long-term > storage but isn't immutable. > > 2. In case of conflict, which version is authoritative? For > instance, suppose that the XML has a 2 in one place but the PDF > renders with a 3. What is the conformance standard? And going back > to point (1), if we all agree that we wish the value were 2, do we > file an erratum on the PDF or just regenerate it? Conversely, if > we all agree that we wish it were 3 then do we file an erratum on > the XML and/or do a bis? > > > Just to sharpen this point, when I say "we wish" I mean it's > completely clear it should be this value, for instance, the approved > draft had the agreed upon value in all formats but it got mangled > somewhere in RFC processing. I am concerned that this is another example of the IETF landing on a very complicated solution through a working group process. The theory is that the XML is authoritative. But in practice, if the IETF has to produce a document to a third party, the third party will insist on something they can read. Most likely, PDF. But then, the PDF is derived from XML by software, and that software can change over time. Imagine two parties in a patent lawsuit arguing whether a technology was covered by RFC XYZT, but arguing from different PDF renderings. "Page 237 says that bla." "Oh, no, no such text on page 237." Endless fun. -- Christian Huitema --------------DEA1CCED97F013B56E26BAB7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 5/12/2020 4:08 PM, Eric Rescorla wrote:

1. As I understand it, the XML is immutable (7990 S 10.2). However, the publication formats can be regenerated as needed. Is that correct? I read the text above as just saying that the PDF should be generated in a way that it is suitable for long-term storage but isn't immutable.

2. In case of conflict, which version is authoritative? For instance, suppose that the XML has a 2 in one place but the PDF renders with a 3. What is the conformance standard? And going back to point (1), if we all agree that we wish the value were 2, do we file an erratum on the PDF or just regenerate it? Conversely, if we all agree that we wish it were 3 then do we file an erratum on the XML and/or do a bis?

Just to sharpen this point, when I say "we wish" I mean it's completely clear it should be this value, for instance, the approved draft had the agreed upon value in all formats but it got mangled somewhere in RFC processing.


I am concerned that this is another example of the IETF landing on a very complicated solution through a working group process. The theory is that the XML is authoritative. But in practice, if the IETF has to produce a document to a third party, the third party will insist on something they can read. Most likely, PDF. But then, the PDF is derived from XML by software, and that software can change over time. Imagine two parties in a patent lawsuit arguing whether a technology was covered by RFC XYZT, but arguing from different PDF renderings. "Page 237 says that bla." "Oh, no, no such text on page 237." Endless fun.

-- Christian Huitema

--------------DEA1CCED97F013B56E26BAB7-- From nobody Tue May 12 16:41: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 EF2173A0C89 for ; Tue, 12 May 2020 16:41: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 cBOrYxtdOU1b for ; Tue, 12 May 2020 16:41:51 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A3D3A0C7F for ; Tue, 12 May 2020 16:41:51 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id h26so12721706qtu.8 for ; Tue, 12 May 2020 16:41:51 -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=vJbio3ueM8TseI1C3E0cyjKy+uy28CaPj/TZQ/Ix6/4=; b=076J3xjCgqXYstS7dx/UzAKbzHRnYvzQodPumOU685MnzgiinL+K+jaGRA71FJK8aR FK3GYda2GDq2qkS1ynQYOPhNeo3ynp9Wz/kWEAfApMCpi/fJMll5KbwtDJZVu2049IuG jseg9V/S2SuPuwgu1WfcvxPVIUIGTtlX5/Sp5Nk1qJDUpkI1NnC+uYXUZYg9/aW9S51l fPuTbq02G2CWRzPIOgsfWtehVlNFoAnAicJq3asOnybwYGOI22vJA+s6PZBLtt6xXRoP mvwH+Mpk4mtqW4FWOYUJvMSJKyQoiQTF3IK/RSAzbKG2cqQx4hgS07Ph1EPbsixq2syE 8uSA== 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=vJbio3ueM8TseI1C3E0cyjKy+uy28CaPj/TZQ/Ix6/4=; b=m8rKDapSeLr6XA0JUzT/HJWdbM36uVkagFNAdzd1ijoT8RuGEz/wCiRtryIyFWlWxh jeaD20GGH+0JDjewCQuN6VIllndwUhRZ6owh7ED2NvePdnm7Umi2WyR1wnwKYFuBLZUH p0fDTqzoL+srAgkjoD/QuEBXgbs1dWZhnAoqWa8wQwHDN+nzpb5zul96I5WyGltMx6e6 7CyFCMb5jA9kEgCm/kejMEHeWOK1Ms/wW/eEJfl9uUu7FB4A/T2bBjYWjDcKjZynuMUg 5iH32FC4spS5tf7BccEsjpGrC0bhQQnGQ41TqCgakgEW+viCaXcClpKX7/pjFnOOVpeC S8AA== X-Gm-Message-State: AGi0PuYaJEGRuToTNKnWIhYl2OJuBJAHSCaQEfGpFF2GEkR0jr3Cy48U Ro9BBg8FDpOUP4r5xXKfTIcNkjvOFB/Wbw== X-Google-Smtp-Source: APiQypLGUXGbocE2Rwr3YoPfjZ/wkJMpetB4XLD4qJ1nm0OMJ1xNq2/JYwWwTehmv5UjQtNtbH6RUA== X-Received: by 2002:ac8:4e1c:: with SMTP id c28mr16508914qtw.378.1589326909935; Tue, 12 May 2020 16:41:49 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id f68sm12641714qke.74.2020.05.12.16.41.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 16:41:49 -0700 (PDT) To: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> <2b5d1174-f959-6275-78e3-7cf4eaa86601@gmail.com> <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> From: Michael StJohns Message-ID: Date: Tue, 12 May 2020 19:41:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 23:41:53 -0000 On 5/12/2020 7:28 PM, Christian Huitema wrote: > I am concerned that this is another example of the IETF landing on a > very complicated solution through a working group process. The theory > is that the XML is authoritative. But in practice, if the IETF has to > produce a document to a third party, the third party will insist on > something they can read. Most likely, PDF. But then, the PDF is > derived from XML by software, and that software can change over time. > Imagine two parties in a patent lawsuit arguing whether a technology > was covered by RFC XYZT, but arguing from different PDF renderings. > "Page 237 says that bla." "Oh, no, no such text on page 237." Endless fun. Just because the legal folk insist on something they can read, doesn't mean that document will end up being the legal reference.   This is akin to the problems where you have two different languages involved in a lawsuit.  There's going to be a source document and a certified translation of some sort.  Think of the PDF as a certified translation between Geek and English. In any event, XPath or something similar may end up being the way a lawyer refers to a paragraph or section or whatever.   We probably don't need to resolve the question at this point and instead leave it to the lawyers to deal with.  We just need to be clear in any legal service what the archival/canonical document actually is. AIRC from recent discussions, any produced PDF is going to end up having the source XML embedded. Later, Mike ps - the underlying language of the more recent Word version is XML.  I've had rendered formats of the underlying XML change pretty radically between versions.  It didn't actually change the meaning of the document. pps - maybe an option on the production tools to embed XPath references in the PDF or HTML rendered document as hidden text or some sort of tool tip comment? From nobody Tue May 12 19:13: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 245BF3A0CD2 for ; Tue, 12 May 2020 19:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNm3d7jIGt3b for ; Tue, 12 May 2020 19:13:55 -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 BF90C3A0CD1 for ; Tue, 12 May 2020 19:13:54 -0700 (PDT) Received: (qmail 84944 invoked from network); 13 May 2020 02:13:50 -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=14bc8.5ebb57de.k2005; bh=ucnLRbXDU4wu0f+C8QzfvfNBwa35Elb7kCDz5IX9i3I=; b=IeoqVxK9MFt4yD1KO9BXoIMHGSVHdRJrEZIschYIL0TW3DJuFcX/FN8Xdhbq3b+0LpH2CXJY8FS3+svSrjA1vM23uqvC2PwN7PRZwvaLoYc/+Wi0DwK1oruGQD8tWgLYvggnrsjpyEes6r/zbROymH18P+M9SuZqqwpg/nx1mzmJ49o0SoDUlnhEZnobQ43EVIShfAg+TKWkIcE6zYn989TgOjdSjHZOkT87Kn302nRNb8sdGZ/Ygc+332ByLAgt Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 13 May 2020 02:13:50 -0000 Received: by ary.qy (Postfix, from userid 501) id 5B02B1943085; Tue, 12 May 2020 22:13:49 -0400 (EDT) Date: 12 May 2020 22:13:49 -0400 Message-Id: <20200513021350.5B02B1943085@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: huitema@huitema.net In-Reply-To: <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [Rfced-future] The XML really is canonical X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 May 2020 02:13:56 -0000 In article <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> you write: >> 1. As I understand it, the XML is immutable (7990 S 10.2). >> However, the publication formats can be regenerated as needed. Is >> that correct? I read the text above as just saying that the PDF >> should be generated in a way that it is suitable for long-term >> storage but isn't immutable. That is correct. We have already regenerated all the PDFs to fix an error in the production process. The layout of the current PDFs is not wonderful and I think it's likely that we'll regenerate them again as we learn more about managing the layout. >I am concerned that this is another example of the IETF landing on a >very complicated solution through a working group process. The theory is >that the XML is authoritative. But in practice, if the IETF has to >produce a document to a third party, the third party will insist on >something they can read. Most likely, PDF. But then, the PDF is derived >from XML by software, and that software can change over time. Imagine >two parties in a patent lawsuit arguing whether a technology was covered >by RFC XYZT, but arguing from different PDF renderings. "Page 237 says >that bla." "Oh, no, no such text on page 237." Endless fun. Fortunately, since the people who designed the v3 format were not completely incompetent, they anticipated that problem. Each PDF has a copy of the XML file embedded in it as a PDF attachment. In the unlikely event that there is a question whether the PDF accurately represents the contents of the XML, anyone who has the PDF can extract the embedded XML and look at it to see what the canonical version says. Since the XML is a stream of ordinary UTF-8 text, I'd say that the chances that there will still be something around that can display it several decades from now remain quite good. Considering the kinds of legal cases in which our RFCs tend to be used, if they can't figure out how to use a text editor to look at the XML they have worse problems than what's in our PDF. I would encourage people in this discussion to remember that even though an issue may be new to you, it doesn't mean it's new to everyone. R's, John PS: we asked our lawyers whether it would be a problem if we rerendered the PDFs, and the answer was no. Legal processes have been dealing with versions of documents for a very long time, and I am sure I'm not the only one here who's been in a court case where some of the evidence was Nth level copies of printouts of who knows what. From nobody Tue May 12 19:24: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 2B0223A0CE4 for ; Tue, 12 May 2020 19:24:15 -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 0TEr3THUm-kK for ; Tue, 12 May 2020 19:24:13 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 794643A0CE3 for ; Tue, 12 May 2020 19:24:13 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id u6so15945608ljl.6 for ; Tue, 12 May 2020 19:24:13 -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=mFy4S/pRa1l7F23786IKIwvA/5jejdN/e3lL0f4CZFk=; b=MulUvdlZT7GbQtAIF/2Rl0DPw2p2LVHcUKocxXS3QkJVCt/WqM6Yz47BTqfHcZtIry D6GdMIfCjv8TDQ4oTWsqGVCz9tODdRbHJ5KHNxX/A6GLU+GKTvtRvrzhfq4FYwCIOEMv WpIo9GaScNOLwbDyBfEta9Am7qWYcYSkYH/fOFATsa3hJ7rnuRkvG5XbA/6OpaHBOh5H 5l5rv9Ytm/DNDgHdCoIp+7HPLNFIkO9ptDzsH7oMJnvFCLBQXOPs7dUqhnZzPS9I1KUZ nqkIh2PSmjk3idj/pFY77btLvwWW82UEuo+3XDzHNAFKoOya3utf1dMlUEUwMjfo2riI ENgA== 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=mFy4S/pRa1l7F23786IKIwvA/5jejdN/e3lL0f4CZFk=; b=f36UD+EXw9oWLKerBE+r9fawzsux5TZ+UV836DuQdFQATE9KBLbCNGx+GGGxA4RPlY pNNWuiJdo9JB2G7fFuWx8XsHAaOCv/PvDAqd5UZ1JL+HYXQHfjaiOfjwY1xk3sZdrYwM 2/yQi6BHSKQLm7JEHkAhgaCOKSZ3Ck6dQMZ/jZkhfBCW4a04T7gVNaZI28ZQ/U7neZkd 5IyHTyDK0Q03qlrE3q/96E7mYnfKZz51OnOTFnmo2wxtZKs3Ivd+DBplMVA4FwSnRonv GC/+TH1BEmO4i6Rn/+cJckzKcvLvWFa55uT4Vzq0TiClFnoTDSSU7F4xLYbbUagHTStG 8jPg== X-Gm-Message-State: AOAM533QW2ThSRu7ff/pag/qzGWEtM6orHaYlg1y+Qdu1eVe/Ic7a4ys T1LMBiHc8dc+5GDN6Fc/pwxFVfzPI9FInGAiMwaD3dKnBgY= X-Google-Smtp-Source: ABdhPJxtbe5CEGot3TDJJ6k1xzq9vOMiJ8yuhPBZhAx16A7D4D4zawhZcMSTbaKDXYlADB6TpVriYJauOS1p8bKwsYM= X-Received: by 2002:a2e:87d3:: with SMTP id v19mr14783941ljj.176.1589336651706; Tue, 12 May 2020 19:24:11 -0700 (PDT) MIME-Version: 1.0 References: <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> <20200513021350.5B02B1943085@ary.qy> In-Reply-To: <20200513021350.5B02B1943085@ary.qy> From: Eric Rescorla Date: Tue, 12 May 2020 19:23:35 -0700 Message-ID: To: John Levine Cc: rfced-future@iab.org, Christian Huitema Content-Type: multipart/alternative; boundary="0000000000008dc9c905a57e466b" Archived-At: Subject: Re: [Rfced-future] The XML really is canonical X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 May 2020 02:24:15 -0000 --0000000000008dc9c905a57e466b Content-Type: text/plain; charset="UTF-8" On Tue, May 12, 2020 at 7:14 PM John Levine wrote: > In article <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> you write: > >> 1. As I understand it, the XML is immutable (7990 S 10.2). > >> However, the publication formats can be regenerated as needed. Is > >> that correct? I read the text above as just saying that the PDF > >> should be generated in a way that it is suitable for long-term > >> storage but isn't immutable. > > That is correct. We have already regenerated all the PDFs to fix an > error in the production process. The layout of the current PDFs is not > wonderful and I think it's likely that we'll regenerate them again as > we learn more about managing the layout. > Thanks. That is what I expected. > I would encourage people in this discussion to remember that even > though an issue may be new to you, it doesn't mean it's new to > everyone. > I didn't think it was new to everyone, but it's not 100% clear in the RFC (at least as I read it) so I wanted to make sure I understood correctly. -Ekr --0000000000008dc9c905a57e466b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 12, 2020 at 7:14 PM John = Levine <johnl@iecc.com> wrote:<= br>
In article <<= a href=3D"mailto:2409aa18-91b2-e184-e203-674c551ec626@huitema.net" target= =3D"_blank">2409aa18-91b2-e184-e203-674c551ec626@huitema.net> you wr= ite:
>>=C2=A0 =C2=A0 =C2=A01. As I understand it, the XML is immutable (79= 90 S 10.2).
>>=C2=A0 =C2=A0 =C2=A0However, the publication formats can be regener= ated as needed. Is
>>=C2=A0 =C2=A0 =C2=A0that correct? I read the text above as just say= ing that the PDF
>>=C2=A0 =C2=A0 =C2=A0should be generated in a way that it is suitabl= e for long-term
>>=C2=A0 =C2=A0 =C2=A0storage but isn't immutable.

That is correct. We have already regenerated all the PDFs to fix an
error in the production process. The layout of the current PDFs is not
wonderful and I think it's likely that we'll regenerate them again = as
we learn more about managing the layout.

Thanks. That is what I expected.

=C2=A0
I would encourage people in this discussion to remember that even
though an issue may be new to you, it doesn't mean it's new to
everyone.

I didn't think it was new= to everyone, but it's not 100% clear in the RFC (at least as I read it= ) so I wanted to make sure I understood correctly.

=
-Ekr

--0000000000008dc9c905a57e466b-- From nobody Tue May 12 19:36: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 EF2D53A0CF0 for ; Tue, 12 May 2020 19:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23aFa8kJCjys for ; Tue, 12 May 2020 19:36:13 -0700 (PDT) Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (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 CE8953A0CEF for ; Tue, 12 May 2020 19:36:13 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id s69so2155238pjb.4 for ; Tue, 12 May 2020 19:36:13 -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=3v3fiFTOdl2SxbDi9W+rFst9yNNuHoVWJ9beD76aric=; b=X1lxEOleayavj0M9B93rvpehi9uY9OYLY2UTDn3PrjLA/CkebujEalWY4p107AvBtL mZSSmGqe+0IJ0yNWhz7omo1F8FxTe1dBL/ayK95jh7zUcMiKC7hD0XisERNAA1kWQh/1 SmXOvZV+vi6a7GipQfigV0kKQQD7vXHJqaGWpwiU0AWbjR9DScEzLIcg0BbpvIlHKDG/ oUaEKW5jIiNACcVBuObpCakeeb0ycVedSdr/wtwp8SvSZBcrOaO7a5kU2zpnB0mhgFWe hgUaeWr9w7Mk19t9wP5+oqjnutj389LevdvrVYW0ZBSH55pWkyOhwF7xySHyFXBNSnJ+ /U/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3v3fiFTOdl2SxbDi9W+rFst9yNNuHoVWJ9beD76aric=; b=s1wSmLd1H2dstCd78jwXDAy/qXugVy+IDLw0RjxAqYJrNgaOMsGRCZ0v/cRSeXf+3N j9L0ZaEj4hTtoQd4WSKGJdrbnsbK8TITrihVNsj0yTrdW/NgTn8vYurpDTVN2mlkXNO+ BozciTydTaMSrGbSAfGQ9t5m5yEQF3my6XCN4rJ2ty/cx0jXLlOA/hgiCLa/DgrubLRr FV6ssvGyHYDiQA0NYkqnW3EewTg9lm96cdUAmJGtNwiQqnJMKgc4battx8iUzxO2iPR4 C+T/QxOgIil4OZmTgzpLywKSX4ym6/h9i5G5Tvmf9ARmjxSJdPCUjORSs2aYodqB5KPN bWhw== X-Gm-Message-State: AGi0PuYrJuS06ePHD1O+rN7yQLvo1ZRvsAQw4RgmOw6TgBPsJ59haoQl U4VnCxFRwSodyU/9ig2pQUA= X-Google-Smtp-Source: APiQypIDMIr8yqXtOrV9JeOf1zkXf9+YM/2hCHd8his2jqGLXTTqfmkILewgVUeCDpqB0E5kp+O77A== X-Received: by 2002:a17:902:6f09:: with SMTP id w9mr23495724plk.245.1589337373271; Tue, 12 May 2020 19:36:13 -0700 (PDT) Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id a138sm13194214pfd.32.2020.05.12.19.36.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2020 19:36:12 -0700 (PDT) To: Eric Rescorla , John Levine Cc: rfced-future@iab.org, Christian Huitema References: <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> <20200513021350.5B02B1943085@ary.qy> From: Brian E Carpenter Message-ID: <8e53d183-1743-79ff-e9ea-add6032909fc@gmail.com> Date: Wed, 13 May 2020 14:36:08 +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] The XML really is canonical X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 May 2020 02:36:15 -0000 On 13-May-20 14:23, Eric Rescorla wrote: >=20 >=20 > On Tue, May 12, 2020 at 7:14 PM John Levine > wrote: >=20 > In article <2409aa18-91b2-e184-e203-674c551ec626@huitema.net > you write: > >>=C2=A0 =C2=A0 =C2=A01. As I understand it, the XML is immutable (= 7990 S 10.2). > >>=C2=A0 =C2=A0 =C2=A0However, the publication formats can be regen= erated as needed. Is > >>=C2=A0 =C2=A0 =C2=A0that correct? I read the text above as just s= aying that the PDF > >>=C2=A0 =C2=A0 =C2=A0should be generated in a way that it is suita= ble for long-term > >>=C2=A0 =C2=A0 =C2=A0storage but isn't immutable. >=20 > That is correct. We have already regenerated all the PDFs to fix an= > error in the production process. The layout of the current PDFs is = not > wonderful and I think it's likely that we'll regenerate them again = as > we learn more about managing the layout. >=20 >=20 > Thanks. That is what I expected. >=20 > =C2=A0 >=20 > I would encourage people in this discussion to remember that even > though an issue may be new to you, it doesn't mean it's new to > everyone. >=20 >=20 > I didn't think it was new to everyone, but it's not 100% clear in the R= FC (at least as I read it) so I wanted to make sure I understood correctl= y. If you mean RFC7990, its initial terminology definition asserts that the = canonical format is archived. That leaves the later statement about PDF/A= -3 ("will be developed with an eye towards long-term archival storage") w= ithout an anchor. I'm not losing any sleep over this. Brian From nobody Tue May 12 19:42:53 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7283A0C99 for ; Tue, 12 May 2020 19:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=jP4g9MUZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JukNFuS4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdPgv2n10bGk for ; Tue, 12 May 2020 19:42:49 -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 21AEB3A0CF0 for ; Tue, 12 May 2020 19:42:49 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 393855C0180; Tue, 12 May 2020 22:42:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 12 May 2020 22:42:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=V 5zcj1so6zKGUGgggbymTqNasKc0tpYuAmuYGevGInM=; b=jP4g9MUZW4NYeRdlm d0/hSUr+u6anOQNmLOWEvZZBXUwyjHN/bYiTgVhzLNLGawM0SMhy0/Hqq/+kCSAY BY12H+WyyXBe6lcLLRfZV7J6A4PIm5P7JT8q+F1ubcf33xv1HBZscvBePdwWR1eO 1h/4TeFO8ehtlxgQhftad0op4OPoLUWZCRLu0o8FY2ksESgZmu72MsTBr9iPnLpb WPMgyWK8kjWQzO4/b715zhPOAOFcPigM4ubpdlvGdKVLlz+KnD9LmnnoKzvPk2xI LZ219QYzC224H8fQwL3DDgGW3AFpYmYDoK9L7V9kirIi4n5D5N/ii9AGavH94d6G 5TsVA== 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=fm2; bh=V5zcj1so6zKGUGgggbymTqNasKc0tpYuAmuYGevGI nM=; b=JukNFuS4GHksx08XpmHHXUk8paraB0Gb3cQh8i8zju+N3949UO+ns8IVF OaACzxNkeLQLl1MpE0eHHwAvbOTQxi+ZHwWRyAC0uSjNIohEerJCEbSO/kuUnTwt ugLqJv5I+BNpt9A+E69wqePK5OrQORO7f21kPswDhfBgTWhyDVqao5tP38JY8KD+ S9EFyDCpiPW6q5pvP3Zuf+X23QtoNHfMIsnemIZvfzZ3r5+Kknr22ypzraECCs4D 74nCmxjtWbKn0U723gX/1s1Bfp7x9WT2suzeNPIma2j+fLOotWRtna8K7jzNLskU KOmT0K6iSQovx9Evu0/9ogGcszKXA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleefgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeevffffhfduteevvefhueffieegtdeutd ehffeltefffedttdeggeejheeiueetteenucffohhmrghinhepmhhnohhtrdhnvghtnecu kfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 9E08E3280059; Tue, 12 May 2020 22:42:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Wed, 13 May 2020 12:42:41 +1000 Cc: Eric Rescorla , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 02:42:52 -0000 Mike, > On 13 May 2020, at 6:46 am, Michael StJohns = wrote: >=20 > Basically, what you've proposed is a strawman to be knocked down. My = guess is that any RSE that lets through something that *is* harmful to = the internet (rather than just thinks it might be) will not have had a = long tenure to start with. What I think you're asking is similar to = the problems that editors of wide circulation publishers go through all = the time - to print or not to print. In their case it might be "do we = have enough evidence that politician A has actually committed adultery = with staffer B" or "does printing C put D and E into danger"? The = business side may say - Lawyers are fine with it and it will make us = money, but no editor worth their salt will let that be the only decision = criteria. I don't think it's helpful to use such a loose analogy in combination = with a hypothetical to inform our discussion. It would be much more = useful if we could focus on whether there's a concrete need to allow the = RSE to do refuse publication -- for example, if it's intended as a = counterbalance to the IESG and other stream managers' powers, let's = examine that (and concurrently look at what counterbalances *that* = power). If we do think that the stream managers need such a check, it's possibly = a bigger discussion; as has been mentioned, the recall process is = intended to be act as a limit on the powers of the IESG and IAB. While = recalls might not be perfect, fixing them indirectly through a function = of the RSE shouldn't be the first thing we try, and it'd need to be = coordinated. If there are other reasons that we think it's valid for the RSE to = refuse publication, let's come up with some examples and see if we can = agree on some underlying principles.=20 > So yes, the RSE absolutely can prevent publication, and yes absolutely = the community (NOT the IESG, not the IAB etc) can arrange to replace the = RSE for cause if such cause exists. The RSE may indeed be able to mechanically prevent publication (in that = they can fail to progress a document). If they did so with the intent of = not allowing a stream to publish for non-editorial reasons, I suspect = the community would indeed react.=20 However, "the community" doesn't do the removing; n random people can't = stand up and say "the RSE is hereby removed" with effect. To even get = close to that being true, we'd need to accept the tyranny of whoever's = able to shout the loudest. On principle, I (and I suspect others) would = not accept _that_, and would endeavour to shout even louder. Currently one can interpret the IAB has having the oversight role that = would be the mechanism for this (with some amount of delegation to RSOC, = and administrative function provided by the LLC); if that's removed to = promote independence of the RSE, what would replace it? For example, we = could assign it to: * Nothing -> RSE as (hopefully B)DFL * The IAB and/or RSOC, but with more specific guidance -> evolution of = the status quo * Some new body -> with the usual questions about selection, appeal, = limits on power, etc. Are there any other options? One more thing -- at some point, I do want to return to the question of = how the RSE judges and gathers the community's input, because if they're = using it as input to decisions like "I should not publish this RFC", how = they go about getting to that decision matters. An RSE that only engages = with parts of the community isn't going to hear all of the perspectives = that are relevant (especially in a community that's as fragmented as = ours). Decisions where the input and deliberation aren't public are = likely to be questioned, because if the RSE is the only person who sees = it all, the decision won't have legitimacy. And so forth. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue May 12 20:26: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 DF8C43A0D1D for ; Tue, 12 May 2020 20:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR3EHFsNZkKu for ; Tue, 12 May 2020 20:26:47 -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 ECFE83A07C2 for ; Tue, 12 May 2020 20:26:46 -0700 (PDT) Received: (qmail 12844 invoked from network); 13 May 2020 03:26:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=322a.5ebb68f5.k2005; i=johnl-iecc.com@submit.iecc.com; bh=TxFBtiOwdu2ulYpXOvVrhxSbuctYDuxRnVtaIq2Fmsw=; b=ODI6j6P7c/yncrPUuxuwarS7rGUuZanjVQ/Rsu3WtOYiAzdwd6QgU24PfXwUnevhPH9BXdRscYLcTWwYaR+OTIIn/sfgxqvBdwkMUZZtKmogqJAzC9G++lFLTrrkIfNvzHvbIyqybMGM++jqQ/tsRTEBcTu7rzgpwmIQAC/eAu29eGMacqYTNSlQlQ7/gnN35fa6lwqcKzzhstxX79CEvM6uMECxTTAfvFNx8XhnGBw6vK42wEzVj3FHr6jBKQcJ 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; 13 May 2020 03:26:44 -0000 Date: 12 May 2020 23:26:44 -0400 Message-ID: From: "John R. Levine" To: "Brian E Carpenter" Cc: rfced-future@iab.org, "Christian Huitema" In-Reply-To: <8e53d183-1743-79ff-e9ea-add6032909fc@gmail.com> References: <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> <20200513021350.5B02B1943085@ary.qy> <8e53d183-1743-79ff-e9ea-add6032909fc@gmail.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Rfced-future] The XML really is canonical X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 May 2020 03:26:49 -0000 > If you mean RFC7990, its initial terminology definition asserts that the canonical format is archived. That leaves the later statement about PDF/A-3 ("will be developed with an eye towards long-term archival storage") without an anchor. > > I'm not losing any sleep over this. I think it makes a lot of sense to have both. PDF-A/3 is a bitrot resistant profile of PDF intended for archival purposes, which is fine for people who want to look at the words. It doesn't have all of the semantics of the tagged stuff in the XML. My usual example is that I e-mail a survey every month to authors of recent RFCs. Starting with the XML it's about four lines of python to extract the addresses. Doing that from a PDF, urrgh. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue May 12 20:32: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 2A8C43A0D19 for ; Tue, 12 May 2020 20:32:38 -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 8o7MK8Jq56MV for ; Tue, 12 May 2020 20:32:36 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD0D3A0D18 for ; Tue, 12 May 2020 20:32:36 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id d21so8384649ljg.9 for ; Tue, 12 May 2020 20:32: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=zz5SAm0kdCXVfpfFmwLQGH/NxoGBV0kSgOtP8JhwdxU=; b=l21jSZTTnQ7zXrXQ8QRTPzv6d6A91vtp3mi3SKL6z+Ts6TtMwg1Rp/fBh2VPu3rlIH wgwgQdJUIokiDF2c1PMRHrRWv166UcXY98nUQC5sFVHGbBZDetaaICEwIyeUG+45xxi0 J+O+tBwreOkF0u3KMW0/asZYJRE8GRhRHWEdzpI2bUOMu0bFPfCHAZzomnPLP7InJHmF QpjE0oHTt5mYIlh9qZu573xW2m05gVy3WKSLsehl3/miA4vabU8Jx/HGq1Sd/ybuikkT RcN2SMZ/s8PFRUmCVzmmTOY1fUBNtVKfITAZix1Yv2VeFFwiVt4dpknn/iiUdT+lEqtS HVnA== 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=zz5SAm0kdCXVfpfFmwLQGH/NxoGBV0kSgOtP8JhwdxU=; b=SAc+YiaIh0cIZeyv9KjbZQOSmz50pqTDzfvTT/hNi2jCpQIkvFRnpXfzKH2ny55qfd 52/wY49L/hMcpwhmvCKSfLZLmvmAxqx08ha8DSWtgH94ZxsPfh7iDcTfMrZaOiGrZzrb eeLT/kpiE+KPowjut47Xu9Fv0dbprmD/H0cXS8x8UEQQgmjt6OlymrHK2tmiKB/Jeze3 H5fninKPkwr1omEaPWMpIwjRw+FeTnJscxFgRmlTszSmSZ7iiub1PTEUx87O1333GhNv rAZMCoRX8GVOeroMEyDxeU6iRs/yl8HpzC5VL9QkmLr2tDD6xZ1s3q1s6QyDgbYnwHKc FXNA== X-Gm-Message-State: AOAM533sGrM7sAgUP4Rb5UBHUt68WTfFoQsYbZXuO4xGylXNPrn6SM7Q XQofz46zYrQ2afGExJZdfAI8AO2QhYNTBFprScq8pVLOQmA= X-Google-Smtp-Source: ABdhPJwnPg0YgRVil4JOF9P/7Q7DwpzEeFRIABSHh5WIOv7BSVBI4QsirM8Gy/JIc7sWR06LbyZZ5u2RQfJY2yN2VSk= X-Received: by 2002:a2e:99ca:: with SMTP id l10mr15740031ljj.274.1589340754251; Tue, 12 May 2020 20:32:34 -0700 (PDT) MIME-Version: 1.0 References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> In-Reply-To: <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> From: Eric Rescorla Date: Tue, 12 May 2020 20:31:58 -0700 Message-ID: To: Mark Nottingham Cc: Michael StJohns , rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000015a80205a57f3b8a" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 03:32:38 -0000 --00000000000015a80205a57f3b8a Content-Type: text/plain; charset="UTF-8" On Tue, May 12, 2020 at 7:42 PM Mark Nottingham wrote: > Mike, > > > On 13 May 2020, at 6:46 am, Michael StJohns > wrote: > > > > Basically, what you've proposed is a strawman to be knocked down. My > guess is that any RSE that lets through something that *is* harmful to the > internet (rather than just thinks it might be) will not have had a long > tenure to start with. What I think you're asking is similar to the > problems that editors of wide circulation publishers go through all the > time - to print or not to print. In their case it might be "do we have > enough evidence that politician A has actually committed adultery with > staffer B" or "does printing C put D and E into danger"? The business side > may say - Lawyers are fine with it and it will make us money, but no editor > worth their salt will let that be the only decision criteria. > > I don't think it's helpful to use such a loose analogy in combination with > a hypothetical to inform our discussion. It would be much more useful if we > could focus on whether there's a concrete need to allow the RSE to do > refuse publication -- for example, if it's intended as a counterbalance to > the IESG and other stream managers' powers, let's examine that (and > concurrently look at what counterbalances *that* power). > > If we do think that the stream managers need such a check, it's possibly a > bigger discussion; as has been mentioned, the recall process is intended to > be act as a limit on the powers of the IESG and IAB. While recalls might > not be perfect, fixing them indirectly through a function of the RSE > shouldn't be the first thing we try, and it'd need to be coordinated. > To draw out this hypothetical a bit it might be helpful to try to understand what the intended semantics would be. Specifically, if the IETF were to approve a specification [0] and the RFC Editor were then to decline to publish it, what would be the status of the specification under those circumstances [1]? Even if we assume ad arguendo that the RSE is empowered to refuse publication in order to protect the integrity of the series, it's hard to understand how that extends to the power to generally veto IETF decisions. -Ekr [0] Mike, I did see your questions. We could certainly flesh out the details of the IESG's decision procedure for the purposes of the hypo, but I'm not sure it really matters. The IETFs rules are what they are and we don't generally treat standards that had very rough consensus or small numbers of IESG Yes ballots as somehow second class. [1] Of course as often noted, we're not the protocol police so the question of normative force is always a little fraught, but consider a document which has side effects, either because it's a process document or results in changes by IANA, etc. --00000000000015a80205a57f3b8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 12, 2020 at 7:42 PM Mark = Nottingham <mnot@mnot.net> wrote= :
Mike,

> On 13 May 2020, at 6:46 am, Michael StJohns <msj@nthpermutation.com> wrote:=
>
> Basically, what you've proposed is a strawman to be knocked down.= =C2=A0 =C2=A0My guess is that any RSE that lets through something that *is*= harmful to the internet (rather than just thinks it might be) will not hav= e had a long tenure to start with.=C2=A0 =C2=A0 What I think you're ask= ing is similar to the problems that editors of wide circulation publishers = go through all the time - to print or not to print.=C2=A0 In their case it = might be "do we have enough evidence that politician A has actually co= mmitted adultery with staffer B" or "does printing C put D and E = into danger"?=C2=A0 The business side may say - Lawyers are fine with = it and it will make us money, but no editor worth their salt will let that = be the only decision criteria.

I don't think it's helpful to use such a loose analogy in combinati= on with a hypothetical to inform our discussion. It would be much more usef= ul if we could focus on whether there's a concrete need to allow the RS= E to do refuse publication -- for example, if it's intended as a counte= rbalance to the IESG and other stream managers' powers, let's exami= ne that (and concurrently look at what counterbalances *that* power).

If we do think that the stream managers need such a check, it's possibl= y a bigger discussion; as has been mentioned, the recall process is intende= d to be act as a limit on the powers of the IESG and IAB. While recalls mig= ht not be perfect, fixing them indirectly through a function of the RSE sho= uldn't be the first thing we try, and it'd need to be coordinated.<= br>

To draw out this hypothetical a bit it = might be helpful to try to understand what the intended semantics would be.=

Specifically, if the IETF were to approve a = specification [0] and the RFC Editor were then to decline to publish it, wh= at would be the status of the specification under those circumstances [1]? = Even if we assume ad arguendo that the RSE is empowered to refuse publicati= on in order to protect the integrity of the series, it's hard to unders= tand how that extends to the power to generally veto IETF decisions.

-Ekr

[0] Mike, I did see yo= ur questions. We could certainly flesh out the details of the IESG's de= cision procedure for the purposes of the hypo, but I'm not sure it real= ly matters. The IETFs rules are what they are and we don't generally tr= eat standards that had very rough consensus or small numbers of IESG Yes ba= llots as somehow second class.

[1] Of course as of= ten noted, we're not the protocol police so the question of normative f= orce is always a little fraught, but consider a document which has side eff= ects, either because it's a process document or results in changes by I= ANA, etc.
--00000000000015a80205a57f3b8a-- From nobody Tue May 12 20:53: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 46CE03A09C0 for ; Tue, 12 May 2020 20:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGjmRiAmUGlR for ; Tue, 12 May 2020 20:53:24 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B193A0D2E for ; Tue, 12 May 2020 20:53:24 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id e10so9229989vsp.12 for ; Tue, 12 May 2020 20:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xofzn/+8cVKAUfS/Md3qLK+eNf9C1GFqSlHuSW0mEMg=; b=sXpcVgNtfzujAp2Hzn8iU75V8teRTgFn3o4x+BqsueL/mrp8S+1JVMPBu14Cy9HEX3 LyNCMdpSaVp2c5RKw6OIgEGL6dTFZMEkWxtXsUwooVz7jnS7eeThTdZf31DQLlWUmgRq /OAE/WmP8ecGMC/oMMXU9fEyv+YwnFUc4wFxWR9IduEdOvFIcjzjyyGTX/EsLPGmM2+L UH/8Kp0y+HaQ1tsc1lDnVe204RljzbURFwS7akbo/76gPwElAnBAaSfbBymIOMS9HZPc KJYN6YnfB8T6hXNCBkFW4v6pm2DxtsYf/IBupTW2cB/j5QSn8r/OspbLYfDfGBVyjJ8i ybmQ== 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=xofzn/+8cVKAUfS/Md3qLK+eNf9C1GFqSlHuSW0mEMg=; b=OEm9kZ0TCP74EhLKZEzgCqLPtyrtbdqULxPi+Qqf9ajEDzU9mPlrJ5yotB/TD9v65e BBMLk5UsMeUn5deWS2wDc7mz5QInM6e9TW9pGMVY5aDw3SPwZLxxYxTGSgpHqd1gfIvW 1bkM/Wm6KnRYXkhDuSh4OoLAVZfxI0sTgvNwjS8dN5me/ykpgtKNaWSJ+f1frh2COl7t tVmbfVw8U87JpPpSb472AJpAOZUvMOPVS0mTBpYnsb8z0tkvSD/f3UxyE3ogCxXv8nTH YWUMFxtczAs+YIy51+A2Ol6+TsQaEL0OPsDvdSvGojx6hd9cPQ1+8vIdZd31LJPLuw9x T6jQ== X-Gm-Message-State: AGi0PubB7xywx8/furfY6qyfZMgcUYx4oknBts4To3XVcovsIGzdxLy2 Hb18aujUAqltg4hm35OjH1mAnjBuAcW3MbGXAGY= X-Google-Smtp-Source: APiQypI6++VSvb09VzKekcSoaITxFsFicydBEGKxAvHq+z89CBXAkyq5wAnSTnzaWjsC/isSQo7nB2ZxHo0S1jXJSf0= X-Received: by 2002:a67:3284:: with SMTP id y126mr19216385vsy.175.1589342003309; Tue, 12 May 2020 20:53:23 -0700 (PDT) MIME-Version: 1.0 References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> In-Reply-To: From: Nevil Brownlee Date: Wed, 13 May 2020 15:52:56 +1200 Message-ID: To: Eric Rescorla Cc: Mark Nottingham , rfced-future@iab.org, Michael StJohns Content-Type: multipart/alternative; boundary="00000000000088ae6b05a57f8519" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 03:53:26 -0000 --00000000000088ae6b05a57f8519 Content-Type: text/plain; charset="UTF-8" Hi all: I reckon Joel summed up the underlying question here. If the RSE sees problems with a draft sent in for publication, the RSE's response is to negotiate with the stream manager who requested it's publication In the worst case, the RSE can publish such an RFC with a note to say what the RSE-perceived problems were. In short, we already have effective answers to such a hypothetical question. Cheers, Nevil On Wed, May 13, 2020 at 3:32 PM Eric Rescorla wrote: > > > On Tue, May 12, 2020 at 7:42 PM Mark Nottingham wrote: > >> Mike, >> >> > On 13 May 2020, at 6:46 am, Michael StJohns >> wrote: >> > >> > Basically, what you've proposed is a strawman to be knocked down. My >> guess is that any RSE that lets through something that *is* harmful to the >> internet (rather than just thinks it might be) will not have had a long >> tenure to start with. What I think you're asking is similar to the >> problems that editors of wide circulation publishers go through all the >> time - to print or not to print. In their case it might be "do we have >> enough evidence that politician A has actually committed adultery with >> staffer B" or "does printing C put D and E into danger"? The business side >> may say - Lawyers are fine with it and it will make us money, but no editor >> worth their salt will let that be the only decision criteria. >> >> I don't think it's helpful to use such a loose analogy in combination >> with a hypothetical to inform our discussion. It would be much more useful >> if we could focus on whether there's a concrete need to allow the RSE to do >> refuse publication -- for example, if it's intended as a counterbalance to >> the IESG and other stream managers' powers, let's examine that (and >> concurrently look at what counterbalances *that* power). >> >> If we do think that the stream managers need such a check, it's possibly >> a bigger discussion; as has been mentioned, the recall process is intended >> to be act as a limit on the powers of the IESG and IAB. While recalls might >> not be perfect, fixing them indirectly through a function of the RSE >> shouldn't be the first thing we try, and it'd need to be coordinated. >> > > To draw out this hypothetical a bit it might be helpful to try to > understand what the intended semantics would be. > > Specifically, if the IETF were to approve a specification [0] and the RFC > Editor were then to decline to publish it, what would be the status of the > specification under those circumstances [1]? Even if we assume ad arguendo > that the RSE is empowered to refuse publication in order to protect the > integrity of the series, it's hard to understand how that extends to the > power to generally veto IETF decisions. > > -Ekr > > [0] Mike, I did see your questions. We could certainly flesh out the > details of the IESG's decision procedure for the purposes of the hypo, but > I'm not sure it really matters. The IETFs rules are what they are and we > don't generally treat standards that had very rough consensus or small > numbers of IESG Yes ballots as somehow second class. > > [1] Of course as often noted, we're not the protocol police so the > question of normative force is always a little fraught, but consider a > document which has side effects, either because it's a process document or > results in changes by IANA, etc. > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > -- ----------------------------------- Nevil Brownlee, Taupo, NZ --00000000000088ae6b05a57f8519 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all:
I reckon Joel summed up the underly= ing question here.=C2=A0 If the RSE sees problems with a draft sent in for = publication, the RSE's response is to negotiate with the stream manager= who requested it's publication=C2=A0 In the worst case, the RSE can pu= blish such an RFC with a note to say what the RSE-perceived problems were.<= /div>
In short, we already have effective answers to such a hypothetica= l question.
Cheers, Nevil

On Wed, May 13, 2020 at 3:32 P= M Eric Rescorla <ekr@r= tfm.com> wrote:


On Tue, May 12, 2020 at 7:42 P= M Mark Nottingham <mn= ot@mnot.net> wrote:
Mike,

> On 13 May 2020, at 6:46 am, Michael StJohns <msj@nthpermutation.com> wrote:=
>
> Basically, what you've proposed is a strawman to be knocked down.= =C2=A0 =C2=A0My guess is that any RSE that lets through something that *is*= harmful to the internet (rather than just thinks it might be) will not hav= e had a long tenure to start with.=C2=A0 =C2=A0 What I think you're ask= ing is similar to the problems that editors of wide circulation publishers = go through all the time - to print or not to print.=C2=A0 In their case it = might be "do we have enough evidence that politician A has actually co= mmitted adultery with staffer B" or "does printing C put D and E = into danger"?=C2=A0 The business side may say - Lawyers are fine with = it and it will make us money, but no editor worth their salt will let that = be the only decision criteria.

I don't think it's helpful to use such a loose analogy in combinati= on with a hypothetical to inform our discussion. It would be much more usef= ul if we could focus on whether there's a concrete need to allow the RS= E to do refuse publication -- for example, if it's intended as a counte= rbalance to the IESG and other stream managers' powers, let's exami= ne that (and concurrently look at what counterbalances *that* power).

If we do think that the stream managers need such a check, it's possibl= y a bigger discussion; as has been mentioned, the recall process is intende= d to be act as a limit on the powers of the IESG and IAB. While recalls mig= ht not be perfect, fixing them indirectly through a function of the RSE sho= uldn't be the first thing we try, and it'd need to be coordinated.<= br>

To draw out this hypothetical a bit it = might be helpful to try to understand what the intended semantics would be.=

Specifically, if the IETF were to approve a = specification [0] and the RFC Editor were then to decline to publish it, wh= at would be the status of the specification under those circumstances [1]? = Even if we assume ad arguendo that the RSE is empowered to refuse publicati= on in order to protect the integrity of the series, it's hard to unders= tand how that extends to the power to generally veto IETF decisions.

-Ekr

[0] Mike, I did see yo= ur questions. We could certainly flesh out the details of the IESG's de= cision procedure for the purposes of the hypo, but I'm not sure it real= ly matters. The IETFs rules are what they are and we don't generally tr= eat standards that had very rough consensus or small numbers of IESG Yes ba= llots as somehow second class.

[1] Of course as of= ten noted, we're not the protocol police so the question of normative f= orce is always a little fraught, but consider a document which has side eff= ects, either because it's a process document or results in changes by I= ANA, etc.
--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future


--
----------------------= -------------
Nevil Brownlee, Taupo, NZ
--00000000000088ae6b05a57f8519-- From nobody Tue May 12 21:20:11 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF4A3A0D35 for ; Tue, 12 May 2020 21:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=XES8q9wV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YTfDdOh6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtejgGvIhi89 for ; Tue, 12 May 2020 21:20:08 -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 3A33F3A0D33 for ; Tue, 12 May 2020 21:20:08 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 384EA6F7 for ; Wed, 13 May 2020 00:20:06 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 13 May 2020 00:20:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=4CH3+ue94cldazojvoyff9TWTJsuxnR UfmrhTYxFEZk=; b=XES8q9wVWy6R/Qqa3BTMRAU2JigaGotWbK/4WA6RUeDai0A 5jqtAAfyxF5W424Ko+34bXlFendkR0mSZR4T4Ju/JSMZVHyvhEnwSFVejqjVLKZB yhTtAj36kgkc7wC0m7vdyEd1b8w1BnbQ+yh4H3E6R8eKTfEzyHgEK1AgWGr0JQpW 6lgWHXQMexHJnS3YS9ASAMYWPsmCyyYwmBL4KX0x2bOErX350KIlgJRZXWiIkEf0 oj3YFt0wNARgrHPPJ5SmTLNJFvPWmX4JSUiBH1lPqcrEJ9BHUvmz01twrDQzc9DL 3hOrpVGMCPbcD+R4KbaxXnHFS0QAuO+cwracoOQ== 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=fm2; bh=4CH3+u e94cldazojvoyff9TWTJsuxnRUfmrhTYxFEZk=; b=YTfDdOh6OWbGPhuEIFPsaS MkMV10nU9V4kfUxnG3fdCe+U3poZNCCAo6SxrZLWPT/Xz9ru6fGLh06Jo8w56Hwy mA45+aAtq0Fu8hM5TF5Qm/H+9AVZV8KyEQ+aF84dMlOLYcSWl2xcCb02zWj9wfNl x4hMXkgabtkgPBsGWIgUyLDeCYDGwCTFQnMu0gRxFGQRIGiXh/98WxMAIDmINmuK Bhe3W80X57KBpIViOy/q/JcJpEckHH0U/R5/27AIIlajkQ1Lg2zh+BSWhOxEvt8Q xsBTIgpaElOBwGkoEgCrNweLgCYP84eHPQQEJA1RWn07FUNKzPnd4oBCGQ2d03ZQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleefgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhephfeitddtveeihfejjefgve efuedugffgkeevkeehueeggeelveekveektdfhueeinecuffhomhgrihhnpehivghtfhdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7109AE00B0; Wed, 13 May 2020 00:20:05 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> In-Reply-To: References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> Date: Wed, 13 May 2020 14:19:45 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 04:20:10 -0000 On Wed, May 13, 2020, at 13:52, Nevil Brownlee wrote: > I reckon Joel summed up the underlying question here. If the RSE sees > problems with a draft sent in for publication, the RSE's response is to > negotiate with the stream manager who requested it's publication In the > worst case, the RSE can publish such an RFC with a note to say what the > RSE-perceived problems were. > In short, we already have effective answers to such a hypothetical > question. It is clear that reasonable people will find a solution. But the point of the exercise is to extract what we believe the principles are, and from that the extent of authority of each of the actors. https://tools.ietf.org/html/rfc6635#section-4.3 perhaps holds the answer here: The RSE may make final decisions unilaterally only to assure the functioning of the process, and only while there is an evaluation of current policies to determine whether they are appropriately implemented in the decision or need adjustment. In particular, it should be noted that final decisions about the technical content of individual documents are the exclusive responsibility of the stream approvers from which those documents originate, as shown in the illustration in Figure 1. The first sentence constrains the unconstrained authority of the RSE to "the functioning of the process". The second makes it clear that technical content is not under their control. Though I agree that we might collectively benefit from a technically competent RSE flagging something, that's not a benefit that we should count on. What it means to assure functioning of the process is what seems to be in question. I'm going to suggest that "the process" in this context refers to the proper functioning of the subsystem comprised of RSE, RPC, and publisher. That puts the functioning of each of the streams out of scope: if a stream produces crap, and insists on publication, this architecture would seem to require that that crap is ultimately published. There is a big squishy space here where we would hope that reasonable people might do better by working with others constructively, but when it comes to the bright lines needed in cases of dispute, this seems to be that bright line. From nobody Tue May 12 21:38:53 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56F53A0AB4 for ; Tue, 12 May 2020 21:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 o74Cc9Lj17TN for ; Tue, 12 May 2020 21:38:49 -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 EE6103A0A44 for ; Tue, 12 May 2020 21:38:48 -0700 (PDT) Received: from client-0133.vpn.uni-bremen.de (client-0133.vpn.uni-bremen.de [134.102.107.133]) (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 49MMPd45G0zyTQ; Wed, 13 May 2020 06:38:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> Date: Wed, 13 May 2020 06:38:45 +0200 X-Mao-Original-Outgoing-Id: 611037524.961055-a5797695086dd78a16d307d643ceb5c8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> <2b5d1174-f959-6275-78e3-7cf4eaa86601@gmail.com> <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 04:38:52 -0000 On 2020-05-13, at 01:28, Christian Huitema wrote: >=20 > Imagine two parties in a patent lawsuit arguing whether a technology = was covered by RFC XYZT, but arguing from different PDF renderings. = "Page 237 says that bla." "Oh, no, no such text on page 237." Endless = fun. =E2=80=A6 and as a side comment on the brokenness of the discussion that = led us to where we are: Not wanting people to cite RFCs by page number was the putative reason = the .TXT files are not currently paginated, decreasing their usefulness = in many situations. Of course the .PDFs are paginated, so if someone = needs a page number, they can use those. So we destroyed useful = functionality (page numbers in .TXT) because we didn=E2=80=99t want to = have that functionality at all but ignored that we need it anyway in a = different place (.PDF). I don=E2=80=99t want to reopen the discussion here, but just use it as a = data point for my conjecture that the V3 process isn=E2=80=99t done yet. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 13 01: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 173A13A0FB1 for ; Wed, 13 May 2020 01:24:28 -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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzm--oALyovN for ; Wed, 13 May 2020 01:24:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 33A253A0FB0 for ; Wed, 13 May 2020 01:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1589358255; bh=E41G151bBYA3UIfm0xlzB3XbFVO6SJ1eyJ0WT9NxXbI=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=BlYTdHki2zYFXn9s+4Ki087hrUTCLp+UB16DXT+PimDFYQN59HCSVAryBI2rP7u2v K466ea/2cjeTEvFTFryQYfeEDGgoJckMyTdhrkuPZKksO8APTOxl58r4A0ZuDLpbha IGQDx793w3im0FyJOu0Ce3GlI/0MFPFuyktlAA7Q= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.182] ([84.171.147.129]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mi2Nv-1iunAk2ZP7-00e2LK; Wed, 13 May 2020 10:24:15 +0200 To: Carsten Bormann , rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> <2b5d1174-f959-6275-78e3-7cf4eaa86601@gmail.com> <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> From: Julian Reschke Message-ID: <5d6cf37a-25ba-225d-23b2-4f1869ca323c@gmx.de> Date: Wed, 13 May 2020 10:24:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:jXCDAbCB9seJ9aqbWKOUyjL/wglCn6knotXM6mFg0j+OHtEKryx k8Z3oQAveIBLxAwYZxwMBslTtRPm+JB+AWJyAqGuKcy01F3zgIN76n6FsDh5KkjxocutWhF ofJ/g+TuyIouFelUnrbKOSsqhmVeQHf27j6hIc0PjMYbHk/ps3sN52YbjrsjLrGB9TSk2ff pK40he7CTXwtDcgxG1XIA== X-UI-Out-Filterresults: notjunk:1;V03:K0:rZw9DTWkofg=:tbg/R7PMWEfO2uMojl55SU BdkcPEDQ/QXLjv/PDF+LiFuGGMHSZBCCWZhQ4/QjknhzmwjGf3bwXAzR8mQlXoqtmXBLF6+Y3 DA7eclPnGfb+G90HTjy5tUEy8voApLkrQFvEt9hS/LkDhF9WuZPNeb8MuzqXRK/+T8iyHsooc 37wya8cAKiaTqaJ2dIFcPFokU6eypEUq9JcGGwt7Jdz7HnAhfr51uTifgTPXlY8p720zLW7xU JvIxqPJm/Gl5L/5YbCULXFE5CmcbArh8HnZPmiftuVeO6fHGCkRUnvMMVDVeDD7WRNRTt2/jk JdR8GeO0dypN3TzA89hNoZs84tqIFqyhd/sHFbaJRZhRx0D3zSTljWgshboTc2L8kBTBU9TF4 JStWUvRls3auhS/Igj4wYjX2lnAEbZ5ZtcEvKc4U0dAjGZaafGzYISO3yIlEfsZ70EH/UyuCc VVpl2hnBM/oxRl8tiJU0nmwmL6ymBaXLeUws0uEH0HI7ohEYdx2fvujf2gGWtOEVd6pV+3JE2 OC6b6VGZEce4dkmUjGHh6YS1EWqitoW/nCBdVAY6/XLRI3lEDAwua2DPeqCHvUultpD9+9LKO boG/VG1xtvXodjgcT7rC8FBMVVA5gUMRoIcGR8E8YjxesXFj74oPC5OXoOLb1HuTaZ6kxN4Cz Z+wzSsaBWbdRVQx0UaCLpT7l5KryjpU3Q2UFiTEMf9Mia/uidHyzM3gPqurFFB26ra8+s81aU GF4Zi4rrayY5j283oOJXG0Hgt2fwMhW/xzfsJNySI0U2ilLrs+UHNS81WOlWk9eBSO7UYGzbE F/9+CttkfsmzksJ5U1eBfb0pRJQGF2W2oXSr/2cmY3HomRiWBwuR8NfIW6r99dVpaab2ty096 7DWvmo59G0dwHsE+KqCzPUup2GOTFX0IzuPa66cQdp5+v85yuSWnPkcLEui2rLEtHNS+ua1Sd N1fKQ+FL2V/vnkL/YayOF4lrkx41gkkCZTzSUP+o8UlZb+hwG1iiTtV/FDK+SPg0QFny+WT7g 9mYJ/9iZXsQI5fJEc+6i4JoTqVXpZEOve5hdF51fB9MtOIwiiPOzDnjSVYs7HKZddG1FwPDRK 3zWvv76DRGv2nhKnZcrlBVQIRdi7JWLa82TRdS/TrB68ToMyHpf/6YcCRI4AWFEbpNICDcthm LoGyme0E47PsiRACXhCuot69FTg//iiyAugQ7NT8fJfKMG3DLGqhmaTxAqm1utOsNKSx4WiE0 /+4RH/i33NGIlfqAu Archived-At: Subject: Re: [Rfced-future] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 08:24:28 -0000 On 13.05.2020 06:38, Carsten Bormann wrote: > On 2020-05-13, at 01:28, Christian Huitema wrote: >> >> Imagine two parties in a patent lawsuit arguing whether a technology = was covered by RFC XYZT, but arguing from different PDF renderings. "Page = 237 says that bla." "Oh, no, no such text on page 237." Endless fun. > > =E2=80=A6 and as a side comment on the brokenness of the discussion that= led us to where we are: > > Not wanting people to cite RFCs by page number was the putative reason t= he .TXT files are not currently paginated, decreasing their usefulness in = many situations. Of course the .PDFs are paginated, so if someone needs a= page number, they can use those. So we destroyed useful functionality (p= age numbers in .TXT) because we didn=E2=80=99t want to have that functiona= lity at all but ignored that we need it anyway in a different place (.PDF)= . > > I don=E2=80=99t want to reopen the discussion here, but just use it as a= data point for my conjecture that the V3 process isn=E2=80=99t done yet. So what would be your proposal here? Have page numbers in plain TXT, and require them to be in sync with the PDF rendering? Best regards, Julian From nobody Wed May 13 01:44:55 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2253A0FD3 for ; Wed, 13 May 2020 01:44: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 Hk6GiO78RMPz for ; Wed, 13 May 2020 01:44:51 -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 12C233A0FCF for ; Wed, 13 May 2020 01:44:51 -0700 (PDT) Received: from client-pool2-203.vpn.uni-bremen.de (client-pool2-203.vpn.uni-bremen.de [134.102.48.203]) (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 49MSsX4kpqzyRg; Wed, 13 May 2020 10:44:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <5d6cf37a-25ba-225d-23b2-4f1869ca323c@gmx.de> Date: Wed, 13 May 2020 10:44:48 +0200 Cc: rfced-future@iab.org X-Mao-Original-Outgoing-Id: 611052287.586758-4135d0af577f29d936de14a5ef9fdf8a Content-Transfer-Encoding: quoted-printable Message-Id: References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <25F32505CBC1C1AF2841AF9A@PSB> <03DB041F-5B4D-4209-8A5F-DF61D4EFE218@mnot.net> <41479198-256c-1823-5244-ddcc3a6f7bac@gmail.com> <2b5d1174-f959-6275-78e3-7cf4eaa86601@gmail.com> <2409aa18-91b2-e184-e203-674c551ec626@huitema.net> <5d6cf37a-25ba-225d-23b2-4f1869ca323c@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Canonical vs Archival [I-D Action: draft-carpenter-rfc-principles-00.txt] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 08:44:54 -0000 Well, I said: >=20 >> I don=E2=80=99t want to reopen the discussion here, > So what would be your proposal here? Have page numbers in plain TXT, = and > require them to be in sync with the PDF rendering? We can discuss this over in RFC-Interest. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 13 13:38:53 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 316723A0924; Wed, 13 May 2020 13:38:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158940233012.14837.187634510503982715@ietfa.amsl.com> Date: Wed, 13 May 2020 13:38:50 -0700 Archived-At: Subject: [Rfced-future] RFC Editor Future Development Program (rfcefdp) WG Virtual Meeting: 2020-05-14 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 20:38:50 -0000 The RFC Editor Future Development Program (rfcefdp) will hold a virtual interim meeting on 2020-05-14 from 21:00 to 22:30 UTC. Agenda: What do we want from the series? What roles are defined and what is their relationship to one another? Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m6e894a38b5cf6c139af7eca0891907ca From nobody Wed May 13 13:49:01 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 09A4E3A0914; Wed, 13 May 2020 13:48:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158940293893.32529.11922749815121661246@ietfa.amsl.com> Date: Wed, 13 May 2020 13:48:58 -0700 Archived-At: Subject: [Rfced-future] RFC Editor Future Development Program (rfcefdp) WG Virtual Meeting: 2020-05-27 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 20:48:59 -0000 The RFC Editor Future Development Program (rfcefdp) will hold a virtual interim meeting on 2020-05-27 from 06:00 to 07:30 UTC. Agenda: We will continue a roundtable exchange of people’s views on the future of the RFC Series Editor. We will further develop the agenda there. All are invited to participate, and to join the list, which can be found at https://www.iab.org/mailman/listinfo/rfced-future. The meeting will be recorded. Current information on the program can be found at https://github.com/intarchboard/rfced-future. Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m1dd4253db4bdf3a30ef9f3aabc64ac75 From nobody Wed May 13 15:36: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 2036B3A0366 for ; Wed, 13 May 2020 15:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5054scvFfZO for ; Wed, 13 May 2020 15:36:38 -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 626B93A03EA for ; Wed, 13 May 2020 15:36:38 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id x13so366958pfn.11 for ; Wed, 13 May 2020 15:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fqxkp6pssrFtDa6Qgm/drT5Y0IurO/KQQ0RfTL2zjoQ=; b=XaQXtt1GMpcUcksXUxbjjF/MCPn1IYJob3CyYit8o1y+wPGvDE32css8zE5D4BXUD5 5Z4HBwgnX11Nxau40MqZ/MYPedjmd2UGYQcvOfPLTRIl6tV1y1pdGP81eFMymPO37Lx1 cnC0SAGYn4VnRRuIPpMlimvzNiIl5qdEFMzhYp9bwAIKXrOB3yQWA5kkEw9NQSExwLMS t3cUQmIXvvwM/L7ClSrah1h+GOdKdrpvs+LasZ5MPhMH0Tost+38+/Aq9MieE9NBevj4 9YM53JgieYE2J8ohQNlRWt1baidURW+6CSl90eduHgXZYq08UYVhospjOy/B4kqDnGip feYw== 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=fqxkp6pssrFtDa6Qgm/drT5Y0IurO/KQQ0RfTL2zjoQ=; b=QIBTKPQpk2y4bxmtCPyO3EwrNgzefjv19uJQ9fARPL1zay6HWFm7aWVtfFWu+iQdd0 a95/OIllTKeaajiCMETEGnKyRxDP2sX4uCr6jKrbw1I92Z98Z3Y4jHY3Bpwxvfsilzy1 NN+koohHviv8ZRznaEY+ZgzYnS4lKSud9UU/jLIw7fNtyQ7Gj6h/a4xDMiCKvkbBIhWM nLoNHRmPlKRNM0/7ME5vZ5kY62MBblhledAF6qEbuK2k+K20y0XFj/dHHT+v75jtUBln TDtuYDWf43O5R5xvIZyaP52S+BTLGcz3+IK9hBj7SlI5iKr+RkxtAfcsE92u919Lkl76 Ab3w== X-Gm-Message-State: AOAM532nT6WppCitVvVTd1zNe1j22N+TkylkPDcFf86H/R5P8e7Tud0F NpIQplg5yGrVNF9VD42LwsxvHXE1 X-Google-Smtp-Source: ABdhPJwQ6/r0AqFDh+OzxEHQ1WJBMjqoapPTMy1qVm5QjQgGP+E2O2YCFDl280NHkAcU4ozltVHeYA== X-Received: by 2002:a63:e547:: with SMTP id z7mr1324603pgj.177.1589409397369; Wed, 13 May 2020 15:36:37 -0700 (PDT) Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id f29sm606550pgf.63.2020.05.13.15.36.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2020 15:36:36 -0700 (PDT) To: Martin Thomson , rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> From: Brian E Carpenter Message-ID: <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> Date: Thu, 14 May 2020 10:36:32 +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: <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 22:36:40 -0000 Hi Martin, > if a stream produces crap, and insists on publication, this architecture would seem to require that that crap is ultimately published. Yes, that is the principle applied to the Independent Stream so it should probably be generalised. For the Independent Stream, the IESG has the right to insert a disclaimer; we would probably need to allow the RSE to insert a disclaimer in a similar way (and of course only in extreme circumstances). Regards Brian On 13-May-20 16:19, Martin Thomson wrote: > On Wed, May 13, 2020, at 13:52, Nevil Brownlee wrote: >> I reckon Joel summed up the underlying question here. If the RSE sees >> problems with a draft sent in for publication, the RSE's response is to >> negotiate with the stream manager who requested it's publication In the >> worst case, the RSE can publish such an RFC with a note to say what the >> RSE-perceived problems were. >> In short, we already have effective answers to such a hypothetical >> question. > > It is clear that reasonable people will find a solution. But the point of the exercise is to extract what we believe the principles are, and from that the extent of authority of each of the actors. > > https://tools.ietf.org/html/rfc6635#section-4.3 perhaps holds the answer here: > > The RSE may make final decisions unilaterally only to assure the > functioning of the process, and only while there is an evaluation of > current policies to determine whether they are appropriately > implemented in the decision or need adjustment. In particular, it > should be noted that final decisions about the technical content of > individual documents are the exclusive responsibility of the stream > approvers from which those documents originate, as shown in the > illustration in Figure 1. > > The first sentence constrains the unconstrained authority of the RSE to "the functioning of the process". The second makes it clear that technical content is not under their control. Though I agree that we might collectively benefit from a technically competent RSE flagging something, that's not a benefit that we should count on. > > What it means to assure functioning of the process is what seems to be in question. I'm going to suggest that "the process" in this context refers to the proper functioning of the subsystem comprised of RSE, RPC, and publisher. That puts the functioning of each of the streams out of scope: if a stream produces crap, and insists on publication, this architecture would seem to require that that crap is ultimately published. > > There is a big squishy space here where we would hope that reasonable people might do better by working with others constructively, but when it comes to the bright lines needed in cases of dispute, this seems to be that bright line. > From nobody Wed May 13 15:55: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 979F23A05A0 for ; Wed, 13 May 2020 15:55:48 -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, 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 UAmuIZPPuLCF for ; Wed, 13 May 2020 15:55:47 -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 417F83A0598 for ; Wed, 13 May 2020 15:55:47 -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.15.2/8.15.2) with ESMTPSA id 04DMthcI064672 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 13 May 2020 17:55:45 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589410545; bh=PuClNeNKOzToPJ2/htxxlHoRYyHCP+7cnvzUlkjnAQY=; h=Subject:To:References:From:Date:In-Reply-To; b=LLrVXEpWvLSvDD37uEA0dWiASGogE/Zq86KM0xY/dDan8BNUbo0DZ356LnbLtc5wx folb1YyqI4NbZs98NGwzGn4AoA5b1mwZPDiq/PT90xGdKYB+Bnwfngt4RYG0pnauz+ E+mMAvPivqPm7lZyRUCO306PpQLhhY8MuJuMzqUs= 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: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> From: Adam Roach Message-ID: <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> Date: Wed, 13 May 2020 17:55:37 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 22:55:49 -0000 On 5/13/2020 5:36 PM, Brian E Carpenter wrote: > we would probably need to allow the RSE to insert a disclaimer in a similar way I'd be curious to hear other people weigh in on whether this matches their expectations. I feel far less strongly about it than I do the broader issue of veto power, but it seems that adding new material wholly fabricated by the RSE (such as a disclaimer) is a bit beyond the remit that the community might reasonably expect. /a From nobody Wed May 13 16:02: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 C21633A0736 for ; Wed, 13 May 2020 16:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=1ZtLGV5a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Kyqvgzot Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXtRZykGQGHV for ; Wed, 13 May 2020 16:02:39 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F983A0764 for ; Wed, 13 May 2020 16:02:38 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id EFB5E5C013B; Wed, 13 May 2020 19:02:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 13 May 2020 19:02:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=E D2T85eEYnJ7pzCZCJY0kBF31jHv/bo6Ob/YFbk4ldk=; b=1ZtLGV5abN2l8cBmd +o/yhfRlOHkcpe6p1hmiPVZkb4e4R7K0iDBrdApLXYQr8R00I8tKIUIQtSBmET4U t0wQ74oL8YhPDRBMmZcSaRnZooAKqpIoRkEx6QC6Ew6UkK2W5U0IU8IqTgArzy0G iBBKpCahL/fvUPqNzoec8leQy4jg9g80e7aMI+ND/lJiAMpAksoka/UbrCdquumY JEQKZmuqCJGsuVuGrHABi/3W3W8SaaC/4YguZFRj2nf8zUA2Ko1q584n/rO0je/k 2jBSO3B+gfpJzhKTbxrlF77n3PlRipeMvsAVF4jA307J+23OvncFxI7d3+UpAfDK DgSPQ== 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=fm2; bh=ED2T85eEYnJ7pzCZCJY0kBF31jHv/bo6Ob/YFbk4l dk=; b=Kyqvgzot7+NHLbpW6+w+0d38YSEn2PNYRwKP6f/zsSJE0x2fEJawjyAFJ peyqVvZM6dM5FNAQ+wGgff1vdDH0sLzZmwHfXd5xgpwJM1WUzQzOYJhx1nEqlYXu YvcDESm7SBzBKjPGy/F/CcvatWKfC9OgXtRIHEe2zpJapVzlwZSucXzSBRgkd4Po X2/eNzI+Vgs2wqYeLtlLiOdUMMMSbGWT89LwcUqFjgR88atr20xOEZSXx74izsry HvH3TgX5KMAestRTJOqGgByc1Eu0MghCZ0GaxYnteIe1RO0VQ2WSB9uvkEZ5Hxqt YzlSseqqEqh1w0qH8V7Trs9MdsbFw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleehgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhe dunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 272A73066320; Wed, 13 May 2020 19:02:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> Date: Thu, 14 May 2020 09:02:29 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 23:02:41 -0000 > On 14 May 2020, at 8:55 am, Adam Roach wrote: >=20 > On 5/13/2020 5:36 PM, Brian E Carpenter wrote: >> we would probably need to allow the RSE to insert a disclaimer in a = similar way >=20 > I'd be curious to hear other people weigh in on whether this matches = their expectations. I feel far less strongly about it than I do the = broader issue of veto power, but it seems that adding new material = wholly fabricated by the RSE (such as a disclaimer) is a bit beyond the = remit that the community might reasonably expect. I personally don't think it's necessary, and would find it surprising = and somewhat unwelcome if it happened tomorrow - mostly because I = wouldn't be entirely sure if there were *other* people who could weigh = in if they so chose.=20 If we want to explicitly give the RSE this power, we should write it = down and canvass it with the community*. Cheers, * Yes, yes. -- Mark Nottingham https://www.mnot.net/ From nobody Wed May 13 16: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 768333A077E for ; Wed, 13 May 2020 16:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ2sYoVZtB51 for ; Wed, 13 May 2020 16:08:49 -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 5186D3A0779 for ; Wed, 13 May 2020 16:08:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 51470BE20; Thu, 14 May 2020 00:08:47 +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 9VoLS6cJ7YvS; Thu, 14 May 2020 00:08:44 +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 E80B5BDCF; Thu, 14 May 2020 00:08:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1589411324; bh=NaxHKSpDR0VBV46egWZ4PH+14z64bax8sZ4TNXurk/M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qmoddtRsmY/BZq1UaNzgNIb93IL4rZf2JuhkAbZfhYJHe+anfsiK3RC5/sIKTr+3T +kplQzoT/9DCRMXY0nCVcJGtYRBeisQ516oVd94T6rEj7Ts2j6SCGiy6fKJKg5hUQ6 SPGpF5AAVIa6G5rRTi9985x/4WyWEamJMaIx7wBs= To: Mark Nottingham , Adam Roach Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> 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: Thu, 14 May 2020 00:08:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ohhkdxshg5c53Y2ix8lkv48VEMbGQsCrf" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 23:08:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ohhkdxshg5c53Y2ix8lkv48VEMbGQsCrf Content-Type: multipart/mixed; boundary="goocnir132J23crlTQVzFetlAemECRlG5"; protected-headers="v1" From: Stephen Farrell To: Mark Nottingham , Adam Roach Cc: rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> In-Reply-To: <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> --goocnir132J23crlTQVzFetlAemECRlG5 Content-Type: multipart/mixed; boundary="------------8A354047BE8F230855ED1A42" Content-Language: en-US This is a multi-part message in MIME format. --------------8A354047BE8F230855ED1A42 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/05/2020 00:02, Mark Nottingham wrote: >=20 >> On 14 May 2020, at 8:55 am, Adam Roach wrote: >>=20 >> On 5/13/2020 5:36 PM, Brian E Carpenter wrote: >>> we would probably need to allow the RSE to insert a disclaimer in >>> a similar way >>=20 >> I'd be curious to hear other people weigh in on whether this >> matches their expectations. I feel far less strongly about it than >> I do the broader issue of veto power, but it seems that adding new >> material wholly fabricated by the RSE (such as a disclaimer) is a >> bit beyond the remit that the community might reasonably expect. >=20 > I personally don't think it's necessary, and would find it surprising > and somewhat unwelcome if it happened tomorrow - mostly because I > wouldn't be entirely sure if there were *other* people who could > weigh in if they so chose. >=20 > If we want to explicitly give the RSE this power, we should write it > down and canvass it with the community*. +1, I think I'd prefer RSE push-back, if needed in extremis, to use other methods, such as mail to ietf@ietf complaining and explaining. Then let the community there deal with the putative crap IETF stream document. Something similar should also be ok for other streams. S. >=20 > Cheers, >=20 > * Yes, yes. >=20 >=20 > -- Mark Nottingham https://www.mnot.net/ >=20 --------------8A354047BE8F230855ED1A42 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----- --------------8A354047BE8F230855ED1A42-- --goocnir132J23crlTQVzFetlAemECRlG5-- --ohhkdxshg5c53Y2ix8lkv48VEMbGQsCrf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl68ffsACgkQWrL68XsX K+oGTg/7Bv5k5mg5+EQlHKw+eDqZpHBTpxS4W1i8TbcOpyGn0DibD0IglcDNlxNn bh718oAZE/I+TkfX/PQPljHiza3u/msiKXHfPNLQtY/9vd0MWqd1fC+TpuCWp1nO t8ut+pMlD8ZMgfUeThP+74Mig/LEPeDh+Du9R8oIHeUJYalsPL6OaK1z1dgPR58i Pa8go9pL0LrlBrIqz8iojJTJ/oZpVbyEKv0s3JsKOijxBVyRis2fNr63dK87bw4l zkS8TOadB/mWUdeBdAT91tXUEP2WWRizSOW22X1ZculKuijfvs7iGatx82t0+7/i 1y+A/iPPQ08FoNLb84gOqY/WxMJlid5AImqWz5PRRuqG3oc4N8Xx0dSCijobKALb 8Vps0ZLV1I/IS/kmz4zuDtaXpnIy2+vgro9U4B/GNdF5bwGIReQhCdXEedY6Np5N TDMIUjwRDoPC4Ge+DbZuDXTsO8+Ha2YQCQbsZcpWWOBIWpbu5qgrYJQPcNYfOIQ9 8+v5opglOUifvDERYlFH0PJIG1gO4NUghEERotFV4amvObf3GiYo6fNHR2uXjl4d CSeUKYFFoLMNeGie2nag9F9n1Un+OStX1j0ZGWqaO33cyn33FB4UJQxSibnqpw2I 8on/vGfUUtwtYC2Os6+CBI9p5LZ+pSiqvxCCmL/i1iOSCnr86us= =yxXi -----END PGP SIGNATURE----- --ohhkdxshg5c53Y2ix8lkv48VEMbGQsCrf-- From nobody Wed May 13 16:22: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 0E1933A0786 for ; Wed, 13 May 2020 16:22:10 -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, MIME_QP_LONG_LINE=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 xn9XvTkN3EZ2 for ; Wed, 13 May 2020 16:22:07 -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 9CEF53A077E for ; Wed, 13 May 2020 16:22:07 -0700 (PDT) Received: from [10.10.8.53] (mobile-166-177-123-155.mycingular.net [166.177.123.155]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 04DNM5hC069979 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 May 2020 18:22:06 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589412126; bh=Teu70+lb0oLeqx+BZOb0ZOZ4X7IrX4VRAleh+nLcrBI=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=qkVMqsqu9LqRb8JCInUvhdRgd1FlRcMfQhcA4mih3kyMbBovEZJlfu65Oi3Qwn1u1 5WypkDAe7C7TGolko9Z3Kwd4euIuupVUSXokm3MO6pCw0MsP73iF16uEYjNgS2DMat ZILxsThuU2/QCe4HeTg/sqqxdLaGKzG9BxRCgRl8= X-Authentication-Warning: raven.nostrum.com: Host mobile-166-177-123-155.mycingular.net [166.177.123.155] claimed to be [10.10.8.53] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ben Campbell Mime-Version: 1.0 (1.0) Date: Wed, 13 May 2020 18:21:59 -0500 Message-Id: <60BABE76-B2BA-49CB-B2E7-BBF14D8CF2D5@nostrum.com> References: <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> Cc: rfced-future@iab.org In-Reply-To: <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> To: Adam Roach X-Mailer: iPad Mail (17E262) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 23:22:10 -0000 > On May 13, 2020, at 5:55 PM, Adam Roach wrote: >=20 > =EF=BB=BFOn 5/13/2020 5:36 PM, Brian E Carpenter wrote: >> we would probably need to allow the RSE to insert a disclaimer in a simil= ar way >=20 >=20 > I'd be curious to hear other people weigh in on whether this matches their= expectations. I feel far less strongly about it than I do the broader issue= of veto power, but it seems that adding new material wholly fabricated by t= he RSE (such as a disclaimer) is a bit beyond the remit that the community m= ight reasonably expect. I agree with Adam here. Circling back to the =E2=80=9Ctechnical=E2=80=9D vs =E2= =80=9Ceditorial=E2=80=9D grounds, I would not expect the RSE to add a discla= imer to an IETF-stream RFC on technical grounds. While less severe than a ve= to, it would still involve an RSE attempting to override consensus.=20 And I can=E2=80=99t imagine a disclaimer on editorial grounds being very use= ful for any purpose other than perhaps washing their hands of responsibility= for a poorly written document. Ben. >=20 > /a >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed May 13 16:23:58 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A223A07AC for ; Wed, 13 May 2020 16:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOgSeaNQ_EXS for ; Wed, 13 May 2020 16:23:55 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321713A07B5 for ; Wed, 13 May 2020 16:23:55 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id 145so412565pfw.13 for ; Wed, 13 May 2020 16:23: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=kgekAb1o02uk1S4jiq2g43L51KH+VUQEuTh8ApHk4CI=; b=BZPqsVxcxI+CqSAzZjV9E802R6d7hXLjXYP5ZqtBCPNb12F1ZLT8U9WfgRNMwzC/z3 079Aar3HfYd52yOO+EGZUeTbj9kqb6u0QXPKEe7kKF12uuPJWxWdKs3dY3qkOIwxJYxC AArf9X5sZgjpTqZiGVvOzRiImVH5Av3s4m40T2FyBYwnPwDMSvPClb0+tAMjCEPvNGRo NnZi/uA8grQRilFy/qf1HFNmksl6oUuLHrPjKZLtTtZrENKLWqaVvu69N5tbZuhx39QA qxypSYCKxPU1Cl/gP8ZXct3nRlCIQsOhpKuSz3itVcZlhHQWX8bF3F5gpKH49vxMv13M ot9w== 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=kgekAb1o02uk1S4jiq2g43L51KH+VUQEuTh8ApHk4CI=; b=K12uVt0sOnSytr0AmHN0JkNXgB9odyjKEgmVBmynQ25snGksWTcinvH7H7nskTAxci cAkrmFba2Bd8ruKbqVk4k/Qhv1UxHPLrRUCPGLnCEnbAq1pi/XSMUBLuPhj/BOni2ckt 0nawP4cBxchjRnyahUlwEWrII1/a3FAnnEWJjWsrknjo21r34U0Y1yiQFXtSKcHP9uwJ jVNL8AtUTImFrmgMJR9bT696rIg9DCZtirU4iaRK6g/3JIhtax7f1hGUJoFyVZJoVsGW IlHr3X+eZPkjyhuhqHZR0m3B+B9wbh7dqkZ3vWORCfj9DiElO3R+i4JvkBoTCx8fKDLa CmAA== X-Gm-Message-State: AOAM53240E3HfRwxI3PA9D2Z4bHq/LjEJtC259MgSky57RZ2klNi9iB+ 5Tlt5SoLNFIWqPPLCYnHnr/Be9cY X-Google-Smtp-Source: ABdhPJwY4gCZWAEevM8/7pWCgMDKxkttC0PZlgKlshFos1xmtZ20earze8HEBEacn3wX+Hw7LqM3Bg== X-Received: by 2002:a63:4911:: with SMTP id w17mr1524185pga.13.1589412234234; Wed, 13 May 2020 16:23:54 -0700 (PDT) Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id 63sm48888pfy.14.2020.05.13.16.23.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2020 16:23:53 -0700 (PDT) To: Stephen Farrell , Mark Nottingham , Adam Roach Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> From: Brian E Carpenter Message-ID: <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> Date: Thu, 14 May 2020 11:23:49 +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] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 23:23:57 -0000 On 14-May-20 11:08, Stephen Farrell wrote: > > > On 14/05/2020 00:02, Mark Nottingham wrote: >> >>> On 14 May 2020, at 8:55 am, Adam Roach wrote: >>> >>> On 5/13/2020 5:36 PM, Brian E Carpenter wrote: >>>> we would probably need to allow the RSE to insert a disclaimer in >>>> a similar way >>> >>> I'd be curious to hear other people weigh in on whether this >>> matches their expectations. I feel far less strongly about it than >>> I do the broader issue of veto power, but it seems that adding new >>> material wholly fabricated by the RSE (such as a disclaimer) is a >>> bit beyond the remit that the community might reasonably expect. >> >> I personally don't think it's necessary, and would find it surprising >> and somewhat unwelcome if it happened tomorrow - mostly because I >> wouldn't be entirely sure if there were *other* people who could >> weigh in if they so chose. >> >> If we want to explicitly give the RSE this power, we should write it >> down and canvass it with the community*. > > +1, I think I'd prefer RSE push-back, if needed in > extremis, to use other methods, such as mail to > ietf@ietf complaining and explaining. Then let the > community there deal with the putative crap IETF > stream document. Something similar should also be > ok for other streams. Certainly we're talking about a very low probability event, comparable to a legislature stating that pi == 3. But would you prefer that the RSE's only option in that case is to resign? Brian > S. > > >> >> Cheers, >> >> * Yes, yes. >> >> >> -- Mark Nottingham https://www.mnot.net/ >> >> From nobody Wed May 13 16:31: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 365883A07CE for ; Wed, 13 May 2020 16:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEB9DBDWHtNv for ; Wed, 13 May 2020 16:31:52 -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 A05E83A07C8 for ; Wed, 13 May 2020 16:31:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6A1B4BE20; Thu, 14 May 2020 00:31:44 +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 noVrGhIHUtxl; Thu, 14 May 2020 00:31:35 +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 C9883BDCF; Thu, 14 May 2020 00:31:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1589412695; bh=8Pv2QDpTJkrQCriqRPMz6H5A3fVK6rSvllY2OY8kZdE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=H1r/meTXChzuO+5URjiz31vuFxEa1ASmu1Gkjq4vu8P2YaKKXhxBpMPvaUqw9VWtN F8ztBVdKd5D9afVYor1TBey2SYsfmP1ZTjjX46L2qQZT5gBDZb8nR+F6OsrJMfEE62 twB1AzNPiqaZSmAY9z6sO7IyZ63mltg7u1NwIzsQ= To: Brian E Carpenter , Mark Nottingham , Adam Roach Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.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: <46b9e60e-79dc-09d9-fc6a-1c8195c29c88@cs.tcd.ie> Date: Thu, 14 May 2020 00:31:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RHkJsRx3Ila8npKHKqJnzlbEifoEcPxOf" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 23:31:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RHkJsRx3Ila8npKHKqJnzlbEifoEcPxOf Content-Type: multipart/mixed; boundary="iEdOZGfOOittJiRaIZ6gKt4OmosSyTTi1"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter , Mark Nottingham , Adam Roach Cc: rfced-future@iab.org Message-ID: <46b9e60e-79dc-09d9-fc6a-1c8195c29c88@cs.tcd.ie> Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> In-Reply-To: <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> --iEdOZGfOOittJiRaIZ6gKt4OmosSyTTi1 Content-Type: multipart/mixed; boundary="------------9970973E2AC42B1FC9EF6BD0" Content-Language: en-US This is a multi-part message in MIME format. --------------9970973E2AC42B1FC9EF6BD0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/05/2020 00:23, Brian E Carpenter wrote: > Certainly we're talking about a very low probability event, comparable > to a legislature stating that pi =3D=3D 3. But would you prefer that th= e > RSE's only option in that case is to resign? Not sure one always has to die on the hill tbh. Sure, if it happened a few times or went badly wrong, that might be the outcome. But overall, yes, I think the IETF community ought win in a case like that. In practice, I'd expect that if the RSE were right in causing a fuss, then there'd more likely be consequences for an AD or WG chair or something. Cheers, S. --------------9970973E2AC42B1FC9EF6BD0 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----- --------------9970973E2AC42B1FC9EF6BD0-- --iEdOZGfOOittJiRaIZ6gKt4OmosSyTTi1-- --RHkJsRx3Ila8npKHKqJnzlbEifoEcPxOf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl68g1MACgkQWrL68XsX K+rxsg/9FctohJTMehEJ1EaqQHiRKQ4w49jUUMRctBS68n7wma+Dukzjrw2cClLw pSqtSBIf1ay5HrHzK4D1Sm5JPOszfSxcM5bhQ6BuuNwxBB6oTt6gdQiOT/R7d+F1 pIqdo8OxBidbLc4Ep56b0EYoUP9hOecmNi1U5ErdQ/riPCPLzp+FhxhWZaYtl/tD Wtguhp5D5r9PXZk+6O3MRWWxrJ5N1pNvnVl4KI7Faf+w98wrI6Nm0B1bNkM5MPhG ec/eiNd4kb2hT724q5etSULOdSy2igPpocxz+WHrS6nzHc/grmdmBOqqoyJX+u1l vK+hfk/qlg9AM6coWDKp7wxhgCLI9mZM3NGxM1QRKyoBpYef+UGowcHpT5Id2Ojk T/uLhWI72nhLosYoLSu7Q0HE+ltJd/o8hjoiSlg7jb3qDtv23FKZuzfnt1zZRqJt cRLPbgUTflJc2Db2EUWH6+80+xDr/OXnFsG3PTqSXAORs95D0pHxYPrsXn+GOeNJ wAqd7MDkjqWvQ4vZZXU+Xap/t4QDa/LsQvB+XbkD/WjdjBbRDUHEAN9rqrsiqP3D CjOfBYPbEI2PQ5HELnPxz3TfWV8zZMQTZZhwN42PyK674jwa//uGykeI2k40eb9a NRPjaWyaXzjXQI5oYlrrRZGn1JEZnjICTsd4oegxRy/++IN5bW4= =26Q7 -----END PGP SIGNATURE----- --RHkJsRx3Ila8npKHKqJnzlbEifoEcPxOf-- From nobody Wed May 13 16:42: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 30E0C3A07F4 for ; Wed, 13 May 2020 16:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, 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 gH1MoI2o_i7F for ; Wed, 13 May 2020 16:42: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 2D0423A07F0 for ; Wed, 13 May 2020 16:42: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.15.2/8.15.2) with ESMTPSA id 04DNgKSF074279 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 May 2020 18:42:22 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589413342; bh=WQFRYjd3YfdRN4Ncfzxi1wOtW0imuhA1g7Flshy3GoQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=QGza5lVolCn31fBNdakhcU0vel7szx1BGfMY2UYS+p81qldqrHjwdzXpHNo76HK/2 pXMg1iMsscZA+Ob2otflFh1I5c1Hk1v96dcbKrK5DckHuKwqjiKRRfy5j9hhVl7Vi1 cfIBgRZthNTEgP8s+Td3JP8jkt1IwttcuQfTekpY= 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 , Stephen Farrell , Mark Nottingham Cc: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> From: Adam Roach Message-ID: Date: Wed, 13 May 2020 18:42:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 23:42:32 -0000 On 5/13/2020 6:23 PM, Brian E Carpenter wrote: > On 14-May-20 11:08, Stephen Farrell wrote: >> >> +1, I think I'd prefer RSE push-back, if needed in >> extremis, to use other methods, such as mail to >> ietf@ietf complaining and explaining. Then let the >> community there deal with the putative crap IETF >> stream document. Something similar should also be >> ok for other streams. > Certainly we're talking about a very low probability event, comparable > to a legislature stating that pi == 3. But would you prefer that the > RSE's only option in that case is to resign? [Insert "Well that escalated quickly" meme here] What I understand this conversation to be trying to do is feeling out the scope of responsibility of the various parties in the ecosystem. My mental model has always been that stream managers are responsible for the technical content of documents [1], while the RFC Editor is responsible for the editorial quality of them. Regardless of how unlikely the situation you envision is to arise, I think the broader point is that the output of this effort needs to make it very clear whether the RSE is responsible for the technical contents of a document; and I beleive the answer needs to unambiguously be "yes" or "no." /a ____ [1] Not unilaterally, of course. They answer to the community they serve, and are subject to the rules that apply to their stream, but I think those constraints are both well-understood and out of scope of this effort. From nobody Wed May 13 16:43: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 122633A07F7 for ; Wed, 13 May 2020 16:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMD-gup5TQB5 for ; Wed, 13 May 2020 16:43:46 -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 2FFBE3A07F6 for ; Wed, 13 May 2020 16:43:45 -0700 (PDT) Received: (qmail 68218 invoked from network); 13 May 2020 23:43:44 -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=10a78.5ebc8630.k2005; bh=ic0SSh1oeFa2ZJDyMzAqhcoOoAKpOLUPPla5Oqz4Gno=; b=xdc8O7jFb093TCd3JHte5OZ5BFt/JHunfGNTwV+Hrd3TGTQQnetJT1D42GZK9mMNLQN6ojS2cjk3TW+9mQW5fw+FboX/Bjsf4A9sS087eQZO9nxUfC2vzrC6yqcA4TLOXM6PUq7qiGecs9FSsb5BWl6POLuISl/+kAwIvCx3b8u0hlyh/R6B3n6A+JonFUeqLD9KTp6fsyM4u8A0qRkMzPNphsZFtL9Cx8V5+51vsjJqsMiyRsptMGDL0xADJUpH Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 13 May 2020 23:43:44 -0000 Received: by ary.qy (Postfix, from userid 501) id 15C25194E347; Wed, 13 May 2020 19:43:43 -0400 (EDT) Date: 13 May 2020 19:43:43 -0400 Message-Id: <20200513234344.15C25194E347@ary.qy> From: "John Levine" To: rfced-future@iab.org In-Reply-To: <56e855da-6886-b0d4-2264-11123da1f2b8@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] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 23:43:48 -0000 In article <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> you write: >Certainly we're talking about a very low probability event, comparable >to a legislature stating that pi == 3. But would you prefer that the >RSE's only option in that case is to resign? Actually, yes. If the various stream managers are at such an impasse that they can't figure out how to advance or abandon a document, I think it's fine for things to blow up. R's, John From nobody Wed May 13 16:44: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 63D143A07F8 for ; Wed, 13 May 2020 16:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=BUi348xa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S2F39yG0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BZTmuxaVFI8 for ; Wed, 13 May 2020 16:44:17 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800FA3A07F4 for ; Wed, 13 May 2020 16:44:17 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8C60F5C0192; Wed, 13 May 2020 19:44:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 13 May 2020 19:44:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=W Y7/c3NSIaW7FADpsa7tWje0IM1n09uBpK9tzMtgvWY=; b=BUi348xagHAuz3YvP CXg37rqr8iXiB8SpHuVlSuWCONP+8fNQ92Rzk/X3Ek8XJcvlhjq9RA7JC8ziFDCK 8rflSuDMWBBx+t+Fh57jCdHXsvomrHgEAij6eAMrqyZKBKGMLJORuTpFmYT9nKlv s6azD/1C2LJFCnjGxWcrzitxTEqCKMorbun4aInQeOV/0uJFMd8HgGbJ095M0i6D YNUQV1q/Mw3sl7M9pelLWypIs+JAmpMLmkAHNvZO9wZNkzjFnx40bgVjl+KEDCua WVWzrTQk8chG59oDL5/KwlkMuFffNVCH6tf8qOjhq+bbDRnnuabFa266J2ud32VY Agqlg== 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=fm2; bh=WY7/c3NSIaW7FADpsa7tWje0IM1n09uBpK9tzMtgv WY=; b=S2F39yG0Kwr7FsblBX4vijB8XzU+MyuR6rIY9/W2FgAeXE7adyWMIQXOS 53vJPMpCBJqUAIt9rIs3De/UyL5Q0EvfwIMEcvt4OK7WfMeiOXBMf+8gub7NYiO1 qcZkhRkz5mpbWH64tOVcgy3NSnaAXxUPOSa8ETIL1eZ/g1iQMfkjaKHtggS8hy/K Rs8zE0CiDAI6G+GROj3jXzriNLuSUxaoErX+L6ObuN2DY7OdrpML9a8HyETnFFKg mwhALmAFOYuuJrF/H1fkQV5+s0JWnKAgN0BeyMvraFSAolRpGXF/nI76Wg1Uj71d 4qeLG3dvz01c06trpC2kQZDaU4p5A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleehgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhe dunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 1C6F73280060; Wed, 13 May 2020 19:44:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> Date: Thu, 14 May 2020 09:44:05 +1000 Cc: Stephen Farrell , Adam Roach , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C534529-4D57-49A9-A8A2-EA1DFEECDA04@mnot.net> References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 23:44:19 -0000 > On 14 May 2020, at 9:23 am, Brian E Carpenter = wrote: >=20 > Certainly we're talking about a very low probability event, comparable > to a legislature stating that pi =3D=3D 3. But would you prefer that = the > RSE's only option in that case is to resign? This is where the editor analogy gets unstuck. If you envision this role = as responsible for the overall quality of the series, but don't give = them the ability to select and change content, hire, fire and direct the = people writing the content, etc. (as a "normal" editor does), you're = setting them up to fail. Even if they can refuse to publish documents = and/or add disclaimers to the top, it's a really poor and indirect form = of quality control. So, I don't think that resignation is on the cards here; it would be = akin to refusing to bake a cake because you don't like the wedding. We = don't expect the baker to have an opinion about what we use the cake = for; we expect them to bake excellent cakes, to train their assistants = well, and to assure that the cake-making business has a future. We = certainly would have a problem if they started writing their opinions on = the cakes. Yes, this analogy will fall apart soon too. This role is hard. We seem to expect it to be filled by someone who = knows about publishing in general, technical publishing specifically, = strategy, XML publication pipelines, indirect team management, project = management, consensus building, and I'm sure much more. Adding the = responsibility to know when something is "bad for the Internet" with = MORE confidence than the entire IESG is a lot to push uphill. It also = adds the considerable risk that a subset of the community will be able = to convince this person that it's bad, but that won't reflect the entire = community's consensus. IMO we should be looking at devolving the responsibilities of this role = to multiple people, rather than piling more on. I think it's much more = tractable if we had, for example, one person who's in charge of finding = what the consensus of the community regarding strategy is, and another = to execute that strategy. I suspect those two people with different = skill sets would be much easier to find than one super-human with all of = them. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed May 13 17:38: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 E5E7E3A088F for ; Wed, 13 May 2020 17:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, 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 NQZ13VQL6drq for ; Wed, 13 May 2020 17:38:17 -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 9C70B3A0890 for ; Wed, 13 May 2020 17:38:17 -0700 (PDT) Received: from [10.10.8.53] (mobile-166-177-123-155.mycingular.net [166.177.123.155]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 04E0c656084347 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 May 2020 19:38:07 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589416689; bh=GSfYyr/njg2giwNqJHYk7prKUR3sw2vO/WH4ryRdXKM=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=CZvs4ZNnjmjGLIj3j7Z8oDG+8jBEE6RFosWmUkhw6lQ7nmmlv3s8Ek0n1ZOQHNgVe rttQ0wvPrjTsSQGJOyGf4HJ4EcuPNtxIVQKnqO520kvDtGc6RPWkAQZJeiHlWYqEaN sOnUg01uSQnRmnrSTOf1INh7UzUxQZi0K/0pRJOE= X-Authentication-Warning: raven.nostrum.com: Host mobile-166-177-123-155.mycingular.net [166.177.123.155] claimed to be [10.10.8.53] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ben Campbell Mime-Version: 1.0 (1.0) Date: Wed, 13 May 2020 19:38:01 -0500 Message-Id: <31486FCA-3952-430C-8493-049F4A1E10EF@nostrum.com> References: <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> Cc: Stephen Farrell , Mark Nottingham , Adam Roach , rfced-future@iab.org In-Reply-To: <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> To: Brian E Carpenter X-Mailer: iPad Mail (17E262) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 00:38:19 -0000 > On May 13, 2020, at 6:24 PM, Brian E Carpenter wrote: >=20 > =EF=BB=BFOn 14-May-20 11:08, Stephen Farrell wrote: >>=20 >>=20 >>> On 14/05/2020 00:02, Mark Nottingham wrote: >>>=20 >>>> On 14 May 2020, at 8:55 am, Adam Roach wrote: >>>>=20 >>>> On 5/13/2020 5:36 PM, Brian E Carpenter wrote: >>>>> we would probably need to allow the RSE to insert a disclaimer in >>>>> a similar way >>>>=20 >>>> I'd be curious to hear other people weigh in on whether this >>>> matches their expectations. I feel far less strongly about it than >>>> I do the broader issue of veto power, but it seems that adding new >>>> material wholly fabricated by the RSE (such as a disclaimer) is a >>>> bit beyond the remit that the community might reasonably expect. >>>=20 >>> I personally don't think it's necessary, and would find it surprising >>> and somewhat unwelcome if it happened tomorrow - mostly because I >>> wouldn't be entirely sure if there were *other* people who could >>> weigh in if they so chose. >>>=20 >>> If we want to explicitly give the RSE this power, we should write it >>> down and canvass it with the community*. >>=20 >> +1, I think I'd prefer RSE push-back, if needed in >> extremis, to use other methods, such as mail to >> ietf@ietf complaining and explaining. Then let the >> community there deal with the putative crap IETF >> stream document. Something similar should also be >> ok for other streams. >=20 > Certainly we're talking about a very low probability event, comparable > to a legislature stating that pi =3D=3D 3. But would you prefer that the > RSE's only option in that case is to resign? I think we are talking about the situation where the RSE cannot in good cons= cious publish an approved IETF-stream document, has attempted to push back t= o the community using appropriate channels, but has been unable to resolve t= he issues.=20 I can imagine 2 scenarios that might lead to that point: 1) The RSE is serio= usly overstepping their remit and is trying to push their own opinion over c= onsensus, or 2) The entire IETF is so far in the weeds that no reasonable RS= E could work with it. Both of those seems like resignation-appropriate scena= rios. Do you imagine other scenarios? Also, How much effort should we undertake to plan for such a low priority ev= ent?=20 Ben.= From nobody Wed May 13 18: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 CBAA73A08CC for ; Wed, 13 May 2020 18:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NgiuwO5Abv6 for ; Wed, 13 May 2020 18:05:10 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 217283A08B9 for ; Wed, 13 May 2020 18:05:10 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id i68so1565044qtb.5 for ; Wed, 13 May 2020 18:05:10 -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=sxmeGJAZO0rzRSfcA07pBd55wRTNTz4LXoAtvRWxbf8=; b=XZYNI7mXLEvHx9wW3J6nVZNkUVljvtnzAUJrX3SDvQKJ+7NY5drvBx72YGwSl3acwC lFQilsoUEhxMairELDUb1l79OmukjcR9Nbo3nyWmLQq6w7+EQ5tSngCvvtgegrjxthua V65LCyaqy4H1IQSM6j8GLYzcyHFzjQ+EQc889c/G2IZe6Wy770mq4tMIEaN0uPOja5tq 9gpxS8Ev30RawLBWRoINiYrUtLXk2qU3+FgLGvM4EkNDdEZihZRibr61oOmHselY0xZP FkXcRZOPqo01kVpGDLvvz8Q3lZtgOvQgty2GCuhOqPBLLpZS6sv3SsuFRpQ2ExqCKC4r +2Lw== 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=sxmeGJAZO0rzRSfcA07pBd55wRTNTz4LXoAtvRWxbf8=; b=PrP9m18DV+MV5E7MbvVuEsaDwElDDldj5tDBHfhp3TAmgZ72T7NWWLS7VugXGgwCj7 sBxhVFJ5YSm+RFeNCRE5aRrVCGgCZAHkY8kYWlOMy/SZPx391ZjUXuVPP1IQ1KM3JoAA 5LSHSOpnxcDaDVuv5GgKN3JxXu9Jafxszx0wPmnX/kNruajz9g1mqfvnGbv/DeLgsX7V jrRweYFExpQEkShsxwhimwmRZGU/hvYdPUJ4FRMnlHG3VQ9vD8rwWbo3Vyd5TiPXmpEM oLQBO6UaeUXXPbeY11TSg9/YKoCZ5dYusRzJmIbl1oZ0upFWQ/KrP9OtoBFZts4On5YR 5cGw== X-Gm-Message-State: AOAM5332bObmPeiluXdcdlU4p2zdKKhdJvs99qR9+Xco2GtYf9i7Rq6Z V4rUEFzFE9ic6/WQKPYcANzxR+pMiKNZYg== X-Google-Smtp-Source: ABdhPJxoYllm4DXE0EQ6trKCvloOSzj1MnStlODRPdboJaPVMBBJQrUyLF5B+rPv8+X/OQVEGhQlyQ== X-Received: by 2002:ac8:2c78:: with SMTP id e53mr1981139qta.365.1589418308791; Wed, 13 May 2020 18:05:08 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id k43sm1359915qtk.67.2020.05.13.18.05.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2020 18:05:08 -0700 (PDT) To: rfced-future@iab.org References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie> <023601d6285d$587bdb70$09739250$@olddog.co.uk> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net> <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net> From: Michael StJohns Message-ID: <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com> Date: Wed, 13 May 2020 21:05:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3B8E2650D04296CBAECF383C" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 01:05:13 -0000 This is a multi-part message in MIME format. --------------3B8E2650D04296CBAECF383C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 5/13/2020 7:08 PM, Stephen Farrell wrote: > > On 14/05/2020 00:02, Mark Nottingham wrote: >>> On 14 May 2020, at 8:55 am, Adam Roach wrote: >>> >>> On 5/13/2020 5:36 PM, Brian E Carpenter wrote: >>>> we would probably need to allow the RSE to insert a disclaimer in >>>> a similar way >>> I'd be curious to hear other people weigh in on whether this >>> matches their expectations. I feel far less strongly about it than >>> I do the broader issue of veto power, but it seems that adding new >>> material wholly fabricated by the RSE (such as a disclaimer) is a >>> bit beyond the remit that the community might reasonably expect. >> I personally don't think it's necessary, and would find it surprising >> and somewhat unwelcome if it happened tomorrow - mostly because I >> wouldn't be entirely sure if there were *other* people who could >> weigh in if they so chose. >> >> If we want to explicitly give the RSE this power, we should write it >> down and canvass it with the community*. > +1, I think I'd prefer RSE push-back, if needed in > extremis, to use other methods, such as mail to > ietf@ietf complaining and explaining. Then let the > community there deal with the putative crap IETF > stream document. Something similar should also be > ok for other streams. > > S. I'm not sure how the above differs from "I can't publish this document at this time for the following reasons - please fix it and until you do I can't publish it". Going back to the "independence" thread, an RSE has to be able to say something like this without fear of retribution, or with sufficient protections against retribution. Later, Mike > >> Cheers, >> >> * Yes, yes. >> >> >> -- Mark Nottingham https://www.mnot.net/ >> >> --------------3B8E2650D04296CBAECF383C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/13/2020 7:08 PM, Stephen Farrell wrote:

On 14/05/2020 00:02, Mark Nottingham wrote:


        

          
On 14 May 2020, at 8:55 am, Adam Roach <adam@nostrum.com> wrote:

On 5/13/2020 5:36 PM, Brian E Carpenter wrote:


          

            
we would probably need to allow the RSE to insert a disclaimer in
a similar way


          

          
I'd be curious to hear other people weigh in on whether this
matches their expectations. I feel far less strongly about it than
I do the broader issue of veto power, but it seems that adding new
material wholly fabricated by the RSE (such as a disclaimer) is a
bit beyond the remit that the community might reasonably expect.


        

        
I personally don't think it's necessary, and would find it surprising
and somewhat unwelcome if it happened tomorrow - mostly because I
wouldn't be entirely sure if there were *other* people who could
weigh in if they so chose.

If we want to explicitly give the RSE this power, we should write it
down and canvass it with the community*.


      

      
+1, I think I'd prefer RSE push-back, if needed in
extremis, to use other methods, such as mail to
ietf@ietf complaining and explaining. Then let the
community there deal with the putative crap IETF
stream document. Something similar should also be
ok for other streams.

S.

    

    
I'm not sure how the above differs from "I can't publish this
      document at this time for the following reasons - please fix it
      and until you do I can't publish it".  

    

    
Going back to the "independence" thread, an RSE has to be able to
      say something like this without fear of retribution, or with
      sufficient protections against retribution.

    
Later, Mike

    


    

    

      



      

        
Cheers,

* Yes, yes.


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



        

        

      

    

    


    

  


--------------3B8E2650D04296CBAECF383C--


From nobody Wed May 13 18:14:11 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E133A08E6 for ; Wed, 13 May 2020 18:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=XCEVOTWa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cJkR/kTx
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZREifgPm2I9 for ; Wed, 13 May 2020 18:14:09 -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 1515D3A08E2 for ; Wed, 13 May 2020 18:14:09 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 162CC4D5; Wed, 13 May 2020 21:14:08 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 13 May 2020 21:14:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=a xuSCCUWDjokZg5SyIfx5E0dr1lqMi88hEJpqRkkdTg=; b=XCEVOTWa9tZjBDTFn ktVoAMY9kXtwTZo6VOaLoD3wUZWhEkr6cs1F8CCoTOofQGN4ig1P9Pc510sG6b0/ HMRBXcurKSO7wBUjJ1idV4pAud9B6ZKji/tD3nIYqAn/wk6d1FthECghGxK2w0w9 CfdBpEBbe3CKgtpcZQhYKuGIN7HsBMmHOdcEfpixiyFPDC3ehd3yIlONbA8Pr98C IRAqq40gXsBBTtkpA10hGxp1QMbPhcVilaf5tMY8/lFaYoHEAg2BG3v+DpgCNHcE usEF6dOjr7+bd3zAuyy4W/4IcyuzJFm4RidlLoEA/CseQee8hO3tLEGV6BYl3o+9 LQ5KQ==
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=fm2; bh=axuSCCUWDjokZg5SyIfx5E0dr1lqMi88hEJpqRkkd Tg=; b=cJkR/kTxEvJJTSnQfHLs8/4/w+bAqeRanuh9AOfhvwhcPaKl5yrUVtOXq 99bszX7spZCI6j6IieIFzbrK0FRMA7r5FhbgDcb2zzaveD5I9deMmoe0DgPOJEqs XDV8UqZvqwTB4xHm4ep7Zu67RwYJM7bghdIYvVxvWR1DQd0WdYkHiMJ+qzOs9EUr YeeP/Zrka7zEo70IuFQzc5rb2hy7nliJyOYCzLQBKck1GcQ4nVzzjja+NVDEk89P WeObw6QArLwY/BCDA1G8eShBm/Sk+uir33T1Q/xRmmiB/KqfCHHrC6Xdhp3ap/cX wgzWlAvo9NcQMxPpSYYpygbUpZ6sQ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleehgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeevffffhfduteevvefhueffieegtdeutd ehffeltefffedttdeggeejheeiueetteenucffohhmrghinhepmhhnohhtrdhnvghtnecu kfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id D8FE93066319; Wed, 13 May 2020 21:14:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>
Date: Thu, 14 May 2020 11:13:58 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4AA6462F-3495-40D4-9398-4343434E2090@mnot.net>
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie>  <023601d6285d$587bdb70$09739250$@olddog.co.uk>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>
To: Michael StJohns 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 01:14:11 -0000

> On 14 May 2020, at 11:05 am, Michael StJohns  =
wrote:
>=20
> an RSE has to be able to say something like this without fear of =
retribution, or with sufficient protections against retribution.

Why?


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


From nobody Wed May 13 18:23: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 7C1043A08F0 for ; Wed, 13 May 2020 18:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8AB_zVZWFZc for ; Wed, 13 May 2020 18:23:13 -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 BA4DD3A08EF for ; Wed, 13 May 2020 18:23:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C23F3BE20; Thu, 14 May 2020 02:23:10 +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 RUqvwNQh9swI; Thu, 14 May 2020 02:22:55 +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 36586BDCF; Thu, 14 May 2020 02:22:55 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1589419375; bh=mWqhqCIA+nBTZ0Pb0cpwcmDNwHb4gsREIia8+yqwHZA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cu+a9sqWulvp2IqrnAUYCsa55CjEcyfTd19c0mqDDmRD6/V/aEjaLMyKz6+POU6Tt gHm1CnVVvQzqdg3SDqKDjlOIGkSi1V9oIBBPoUg1N6mTd8T4n+dW7KD33Xa5Gdn7YN +m3SQYr4TteFLxvINySo55Lq4dP8DCY5CDUbS2YU=
To: Michael StJohns , rfced-future@iab.org
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <023601d6285d$587bdb70$09739250$@olddog.co.uk>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.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: <8d89a7f6-8f04-fd26-a60b-2c9bec08e2fb@cs.tcd.ie>
Date: Thu, 14 May 2020 02:22:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sfunI6M0qZ5WuSJRQIJWlNKFqK4q1GyRc"
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 01:23:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--sfunI6M0qZ5WuSJRQIJWlNKFqK4q1GyRc
Content-Type: multipart/mixed; boundary="ru6OkwS7X3AMFdwn9tdWcWmH4HFh9WQHV";
 protected-headers="v1"
From: Stephen Farrell 
To: Michael StJohns , rfced-future@iab.org
Message-ID: <8d89a7f6-8f04-fd26-a60b-2c9bec08e2fb@cs.tcd.ie>
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>
 
 <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie>
  <023601d6285d$587bdb70$09739250$@olddog.co.uk>
 
 
 <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>
 
 
 <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>
 
 
 <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com>
 <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com>
 <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com>
 <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>
 
 <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>
In-Reply-To: <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>

--ru6OkwS7X3AMFdwn9tdWcWmH4HFh9WQHV
Content-Type: multipart/mixed;
 boundary="------------ACF5AEB7F68235A227AA6F84"
Content-Language: en-US

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


Hiya,

On 14/05/2020 02:05, Michael StJohns wrote:
>=20
> I'm not sure how the above differs from "I can't publish this document
> at this time for the following reasons - please fix it and until you do=

> I=C2=A0can't=C2=A0publish=C2=A0it"

I don't think we should have a written procedure for when
the RSE ought/can say the above. I do think a wise RSE
might say something like that in extremis. (Which'll not
happen I bet.)

>=20
> Going back to the "independence" thread, an RSE has to be able to say
> something like this without fear of retribution, or with sufficient
> protections=C2=A0against=C2=A0retribution.

Fear, or the lack thereof, seems to me to be in the mind
of the RSE, and not something we can specify. So I don't
see how that's relevant other than as rhetoric.

I'm not sure what "protections against retribution" might mean, nor what
retribution could be relevant.

Basically, I think we're dancing on the head of a pin
at this point in the thread;-)

But maybe there's a concrete outcome: we should make sure
to hire an RSE that doesn't take crap from treams or I*
bodies and maybe even make some nicely-phrased equivalent
part of the job spec., without really defining what is
an attitude and expectation of independence. I'd be fine
if we had such a no-shrinking-violets clause somewhere
like that.

Cheers,
S.

--------------ACF5AEB7F68235A227AA6F84
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-----

--------------ACF5AEB7F68235A227AA6F84--

--ru6OkwS7X3AMFdwn9tdWcWmH4HFh9WQHV--

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

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

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl68nWwACgkQWrL68XsX
K+reCA/+NU+t1TyhRvtjlmakVMNDVARB4SwkoG4Kif1AUSFPsxrG2GIcL+8A2Rvh
DxloFA2Hlf5cwYcYUqO+X8QVBx9E++XJXMKLkwf5k0Z4HyOY4mf8wfASRhYqRCg4
Ed0N2QH7e9Xt8x4LLkeBs2o4ecS7X/aZlw8n160/AxObdwS/JE+cwB86ZZ3G9Nr+
Mqn9NDHYvFaY/nzcLOKjtSYGRQCybMz/QKpastbyiIATiRLqm2nscWdq3fLYwJcu
hTR8Q7DhrMKc6HWU8DJBnpamW4xrNeVDJ7Mn1QgTFWkH+1Kq1a9v/dpvGRaMYNBG
pbeCF96VTHK+TeHDRTTuTbtwUhA+qYl/yOQ7kPNBfKIfaVMkqRTfn5PkEYBLGIxY
4awXMy8oDYngzbKkK7Qg6ul9RTqdPHsB/soxPpg30qM1UQGyxvN0PQm1LzsN8kNH
HAir5el85ZegvGD+U7D8QONrzHpivN0Xm8LkMfb+wJGz+HLwQt+soqvTwEAxwlf3
sKE6BBQSB7LruynlBU7GdyPrET/NHIiqKb7LqfzHCKlazKs/Xj8ILM/SGsVaKtOh
sWq6OjoGW/zqj3Pi9Kfv1WLu7TGQVkBYQwdgHt6Wtaz61JJNhyd0JI4xpZ3vL+P3
EV0lgj/X29gEHExK/FP8qWDMnH2WoyMW4/nSScT45f+rJSuLgPs=
=7TOX
-----END PGP SIGNATURE-----

--sfunI6M0qZ5WuSJRQIJWlNKFqK4q1GyRc--


From nobody Wed May 13 18:45: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 C5DED3A08FC for ; Wed, 13 May 2020 18:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.269
X-Spam-Level: 
X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaQ3kBG2qbQQ for ; Wed, 13 May 2020 18:45:51 -0700 (PDT)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 687AC3A090B for ; Wed, 13 May 2020 18:45:51 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04E1bO98015586; Wed, 13 May 2020 18:45:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=9qHKTePIVmpMbBTbFeUxFn9kYsMyF/NjTlvgusir7Io=; b=tiRDsPFawgjHKGE9h5HH801grAtAuE9olJakNt5Mro5eg5l9vqqKyO962shKxKqdk7zk jYCOkB9sQMZJ210rRQqQ0ezAEcZzSkGkCJoATFkjOOb6mBr+IqurVCmH4EJzJM3Uapbl BlTbjhrgTUMjsj6J9Ocsp7VyCoia1MRDJL37JRQF3Y+CGPOsyAwylH9rOGCwjtavzb0C /L3MvfIUeBGMsn1AryNWtgAvC8rBEimfrMKK5+cBpRZxlQ0dpNylYYIBIfx3H0Il3KI7 prHkJPTVtcZ/Zcobq2EeGgAe1SYbYo7jGwgwoMO+UWUW9fmjimVRIe6KIZ8jcuI2XMUe 2A== 
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp01.apple.com with ESMTP id 3100y828p6-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 May 2020 18:45:51 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QAA008QASWC3K90@rn-mailsvcp-mta-lapp03.rno.apple.com>;  Wed, 13 May 2020 18:45:48 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QAA00700SMVVT00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 13 May 2020 18:45:48 -0700 (PDT)
X-Va-A: 
X-Va-T-CD: 6b8565b207e7e7be5dbfe0b8c616acbf
X-Va-E-CD: cc53f8bb3ec6d9be4ff9fd47d77a7389
X-Va-R-CD: e7dcbead7f2d929fd35cea94dfc007cd
X-Va-CD: 0
X-Va-ID: 72a81d49-482a-4abe-a368-7017c66f8963
X-V-A: 
X-V-T-CD: 6b8565b207e7e7be5dbfe0b8c616acbf
X-V-E-CD: cc53f8bb3ec6d9be4ff9fd47d77a7389
X-V-R-CD: e7dcbead7f2d929fd35cea94dfc007cd
X-V-CD: 0
X-V-ID: d7db34bd-a1e8-4c41-bc70-f16be7ef6db3
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-13_09:2020-05-13, 2020-05-13 signatures=0
Received: from [10.105.90.87] (unknown [10.105.90.87]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QAA00K1GSW9SW00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 13 May 2020 18:45:45 -0700 (PDT)
Content-type: multipart/alternative; boundary=Apple-Mail-053DD4F5-BF3B-4032-BF4C-4FD989AC121A
Content-transfer-encoding: 7bit
From: Tommy Pauly 
MIME-version: 1.0 (1.0)
Date: Wed, 13 May 2020 18:45:44 -0700
Message-id: 
References: <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com>
Cc: rfced-future@iab.org
In-reply-to: <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com>
To: Adam Roach 
X-Mailer: iPhone Mail (18A288)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-13_09:2020-05-13, 2020-05-13 signatures=0
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 01:45:53 -0000

--Apple-Mail-053DD4F5-BF3B-4032-BF4C-4FD989AC121A
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

To the point of adding a disclaimer or similar, I agree that doing so would c=
ertainly go beyond the remit of the RSE. An RFC published on the IETF stream=
 is not a reflection on the RSE, and thus even if the RSE had some technical=
 quarrel with a document, for the purposes of that document the RSE would be=
 acting as just another individual in the standards process=E2=80=94=E2=80=9C=
no hats=E2=80=9D, in a way.

The existing text on IETF track RFCs is *already* disclaimer/explanation eno=
ugh. It does not require that the RSE has any technical opinion at all.=20

=3D=3D=3D
This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It=
 represents the consensus of the IETF community. It has received public revi=
ew and has been approved for publication by the Internet Engineering Steerin=
g Group (IESG). Further information on Internet Standards is available in Se=
ction 2 of RFC 7841.

=3D=3D=3D

Thanks,

Tommy


> On May 13, 2020, at 3:55 PM, Adam Roach  wrote:
>=20
> =EF=BB=BFOn 5/13/2020 5:36 PM, Brian E Carpenter wrote:
>> we would probably need to allow the RSE to insert a disclaimer in a simil=
ar way
>=20
>=20
> I'd be curious to hear other people weigh in on whether this matches their=
 expectations. I feel far less strongly about it than I do the broader issue=
 of veto power, but it seems that adding new material wholly fabricated by t=
he RSE (such as a disclaimer) is a bit beyond the remit that the community m=
ight reasonably expect.
>=20
> /a
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--Apple-Mail-053DD4F5-BF3B-4032-BF4C-4FD989AC121A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


To the point of adding a d=
isclaimer or similar, I agree that doing so would certainly go beyond the re=
mit of the RSE. An RFC published on the IETF stream is not a reflection on t=
he RSE, and thus even if the RSE had some technical quarrel with a document,=
 for the purposes of that document the RSE would be acting as just another i=
ndividual in the standards process=E2=80=94=E2=80=9Cno hats=E2=80=9D, in a w=
ay.

The existing text on IE=
TF track RFCs is *already* disclaimer/explanation enough. It does not requir=
e that the RSE has any technical opinion at all. 

=3D=3D=3D
This is an Internet Standards Track document.
<=
p id=3D"section-boilerplate.1-2" style=3D"-webkit-text-size-adjust: auto; pa=
dding: 0px; margin: 0px 0px 1em; caret-color: rgb(34, 34, 34); color: rgb(34=
, 34, 34); font-family: "Noto Sans", Arial, Helvetica, sans-serif;=
 font-size: 14px;">This document is a product of the Internet Engineering Ta=
sk Force (IETF). It represents the consensus of the IETF community. It has r=
eceived public review and has been approved for publication by the Internet E=
ngineering Steering Group (IESG). Further information on Internet Standards i=
s available in Section 2 of RFC 7841.
=3D=3D=3D
Thanks,
Tommy
=


On May 13, 2020, at 3:55 PM, A=
dam Roach <adam@nostrum.com> wrote:

=EF=BB=BFOn 5/13/2020 5:36 PM, Bria=
n E Carpenter wrote:
we would prob=
ably need to allow the RSE to insert a disclaimer in a similar way


I'd be curious to hear=
 other people weigh in on whether this matches their expectations. I feel fa=
r less strongly about it than I do the broader issue of veto power, but it s=
eems that adding new material wholly fabricated by the RSE (such as a discla=
imer) is a bit beyond the remit that the community might reasonably expect.<=
/span>

/a

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

=

--Apple-Mail-053DD4F5-BF3B-4032-BF4C-4FD989AC121A--


From nobody Wed May 13 18:59: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 DB8A23A0912 for ; Wed, 13 May 2020 18:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC-tqiC2LkzL for ; Wed, 13 May 2020 18:59:50 -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 730AF3A0911 for ; Wed, 13 May 2020 18:59:50 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id C36C120895; Wed, 13 May 2020 18:59:49 -0700 (PDT)
From: Wes Hardaker 
To: Michael StJohns 
Cc: rfced-future@iab.org
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie>  <023601d6285d$587bdb70$09739250$@olddog.co.uk>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>
Date: Wed, 13 May 2020 18:59:49 -0700
In-Reply-To: <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com> (Michael StJohns's message of "Wed, 13 May 2020 21:05:07 -0400")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 01:59:52 -0000

Michael StJohns  writes:

> I'm not sure how the above differs from "I can't publish this document at=
 this
> time for the following reasons - please fix it and until you do I can't p=
ublish
> it".=C2=A0
>=20
> Going back to the "independence" thread, an RSE has to be able to say som=
ething
> like this without fear of retribution, or with sufficient protections aga=
inst
> retribution.

Let's say someone is upset about a document being published in a WG.  It
goes through last call(s), and they raise their concerns but are in the
minority (still).  They appeal to the IESG and the appeal is denied.
They appeal to the IAB and the appeal is denied.  They then appeal to
the RSE about their issue, the RSE agrees and refuses to publish it "for
the following reasons" (which came from the objection-er).

What types of issues is this acceptable under?

If we opt for entirely-independent, then this is considered acceptable.
If we only allow for non-technical changes, then we are reducing their
independence to only the other elements of publication.  If we prevent
this scenario at all, then is there any independence left?

Slide your slider somewhere along that line.

--=20
Wes Hardaker
USC/ISI


From nobody Wed May 13 19:28: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 A3B033A092A for ; Wed, 13 May 2020 19:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ImVo5gxLAN2Y for ; Wed, 13 May 2020 19:28:35 -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 A62533A0929 for ; Wed, 13 May 2020 19:28:35 -0700 (PDT)
Received: from xse217.mail2web.com ([66.113.196.217] helo=xse.mail2web.com) by mx165.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jZ3br-000v2i-17 for rfced-future@iab.org; Thu, 14 May 2020 04:28:32 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49MwQN6YbJz2bV0 for ; Wed, 13 May 2020 19:26:20 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jZ3Zk-0004Rw-QG for rfced-future@iab.org; Wed, 13 May 2020 19:26:20 -0700
Received: (qmail 14416 invoked from network); 14 May 2020 02:26:20 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.109]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 May 2020 02:26:20 -0000
To: Wes Hardaker , Michael StJohns 
Cc: rfced-future@iab.org
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <023601d6285d$587bdb70$09739250$@olddog.co.uk>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com> 
From: Christian Huitema 
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>
Date: Wed, 13 May 2020 19:26:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------67CAD93C5628F405499E6B1C"
Content-Language: en-US
X-Originating-IP: 66.113.196.217
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.217/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.217/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0RZ/HtDapBdRUZhgsSk2AkqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4hfMOx8mREbGKHrNg1kUlXyQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuE1/kfoVSTvW73WxnprP91bu42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGZNFSBymhtbd6ygEffuU1+3geyC5iskgZbtXyitbf1DvlDoBpuj/fJ/lP0g68qsJ5jQ H50sZPeDQaETTMuyQC0ZZNNqYNicJ97CwGWLQv+wBnuXCC1A5Cukky0WFo38JXT3Y80OmAux3oN1 3+ztUzneEjHnhKws2M9ikCJ5D0tClb83o7TP54FLJfg9sR3SxHKjhzv4uJA5VDvmJs3/bbU6MrxO K8GOQiLXBuZw+nHmcIW+axx2DzNv8BNlsyaVn+VKDFfUMQ7+ovGOjQuQ28Pr3UVkhX78ZcdZtWJt ri4lXS4599fEDT1GENo62d+DqD+gavEa4Cf1ILpAKBLSDHQENgjpXL2y/ONOC04/YEfTu1ss+n2f fnQxt6aJ7klZab8CvOT2YjlrAxveXsTwUzCTkiX4qyX2d5a1xbDejUjyqRVeiJQ5XjnH4gzAuCMQ 8aUxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 02:28:38 -0000

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

On 5/13/2020 6:59 PM, Wes Hardaker wrote:

> Michael StJohns  writes:
>
>> I'm not sure how the above differs from "I can't publish this document=
 at this
>> time for the following reasons - please fix it and until you do I can'=
t publish
>> it".=C2=A0
>>
>> Going back to the "independence" thread, an RSE has to be able to say =
something
>> like this without fear of retribution, or with sufficient protections =
against
>> retribution.
> Let's say someone is upset about a document being published in a WG.  I=
t
> goes through last call(s), and they raise their concerns but are in the=

> minority (still).  They appeal to the IESG and the appeal is denied.
> They appeal to the IAB and the appeal is denied.  They then appeal to
> the RSE about their issue, the RSE agrees and refuses to publish it "fo=
r
> the following reasons" (which came from the objection-er).
>
> What types of issues is this acceptable under?
>
> If we opt for entirely-independent, then this is considered acceptable.=

> If we only allow for non-technical changes, then we are reducing their
> independence to only the other elements of publication.  If we prevent
> this scenario at all, then is there any independence left?
>
> Slide your slider somewhere along that line.

The RSE refusing publication on editorial grounds is fine, but when it
comes to technical issues the RSE is just another individual whose
technical opinion has no more precedence than any other member of the
community. Giving the RSE power to arbitrage technical issues would just
but the placing the RSE on a collision course with the IETF. I don't
think that creating more sources of conflict would be productive in any w=
ay.

-- Christian Huitema


--------------67CAD93C5628F405499E6B1C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 5/13/2020 6:59 PM, Wes Hardaker wrote:

    

    

      
Michael StJohns <msj@nthpermutation.com> writes:



      

        
I'm not sure how the above differs from "I can't publish this document at this
time for the following reasons - please fix it and until you do I can't publish
it". 

Going back to the "independence" thread, an RSE has to be able to say something
like this without fear of retribution, or with sufficient protections against
retribution.


      

      
Let's say someone is upset about a document being published in a WG.  It
goes through last call(s), and they raise their concerns but are in the
minority (still).  They appeal to the IESG and the appeal is denied.
They appeal to the IAB and the appeal is denied.  They then appeal to
the RSE about their issue, the RSE agrees and refuses to publish it "for
the following reasons" (which came from the objection-er).

What types of issues is this acceptable under?

If we opt for entirely-independent, then this is considered acceptable.
If we only allow for non-technical changes, then we are reducing their
independence to only the other elements of publication.  If we prevent
this scenario at all, then is there any independence left?

Slide your slider somewhere along that line.

    

    
The RSE refusing publication on editorial grounds is fine, but
      when it comes to technical issues the RSE is just another
      individual whose technical opinion has no more precedence than any
      other member of the community. Giving the RSE power to arbitrage
      technical issues would just but the placing the RSE on a collision
      course with the IETF. I don't think that creating more sources of
      conflict would be productive in any way.

    

    
-- Christian Huitema

    

  


--------------67CAD93C5628F405499E6B1C--


From nobody Wed May 13 19:52: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 1A1493A0920 for ; Wed, 13 May 2020 19:52:02 -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, 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 KlAaqldcjyTC for ; Wed, 13 May 2020 19:52:00 -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 878FC3A0933 for ; Wed, 13 May 2020 19:52:00 -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.15.2/8.15.2) with ESMTPSA id 04E2pwRd010583 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 May 2020 21:51:59 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589424719; bh=JgEqp4Zdvzg+zJcEjFETeLyC0cftC0jZRescjAL1zpQ=; h=Subject:To:References:From:Date:In-Reply-To; b=m1tmyhwGgPWBQlcvNxr2yVDOzAyoIxrVi5gwonj32tP1HilL6uN3zRqprzT6BViEy /o/4folol7umn/Tp75tHDlrMcQOMUZhPtVJDdqx7TUR5rupzk+KoHe5zD4lJ9dkFVY 1ZUYG/3BrOGI/6a0RlkXV9KebgWGQXaBa6KcmoCA=
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: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <023601d6285d$587bdb70$09739250$@olddog.co.uk>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>
From: Adam Roach 
Message-ID: 
Date: Wed, 13 May 2020 21:51:53 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 02:52:02 -0000

On 5/13/2020 8:05 PM, Michael StJohns wrote:
>
> I'm not sure how the above differs from "I can't publish this document 
> at this time for the following reasons - please fix it and until you 
> do I can't publish it".
>
> Going back to the "independence" thread, an RSE has to be able to say 
> something like this without fear of retribution, or with sufficient 
> protections against retribution.
>

Can you clarify the distinction you would make between "retribution" and 
"accountability"?

/a


From nobody Wed May 13 20:10: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 4AF4E3A0948 for ; Wed, 13 May 2020 20:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hEYWAS3GQ0pV for ; Wed, 13 May 2020 20:10:38 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2333A094B for ; Wed, 13 May 2020 20:10:37 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id s186so1691820qkd.4 for ; Wed, 13 May 2020 20:10:37 -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=iMyAnrDOA5jf/2I4ylPAnucvlssh04kISnLmygoq9d8=; b=NMK1vtE3jYS48MtW+gNAfMGUdDlidPLe8bQ15fbXJ4gbIjdVYbsDCe0GsWuhGTXf19 /EuamylJmmsDp3uGqic7AGcFB181XAAAmKf3P2YJkCo7oZqhvSF1s/ZNU9aNBFFYLYOB 8m1pQoqLOJRzWYZexq6Ui/Yqw4l3+zGuKm98cIWPbDZhNNAccZDqTU354Y1z9QbL5PKm 421dMdnGuEI8lTmTdKnXF6/mafsCuEqFn7avbjKR40F/FrYaB/wSpXMcE9jh84SuNXOK yoqDOAs0hdP6B8kKAcBC3Hag8XdiDf71RiF0nXUlgAWLLd23hyPOc8nGjndCUZ0hsQ/X KLmA==
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=iMyAnrDOA5jf/2I4ylPAnucvlssh04kISnLmygoq9d8=; b=OVfP/kxKS0zjyuZd+3Iar+0obOjIwnxbe8D7RxOrffA60NSIlG9nREEp4VRH2TPLkz xpcFI1wDXnIbAY+N71Nauf1v0kstk0X+t8CGaq4L0+oLdxxHba8M3Pb8IHfWOjUyoYUF o+Qu/QRX+4fNjyyHasHxTuJp4KmvX/VvJLdk8SkPhjdl792YgSkJzMRa18b59C4uRi3J 5Co2T2d5c+dkRdXd1g3xayVttZHDIpfQx3qgJnGvlIcOM1Ys0ptikszFXrHxm/o9eHhT YBVhgzhr8zXTltJPYToQgKxy2EzbsRxgXTQB/LI7O5bSqXYRa4kvtGcnFHd0yhcl5QlJ H9Cw==
X-Gm-Message-State: AOAM533fsTGtkDbYzQO0Yy1//0S8qXIoLbWZA/8guZO99wcH+kAypFPv xU6o6eZZQXAYxk8B31R7Fdk3gAilM9JVnA==
X-Google-Smtp-Source: ABdhPJzOjZYHxuJFaV64Oi/8z6pEHgeD40/2SS7iJY/cJ2xUgQ1KxmCImWYfcpH4qiFia9V5X/jeIQ==
X-Received: by 2002:a37:6409:: with SMTP id y9mr2970111qkb.184.1589425836211;  Wed, 13 May 2020 20:10:36 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id c24sm1611258qka.25.2020.05.13.20.10.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2020 20:10:35 -0700 (PDT)
To: Adam Roach , rfced-future@iab.org
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <023601d6285d$587bdb70$09739250$@olddog.co.uk>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com> 
From: Michael StJohns 
Message-ID: <2a7a83bb-e41b-793b-bb8b-fa4cf01d276d@nthpermutation.com>
Date: Wed, 13 May 2020 23:10:34 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 03:10:40 -0000

On 5/13/2020 10:51 PM, Adam Roach wrote:
> On 5/13/2020 8:05 PM, Michael StJohns wrote:
>>
>> I'm not sure how the above differs from "I can't publish this 
>> document at this time for the following reasons - please fix it and 
>> until you do I can't publish it".
>>
>> Going back to the "independence" thread, an RSE has to be able to say 
>> something like this without fear of retribution, or with sufficient 
>> protections against retribution.
>>
>
> Can you clarify the distinction you would make between "retribution" 
> and "accountability"?
>
> /a
>
Sure - can you tell me what you mean by accountability in this model?

Mike



From nobody Wed May 13 20:46: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 881313A0AFE for ; Wed, 13 May 2020 20:46:50 -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, 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 xZnHXDOP8jDz for ; Wed, 13 May 2020 20:46:49 -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 20DE33A0AFF for ; Wed, 13 May 2020 20:46:49 -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.15.2/8.15.2) with ESMTPSA id 04E3kkwH022185 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 May 2020 22:46:47 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589428008; bh=k7znysS0rSTwju3MfheUDJYvxH4hGru7XWhnYNTBGA0=; h=Subject:To:References:From:Date:In-Reply-To; b=vG/92woCJ0TsUq6PxF2AQshiaBRWGMTtlUW2SMTMBXOYbk87ZZeH/UKCL2JfmWo0p 2+3TxoMTOsKnfpe6IEDrYWt8WRlTR2kjtLX0zgaa46H0I2oEhHB9H8l762crt8QqmG lvMkZ61Uqgzsry6e14l+G1wiOGqxObUpez2x0J+o=
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: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <2a7a83bb-e41b-793b-bb8b-fa4cf01d276d@nthpermutation.com>
From: Adam Roach 
Message-ID: <5252fcf9-5d48-6df0-9875-341c7861d275@nostrum.com>
Date: Wed, 13 May 2020 22:46:41 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <2a7a83bb-e41b-793b-bb8b-fa4cf01d276d@nthpermutation.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 03:46:51 -0000

On 5/13/2020 10:10 PM, Michael StJohns wrote:
> On 5/13/2020 10:51 PM, Adam Roach wrote:
>> On 5/13/2020 8:05 PM, Michael StJohns wrote:
>>>
>>> I'm not sure how the above differs from "I can't publish this 
>>> document at this time for the following reasons - please fix it and 
>>> until you do I can't publish it".
>>>
>>> Going back to the "independence" thread, an RSE has to be able to 
>>> say something like this without fear of retribution, or with 
>>> sufficient protections against retribution.
>>>
>>
>> Can you clarify the distinction you would make between "retribution" 
>> and "accountability"?
>>
>> /a
>>
> Sure - can you tell me what you mean by accountability in this model?


Let's tease this out by making it a little less abstract.

Imagine TLS 1.3 were still under development, and that its publication 
request came under the future model we're developing. For whatever 
reason, the newly-installed RSE has decided that the various new 
security properties in TLS 1.3 are problematic for law enforcement's 
surveillance activities. They've extrapolated this to an increase in the 
chances of a terror attack to such a degree that they're willing to 
stake their professional credibility on making sure it does not get 
published in the form that the working group, the IETF at large, and the 
IESG agreed to.

So they respond to the IETF with "I can't publish this document at this 
time because it lacks interception-related features. Please fix it, and 
until you do, I can't publish it."

If you think that the system we're developing here makes this the final 
word on that technical matter -- either we insert interception-related 
features in TLS 1.3, or it simply doesn't get an RFC number -- please be 
sure to say so clearly and unambiguously.

But if the ultimate conclusion here is that the RSE is removed from 
their post (ignoring for a moment who makes the decision to perform such 
removal) and the RFC is published with the technical content generated 
by the IETF, is that retribution? Or is that holding the RSE accountable 
for failing to perform their duties?

/a


From nobody Wed May 13 21:53: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 1ADBB3A0B2E for ; Wed, 13 May 2020 21:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo0P91Qk9NOp for ; Wed, 13 May 2020 21:53:22 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDD03A0B2D for ; Wed, 13 May 2020 21:53:22 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id r22so739248pga.12 for ; Wed, 13 May 2020 21:53:22 -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=zRs7149UtZsx2Fk4iuplaVBnQB4hqdSdNkkkGmaBFas=; b=a7IOC+i36WgwzYfTvp3bhEigeNRhTS8tDA3kbvN4FxH6MCvOA+25W1dLNrwInu8Y8D 8xTqznzgLP7KsQ8YoYfWFthSsPy4scyS7z1pbnzuPRaZck7kMQ8m3xBFL38K5F3MofQY m10RRRQoeMu5W5CtyYbZhTZ1fTZWlPI7GYY2UeNfhisdS8qdeEGyuXiU5m6RqkNqNUnM A19uqQ2RBuR6Rrf5QccQtvJtN8/3nzluWKuxgtDiFbLgV/TsEp4AcrLdWPObmw87ohQY oS1vDgV+4zZcaC4t5L4h5nKKibd2BcxhKHSOKovyx+Xf/1xIhw+HOAIt2NYrQU/WTt3q ZukA==
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=zRs7149UtZsx2Fk4iuplaVBnQB4hqdSdNkkkGmaBFas=; b=I4j0zF+Znvbm3kBb3W+yYuNz7Tmkrmmu2qd1UtWejlTduU102LujXiufHJJCxTmEK1 xDviP0JsegYh320Xo3P0sMgI4CeqHUycaWCXvq802wb0xmk/LxyE98f+Z8Ac6KgsFSqP TCBTRVSZEc7m5pHQhWhCFvUe3rv213dTpxNbTPG8fPrQzFuhOygkFqsRCeBblhZooRj7 /lYxl2x2j2GfqxghdrVEsxJNGmgsj5daUFVtAgMlNffJXbGaxRGzZNubSTaHetTgzM4P jwaSPMYL1eAP0gGU49Z/O1diyOzpLWlP6TiK4tIYPAePtxxQh3wMhkxgZLOnHygw/yGC iLeQ==
X-Gm-Message-State: AOAM5302IC/lxB9t5TF9OU8cBJKd3zxtBiyKNKZQDYQQyStsyB1stwiC L2gs+BqHqUO/y81hmWwUSeW/hKAw
X-Google-Smtp-Source: ABdhPJxUQoANB44t8IXeLWuUS1JwuwTCNLGlBtr+NxuNnkHRXeeOY3z0SBZ8JUL9m1/W0xq8E8p/gg==
X-Received: by 2002:a65:611a:: with SMTP id z26mr2374305pgu.341.1589432001494;  Wed, 13 May 2020 21:53:21 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id b21sm1108047pgj.9.2020.05.13.21.53.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2020 21:53:20 -0700 (PDT)
To: Christian Huitema , Wes Hardaker , Michael StJohns 
Cc: rfced-future@iab.org
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>
From: Brian E Carpenter 
Message-ID: 
Date: Thu, 14 May 2020 16:53:16 +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: <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>
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-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 04:53:24 -0000

Wow, this thread has a life of its own. Below...
On 14-May-20 14:26, Christian Huitema wrote:
> On 5/13/2020 6:59 PM, Wes Hardaker wrote:
>=20
>> Michael StJohns  writes:
>>
>>> I'm not sure how the above differs from "I can't publish this documen=
t at this
>>> time for the following reasons - please fix it and until you do I can=
't publish
>>> it".=C2=A0
>>>
>>> Going back to the "independence" thread, an RSE has to be able to say=
 something
>>> like this without fear of retribution, or with sufficient protections=
 against
>>> retribution.
>> Let's say someone is upset about a document being published in a WG.  =
It
>> goes through last call(s), and they raise their concerns but are in th=
e
>> minority (still).  They appeal to the IESG and the appeal is denied.
>> They appeal to the IAB and the appeal is denied.  They then appeal to
>> the RSE about their issue, the RSE agrees and refuses to publish it "f=
or
>> the following reasons" (which came from the objection-er).
>>
>> What types of issues is this acceptable under?
>>
>> If we opt for entirely-independent, then this is considered acceptable=
=2E
>> If we only allow for non-technical changes, then we are reducing their=

>> independence to only the other elements of publication.  If we prevent=

>> this scenario at all, then is there any independence left?
>>
>> Slide your slider somewhere along that line.
>=20
> The RSE refusing publication on editorial grounds is fine, but when it =
comes to technical issues the RSE is just another individual whose techni=
cal opinion has no more precedence than any other member of the community=
=2E Giving the RSE power to arbitrage technical issues would just but the=
 placing the RSE on a collision course with the IETF. I don't think that =
creating more sources of conflict would be productive in any way.

My feeling after reading the thread is that in such a situation, the RSE =
should be like any other community member: (s)he can appeal the IESG's de=
cision to publish, and possibly escalate the appeal to the IAB. Whether t=
he grounds for the appeal are technical (pi is actually 22/7) or more gen=
eral (the lawyer says that we will be sued or prosecuted) is beside the p=
oint.

In other words, if there's a conflict, use the existing conflict-resoluti=
on mechanism.

But an actual veto on technical content seems to fundamentally break the =
stream model.

Regards
   Brian


From nobody Wed May 13 23:08: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 3D20D3A0BD5 for ; Wed, 13 May 2020 23:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=pZhHF3U3; dkim=pass (2048-bit key) header.d=gmail.com header.b=t9Xr5JtV
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhdYN0MAFpmN for ; Wed, 13 May 2020 23:07:59 -0700 (PDT)
Received: from mail-lf1-x149.google.com (mail-lf1-x149.google.com [IPv6:2a00:1450:4864:20::149]) (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 B2B1C3A0BA1 for ; Wed, 13 May 2020 23:07:58 -0700 (PDT)
Received: by mail-lf1-x149.google.com with SMTP id 68so775606lfj.9 for ; Wed, 13 May 2020 23:07:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=vgtAynvJNH/DYZjlVe+fWS6nDLJgB0aJVvcbAaOVBNc=; b=pZhHF3U3IOjG/5rOVWscHqKWoX1dX5n5OHm4GA6e9t29n5GManYGeNKPNTjsab201g Bdbho/h476MoPTBag0AiY7z7VawryD5fT6vWb3tUGuCpnAPmC7NbJj2R/+2QDr8JLE30 izJsm7nEy7k3W0gZImnH/ykUIx5EA0/HAcn08rcwlr2jlgEv92AYVlUBkFYkVF14hymP ht8qkSe6QGBp6vX4TprUZuN613dtqNiApq0/I4O2cwUvoS5oUKvjyD29i3Wg+oo/cJtb 6+GqIuV2r7QO7w2TtvTb/I622Yr7Pcdu7Dqp19u5n4HSjjq3FBU1pizFbSuitVH3DV95 klVg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:reply-to:sender:message-id:date:subject:from:to;  bh=vgtAynvJNH/DYZjlVe+fWS6nDLJgB0aJVvcbAaOVBNc=; b=t9Xr5JtVZDm2DxoeaxlwPvsFKe9p5wChyoJFnTEzDFoIBIAnB8b5KYsdPLaSCPorSl y/+TuyevJ/YxJmyIq65RFc+e1yOuNDbMeA82HyNlp4WeIN+tfmx43NuDxehTDW62OSvf DjhgOLqBK7Lxvo2V1ZNPpfruhA+SRmBt94kCV7ReEpQn3ObfZGflqzeOx6qOazzOcre6 yHtzwD8H8/pthgsGgbQurAcOrJigrk6oVTxzX/Dtgo/eLsaYXah8GzDdGwu3gAA0hAmb 52E9/C9XqzTHSyzTw8OYnLbW00zdT/3dsz5szOFBSJbrddVRuVJHGCXpNafKY9odtYy9 0oTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:message-id:date :subject:from:to; bh=vgtAynvJNH/DYZjlVe+fWS6nDLJgB0aJVvcbAaOVBNc=; b=ubvAmmYg2PKCCOKbcQvKFk1iR8flMWYDTqTpimYPkTCBHk2ftkMeU27Kvj0dzG7kjX FE9ef98kjPFTLsnA3R34HdswjUcDHa+h47t7Mqwtb5y0L+br0NufkRnlGv5W9Rw+ManL DfHBb1PmaVdcBGpIfiwy+MPhj2lzhF3PzoQX8jdJu7e3QMzt7+IjCq3as3CWVYLD0YIF H8rSK0LU2CIwNPQXOg6zHCw8E9zs1yuCe+Rt090KuboCesh3n8RHwVMGk1boOkRx2g2Y aMyOMSBZVpToWbRQEazHN4rH/HsjgKWJgHq0Ip/6pVyL6yeEA8F3xsLjJx2Y36HN8YC6 ZIdA==
X-Gm-Message-State: AOAM532/mcEmpR5Rf70CXx/5R+BnWOwvAGQISRRk5b5IJg3dSgpkQGyC A/UL3KmM19JOx2EwG7LF8e3Tg2Q7gObLTlGvzzbc
X-Google-Smtp-Source: ABdhPJw3+T8GQjXx3Oxy/PD3CRhyW/sgUBwJ+nSHdpug+Hxopg+f1UPkgiyVZledVz5bXFYoU9+JSzp7/RdQO0N6W7ab
MIME-Version: 1.0
X-Received: by 2002:a19:4a15:: with SMTP id x21mr2065720lfa.22.1589436476717;  Wed, 13 May 2020 23:07:56 -0700 (PDT)
Reply-To: dhruv.ietf@gmail.com
Sender: Google Calendar 
Message-ID: <000000000000967ddd05a5958418@google.com>
Date: Thu, 14 May 2020 06:07:56 +0000
From: dhruv.ietf@gmail.com
To: rfced-future@iab.org, ietf-announce@ietf.org, iesg-secretary@ietf.org
Content-Type: multipart/mixed; boundary="000000000000967dca05a5958417"
Archived-At: 
Subject: [Rfced-future] Invitation: RFC Editor Future Development Program (rfc... @ Wed May 27, 2020 11:30am - 1pm (IST) (rfced-future@iab.org)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 14 May 2020 06:08:04 -0000

--000000000000967dca05a5958417
Content-Type: multipart/alternative; boundary="000000000000967dc805a5958415"

--000000000000967dc805a5958415
Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes
Content-Transfer-Encoding: base64

WW91IGhhdmUgYmVlbiBpbnZpdGVkIHRvIHRoZSBmb2xsb3dpbmcgZXZlbnQuDQoNClRpdGxlOiBb
UmZjZWQtZnV0dXJlXSBSRkMgRWRpdG9yIEZ1dHVyZSBEZXZlbG9wbWVudCBQcm9ncmFtIChyZmNl
ZmRwKSBXRyAgDQpWaXJ0dWFsIE1lZXRpbmc6IDIwMjAtMDUtMjcNClRoZSBSRkMgRWRpdG9yIEZ1
dHVyZSBEZXZlbG9wbWVudCBQcm9ncmFtIChyZmNlZmRwKSB3aWxsIGhvbGQNCmEgdmlydHVhbCBp
bnRlcmltIG1lZXRpbmcgb24gMjAyMC0wNS0yNyBmcm9tIDA2OjAwIHRvIDA3OjMwIFVUQy4NCg0K
QWdlbmRhOg0KV2Ugd2lsbCBjb250aW51ZSBhIHJvdW5kdGFibGUgZXhjaGFuZ2Ugb2YgcGVvcGxl
4oCZcyB2aWV3cyBvbiB0aGUgZnV0dXJlIG9mICANCnRoZSBSRkMgU2VyaWVzIEVkaXRvci4gV2Ug
d2lsbCBmdXJ0aGVyIGRldmVsb3AgdGhlIGFnZW5kYSB0aGVyZS4gQWxsIGFyZSAgDQppbnZpdGVk
IHRvIHBhcnRpY2lwYXRlLCBhbmQgdG8gam9pbiB0aGUgbGlzdCwgd2hpY2ggY2FuIGJlIGZvdW5k
IGF0ICANCmh0dHBzOi8vd3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmNlZC1mdXR1cmUu
IFRoZSBtZWV0aW5nIHdpbGwgYmUgIA0KcmVjb3JkZWQuIEN1cnJlbnQgaW5mb3JtYXRpb24gb24g
dGhlIHByb2dyYW0gY2FuIGJlIGZvdW5kIGF0ICANCmh0dHBzOi8vZ2l0aHViLmNvbS9pbnRhcmNo
Ym9hcmQvcmZjZWQtZnV0dXJlLg0KDQpJbmZvcm1hdGlvbiBhYm91dCByZW1vdGUgcGFydGljaXBh
dGlvbjoNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xZGQ0MjUzZGI0
YmRmM2EzMGVmOWYzYWFiYzY0YWM3NQ0KDQotLQ0KUmZjZWQtZnV0dXJlIG1haWxpbmcgbGlzdA0K
UmZjZWQtZnV0dXJlQGlhYi5vcmcNCmh0dHBzOi8vd3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5m
by9yZmNlZC1mdXR1cmUNCldoZW46IFdlZCBNYXkgMjcsIDIwMjAgMTE6MzBhbSDigJMgMXBtIElu
ZGlhIFN0YW5kYXJkIFRpbWUgLSBLb2xrYXRhDQpDYWxlbmRhcjogcmZjZWQtZnV0dXJlQGlhYi5v
cmcNCldobzoNCiAgICAgKiBkaHJ1di5pZXRmQGdtYWlsLmNvbSAtIG9yZ2FuaXplcg0KICAgICAq
IGlldGYtYW5ub3VuY2VAaWV0Zi5vcmcNCiAgICAgKiBpZXNnLXNlY3JldGFyeUBpZXRmLm9yZw0K
ICAgICAqIHJmY2VkLWZ1dHVyZUBpYWIub3JnDQoNCkV2ZW50IGRldGFpbHM6ICANCmh0dHBzOi8v
d3d3Lmdvb2dsZS5jb20vY2FsZW5kYXIvZXZlbnQ/YWN0aW9uPVZJRVcmZWlkPU4yaHljM05pYUdV
eWNYSTVhRFZzYkdGbVkyOXdabUpuT1dVZ2NtWmpaV1F0Wm5WMGRYSmxRR2xoWWk1dmNtYyZ0b2s9
TWpBalpHaHlkWFl1YVdWMFprQm5iV0ZwYkM1amIyMDNaamt6TkdVMU5EWXlNVGMwTlRVM01qaGhZ
bU0zTnpsaFl6WmpOalUxTWpjMk4yRmpNVGhoJmN0ej1Bc2lhJTJGS29sa2F0YSZobD1lbiZlcz0w
DQoNCkludml0YXRpb24gZnJvbSBHb29nbGUgQ2FsZW5kYXI6IGh0dHBzOi8vd3d3Lmdvb2dsZS5j
b20vY2FsZW5kYXIvDQoNCllvdSBhcmUgcmVjZWl2aW5nIHRoaXMgY291cnRlc3kgZW1haWwgYXQg
dGhlIGFjY291bnQgcmZjZWQtZnV0dXJlQGlhYi5vcmcgIA0KYmVjYXVzZSB5b3UgYXJlIGFuIGF0
dGVuZGVlIG9mIHRoaXMgZXZlbnQuDQoNClRvIHN0b3AgcmVjZWl2aW5nIGZ1dHVyZSB1cGRhdGVz
IGZvciB0aGlzIGV2ZW50LCBkZWNsaW5lIHRoaXMgZXZlbnQuICANCkFsdGVybmF0aXZlbHkgeW91
IGNhbiBzaWduIHVwIGZvciBhIEdvb2dsZSBhY2NvdW50IGF0ICANCmh0dHBzOi8vd3d3Lmdvb2ds
ZS5jb20vY2FsZW5kYXIvIGFuZCBjb250cm9sIHlvdXIgbm90aWZpY2F0aW9uIHNldHRpbmdzIGZv
ciAgDQp5b3VyIGVudGlyZSBjYWxlbmRhci4NCg0KRm9yd2FyZGluZyB0aGlzIGludml0YXRpb24g
Y291bGQgYWxsb3cgYW55IHJlY2lwaWVudCB0byBzZW5kIGEgcmVzcG9uc2UgdG8gIA0KdGhlIG9y
Z2FuaXplciBhbmQgYmUgYWRkZWQgdG8gdGhlIGd1ZXN0IGxpc3QsIG9yIGludml0ZSBvdGhlcnMg
cmVnYXJkbGVzcyAgDQpvZiB0aGVpciBvd24gaW52aXRhdGlvbiBzdGF0dXMsIG9yIHRvIG1vZGlm
eSB5b3VyIFJTVlAuIExlYXJuIG1vcmUgYXQgIA0KaHR0cHM6Ly9zdXBwb3J0Lmdvb2dsZS5jb20v
Y2FsZW5kYXIvYW5zd2VyLzM3MTM1I2ZvcndhcmRpbmcNCg==
--000000000000967dc805a5958415
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


You have been invited to the foll=
owing event.
[Rfced-future] RFC Editor Future De=
velopment Program (rfcefdp) WG Virtual Meeting: 2020-05-27
When
Wed May 27, 2020 11:30am =E2=80=
=93 1pm India Standard Time - Kolkata
Calendar
rfced-future@iab.org
Who=

=

•
dhruv.ietf@gmail.com - organizer
•<=
/div>
ietf-anno=
unce@ietf.org
•
iesg-secretary@ietf.org
•
rfced-future@iab.org
The RFC Editor Future Deve=
lopment Program (rfcefdp) will hold
a virtual interim meeting on 2020-05=
-27 from 06:00 to 07:30 UTC.
Agenda:
We will continue a roundtable exc=
hange of people=E2=80=99s views on the future of the RFC Series Editor. We =
will further develop the agenda there. All are invited to participate, and =
to join the list, which can be found at https://www.iab.org/mailman/listinfo/rfced-future. The m=
eeting will be recorded. Current information on the program can be found at=
 https://github.com/intarchboard=
/rfced-future.
Information about remote participation:
https:/=
/ietf.webex.com/ietf/j.php?MTID=3Dm1dd4253db4bdf3a30ef9f3aabc64ac75
=

--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future
Going (rfce=
d-future@iab.org)?   Yes - Maybe - No    =
more options »
Invitation from Google =
Calendar
You are receiving this courtesy email at the account rfc=
ed-future@iab.org because you are an attendee of this event.
To stop =
receiving future updates for this event, decline this event. Alternatively =
you can sign up for a Google account at https://www.google.com/calendar/ an=
d control your notification settings for your entire calendar.
Forwar=
ding this invitation could allow any recipient to send a response to the or=
ganizer and be added to the guest list, or invite others regardless of thei=
r own invitation status, or to modify your RSVP. Learn More.
=


--000000000000967dc805a5958415
Content-Type: text/calendar; charset="UTF-8"; method=REQUEST
Content-Transfer-Encoding: quoted-printable

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20200527T060000Z
DTEND:20200527T073000Z
DTSTAMP:20200514T060756Z
ORGANIZER;CN=3Ddhruv.ietf@gmail.com:mailto:dhruv.ietf@gmail.com
UID:7hrssbhe2qr9h5llafcopfbg9e@google.com
ATTENDEE;CUTYPE=3DINDIVIDUAL;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION=
;RSVP=3D
 TRUE;CN=3Dietf-announce@ietf.org;X-NUM-GUESTS=3D0:mailto:ietf-announce@iet=
f.org
ATTENDEE;CUTYPE=3DINDIVIDUAL;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION=
;RSVP=3D
 TRUE;CN=3Diesg-secretary@ietf.org;X-NUM-GUESTS=3D0:mailto:iesg-secretary@i=
etf.o
 rg
ATTENDEE;CUTYPE=3DINDIVIDUAL;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION=
;RSVP=3D
 TRUE;CN=3Drfced-future@iab.org;X-NUM-GUESTS=3D0:mailto:rfced-future@iab.or=
g
ATTENDEE;CUTYPE=3DINDIVIDUAL;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DACCEPTED;RSV=
P=3DTRUE
 ;CN=3Ddhruv.ietf@gmail.com;X-NUM-GUESTS=3D0:mailto:dhruv.ietf@gmail.com
X-MICROSOFT-CDO-OWNERAPPTID:1442736557
CREATED:20200514T060755Z
DESCRIPTION:The RFC Editor Future Development Program (rfcefdp) will hold\n
 a virtual interim meeting on 2020-05-27 from 06:00 to 07:30 UTC.\n\nAgenda=
:
 \nWe will continue a roundtable exchange of people=E2=80=99s views on the =
future of
  the RFC Series Editor. We will further develop the agenda there. All are =
i
 nvited to participate\, and to join the list\, which can be found at https=
:
 //www.iab.org/mailman/listinfo/rfced-future. The meeting will be recorded.=
=20
 Current information on the program can be found at https://github.com/inta=
r
 chboard/rfced-future.\n\nInformation about remote participation:\nhttps://=
i
 etf.webex.com/ietf/j.php?MTID=3Dm1dd4253db4bdf3a30ef9f3aabc64ac75\n\n--\nR=
fce
 d-future mailing list\nRfced-future@iab.org\nhttps://www.iab.org/mailman/l=
i
 stinfo/rfced-future\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~=
:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of th=
e
  description.\n\nView your event at https://www.google.com/calendar/event?=
a
 ction=3DVIEW&eid=3DN2hyc3NiaGUycXI5aDVsbGFmY29wZmJnOWUgcmZjZWQtZnV0dXJlQGl=
hYi5v
 cmc&tok=3DMjAjZGhydXYuaWV0ZkBnbWFpbC5jb203ZjkzNGU1NDYyMTc0NTU3MjhhYmM3Nzlh=
YzZ
 jNjU1Mjc2N2FjMThh&ctz=3DAsia%2FKolkata&hl=3Den&es=3D1.\n-::~:~::~:~:~:~:~:=
~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20200514T060756Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:[Rfced-future] RFC Editor Future Development Program (rfcefdp) WG V
 irtual Meeting: 2020-05-27
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

--000000000000967dc805a5958415--

--000000000000967dca05a5958417
Content-Type: application/ics; name="invite.ics"
Content-Disposition: attachment; filename="invite.ics"
Content-Transfer-Encoding: base64

QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vR29vZ2xlIEluYy8vR29vZ2xlIENhbGVuZGFyIDcw
LjkwNTQvL0VODQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6UkVRVUVT
VA0KQkVHSU46VkVWRU5UDQpEVFNUQVJUOjIwMjAwNTI3VDA2MDAwMFoNCkRURU5EOjIwMjAwNTI3
VDA3MzAwMFoNCkRUU1RBTVA6MjAyMDA1MTRUMDYwNzU2Wg0KT1JHQU5JWkVSO0NOPWRocnV2Lmll
dGZAZ21haWwuY29tOm1haWx0bzpkaHJ1di5pZXRmQGdtYWlsLmNvbQ0KVUlEOjdocnNzYmhlMnFy
OWg1bGxhZmNvcGZiZzllQGdvb2dsZS5jb20NCkFUVEVOREVFO0NVVFlQRT1JTkRJVklEVUFMO1JP
TEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPQ0KIFRSVUU7Q049
aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZztYLU5VTS1HVUVTVFM9MDptYWlsdG86aWV0Zi1hbm5vdW5j
ZUBpZXRmLm9yZw0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBB
TlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj1pZXNnLXNlY3JldGFyeUBp
ZXRmLm9yZztYLU5VTS1HVUVTVFM9MDptYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vDQogcmcN
CkFUVEVOREVFO0NVVFlQRT1JTkRJVklEVUFMO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFU
PU5FRURTLUFDVElPTjtSU1ZQPQ0KIFRSVUU7Q049cmZjZWQtZnV0dXJlQGlhYi5vcmc7WC1OVU0t
R1VFU1RTPTA6bWFpbHRvOnJmY2VkLWZ1dHVyZUBpYWIub3JnDQpBVFRFTkRFRTtDVVRZUEU9SU5E
SVZJRFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1BQ0NFUFRFRDtSU1ZQPVRSVUUN
CiA7Q049ZGhydXYuaWV0ZkBnbWFpbC5jb207WC1OVU0tR1VFU1RTPTA6bWFpbHRvOmRocnV2Lmll
dGZAZ21haWwuY29tDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6MTQ0MjczNjU1Nw0KQ1JF
QVRFRDoyMDIwMDUxNFQwNjA3NTVaDQpERVNDUklQVElPTjpUaGUgUkZDIEVkaXRvciBGdXR1cmUg
RGV2ZWxvcG1lbnQgUHJvZ3JhbSAocmZjZWZkcCkgd2lsbCBob2xkXG4NCiBhIHZpcnR1YWwgaW50
ZXJpbSBtZWV0aW5nIG9uIDIwMjAtMDUtMjcgZnJvbSAwNjowMCB0byAwNzozMCBVVEMuXG5cbkFn
ZW5kYToNCiBcbldlIHdpbGwgY29udGludWUgYSByb3VuZHRhYmxlIGV4Y2hhbmdlIG9mIHBlb3Bs
ZeKAmXMgdmlld3Mgb24gdGhlIGZ1dHVyZSBvZg0KICB0aGUgUkZDIFNlcmllcyBFZGl0b3IuIFdl
IHdpbGwgZnVydGhlciBkZXZlbG9wIHRoZSBhZ2VuZGEgdGhlcmUuIEFsbCBhcmUgaQ0KIG52aXRl
ZCB0byBwYXJ0aWNpcGF0ZVwsIGFuZCB0byBqb2luIHRoZSBsaXN0XCwgd2hpY2ggY2FuIGJlIGZv
dW5kIGF0IGh0dHBzOg0KIC8vd3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmNlZC1mdXR1
cmUuIFRoZSBtZWV0aW5nIHdpbGwgYmUgcmVjb3JkZWQuIA0KIEN1cnJlbnQgaW5mb3JtYXRpb24g
b24gdGhlIHByb2dyYW0gY2FuIGJlIGZvdW5kIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9pbnRhcg0K
IGNoYm9hcmQvcmZjZWQtZnV0dXJlLlxuXG5JbmZvcm1hdGlvbiBhYm91dCByZW1vdGUgcGFydGlj
aXBhdGlvbjpcbmh0dHBzOi8vaQ0KIGV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xZGQ0
MjUzZGI0YmRmM2EzMGVmOWYzYWFiYzY0YWM3NVxuXG4tLVxuUmZjZQ0KIGQtZnV0dXJlIG1haWxp
bmcgbGlzdFxuUmZjZWQtZnV0dXJlQGlhYi5vcmdcbmh0dHBzOi8vd3d3LmlhYi5vcmcvbWFpbG1h
bi9saQ0KIHN0aW5mby9yZmNlZC1mdXR1cmVcblxuLTo6fjp+Ojp+On46fjp+On46fjp+On46fjp+
On46fjp+On46fjp+On46fjp+On46fjp+Og0KIH46fjp+On46fjp+On46fjp+On46fjp+On46fjo6
fjp+OjotXG5QbGVhc2UgZG8gbm90IGVkaXQgdGhpcyBzZWN0aW9uIG9mIHRoZQ0KICBkZXNjcmlw
dGlvbi5cblxuVmlldyB5b3VyIGV2ZW50IGF0IGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vY2FsZW5k
YXIvZXZlbnQ/YQ0KIGN0aW9uPVZJRVcmZWlkPU4yaHljM05pYUdVeWNYSTVhRFZzYkdGbVkyOXda
bUpuT1dVZ2NtWmpaV1F0Wm5WMGRYSmxRR2xoWWk1dg0KIGNtYyZ0b2s9TWpBalpHaHlkWFl1YVdW
MFprQm5iV0ZwYkM1amIyMDNaamt6TkdVMU5EWXlNVGMwTlRVM01qaGhZbU0zTnpsaFl6Wg0KIGpO
alUxTWpjMk4yRmpNVGhoJmN0ej1Bc2lhJTJGS29sa2F0YSZobD1lbiZlcz0xLlxuLTo6fjp+Ojp+
On46fjp+On46fjp+On46fg0KIDp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+
On46fjp+On46fjp+On46fjo6fjp+OjotDQpMQVNULU1PRElGSUVEOjIwMjAwNTE0VDA2MDc1NloN
CkxPQ0FUSU9OOg0KU0VRVUVOQ0U6MA0KU1RBVFVTOkNPTkZJUk1FRA0KU1VNTUFSWTpbUmZjZWQt
ZnV0dXJlXSBSRkMgRWRpdG9yIEZ1dHVyZSBEZXZlbG9wbWVudCBQcm9ncmFtIChyZmNlZmRwKSBX
RyBWDQogaXJ0dWFsIE1lZXRpbmc6IDIwMjAtMDUtMjcNClRSQU5TUDpPUEFRVUUNCkVORDpWRVZF
TlQNCkVORDpWQ0FMRU5EQVINCg==
--000000000000967dca05a5958417--


From nobody Wed May 13 23:50: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 B6AC43A0BD2 for ; Wed, 13 May 2020 23:50:04 -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 gW6LVl9maBqC for ; Wed, 13 May 2020 23:50:03 -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 14B253A0BCF for ; Wed, 13 May 2020 23:50:03 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jZ7gp-0000Bj-I4; Thu, 14 May 2020 02:49:55 -0400
Date: Thu, 14 May 2020 02:49:50 -0400
From: John C Klensin 
To: Brian E Carpenter , Christian Huitema , Wes Hardaker ,  Michael StJohns 
cc: rfced-future@iab.org
Message-ID: <48F3E58D4D06C8EAE9D22438@PSB>
In-Reply-To: 
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net> 
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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 06:50:05 -0000

--On Thursday, May 14, 2020 16:53 +1200 Brian E Carpenter
 wrote:

>> The RSE refusing publication on editorial grounds is fine,
>> but when it comes to technical issues the RSE is just another
>> individual whose technical opinion has no more precedence
>> than any other member of the community. Giving the RSE power
>> to arbitrage technical issues would just but the placing the
>> RSE on a collision course with the IETF. I don't think that
>> creating more sources of conflict would be productive in any
>> way.
> 
> My feeling after reading the thread is that in such a
> situation, the RSE should be like any other community member:
> (s)he can appeal the IESG's decision to publish, and possibly
> escalate the appeal to the IAB. Whether the grounds for the
> appeal are technical (pi is actually 22/7) or more general
> (the lawyer says that we will be sued or prosecuted) is beside
> the point.
> 
> In other words, if there's a conflict, use the existing
> conflict-resolution mechanism.
> 
> But an actual veto on technical content seems to fundamentally
> break the stream model.

I have just had occasion to read through multiple documents
trying to find the reference associated with my recollection
that there was a procedure for the RFC Editor Function to reject
a document on editorial grounds and for the IESG to say "publish
anyway, if necessary with a note indicating that the document
did not meet RFC Series Standards".  I have not been able to
find it (and may well be suffering from deteriorating memory)
but, in the process, I did run across a sentence in the fourth
paragraph of Section 4.3 of RFC 8728 (present in identical, or
nearly identical form, in RFCs 6635 and 5620).  It reads:

  "In particular, it should be noted that final decisions about
  the technical content of individual documents are the
  exclusive responsibility of the stream approvers from which
  those documents originate, as shown in the illustration in
  Figure 1."

While I understand (and anticipate) that the discussions during
this effort may lead to some fundamental changes to RFC 8728, I
would hope that we can all be sufficiently familiar with that
document (and other key documents about the RFC Series) to avoid
going around loops on issues that seem to have been settled long
ago and that do not seem to be in obvious need of reopening.

best,
   john




From nobody Thu May 14 00:06: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 83A6F3A00B2 for ; Thu, 14 May 2020 00:06:21 -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 fZZs6MghckFE for ; Thu, 14 May 2020 00:06:19 -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 681C83A00C4 for ; Thu, 14 May 2020 00:06:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3946; q=dns/txt; s=iport; t=1589439979; x=1590649579; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=rquklBiirO6yvlzxI5XcOPHB0JfHx/7aaRuGKnv+Bdk=; b=eO9CXSWtqchf0YyMrE4NiyWEFqIyqtysWodEIn4OlXy1eLIrdPWczXjo d7V5llqKXJoi8zGYo+AV05DpFd47+isVC8nZ+ieNyyJgNYhvc15L7qPRe B9g5Y+kEwcOWoGZE2CD8HFm+CtqMurXC9V1y4CrbTZKWmcEgO+Ry9YAwF c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUAAD97Lxe/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBdQUBAQsBAYNtASAShFGJAZtZhhGBewsBAQEMAQEvBAEBhEQ?= =?us-ascii?q?CgjU2Bw4CAwEBCwEBBQEBAQIBBQRthWJCARABhR4GI1YQCwQ+AgJXBoM5gn2?= =?us-ascii?q?xBHaBMoVRhSSBOAGMW4IAgTgcgk0+hBiDSjOCLQSyfoJXgnGVQx2QJI0lqh+?= =?us-ascii?q?DRQIEBgUCFYFZDiSBVjMaCBsVZQGCPz0SGA2fBwM/A2cCBgEHAQEDCYVCigI?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos; i="5.73,390,1583193600"; d="scan'208,217"; a="26181481"
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; 14 May 2020 07:06:15 +0000
Received: from [10.61.174.163] ([10.61.174.163]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04E76EqJ004477 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 May 2020 07:06:15 GMT
From: Eliot Lear 
Message-Id: <90BD470B-9F66-48F8-A151-BA9CE791DC2D@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_14DF0F16-F728-40F2-A6DD-1FFEC2623B1F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 14 May 2020 09:06:14 +0200
In-Reply-To: 
Cc: rfced-future@iab.org
To: Brian E Carpenter 
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.174.163, [10.61.174.163]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 07:06:22 -0000

--Apple-Mail=_14DF0F16-F728-40F2-A6DD-1FFEC2623B1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Brian,

Thanks for putting out the draft.  It has really stimulated =
conversation, a task I prefer to not have to perform ;-).  And thanks to =
all who are participating.

I am trying to keep track of questions raised:

Does the RFC Editor have the authority to refuse to publish based on =
technical concerns?
Does the RFC Editor have the authority to add a note based on technical =
concerns?
Does the RFC Editor have the authority to add a note expressing concern?

The value of these questions is that they do indeed, as Adam wrote, =
explore the scope of authority the RFC Editor has, and they also bring =
into focus the skill set and experience that an RSE should/should not =
require.

John=E2=80=99s point, that these questions have already been settled =
long ago, is valid, but sometimes it is nice to test whether the =
question has a different answer after time as passed (even though very =
little time has passed since RFC 8728).  I see that we have done that =
here, and most of us are drawing the same conclusions.

One additional question that came up:

What should the RFC Editor do when she or he vehemently disagrees with a =
point of view expressed in a draft?

The question of retribution versus accountability has come up, and has =
not been fully explored.

Eliot


--Apple-Mail=_14DF0F16-F728-40F2-A6DD-1FFEC2623B1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Brian,

Thanks for putting out the draft.  It has really =
stimulated conversation, a task I prefer to not have to perform ;-). =
 And thanks to all who are participating.

I am trying to keep track of questions =
raised:

  • Does the RFC Editor have the =
authority to refuse to publish based on technical concerns?
  • Does the RFC Editor have the authority to add a note based on =
technical concerns?
  • Does the RFC Editor have the =
authority to add a note expressing concern?

The value of these questions is =
that they do indeed, as Adam wrote, explore the scope of authority the =
RFC Editor has, and they also bring into focus the skill set and =
experience that an RSE should/should not require.
John=E2=80=99s point, that these =
questions have already been settled long ago, is valid, but sometimes it =
is nice to test whether the question has a different answer after time =
as passed (even though very little time has passed since RFC 8728). =
 I see that we have done that here, and most of us are drawing the =
same conclusions.

One additional question that came up:

  • What should the RFC Editor do when she or he vehemently =
disagrees with a point of view expressed in a draft?

The question of =
retribution versus accountability has come up, and has not been fully =
explored.

Eliot

=

--Apple-Mail=_14DF0F16-F728-40F2-A6DD-1FFEC2623B1F--


From nobody Thu May 14 02:55:51 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE153A088C for ; Thu, 14 May 2020 02:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level: 
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b61y2CANRGWi for ; Thu, 14 May 2020 02:55:45 -0700 (PDT)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 97A183A0889 for ; Thu, 14 May 2020 02:55:42 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.71.33]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 04E9tSv1003753 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2020 02:55:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1589450141; x=1589536541; i=@elandsys.com; bh=CaTr9rdf697pzffWGSYYQUlCO41aq6408H0OP+UwW5Q=; h=Date:To:From:Subject:In-Reply-To:References; b=Wpn0pEMSVoWhjo8T4TD4FeaPvOqzdNHNmNYYBAhbrmnYteskMlk9b6KD8Fd+UBo3s OWYr9DEOKGpn0d3IP7P8fn4OCOfBLQBfegfhY7kULyBdysWZw73vj33HBTDFqWOlZV PyVHLI7SJhhQ3JchngjkFMKjB6N9E0IIskBxg7AQ=
Message-Id: <6.2.5.6.2.20200514015643.0ae6daf0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 14 May 2020 02:55:05 -0700
To: John C Klensin , rfced-future@iab.org
From: S Moonesamy 
In-Reply-To: <48F3E58D4D06C8EAE9D22438@PSB>
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>  <48F3E58D4D06C8EAE9D22438@PSB>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 09:55:49 -0000

Hi John,
At 11:49 PM 13-05-2020, John C Klensin wrote:
>I have just had occasion to read through multiple documents
>trying to find the reference associated with my recollection
>that there was a procedure for the RFC Editor Function to reject
>a document on editorial grounds and for the IESG to say "publish
>anyway, if necessary with a note indicating that the document
>did not meet RFC Series Standards".  I have not been able to
>find it (and may well be suffering from deteriorating memory)
>but, in the process, I did run across a sentence in the fourth
>paragraph of Section 4.3 of RFC 8728 (present in identical, or
>nearly identical form, in RFCs 6635 and 5620).  It reads:

Are you thinking about Section 4.6 of RFC 4846?  There is the 
following sentence: "Such rejection would normally be based on the 
conclusion that the submission does not meet the technical or 
editorial standards of the RFC Series or is not relevant to the areas 
that the series covers".  To keep matters simple, I would say that it 
does not apply to IETF documents.  At some point in IETF history, the 
approach was: "the RFC Editor will fix the draft".  I don't know 
whether to impact on the cost of that decision were duly considered 
or whether there was any formal decision.

There are some past decisions which made sense at that point in 
time.  For example, the concern around the time that RFC 6335 was 
written was to find a RFC Editor.  My guess is that it also 
influenced some of the changes which gained agreement at that 
time.  There was probably some administrative issues as well.

Regards,
S. Moonesamy

    


From nobody Thu May 14 06:38: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 E34443A0AC2 for ; Thu, 14 May 2020 06:38:43 -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 OaVvW29GN-jM for ; Thu, 14 May 2020 06:38:41 -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 E62383A0AC6 for ; Thu, 14 May 2020 06:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=307; q=dns/txt; s=iport; t=1589463515; x=1590673115; h=from:content-transfer-encoding:mime-version:subject: message-id:date:to; bh=LCErGI2VYxunt6zzZaFBrffmN7s4iseS5HZC35CjPNA=; b=JKD+iLbJrbGKlkLJP5BHeeQEHQvUTSbVIEUCHV2wpvxCISm6OxXt/l8+ BMYNJRhsURhTavqs4bVbQlyAnOHCCmU9TtF5qMhbY6KHy0yiW+lxQdup1 cJckaOBuYAq0TMa25f6Jop47EuhWBxy+j5KeMjrnNyvXBhnXxIqGBDJ1x s=;
X-IPAS-Result: =?us-ascii?q?A0AsBwBTSb1e/xbLJq1mHQEBAQEJARIBBQUBQIFHAoMZV?= =?us-ascii?q?AEgEoRRiQGYEYtVCwEBAQwBASMMBAEBhn84EwIDAQEBAwIDAQEBAQUBAQECA?= =?us-ascii?q?QUEbYVWDEIBEAGFR4ELAiYChBgBgnwPonSOEHaBMoVRhQkGgQ4qAYxbggCBO?= =?us-ascii?q?ByCH4NTAQEDgi+CRzOCLQSOegKkAoJXgnGFLJAXHYJMAY1XjSWaC5AUg0UCB?= =?us-ascii?q?AYFAhWBaSKBVjMaCBsVZQGCCgE0PRIYDZlGhUQ/A2cCBgEHAQEDCYVCigIBA?= =?us-ascii?q?Q?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.73,391,1583193600"; d="scan'208";a="23865409"
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; 14 May 2020 13:38:31 +0000
Received: from [10.61.174.163] ([10.61.174.163]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 04EDcTUF022597 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 14 May 2020 13:38:30 GMT
From: Eliot Lear 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <4189F792-C93B-4F37-8CCE-6E14F319377D@cisco.com>
Date: Thu, 14 May 2020 15:38:29 +0200
To: rfced-future@iab.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.174.163, [10.61.174.163]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: [Rfced-future] Program Information now available in datatracker
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 14 May 2020 13:38:48 -0000

As of the latest data tracker release, IAB Programs are now supported.  =
Many thanks to the tooling team and to Cindy for facilitating.

https://datatracker.ietf.org/group/rfcefdp/about/

You will note that I broke it in, by uploading today=E2=80=99s chair=E2=80=
=99s slides.

Regards,

Eliot=


From nobody Thu May 14 07:43: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 6AF3B3A098C for ; Thu, 14 May 2020 07:43:22 -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 TTikCK6Vox0y for ; Thu, 14 May 2020 07:43:19 -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 9D6713A0B1D for ; Thu, 14 May 2020 07:43:19 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jZF4s-0001Mm-2I; Thu, 14 May 2020 10:43:14 -0400
Date: Thu, 14 May 2020 10:43:08 -0400
From: John C Klensin 
To: S Moonesamy , rfced-future@iab.org
Message-ID: <6DE3FCF2C99FC0AABB97C0D2@PSB>
In-Reply-To: <6.2.5.6.2.20200514015643.0ae6daf0@elandnews.com>
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>  <48F3E58D4D06C8EAE9D22438@PSB> <6.2.5.6.2.20200514015643.0ae6daf0@elandnews.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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 14:43:23 -0000

--On Thursday, May 14, 2020 02:55 -0700 S Moonesamy
 wrote:

> Hi John,
> At 11:49 PM 13-05-2020, John C Klensin wrote:
>> I have just had occasion to read through multiple documents
>> trying to find the reference associated with my recollection
>> that there was a procedure for the RFC Editor Function to
>> reject a document on editorial grounds and for the IESG to
>> say "publish anyway, if necessary with a note indicating that
>> the document did not meet RFC Series Standards".  I have not
>> been able to find it (and may well be suffering from
>> deteriorating memory) but, in the process, I did run across a
>> sentence in the fourth paragraph of Section 4.3 of RFC 8728
>> (present in identical, or nearly identical form, in RFCs 6635
>> and 5620).  It reads:
> 
> Are you thinking about Section 4.6 of RFC 4846?  There is the
> following sentence: "Such rejection would normally be based on
> the conclusion that the submission does not meet the technical
> or editorial standards of the RFC Series or is not relevant to
> the areas that the series covers".  To keep matters simple, I
> would say that it does not apply to IETF documents. 

No, I was not.  The concern was strictly about the IETF stream.
In the Independent Stream, evaluation for technical quality is a
major part of the activity.

> At some
> point in IETF history, the approach was: "the RFC Editor will
> fix the draft".  I don't know whether to impact on the cost of
> that decision were duly considered or whether there was any
> formal decision.

"The RFC Editor will fix..." is still the policy.  The questions
are the limits of how good something has to be for the RFC
Editor to fix it and, potentially, the resource requirements if
many documents that require significant work come over the wall.
For the recent discussion, I think that, although other
scenarios could be made up, there are only two realistic
situations of interest (and one of them isn't very realistic).

* An I-D was written by someone with sufficiently poor written
English that the RFC Editor Function couldn't make sense or it
or determine how to edit it into acceptable English and style.
>From a slightly different perspective, such a document would
need translation, not editing, and (at least so far) that has
never been considered an RFC Editor function.  I don't consider
this realistic because I cannot imagine such a document getting
through IETF Last Call and IESG review without the IESG deciding
that the document (and maybe the author) needs help rather than
forwarding it to the RFC Editor.

* A document reaches the RPC that, in their judgment, contains
ambiguous language they cannot determine how to fix.  They
presumably go back to the author and/or IESG and say, very
politely, "what does this mean?  A or B?".  Under any
normal/sane conditions, they get a reply and everyone goes
happily on their way.  If there are many such issues, we would
hope that the IESG would pull the document and send it back to
the WG or author(s).   One would also hope that a document with
such problems, especially a high density of them, would be
caught during Last Call and never reach the RFC Editor in that
form (if it isn't, that would be, IMO, a failure in the review
process).   AFAICT, an issue of the sort we have been talking
about would arise only if the RFC Editor says "these things are
ambiguous or otherwise broken and we cannot edit it unless those
issues are resolved" and the IESG and author(s) respond
"perfectly clear to us, we are not going to change it, just
publish it".  

That raises an issue that probably belongs on our agenda as a
subpart of the "who is accountable to whom topic": RFC 5620 and
6635/8728 contain sections that describe what happens if there
is a disagreement among between one of the streams and the RFC
Editor.  After some discussion that I think can be summarized as
"everyone should behave like adults and get help from other
adults if needed", 5620 pushes thinks onto the RSAG, a body
appointed by the RSE.   6635 changed that to push things to the
RSOC, a body appointed by the IAB.  While it is probably
reasonable to assume that the RSE would appoint people to the
RSAG who have significant technical publications expertise and
other useful substantive (i.e., not purely managerial or general
interest) experience, that is not (as we have seen) a realistic
expectation of the RSOC as now constituted.   So, depending on
what we do in other areas, those sections will likely need to be
rethought.

>...

best,
   john


From nobody Thu May 14 08:59: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 C62483A0B49 for ; Thu, 14 May 2020 08:59: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 J6ZNIAa7Ps_L for ; Thu, 14 May 2020 08:59:06 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5783A0B42 for ; Thu, 14 May 2020 08:59:05 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id 4so3285254qtb.4 for ; Thu, 14 May 2020 08:59:05 -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=7oVV0+Ttu+7htmL7uaAmJ3ZNybIjRKB+uS7ZpT+gWL4=; b=kqV7eSxBYBI9ff5ybfsX8InZetaamc4vVlfo+PQt270x4Uwp+ngkGyuHLLXQogE5UJ rqORtgLKp0hyWvYwAzkZDuMdEDDoTO+rtLj6BB+pb094vAXBtDUwL1Lz52OS9W26dSz5 OiidnaARZYaGJ9Z/P2io1nWqLTPBQkfp/lzs6IevcwcsbAoqwKPR3bkNtY2q3IQ7cmxT y19tR3XepEZ5HfH5lII8sROnc3Owh8pxDvlet4oeRUoi9AF2+PmGbDRlpgchIFg04MzS ztXnopetGElbTkENItewILTPVjkM1k4Yu0NqWB/FBCX4LaBj9Yd2h5II+fJENOz4KIIt 2Usg==
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=7oVV0+Ttu+7htmL7uaAmJ3ZNybIjRKB+uS7ZpT+gWL4=; b=rZFEIw+J/bLM5s+FvTGXLorrqMmP/3cy7l+ufoIhvyF8Us9ujmGcQ87GcwOgFpxAC0 9/lOlhC3F9zij4sVAT5tf7sEjsgeh9pobTZ0xBaKJr4sjrMrKgMfO+aV/YOHO7cwPKjL 8l/vrb7eizPfBUZ6+77CMcnMJPzVBdAvI85Vt22xBPCvKkwi0TuRv+4euiVywXVW6Atk wcIfaiCsNtyUQ9CIpJ2+CURFPBtSfHaZt2KU5lx79OkqY/VjsVN8R+1iAjoMbllO4rxx va4XWbmcIBs3+MgsDKOY5LpyFqFDRFrPoh+T1sL4yQZu00PdGMax9x9ek8THlMW+HCR2 TfDg==
X-Gm-Message-State: AOAM5313Jwe/agnCCbNI/mCK2tQI4KWLAtWIFRnRB0Myqyyy//vQpPv+ KRHXLKHSiPApz5DtF1S79mqIu8tpWx3d2g==
X-Google-Smtp-Source: ABdhPJwFci8/PqUP9/H71/yR4fBG12+6BdUU07gXtwyB1B/0TTCmGTV58l95p5h7pcflICHD7o1+GQ==
X-Received: by 2002:ac8:18a3:: with SMTP id s32mr5225360qtj.102.1589471944222;  Thu, 14 May 2020 08:59:04 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id 23sm2857345qkk.11.2020.05.14.08.59.03 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 May 2020 08:59:03 -0700 (PDT)
To: rfced-future@iab.org
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net> 
From: Michael StJohns 
Message-ID: 
Date: Thu, 14 May 2020 11:59:02 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 15:59:08 -0000

(trimming back to the list)

On 5/14/2020 12:53 AM, Brian E Carpenter wrote:
> Wow, this thread has a life of its own. Below...
> On 14-May-20 14:26, Christian Huitema wrote:
>> On 5/13/2020 6:59 PM, Wes Hardaker wrote:
>>
>>> Michael StJohns  writes:
>>>
>>>> I'm not sure how the above differs from "I can't publish this document at this
>>>> time for the following reasons - please fix it and until you do I can't publish
>>>> it".
>>>>
>>>> Going back to the "independence" thread, an RSE has to be able to say something
>>>> like this without fear of retribution, or with sufficient protections against
>>>> retribution.
>>> Let's say someone is upset about a document being published in a WG.  It
>>> goes through last call(s), and they raise their concerns but are in the
>>> minority (still).  They appeal to the IESG and the appeal is denied.
>>> They appeal to the IAB and the appeal is denied.  They then appeal to
>>> the RSE about their issue, the RSE agrees and refuses to publish it "for
>>> the following reasons" (which came from the objection-er).
>>>
>>> What types of issues is this acceptable under?
>>>
>>> If we opt for entirely-independent, then this is considered acceptable.
>>> If we only allow for non-technical changes, then we are reducing their
>>> independence to only the other elements of publication.  If we prevent
>>> this scenario at all, then is there any independence left?
>>>
>>> Slide your slider somewhere along that line.
>> The RSE refusing publication on editorial grounds is fine, but when it comes to technical issues the RSE is just another individual whose technical opinion has no more precedence than any other member of the community. Giving the RSE power to arbitrage technical issues would just but the placing the RSE on a collision course with the IETF. I don't think that creating more sources of conflict would be productive in any way.
> My feeling after reading the thread is that in such a situation, the RSE should be like any other community member: (s)he can appeal the IESG's decision to publish, and possibly escalate the appeal to the IAB. Whether the grounds for the appeal are technical (pi is actually 22/7) or more general (the lawyer says that we will be sued or prosecuted) is beside the point.

Some folks are using "veto" and that tends to imply prohibition without 
discussion and I don't think that's what I mean.  I'm on board with a 
collaborative approach to fix things, but in the end its possible the 
stream, or author may not want to cooperate.  We ought to be able to 
find a path through, but that's not always easy.

With respect to "refusing publication on editorial grounds..." consider 
the following statement that might appear by accident in an RFC and make 
it all the way through WG and IETF last call:

"... the transmission rate can exceed the speed of light..."

This is obviously not an editorial problem, but it;s ... well ... wrong. 
Obviously, the word should be "cannot".  Under the strictest 
interpretation of "stick with editing", this would not be something the 
RSE nor the RPC could or should address - e.g. it's not editorial in 
nature - it's well structured English on a technical topic.  There are 
probably other examples (and some that have actually happened) - leading 
me to be leery  of circumscribing the RSE authority to "editorial problems".

The general rule in the IETF has been to avoid giving detailed 
instructions for policy things instead count on an ability to derive 
consensus as needed.   My main comment here is that we shouldn't overly 
circumscribe the RSE's editorial role and instead just do as we've been 
doing:  The RSE may refuse to publish as-is and will attempt to resolve 
any discovered issues with the streams, WGs and authors.  We're clear 
that changes in the RFC candidate require author approval and in some 
cases require the WG to weigh in or even the possibility of yet another 
last call.  The problem occurs when you get to an impasse where both 
sides think they're doing the right thing.  Rather than try to set hard 
and fast boundaries, I'd leave intact the notion that the RSE is 
ultimately responsible for the content of the series, and that the 
community may remove an RSE whose view of appropriate content diverges 
from the consensus.

I mostly don't disagree with anything Brian has said here, and I would 
expect technical pushback by the RSE/RPC to use internal channels first, 
(author/WG/AD/IRTF chair/ISE), but I don't think our appeal chains are 
really set up for the type of pushback by the RSE that might be 
necessary; the RSE is not - exactly - a community participant in the way 
the appeal process is laid out.

Ultimately, this is either an job with editorial control or a rubber 
stamping operation - the more constraints on decision making, the less 
this is an editorial job and more of a project management job.  I'd 
rather pick good people, tell them to shepherd and enhance the series, 
give them the mission of the series and all the various documents that 
have been written describing various processes and step back and let 
them do their job, including telling us when we're trying to publish 
something ... lacking ....

Mike



>
> In other words, if there's a conflict, use the existing conflict-resolution mechanism.
>
> But an actual veto on technical content seems to fundamentally break the stream model.
>
> Regards
>     Brian
>


From nobody Thu May 14 09:13: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 D20023A0C7D for ; Thu, 14 May 2020 09:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.27
X-Spam-Level: 
X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C__gdLOZw7rC for ; Thu, 14 May 2020 09:13:32 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC333A0C36 for ; Thu, 14 May 2020 09:13:24 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04EG9YfJ012262; Thu, 14 May 2020 09:13:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=GPMG7ifHNVzieqViNbtnqG4tHGb2hX/q6ANGtQ6CVEE=; b=dvRfbuirmHZOU/jbq+vs4Db2yiUFqg4eECaSHHzub42ymovM5Z8jwCXT6CVYwDvymrn/ Qsg78B4QftmCBUHomnL8cQlD+tkZsVOQL5gyuDmXBKb4KICyoBD9e8cjBNdWN2Ovp07/ fvNFrN7XcwgJKv+H+qZIbL3f7JCToklHRNvfiQyUX1/i5sjNpQGXTajVokCeU4nGY99O pvo1KwaXW8G06Og12UcF7iSynig2jya6L7BEzbGNAXpfm+yzXxESSPFeOKLfTfeT9NH2 q3cK4DuAzJTeuwRB74cvBgl1hzgGnfed9DS1RTmf/j8pLDKdP592NSidPI87A3yrtBqt dg== 
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 3100xcx1k1-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 May 2020 09:13:23 -0700
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QAB00DQLX28P6F0@rn-mailsvcp-mta-lapp01.rno.apple.com>;  Thu, 14 May 2020 09:13:21 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QAB00900WG3Y300@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 14 May 2020 09:13:20 -0700 (PDT)
X-Va-A: 
X-Va-T-CD: 68a6137fce59d516aef5959c13ebaf00
X-Va-E-CD: cc53f8bb3ec6d9be4ff9fd47d77a7389
X-Va-R-CD: e7dcbead7f2d929fd35cea94dfc007cd
X-Va-CD: 0
X-Va-ID: 711c40a8-42bc-4f67-8027-b56901f1f0ef
X-V-A: 
X-V-T-CD: 68a6137fce59d516aef5959c13ebaf00
X-V-E-CD: cc53f8bb3ec6d9be4ff9fd47d77a7389
X-V-R-CD: e7dcbead7f2d929fd35cea94dfc007cd
X-V-CD: 0
X-V-ID: 0a18205f-6625-4354-bef6-1675a5974dc0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-14_05:2020-05-14, 2020-05-14 signatures=0
Received: from [17.234.73.40] (unknown [17.234.73.40]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QAB006LJX258400@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 14 May 2020 09:13:18 -0700 (PDT)
From: Tommy Pauly 
Message-id: 
Content-type: multipart/alternative; boundary="Apple-Mail=_9E28722C-0ACF-4284-A7A2-68F2B7CD8A7E"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
Date: Thu, 14 May 2020 09:13:17 -0700
In-reply-to: 
Cc: rfced-future@iab.org
To: Michael StJohns 
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>  
X-Mailer: Apple Mail (2.3608.80.7.2.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-14_05:2020-05-14, 2020-05-14 signatures=0
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 16:13:42 -0000

--Apple-Mail=_9E28722C-0ACF-4284-A7A2-68F2B7CD8A7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 14, 2020, at 8:59 AM, Michael StJohns  =
wrote:
>=20
> With respect to "refusing publication on editorial grounds..." =
consider the following statement that might appear by accident in an RFC =
and make it all the way through WG and IETF last call:
>=20
> "... the transmission rate can exceed the speed of light..."
>=20
> This is obviously not an editorial problem, but it;s ... well ... =
wrong. Obviously, the word should be "cannot".  Under the strictest =
interpretation of "stick with editing", this would not be something the =
RSE nor the RPC could or should address - e.g. it's not editorial in =
nature - it's well structured English on a technical topic.  There are =
probably other examples (and some that have actually happened) - leading =
me to be leery  of circumscribing the RSE authority to "editorial =
problems=E2=80=9D.

I=E2=80=99d argue that this example is indeed an editorial problem, or =
at least one the RSE would be able to reasonably raise as an editorial =
question. The presumed cause for this error in the document was a typo =
that reviewers glossed over=E2=80=94someone meant to type =E2=80=9Ccannot=E2=
=80=9D and type =E2=80=9Ccan=E2=80=9D. It is perfectly reasonable for =
the editor to, during the process of editing, raise that point to the =
authors and various interested parties. In this example, the typo can be =
corrected. Indeed, I would expect this question to be raised. The stream =
owners are then responsible for clarifying whether a perceived error is =
indeed an editorial error, or was intended.

Tommy=

--Apple-Mail=_9E28722C-0ACF-4284-A7A2-68F2B7CD8A7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On =
May 14, 2020, at 8:59 AM, Michael StJohns <msj@nthpermutation.com> wrote:

With respect to "refusing =
publication on editorial grounds..." consider the following statement =
that might appear by accident in an RFC and make it all the way through =
WG and IETF last call:

"... the transmission rate can exceed the speed of =
light..."

This is =
obviously not an editorial problem, but it;s ... well ... wrong. =
Obviously, the word should be "cannot".  Under the strictest =
interpretation of "stick with editing", this would not be something the =
RSE nor the RPC could or should address - e.g. it's not editorial in =
nature - it's well structured English on a technical topic.  There =
are probably other examples (and some that have actually happened) - =
leading me to be leery  of circumscribing the RSE authority to =
"editorial problems=E2=80=9D.

I=E2=80=99d argue that this example is indeed an =
editorial problem, or at least one the RSE would be able to reasonably =
raise as an editorial question. The presumed cause for this error in the =
document was a typo that reviewers glossed over=E2=80=94someone meant to =
type =E2=80=9Ccannot=E2=80=9D and type =E2=80=9Ccan=E2=80=9D. It is =
perfectly reasonable for the editor to, during the process of editing, =
raise that point to the authors and various interested parties. In this =
example, the typo can be corrected. Indeed, I would expect this question =
to be raised. The stream owners are then responsible for clarifying =
whether a perceived error is indeed an editorial error, or was =
intended.

Tommy
=

--Apple-Mail=_9E28722C-0ACF-4284-A7A2-68F2B7CD8A7E--


From nobody Thu May 14 10:22: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 7A8673A0B66 for ; Thu, 14 May 2020 10:22:50 -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, 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 CoRk83rieR4D for ; Thu, 14 May 2020 10:22:43 -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 C3CED3A0B84 for ; Thu, 14 May 2020 10:22:43 -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.15.2/8.15.2) with ESMTPSA id 04EHMdgC077767 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 12:22:40 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589476961; bh=ENcMoIWbqbYumu5N/Lsy6Tpzo8wdIYEZHfHto63dIW0=; h=Subject:To:References:From:Date:In-Reply-To; b=J0HRNZ/ul5pVJgxJ6Hw3mRsj/zbIA678RTOp8stviVVkW/ygqV5OWpkGudtMB4w9S RFua5/4DxFBo56wtHa8z35SzJWbmbyP5ynEQMTmJZYbMEIAUCNdC9TXrg9013zsaee /DYd5brAzkXmkSZmv2G8az3gAsWgBgcnl3MIE3/c=
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: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>  
From: Adam Roach 
Message-ID: <540f47a6-7f31-52bc-aea8-77d66b0b2a2e@nostrum.com>
Date: Thu, 14 May 2020 12:22:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 17:22:50 -0000

On 5/14/2020 10:59 AM, Michael StJohns wrote:
>
> Some folks are using "veto" and that tends to imply prohibition 
> without discussion and I don't think that's what I mean.


I'm trying to figure out the line you are drawing between "please fix 
this and until you don't I can't publish it" and "veto". At this point, 
I'm baffled.


> I'm on board with a collaborative approach to fix things, but in the 
> end its possible the stream, or author may not want to cooperate. We 
> ought to be able to find a path through, but that's not always easy.


Sure. We definitely need to optimize for success, but also make sure we 
don't have some kind of constitutional crisis when failure arises. In 
the unfortunate case of a complete impasse, who ultimately owns the 
decision about the technical contents of the document?


> With respect to "refusing publication on editorial grounds..." 
> consider the following statement that might appear by accident in an 
> RFC and make it all the way through WG and IETF last call:
>
> "... the transmission rate can exceed the speed of light..."
>
> This is obviously not an editorial problem, but it;s ... well ... 
> wrong. Obviously, the word should be "cannot".  Under the strictest 
> interpretation of "stick with editing", this would not be something 
> the RSE nor the RPC could or should address - e.g. it's not editorial 
> in nature - it's well structured English on a technical topic.  There 
> are probably other examples (and some that have actually happened) - 
> leading me to be leery  of circumscribing the RSE authority to 
> "editorial problems".


You're conflating authority with responsibility [1]. In the case you 
describe, of course the RSE and/or RPC would be responsible for flagging 
the issue to the stream manager and authors. But the ultimate authority 
over the the technical content needs to live in one place so as to 
handle those hopefully rare cases when a conflict arises.


> The general rule in the IETF has been to avoid giving detailed 
> instructions for policy things instead count on an ability to derive 
> consensus as needed.   My main comment here is that we shouldn't 
> overly circumscribe the RSE's editorial role and instead just do as 
> we've been doing:  The RSE may refuse to publish as-is and will 
> attempt to resolve any discovered issues with the streams, WGs and 
> authors.


As before, I'm thoroughly perplexed by the distinction you believe 
you're making between "refuse" and "veto."


> We're clear that changes in the RFC candidate require author approval 
> and in some cases require the WG to weigh in or even the possibility 
> of yet another last call.  The problem occurs when you get to an 
> impasse where both sides think they're doing the right thing.  Rather 
> than try to set hard and fast boundaries, I'd leave intact the notion 
> that the RSE is ultimately responsible for the content of the series, 
> and that the community may remove an RSE whose view of appropriate 
> content diverges from the consensus.


What you're advocating here is a model that explicitly has overlapping 
spheres of authority. In my experience, that works well enough when 
things are going well, and goes catastrophically wrong when they don't.

I agree with what I infer as a major part of what you're saying: there 
is nothing more important in this model than ensuring that the 
relationship between the RSE and the stream managers is collaborative. I 
think where we're diverging is whether having clearly assigned authority 
makes this more likely or less likely.

So, for example, if the RSE decided that they wanted to make a 
transition from the Chicago Manual of Style [2] to the New York Law 
Reports Style Manual, I would expect that one or more stream managers 
would reasonably provide feedback that such a change isn't well suited 
for engineering documents (in fact, going back to the 
responsibility/authority distinction, I would argue that they would have 
a responsibility to do so). But if the RSE remains unconvinced by that 
feedback, the authority needs to reside in exactly one place so that an 
ultimate, legitimate decision can be made.

As long as this delineation of authority is clearly spelled out by the 
community in advance, this kind of disagreement doesn't escalate into a 
tussle that threatens the overall structure. Without clear lines of 
authority, that is exactly what happens every time (at least, in my 
experience).


> Ultimately, this is either an job with editorial control or a rubber 
> stamping operation - the more constraints on decision making, the less 
> this is an editorial job and more of a project management job.  I'd 
> rather pick good people, tell them to shepherd and enhance the series, 
> give them the mission of the series and all the various documents that 
> have been written describing various processes and step back and let 
> them do their job, including telling us when we're trying to publish 
> something ... lacking .... 


Absolutely. I think it's critical that the role have *responsibility* 
for telling the stream managers when they think something in a document 
is wrong. This is not the same thing as having *authority* on the 
technical content of the documents (again, [1]).

/a

____
[1] I'm using these terms in the sense generally used in a 
Responsibility Assignment Matrix.

[2] See RFC 7322, section 1


From nobody Thu May 14 11:23: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 48A8B3A0B0B for ; Thu, 14 May 2020 11:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level: 
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRuI_3NZ7WVu for ; Thu, 14 May 2020 11:23:40 -0700 (PDT)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id C937B3A00C3 for ; Thu, 14 May 2020 11:23:40 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.71.33]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 04EINM6b011202 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2020 11:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1589480615; x=1589567015; i=@elandsys.com; bh=15t0LopnQ+rnX7Ea67yvnHz1xKUY1Hg0tPQCco7UlbU=; h=Date:To:From:Subject:In-Reply-To:References; b=mEvA4KpR2Yk1edird8EzbPi4m99mTposDjZ1RWAciZVsUK/R7mqJu8K8x0TZSKJdE +U1QxIuqsEM4Ry+u/VcYbrRxIzJH4BIfLFNnvQCM8EO2iqmk8B2HA7Yb1ntLvo8LNZ KmBfRp2I/Jw7kyZnZoPvbcUX2jmT4RbeR6ygBkgc=
Message-Id: <6.2.5.6.2.20200514105951.0ad585d0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 14 May 2020 11:23:12 -0700
To: John C Klensin , rfced-future@iab.org
From: S Moonesamy 
In-Reply-To: <6DE3FCF2C99FC0AABB97C0D2@PSB>
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>  <48F3E58D4D06C8EAE9D22438@PSB> <6.2.5.6.2.20200514015643.0ae6daf0@elandnews.com> <6DE3FCF2C99FC0AABB97C0D2@PSB>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 18:23:44 -0000

Hi John,
At 07:43 AM 14-05-2020, John C Klensin wrote:
>No, I was not.  The concern was strictly about the IETF stream.
>In the Independent Stream, evaluation for technical quality is a
>major part of the activity.

I don't recall reading anything related to that.  However, you have 
been around longer than I have.

>"The RFC Editor will fix..." is still the policy.  The questions
>are the limits of how good something has to be for the RFC
>Editor to fix it and, potentially, the resource requirements if
>many documents that require significant work come over the wall.
>For the recent discussion, I think that, although other
>scenarios could be made up, there are only two realistic
>situations of interest (and one of them isn't very realistic).
>
>* An I-D was written by someone with sufficiently poor written
>English that the RFC Editor Function couldn't make sense or it
>or determine how to edit it into acceptable English and style.
> >From a slightly different perspective, such a document would
>need translation, not editing, and (at least so far) that has
>never been considered an RFC Editor function.  I don't consider
>this realistic because I cannot imagine such a document getting
>through IETF Last Call and IESG review without the IESG deciding
>that the document (and maybe the author) needs help rather than
>forwarding it to the RFC Editor.

I haven't been following the IETF that closely as I had to focus on 
other problems.  I haven't seen the above case arising in the IETF Stream.

>* A document reaches the RPC that, in their judgment, contains
>ambiguous language they cannot determine how to fix.  They
>presumably go back to the author and/or IESG and say, very
>politely, "what does this mean?  A or B?".  Under any
>normal/sane conditions, they get a reply and everyone goes
>happily on their way.  If there are many such issues, we would
>hope that the IESG would pull the document and send it back to
>the WG or author(s).   One would also hope that a document with
>such problems, especially a high density of them, would be
>caught during Last Call and never reach the RFC Editor in that
>form (if it isn't, that would be, IMO, a failure in the review
>process).   AFAICT, an issue of the sort we have been talking
>about would arise only if the RFC Editor says "these things are
>ambiguous or otherwise broken and we cannot edit it unless those
>issues are resolved" and the IESG and author(s) respond
>"perfectly clear to us, we are not going to change it, just
>publish it".

The above could arise.  My short experience of the RPC is that they 
sometimes ask very good questions.  If I am not mistaken, the 
practice in the IETF is to have an Area Director review before an 
Internet-Draft reaches Last Call.  It is useful to distinguish 
between the authors and the audience.  If everything approved by the 
IESG and the author were perfectly clear, there would not be a need 
to review any erratum.

>That raises an issue that probably belongs on our agenda as a
>subpart of the "who is accountable to whom topic": RFC 5620 and
>6635/8728 contain sections that describe what happens if there
>is a disagreement among between one of the streams and the RFC
>Editor.  After some discussion that I think can be summarized as

Yes, I spotted that yesterday.

>"everyone should behave like adults and get help from other
>adults if needed", 5620 pushes thinks onto the RSAG, a body
>appointed by the RSE.   6635 changed that to push things to the
>RSOC, a body appointed by the IAB.  While it is probably
>reasonable to assume that the RSE would appoint people to the
>RSAG who have significant technical publications expertise and
>other useful substantive (i.e., not purely managerial or general
>interest) experience, that is not (as we have seen) a realistic
>expectation of the RSOC as now constituted.   So, depending on
>what we do in other areas, those sections will likely need to be
>rethought.

I recently commented about the RSOC: 
https://mailarchive.ietf.org/arch/msg/rfced-future/YnM22Y1kJ3xAYmifZlolwSwtM8s/

Regards,
S. Moonesamy 


From nobody Thu May 14 12:08: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 50CBA3A074B for ; Thu, 14 May 2020 12:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=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 mfIaPlTauu1b for ; Thu, 14 May 2020 12:08:32 -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 1C5193A0844 for ; Thu, 14 May 2020 12:08:32 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jZJDY-00026o-Pm; Thu, 14 May 2020 15:08:28 -0400
Date: Thu, 14 May 2020 15:08:22 -0400
From: John C Klensin 
To: Tommy Pauly , Michael StJohns 
cc: rfced-future@iab.org
Message-ID: <1E256A4B9BDC8328CEDFE50F@PSB>
In-Reply-To: 
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 19:08:33 -0000

--On Thursday, May 14, 2020 09:13 -0700 Tommy Pauly
 wrote:

>=20
>> On May 14, 2020, at 8:59 AM, Michael StJohns
>>  wrote:
>>=20
>> With respect to "refusing publication on editorial
>> grounds..." consider the following statement that might
>> appear by accident in an RFC and make it all the way through
>> WG and IETF last call:
>>=20
>> "... the transmission rate can exceed the speed of light..."
>>=20
>> This is obviously not an editorial problem, but it;s ... well
>> ... wrong. Obviously, the word should be "cannot".  Under the
>> strictest interpretation of "stick with editing", this would
>> not be something the RSE nor the RPC could or should address
>> - e.g. it's not editorial in nature - it's well structured
>> English on a technical topic.  There are probably other
>> examples (and some that have actually happened) - leading me
>> to be leery  of circumscribing the RSE authority to
>> "editorial problems".
>=20
> I'd argue that this example is indeed an editorial problem,
> or at least one the RSE would be able to reasonably raise as
> an editorial question. The presumed cause for this error in
> the document was a typo that reviewers glossed =
over=E2=80=94someone
> meant to type "cannot" and type "can". It is perfectly
> reasonable for the editor to, during the process of editing,
> raise that point to the authors and various interested
> parties.

Yes.  =20
TL;DR Summary (skipping a lot of historical context): The
example actually isn't interesting.  Ain't broke, don't fix it.
There is a family of related examples that do raise interesting
questions (see last part of message).

   -------------

So, let's assume for a moment that we were starting from scratch
and didn't have fifty years of history with the RFC Series.
Almost any reasonable editorial process for the last few hundred
years would deal with a situation like this either by the editor
going to the author (or approving body) while the document is
being worked on and say "hey, this looks like it should have
been "cannot" to me, is that right" or having some sort of final
pre-publication review process in which the author gets to check
either the editor's markup, final prepublication proofs (aka
galley proofs for some technologies), or all three. =20

Once upon a time, the RFC Editor process didn't have that
author-approval loop.  Documents would go to Jon and Joyce and
they would either edit as they thought necessary, assign
numbers, and publish or hand the draft back to the authors with
instructions to do more work.  With the first option, when they
were not very confident about the fixes, they went back to
authors with questions, but it was rare for authors to actually
see final text before publication.  Any experienced technical
(or, in this case, even non-technical) editor or publisher
probably could have told them that, eventually, they would make
an incorrect or otherwise unwanted change and it would lead to
aggravation.  However, for one reason or another (one of which
is that they did a superb job, much better than the community
had any right to expect), that worked for years.  Eventually an
unwanted and erroneous change was made and that led directly to
what we now call AUTH48.  =20

For the information of those who haven't written RFCs in the
last two decades and a refresher for those who have, at that
point, authors (and now for IETF Stream documents, WG Chairs,
document shepherds, and responsible ADs) have an opportunity to
review the near-final document to be sure the editing process
did not produce any unwanted changes, especially ones that would
change the meaning of anything technical.  At least in my
experience and understanding (if people from the RPC are
watching this discussion, I'd appreciate it if they stepped in
and shared their wider experience), authors generally take that
review obligation very seriously so, for Mike's example, if "can
exceed" were really intended, it would presumably be caught and
negotiated.  And, fwiw, I am not aware of any instances, in my
documents or those of others (going back to well before the turn
of the century) in which, if the author said "that change in not
correct technically" the result would not have been a discussion
and effort to agree on the right text, never a fight between the
RFC Editor and the author about who was correct. =20

So, unless we feel like we have to overturn established ways of
doing things, not because there is a problem, but because we
can, I don't see the problem, at least with Mike's example.

We do have a new issue in the last year (closely connected to
the canonical vs. archival discussion), which is whether the
AUTH48 review should be about the HTML, the text, or the PDF.
One position is that authors (and other AUTH48 reviewers) should
examine and sign off on all three.  That is not only burdensome,
but violates the basic principle that authors normally do not
have expertise in presentation and layout issues and they
effectively putting them in charge of such things is basically a
waste of everyone's time and about as sensible as putting a good
technical editor with no background in network engineering in
charge of new routing protocols.  And, if those presentation
forms are mutable, then there is some question about what is
being reviewed.  However, if we cannot get an RSE (or, noting
Mark's comments, an RSE team) in place (and in place quickly
enough that we don't find ourselves with bed precedents that
cannot plausibly be undone) that can address and resolve those
sorts of issues, we are probably wasting our time in this =
effort.

Coming back to the example, while I would hope that any editor
with a secondary school education would spot and question "can
exceed the speed of light", I don't know what our expectations
should be about, e.g., "using this protocol, there will be no
problem with real-time two-way video communications between
earth and a moon base".  The issue about the speed of light is
ultimately the same, but whether "no" belongs in that sentence
(and hence whether it is an editorial issue) raises the bar,
perhaps significantly, about the amount of technical knowledge
we expect the RFC Editor team to have and apply... even though I
think it is an obvious editorial error and you and Mike probably
do too.

best,
   john


From nobody Thu May 14 12:56:59 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B98C3A0CA9 for ; Thu, 14 May 2020 12:56:57 -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=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 NFSrFLNCQfvb for ; Thu, 14 May 2020 12:56:55 -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 48D573A0CB2 for ; Thu, 14 May 2020 12:56:55 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jZJyO-0002Cw-8E; Thu, 14 May 2020 15:56:52 -0400
Date: Thu, 14 May 2020 15:56:46 -0400
From: John C Klensin 
To: Eliot Lear , Brian E Carpenter 
cc: rfced-future@iab.org
Message-ID: <79EAE6492A175A79D989814A@PSB>
In-Reply-To: <90BD470B-9F66-48F8-A151-BA9CE791DC2D@cisco.com>
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>  <90BD470B-9F66-48F8-A151-BA9CE791DC2D@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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 19:56:57 -0000

--On Thursday, May 14, 2020 09:06 +0200 Eliot Lear
 wrote:

> Brian,
> 
> Thanks for putting out the draft.  It has really stimulated
> conversation, a task I prefer to not have to perform ;-).  And
> thanks to all who are participating.
> 
> I am trying to keep track of questions raised:
> 
> Does the RFC Editor have the authority to refuse to publish
> based on technical concerns? Does the RFC Editor have the
> authority to add a note based on technical concerns? Does the
> RFC Editor have the authority to add a note expressing concern?
> 
> The value of these questions is that they do indeed, as Adam
> wrote, explore the scope of authority the RFC Editor has, and
> they also bring into focus the skill set and experience that
> an RSE should/should not require.
> 
> John's point, that these questions have already been settled
> long ago, is valid, but sometimes it is nice to test whether
> the question has a different answer after time as passed (even
> though very little time has passed since RFC 8728).  I see
> that we have done that here, and most of us are drawing the
> same conclusions.

First, hard to blame anything on RFC 8728, since it, as far as I
can tell and remember from IASA2 WG discussions, changed almost
nothing other than what was needed for IASA-> IASA2/LLC
transitions.  If you attribute most of those "settled" issues to
RFC 6635, we've got a good eight years of experience.

Curiously, as far as I know, the "push things all the way to the
RSAG" (from RFC 5620) and "push things all the way to the RSOC"
(from RFC 6635) have, as far as I know, never actually been used
and tested, putting questions about how well they would work and
whether they are what we want into the same general category as
reexamining the Recall procedure. 

On the other hand as I hope was clear from my more recent notes,
the AUTH48 procedure for reviewing changes has been extensively
tested for decades and, while I (and, I assume, others) could
suggest ways to tune it, it has worked well enough that I can't
imagine it --and whether it is an adequate solution to the
issues that have been raised-- is a good use of this group's
high-priority time at this particular stage (although whether
the details of how it works are an RSE responsibility or not
might be).

> One additional question that came up:
> 
> What should the RFC Editor do when she or he vehemently
> disagrees with a point of view expressed in a draft?

FWIW, I agree with those who think the appeals mechanism is (at
least) a good first answer.   Then there is the question of the
RSAG and then RSOC mechanisms proposed in the RFC Editor Model
docs are what we want.  And that goes, I think, directly to...
 
> The question of retribution versus accountability has come up,
> and has not been fully explored.

Indeed.  But, again just IMO, aspects of that question may be
part of what got us here... and part of why several people have
suggested that the direct management of the RSE (and RFC Editor
Function more generally) by assorted I* groups is a bad idea.

   john


From nobody Thu May 14 12:58:55 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888BC3A0BED for ; Thu, 14 May 2020 12:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.279
X-Spam-Level: 
X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, 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 q0Luo7kJa6CE for ; Thu, 14 May 2020 12:58:52 -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 77CCC3A0C95 for ; Thu, 14 May 2020 12:58:52 -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.15.2/8.15.2) with ESMTPSA id 04EJwndS008715 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 14:58:50 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589486331; bh=TL6BY4RZbOwaelg7kkq2KBGIwV1p/MIkjMTZw4ZcDn4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=NkWz4RtkbJh3Yj2QT8bR2QNIpRo1WbC0zGzPzjfao6Gtx7WAVAvIPShYrtw6FmoF5 p7cBfCwUWEM0yDf9+ytbe7IXyL7f1+sQ8Q+oZ4Y3QWIgLz1SOWfUpYAl9Wk8Eaqw76 foJfwmM+JuUkX1ZFeYIOWcJ3rwEo6iiUWPzMHpFk=
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 , Tommy Pauly , Michael StJohns 
Cc: rfced-future@iab.org
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>    <1E256A4B9BDC8328CEDFE50F@PSB>
From: Adam Roach 
Message-ID: <8b82bcba-6003-e67d-521e-68d874584c51@nostrum.com>
Date: Thu, 14 May 2020 14:58:43 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <1E256A4B9BDC8328CEDFE50F@PSB>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 19:58:54 -0000

On 5/14/2020 2:08 PM, John C Klensin wrote:
> Coming back to the example, while I would hope that any editor
> with a secondary school education would spot and question "can
> exceed the speed of light", I don't know what our expectations
> should be about, e.g., "using this protocol, there will be no
> problem with real-time two-way video communications between
> earth and a moon base".  The issue about the speed of light is
> ultimately the same, but whether "no" belongs in that sentence
> (and hence whether it is an editorial issue) raises the bar,
> perhaps significantly, about the amount of technical knowledge
> we expect the RFC Editor team to have and apply... even though I
> think it is an obvious editorial error and you and Mike probably
> do too.


Right. I think the problem is that we're spending a lot of time talking 
about situations where the prospect of an actual conflict is basically 
zero (pi=3, 8-bit IP addresses, and violations of special relativity).

The lack of plausible conflict makes these examples far less than 
illustrative of any real principles.

What we need to explore is: when a plausible and potentially intractable 
conflict arises (e.g., the actual real-world Ethernet-MIB variable 
changes that Elliot cited elsewhere, or the theoretical but plausible 
TLS 1.3 example that I gave up-thread), what does the community expect 
should happen?

/a


From nobody Thu May 14 13:48: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 5E8563A08DC for ; Thu, 14 May 2020 13:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WdPr8RkzjLS for ; Thu, 14 May 2020 13:48:09 -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 13C1E3A08D3 for ; Thu, 14 May 2020 13:48:09 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jZKly-0002UX-P7; Thu, 14 May 2020 16:48:06 -0400
Date: Thu, 14 May 2020 16:48:00 -0400
From: John C Klensin 
To: Adam Roach 
cc: rfced-future@iab.org
Message-ID: <04FA4F5354E5D6EA839E1088@PSB>
In-Reply-To: <8b82bcba-6003-e67d-521e-68d874584c51@nostrum.com>
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>    <1E256A4B9BDC8328CEDFE50F@PSB> <8b82bcba-6003-e67d-521e-68d874584c51@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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 20:48:11 -0000

--On Thursday, May 14, 2020 14:58 -0500 Adam Roach
 wrote:

> Right. I think the problem is that we're spending a lot of
> time talking about situations where the prospect of an actual
> conflict is basically zero (pi=3, 8-bit IP addresses, and
> violations of special relativity).
> 
> The lack of plausible conflict makes these examples far less
> than illustrative of any real principles.
> 
> What we need to explore is: when a plausible and potentially
> intractable conflict arises (e.g., the actual real-world
> Ethernet-MIB variable changes that Elliot cited elsewhere, or
> the theoretical but plausible TLS 1.3 example that I gave
> up-thread), what does the community expect should happen?

Adam,

Let me refine that a bit further, coming back to your "basically
zero" likelihood conditions.   My expectation, and I assume the
community's, is that such problems would be caught during IETF
Last Call or, at worst, during IESG review and would never reach
the RFC Editor [1].  If documents containing those sorts of
errors reach the RFC Editor, that is already a process failure.
Indeed, I think that, if such documents reach the IESG without
the issues being observed during IETF Last Call, _that_ is a
process failure relative to the assumptions made when RFC 2026
was written.  Do we expect the RFC Editor to catch such things
and, if they do, is there are realistic possibility of the
authors and IESG pushing back on proposed changes or ignoring
questions?  I hope not.  And, if no one at all catches them, who
is to blame?  (I suggest maybe the IESG and assorted reviewers,
shepherds, etc., but not the RFC Editor.)

That is the sense in which Mike's example is more realistic: it
is not hard to imagine "not" being accidentally omitted (or
inserted) and the eyes of everyone in the in-stream review
process being sufficiently glazed over to not catch it.  But
that is an even more clear case in which the normal process (at
AUTH48 or earlier) might be expected to catch the problem with a
vanishingly small possibility of someone pushing back on the fix.

    john

[1] The number of real or imaginary problems caught during IESG
review that don't turn up during IETF LC and questions about how
they should be handled are probably more important, and more of
a threat to serious claims of IETF Consensus for a document,
than this discussion about RFC Editor detection of problems and
conflicts over them but, fortunately, are not part of this
Program's discussion and, in hope, not in its critical path.


From nobody Thu May 14 13:53: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 8A2523A0D1F for ; Thu, 14 May 2020 13:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9GeTzZBfsw2 for ; Thu, 14 May 2020 13:53:16 -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 2A86C3A08D3 for ; Thu, 14 May 2020 13:53:15 -0700 (PDT)
Received: from client-pool2-383.vpn.uni-bremen.de (client-pool2-383.vpn.uni-bremen.de [134.102.49.127]) (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 49NNzZ0xDSzyWt; Thu, 14 May 2020 22:53:14 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: <04FA4F5354E5D6EA839E1088@PSB>
Date: Thu, 14 May 2020 22:53:14 +0200
X-Mao-Original-Outgoing-Id: 611182393.9921089-d9e67fe2948fc558aefebaae429adf90
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C2839F4-24E4-4890-8A0C-9388EE72E02F@tzi.org>
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>    <1E256A4B9BDC8328CEDFE50F@PSB> <8b82bcba-6003-e67d-521e-68d874584c51@nostrum.com> <04FA4F5354E5D6EA839E1088@PSB>
To: rfced-future@iab.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 20:53:19 -0000

On 2020-05-14, at 22:48, John C Klensin  wrote:
>=20
> =E2=80=9Cbasically zero=E2=80=9D likelihood

Brian's draft has a security considerations section.
Let me add one security consideration.

We make contracts to handle certain unlikely events.
And, actually more importantly, to make those events unlikely.

The assumption here seems to be that all actors act in good faith (even =
if, maybe, somewhat ignorant or misinformed).

But what about truly nefarious situations?
An actor turns bankrupt (or the company where they have their day job =
does), and the administration starts to make unreasonable demands?
What if the RSE=E2=80=99s husband is captured by a rogue country?

This all may seem unlikely, but the point of setting up relationships =
right is that these events *stay* unlikely, by limiting the bounty that =
can be had from acting nefariously.

Investing authority in someone/some entity (called =E2=80=9Ctrust=E2=80=9D=
 in some security circles) also is a liability:
It makes that someone/entity a potentially rewarding and thus =
interesting target of an attack.

Another reason checks and balances are good.

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


From nobody Thu May 14 13:56: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 5236C3A0D2A for ; Thu, 14 May 2020 13:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjz5Ykx0qObL for ; Thu, 14 May 2020 13:56:38 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB063A0D29 for ; Thu, 14 May 2020 13:56:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=9pATSOoPDQKTWRCsvSK8wzaZXSSnI8U8l/5rFEWzXg8=; b=oNSKqvbktuUcTid0xH+Ocka7dK L0FApi9QcpQrxV6pGC2PVcmQw2MZzZEB6ElGkevXK0pXbr07iYoWBvgO5kil5x9l7/awS6knaLKOw y7XkG32OIrAWLIIKyWRPrO2xn7F6SiBH3e33qYKB5TBpT7zkDc/xZGko9D3vB6rUY0I8EvATsnRfm usOWaGFzLaMzzTT9xyQHRKsYOfpSsgFtDlTyV7Lwzv/FOYK3+r6990qGcVD2MvWiJTEOKHrZfRMub NYVKAt+yqjH3QCJQuQ/4TQQdrKnMSISgEbgtdEUo5Oh+B4Ab0/sV/ze/tFYNTCkqE9DBJ9y2i2s+E 8mFWFd7A==;
Received: from [81.187.2.149] (port=41238 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jZKuB-0000up-OP; Thu, 14 May 2020 21:56:36 +0100
From: Colin Perkins 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_1164FDBB-E4A6-40A5-AE25-04CA03CB5B5F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Thu, 14 May 2020 21:56:32 +0100
In-Reply-To: <77479725-3b0c-8a5f-d15d-aee54abdae7d@nostrum.com>
Cc: rfced-future@iab.org
To: Adam Roach 
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <1adc5fe7-deb1-4aa6-5159-71ea4adfed57@gmail.com>  <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie>  <023601d6285d$587bdb70$09739250$@olddog.co.uk>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com> <77479725-3b0c-8a5f-d15d-aee54abdae7d@nostrum.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 14
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 20:56:41 -0000

--Apple-Mail=_1164FDBB-E4A6-40A5-AE25-04CA03CB5B5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

[Catching up on the discussion]

> On 12 May 2020, at 22:30, Adam Roach  wrote:
>=20
> On 5/12/2020 3:25 PM, Michael StJohns wrote:
>> On 5/12/2020 4:16 PM, Eric Rescorla wrote:
>>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns =
> wrote:
>>> > Mark (in another email) is correct that the level of independence =
of the
>>> > current RSE is not the same as in the past - but I consider that a =
bug
>>> > rather than a feature as it means that its possible for a small =
subset
>>> > of the IETF community to affect the culture of the RFC series in =
ways
>>> > that may not represent the interests of the broader community.
>>>=20
>>> I want to zero in on this point, because I think it's useful to =
scope
>>> out people's views of "independence".
>>>=20
>>> Let me try to start with what's hopefully a simple case: suppose
>>> that the IETF produces and the IESG approves a document to be
>>> published as RFC that the RSE believes is harmful to the Internet
>>> for technical reasons (it redefines IPv6 to have an 8 bit address,
>>> say). Do you believe that the RSE should be able to refuse to
>>> publish such a document?
>>>=20
>>> -Ekr=20
>> Oooh   tricky.   I'd either have the RSE refer it to the ISE as =
publication as an April Fool's RFC, or I'd probably be the first to sign =
on to a petition to recall the entire IESG.     In any case, the answer =
is probably yes, the RSE should refuse to publish the document as an =
Internet standard.   That assumes that the RSE - with the appropriate =
technical advisors - has the skillset to determine said document is =
"harmful to the Internet".
>>=20
>=20
> I think we can appreciate that the example was chosen to be =
fantastical so as to not focus discussion on the technical matter as =
much as the degree of control the RSE is afforded over the technical =
contents of a document.
>=20
> Now, I do recall a recent anecdote about Postel himself heatedly =
refusing to publish a specification he felt was technically misguided =
[1], so this authority did exist with the position at some point. =
Although never explicitly revoked, RFC 4844, section 4.1 et seq makes it =
pretty clear that the RSE has approval authority over precisely one =
stream (the Independent Submission stream). To the extent that the IAB =
had authority to publish RFC 4844, I think it makes it clear that the =
scope of authority had been pared back substantially since the "I am not =
going to publish a faulty specification as an RFC" days of 1991.
>=20
> I'm not entirely sure my analysis above is all that useful, though, as =
this is the "rfced-future" discussion rather than the "rfced-history" =
discussion, and so it seems more sensible to focus on meeting the needs =
of the Internet community in 2020 and beyond than is is to lean on the =
historical narrative.
>=20
> And so more to the point: I think that the IETF community writ large =
would be floored if a working group produced a document, the IETF found =
consensus on it during last call, the IESG approved it, and then the RSE =
refused to publish it (or imposed technical changes on its contents). =
Ditto for the IRTF and their documents. So, if we're matching authority =
with community expectations -- at least for a large swath of the =
relevant community -- I think the answer above of "the RSE should refuse =
to publish the document" is exactly wrong.
>=20

I agree =E2=80=93 provided the correct process has been followed by a =
stream, and once any cross-stream conflict reviews, appeals, etc., have =
concluded, the RSE shouldn=E2=80=99t be able to refuse to publish a =
document.=20

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





--Apple-Mail=_1164FDBB-E4A6-40A5-AE25-04CA03CB5B5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

[Catching up on the discussion]

On 12 =
May 2020, at 22:30, Adam Roach <adam@nostrum.com> wrote:


 =20
    
 =20
  

    
On 5/12/2020 3:25 PM, Michael StJohns
      wrote:

    

    

      
      
On 5/12/2020 4:16 PM, Eric Rescorla
        wrote:

      

      

        
        
In Tue, May 12, 2020 at 10:55 AM =
Michael StJohns
          <msj@nthpermutation.com> =
wrote:

          

            
> Mark (in another email) is correct that =
the level
              of independence of the

              > current RSE is not the same as in the past - but I
              consider that a bug

              > rather than a feature as it means that its possible
              for a small subset

              > of the IETF community to affect the culture of the
              RFC series in ways

              > that may not represent the interests of the broader
              community.

              

              I want to zero in on this point, because I think it's
              useful to scope

              out people's views of "independence".

              

              Let me try to start with what's hopefully a simple case:
              suppose

              that the IETF produces and the IESG approves a document to
              be

              published as RFC that the RSE believes is harmful to the
              Internet

              for technical reasons (it redefines IPv6 to have an 8 bit
              address,

              say). Do you believe that the RSE should be able to refuse
              to

              publish such a document?

              

              -Ekr 

            

          

        

      
Oooh   tricky.   =
I'd either have the RSE refer it to the ISE as
        publication as an April Fool's RFC, or I'd probably be the first
        to sign on to a petition to recall the entire =
IESG.     In any
        case, the answer is probably yes, the RSE should refuse to
        publish the document as an Internet standard.   That =
assumes
        that the RSE - with the appropriate technical advisors - has the
        skillset to determine said document is "harmful to the
        Internet".

    


    
I think we can appreciate that the example was =
chosen to be
      fantastical so as to not focus discussion on the technical matter
      as much as the degree of control the RSE is afforded over the
      technical contents of a document.
Now, I do =
recall a recent anecdote about Postel himself heatedly
      refusing to publish a specification he felt was technically
      misguided [1], so this authority did exist with the position at
      some point. Although never explicitly revoked, RFC 4844, section
      4.1 et seq makes it pretty clear that the RSE has approval
      authority over precisely one stream (the Independent Submission
      stream). To the extent that the IAB had authority to publish RFC
      4844, I think it makes it clear that the scope of authority had
      been pared back substantially since the "I am not going to publish
      a faulty specification as an RFC" days of 1991.
I'm=
 not entirely sure my analysis above is all that useful,
      though, as this is the "rfced-future" discussion rather than the
      "rfced-history" discussion, and so it seems more sensible to focus
      on meeting the needs of the Internet community in 2020 and beyond
      than is is to lean on the historical narrative.

    
And so more to the point: I think that the IETF =
community writ
      large would be floored if a working group produced a document, the
      IETF found consensus on it during last call, the IESG approved it,
      and then the RSE refused to publish it (or imposed technical
      changes on its contents). Ditto for the IRTF and their documents.
      So, if we're matching authority with community expectations -- at
      least for a large swath of the relevant community -- I think the
      answer above of "the RSE should refuse to publish the document" is
      exactly wrong.

I agree =E2=80=93 provided the correct process has been followed by a =
stream, and once any cross-stream conflict reviews, appeals, etc., have =
concluded, the RSE shouldn=E2=80=99t be able to refuse to publish a =
document. 

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








=

--Apple-Mail=_1164FDBB-E4A6-40A5-AE25-04CA03CB5B5F--


From nobody Thu May 14 13:59: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 C3A133A0D36 for ; Thu, 14 May 2020 13:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgPycwl5rNoY for ; Thu, 14 May 2020 13:59:33 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915363A0D2D for ; Thu, 14 May 2020 13:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=V5hprjr0gfO27hU3LwILO5DHjeqLV66DLoPp/NdTis0=; b=0GRyBmpRvUy/LLenPaAG3p2IRS 9VgGdCQNv+6PJkUGV4+RIVSL2g5G5oPozqiq3bkRPwzD5WVrvVCR6T0hb586DQEQAMtrTDEM8X/YM 2VermL7wKq539pCsdMH4q3nnLHuX0Nh45+nC4MiT7tcqY6+yASC2eZzusHd7i5bosJmiCU5vVbS9c VLXxnivef6CIH9jL3Dtldas7ULd6zCXBIjLR1vAYkQK3Qh8O088dIEW9ifjQg52wYwA1aKVPxwA+T yUyomNM5ujQyXlGyJfIPObMWycAxPtgYW/gnakCmwltOmVIREFF1545aYXewNZpfMRYgI3S8+8Sl6 JHQOJU7g==;
Received: from [81.187.2.149] (port=48270 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jZKwx-0001Jg-CS; Thu, 14 May 2020 21:59:27 +0100
From: Colin Perkins 
Message-Id: <2E652F7D-B451-4C36-A8B8-559A93FDF457@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4A874526-9EC3-4AF2-8D3E-DA092E6F0B01"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Thu, 14 May 2020 21:59:23 +0100
In-Reply-To: <52c04df7-a629-6109-5e71-ce7e2a68720f@nostrum.com>
Cc: Ben Campbell , "Joel M. Halpern" , rfced-future@iab.org
To: Adam Roach 
References:   <52c04df7-a629-6109-5e71-ce7e2a68720f@nostrum.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 14
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 20:59:38 -0000

--Apple-Mail=_4A874526-9EC3-4AF2-8D3E-DA092E6F0B01
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes, certainly =E2=80=93 but should the stream manager eventually be =
able to overrule the RSE and say =E2=80=9Cpublish it, the editorial =
quality is good enough=E2=80=9D?

Colin




> On 12 May 2020, at 23:15, Adam Roach  wrote:
>=20
> Right. I apologize if it was unclear that I was speaking strictly =
about the technical contents of a document. Personally, I'd be happy if =
the RSE/RPC were more liberal about sending things back as too poorly =
written to economically edit.
>=20
> /a
>=20
> On 5/12/2020 5:05 PM, Ben Campbell wrote:
>> I was mentally composing a reply to the effect of =E2=80=9CThe RSE =
should not be able to veto an IETF stream document approved through =
normal procedures on technical grounds, but could conceivably need to do =
so on editorial grounds.=E2=80=9D  But Joel beat me to it.
>>=20
>> Ben.
>>=20
>>> On May 12, 2020, at 4:57 PM, Joel M. Halpern  =
wrote:
>>>=20
>>> =EF=BB=BFCan we step this down?
>>>=20
>>> On the one hand, no, I do not think the RSE should have the =
authority to tell the IESG that the IETF can not publish particular =
technical content on technical grounds.
>>> On the other hand, if a technically competent RSE is that concerned =
about a document, I think we probably have a whole lot of other problems =
that need to be addressed.  Whether the RSE actually publishes that =
document or not is probably the least of our worries.
>>>=20
>>> And I do think the RSE should have the authority to say to any =
stream "turn this into proper English before the RPC will process it."
>>>=20
>>> Yours,
>>> Joel
>>>=20
>>>> On 5/12/2020 5:30 PM, Adam Roach wrote:
>>>>> On 5/12/2020 3:25 PM, Michael StJohns wrote:
>>>>> On 5/12/2020 4:16 PM, Eric Rescorla wrote:
>>>>>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns =
> wrote:
>>>>>>> Mark (in another email) is correct that the level of =
independence of the
>>>>>>> current RSE is not the same as in the past - but I consider that =
a bug
>>>>>>> rather than a feature as it means that its possible for a small =
subset
>>>>>>> of the IETF community to affect the culture of the RFC series in =
ways
>>>>>>> that may not represent the interests of the broader community.
>>>>>> I want to zero in on this point, because I think it's useful to =
scope
>>>>>> out people's views of "independence".
>>>>>>=20
>>>>>> Let me try to start with what's hopefully a simple case: suppose
>>>>>> that the IETF produces and the IESG approves a document to be
>>>>>> published as RFC that the RSE believes is harmful to the Internet
>>>>>> for technical reasons (it redefines IPv6 to have an 8 bit =
address,
>>>>>> say). Do you believe that the RSE should be able to refuse to
>>>>>> publish such a document?
>>>>>>=20
>>>>>> -Ekr
>>>>> Oooh   tricky.   I'd either have the RSE refer it to the ISE as =
publication as an April Fool's RFC, or I'd probably be the first to sign =
on to a petition to recall the entire IESG.     In any case, the answer =
is probably yes, the RSE should refuse to publish the document as an =
Internet standard.   That assumes that the RSE - with the appropriate =
technical advisors - has the skillset to determine said document is =
"harmful to the Internet".
>>>>>=20
>>>> I think we can appreciate that the example was chosen to be =
fantastical so as to not focus discussion on the technical matter as =
much as the degree of control the RSE is afforded over the technical =
contents of a document.
>>>> Now, I do recall a recent anecdote about Postel himself heatedly =
refusing to publish a specification he felt was technically misguided =
[1], so this authority did exist with the position at some point. =
Although never explicitly revoked, RFC 4844, section 4.1 et seq makes it =
pretty clear that the RSE has approval authority over precisely one =
stream (the Independent Submission stream). To the extent that the IAB =
had authority to publish RFC 4844, I think it makes it clear that the =
scope of authority had been pared back substantially since the "I am not =
going to publish a faulty specification as an RFC" days of 1991.
>>>> I'm not entirely sure my analysis above is all that useful, though, =
as this is the "rfced-future" discussion rather than the "rfced-history" =
discussion, and so it seems more sensible to focus on meeting the needs =
of the Internet community in 2020 and beyond than is is to lean on the =
historical narrative.
>>>> And so more to the point: I think that the IETF community writ =
large would be floored if a working group produced a document, the IETF =
found consensus on it during last call, the IESG approved it, and then =
the RSE refused to publish it (or imposed technical changes on its =
contents). Ditto for the IRTF and their documents. So, if we're matching =
authority with community expectations -- at least for a large swath of =
the relevant community -- I think the answer above of "the RSE should =
refuse to publish the document" is exactly wrong.
>>>> /a
>>>> ____
>>>> [1] =
https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh9=
70H0/
>>> --=20
>>> Rfced-future mailing list
>>> Rfced-future@iab.org
>>> https://www.iab.org/mailman/listinfo/rfced-future


--Apple-Mail=_4A874526-9EC3-4AF2-8D3E-DA092E6F0B01
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes, =
certainly =E2=80=93 but should the stream manager eventually be able to overrule the RSE and say =E2=80=9Cpub=
lish it, the editorial quality is good enough=E2=80=9D?
Colin




On 12 May 2020, at 23:15, Adam Roach <adam@nostrum.com> =
wrote:

Right. I apologize if it was unclear that I was speaking =
strictly about the technical contents of a document. Personally, I'd be =
happy if the RSE/RPC were more liberal about sending things back as too =
poorly written to economically edit.

/a

On 5/12/2020 5:05 PM, Ben Campbell wrote:
I was mentally composing =
a reply to the effect of =E2=80=9CThe RSE should not be able to veto an =
IETF stream document approved through normal procedures on technical =
grounds, but could conceivably need to do so on editorial grounds.=E2=80=9D=
  But Joel beat me to it.

Ben.

On May =
12, 2020, at 4:57 PM, Joel M. Halpern <jmh@joelhalpern.com>=
 wrote:

=EF=BB=BFCan we step this down?

On the one hand, no, I do not think the RSE =
should have the authority to tell the IESG that the IETF can not publish =
particular technical content on technical grounds.
On the =
other hand, if a technically competent RSE is that concerned about a =
document, I think we probably have a whole lot of other problems that =
need to be addressed.  Whether the RSE actually publishes that =
document or not is probably the least of our worries.

And I do think the RSE should have the authority to say to =
any stream "turn this into proper English before the RPC will process =
it."

Yours,
Joel

On =
5/12/2020 5:30 PM, Adam Roach wrote:
On 5/12/2020 3:25 PM, Michael StJohns wrote:
On 5/12/2020 4:16 PM, Eric Rescorla wrote:
In Tue, May 12, 2020 at =
10:55 AM Michael StJohns <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:
Mark (in another email) =
is correct that the level of independence of the
current =
RSE is not the same as in the past - but I consider that a bug
rather than a feature as it means that its possible for a =
small subset
of the IETF community to affect the culture =
of the RFC series in ways
that may not represent the =
interests of the broader community.
I want to =
zero in on this point, because I think it's useful to scope
out people's views of "independence".

Let me try to start with what's hopefully a simple case: =
suppose
that the IETF produces and the IESG approves a =
document to be
published as RFC that the RSE believes is =
harmful to the Internet
for technical reasons (it =
redefines IPv6 to have an 8 bit address,
say). Do you =
believe that the RSE should be able to refuse to
publish =
such a document?

-Ekr
Oooh   tricky.   I'd either =
have the RSE refer it to the ISE as publication as an April Fool's RFC, =
or I'd probably be the first to sign on to a petition to recall the =
entire IESG.     In any case, the answer is probably =
yes, the RSE should refuse to publish the document as an Internet =
standard.   That assumes that the RSE - with the appropriate =
technical advisors - has the skillset to determine said document is =
"harmful to the Internet".

I =
think we can appreciate that the example was chosen to be fantastical so =
as to not focus discussion on the technical matter as much as the degree =
of control the RSE is afforded over the technical contents of a =
document.
Now, I do recall a recent anecdote about Postel =
himself heatedly refusing to publish a specification he felt was =
technically misguided [1], so this authority did exist with the position =
at some point. Although never explicitly revoked, RFC 4844, section 4.1 =
et seq makes it pretty clear that the RSE has approval authority over =
precisely one stream (the Independent Submission stream). To the extent =
that the IAB had authority to publish RFC 4844, I think it makes it =
clear that the scope of authority had been pared back substantially =
since the "I am not going to publish a faulty specification as an RFC" =
days of 1991.
I'm not entirely sure my analysis above is =
all that useful, though, as this is the "rfced-future" discussion rather =
than the "rfced-history" discussion, and so it seems more sensible to =
focus on meeting the needs of the Internet community in 2020 and beyond =
than is is to lean on the historical narrative.
And so =
more to the point: I think that the IETF community writ large would be =
floored if a working group produced a document, the IETF found consensus =
on it during last call, the IESG approved it, and then the RSE refused =
to publish it (or imposed technical changes on its contents). Ditto for =
the IRTF and their documents. So, if we're matching authority with =
community expectations -- at least for a large swath of the relevant =
community -- I think the answer above of "the RSE should refuse to =
publish the document" is exactly wrong.
/a
____
[1] https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9=
iAz3PogGqh970H0/
-- 
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

=

--Apple-Mail=_4A874526-9EC3-4AF2-8D3E-DA092E6F0B01--


From nobody Thu May 14 14:02: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 5C0C63A0D3B for ; Thu, 14 May 2020 14:02:15 -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, 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 uOkTcavBIa7q for ; Thu, 14 May 2020 14:02:13 -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 C47DC3A0D3A for ; Thu, 14 May 2020 14:02:13 -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.15.2/8.15.2) with ESMTPSA id 04EL2BkO021230 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 16:02:13 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589490133; bh=OPNwsBsIfqxsYUfpMKdM1zlMm8ggI8qzl7HF0im6S8A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=MJvJz4PZRfiO4ICyJLfsc1BBrK0wRuIeJh1mGXRMUjRNmyR2afSp+/YO5grGCDLSh My7mQnnN6UA6eMkokvJWFu+Zcb2gaq16OeaOJNhHfXpILccfvpnPP5JZ34sa2uH9XJ tpD99vsrTIJ3WFeHcwBNA29kE02NJ3qC7xsy3IsU=
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: rfced-future@iab.org
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>    <1E256A4B9BDC8328CEDFE50F@PSB> <8b82bcba-6003-e67d-521e-68d874584c51@nostrum.com> <04FA4F5354E5D6EA839E1088@PSB>
From: Adam Roach 
Message-ID: <23a53aa3-91ec-b094-b72b-ec5bac8a8bbf@nostrum.com>
Date: Thu, 14 May 2020 16:02:05 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <04FA4F5354E5D6EA839E1088@PSB>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 21:02:15 -0000

On 5/14/2020 3:48 PM, John C Klensin wrote:
> That is the sense in which Mike's example is more realistic: it
> is not hard to imagine "not" being accidentally omitted (or
> inserted) and the eyes of everyone in the in-stream review
> process being sufficiently glazed over to not catch it.  But
> that is an even more clear case in which the normal process (at
> AUTH48 or earlier) might be expected to catch the problem with a
> vanishingly small possibility of someone pushing back on the fix.


Definitely. My point is that they're not *interesting*. We know exactly 
what's supposed to happen, and I don't think there's going to be much 
contention on that point.

Given the complete lack of engagement about the less cut-and-dried 
conflicts I've described, I'm inferring a discomfort in this group at 
even thinking about the cases where actual conflicts might arise. If all 
we do in this effort is answer the easy questions without even broaching 
the hard ones, I don't think we've achieved anything.

/a


From nobody Thu May 14 14:15:18 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC0F3A09DE for ; Thu, 14 May 2020 14:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 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.4, 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 xsdidHcXdU1H for ; Thu, 14 May 2020 14:15:12 -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 717F03A08F4 for ; Thu, 14 May 2020 14:15:12 -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.15.2/8.15.2) with ESMTPSA id 04ELF62T023733 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 16:15:08 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589490908; bh=755s39oAKKppedZPpTyxsS3K7wM9+7gp5ht3icZuMrA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=YF2IBUxwfxo4PYUL1tsC9ydYErxbOGT69o7xyDslBbSRZj84szGphvQP31c68FVWw SEkG76/ryGyq8z2enazek5sEE1r2/psLBqUsguCzmW/KSeLrCwd90+Bnpyid0wCrJv Q86AbZ5t7x9GGkFkx6ej05mMvLWSXBhi1wJSkCfU=
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: Colin Perkins 
Cc: Ben Campbell , "Joel M. Halpern" , rfced-future@iab.org
References:   <52c04df7-a629-6109-5e71-ce7e2a68720f@nostrum.com> <2E652F7D-B451-4C36-A8B8-559A93FDF457@csperkins.org>
From: Adam Roach 
Message-ID: <03ef5dba-0f70-5ee2-3877-7c8594d5ec70@nostrum.com>
Date: Thu, 14 May 2020 16:15:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <2E652F7D-B451-4C36-A8B8-559A93FDF457@csperkins.org>
Content-Type: multipart/alternative; boundary="------------C29085405606CD67B3F201CD"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 21:15:16 -0000

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

I believe it would be reasonable for the stream manager to make such a 
request when circumstances warrant (and I seem to recall a passage in an 
RFC that explicitly makes this suggestion at least for the IESG, but I 
can't find it on a quick search). Assuming that we agree that the RSE 
has editorial control over the series, I think the ultimate 
decision-making authority on editorial issues would lie with the RSE. As 
with the discussion about technical issues, I would hope that there 
would be a substantial, good-faith effort to reach a mutually agreeable 
conclusion in a collegial and consultative way; but ultimately, one 
single entity needs to own the decision.

/a

On 5/14/2020 3:59 PM, Colin Perkins wrote:
> Yes, certainly – but should the stream manager /eventually/ be able to 
> overrule the RSE and say “publish it, the editorial quality is good 
> enough”?
>
> Colin
>
>
>
>
>> On 12 May 2020, at 23:15, Adam Roach > > wrote:
>>
>> Right. I apologize if it was unclear that I was speaking strictly 
>> about the technical contents of a document. Personally, I'd be happy 
>> if the RSE/RPC were more liberal about sending things back as too 
>> poorly written to economically edit.
>>
>> /a
>>
>> On 5/12/2020 5:05 PM, Ben Campbell wrote:
>>> I was mentally composing a reply to the effect of “The RSE should 
>>> not be able to veto an IETF stream document approved through normal 
>>> procedures on technical grounds, but could conceivably need to do so 
>>> on editorial grounds.”  But Joel beat me to it.
>>>
>>> Ben.
>>>
>>>> On May 12, 2020, at 4:57 PM, Joel M. Halpern >>> > wrote:
>>>>
>>>> Can we step this down?
>>>>
>>>> On the one hand, no, I do not think the RSE should have the 
>>>> authority to tell the IESG that the IETF can not publish particular 
>>>> technical content on technical grounds.
>>>> On the other hand, if a technically competent RSE is that concerned 
>>>> about a document, I think we probably have a whole lot of other 
>>>> problems that need to be addressed.  Whether the RSE actually 
>>>> publishes that document or not is probably the least of our worries.
>>>>
>>>> And I do think the RSE should have the authority to say to any 
>>>> stream "turn this into proper English before the RPC will process it."
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>>> On 5/12/2020 5:30 PM, Adam Roach wrote:
>>>>>> On 5/12/2020 3:25 PM, Michael StJohns wrote:
>>>>>> On 5/12/2020 4:16 PM, Eric Rescorla wrote:
>>>>>>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns 
>>>>>>>  
>>>>>>> > wrote:
>>>>>>>> Mark (in another email) is correct that the level of 
>>>>>>>> independence of the
>>>>>>>> current RSE is not the same as in the past - but I consider 
>>>>>>>> that a bug
>>>>>>>> rather than a feature as it means that its possible for a small 
>>>>>>>> subset
>>>>>>>> of the IETF community to affect the culture of the RFC series 
>>>>>>>> in ways
>>>>>>>> that may not represent the interests of the broader community.
>>>>>>> I want to zero in on this point, because I think it's useful to 
>>>>>>> scope
>>>>>>> out people's views of "independence".
>>>>>>>
>>>>>>> Let me try to start with what's hopefully a simple case: suppose
>>>>>>> that the IETF produces and the IESG approves a document to be
>>>>>>> published as RFC that the RSE believes is harmful to the Internet
>>>>>>> for technical reasons (it redefines IPv6 to have an 8 bit address,
>>>>>>> say). Do you believe that the RSE should be able to refuse to
>>>>>>> publish such a document?
>>>>>>>
>>>>>>> -Ekr
>>>>>> Oooh   tricky.   I'd either have the RSE refer it to the ISE as 
>>>>>> publication as an April Fool's RFC, or I'd probably be the first 
>>>>>> to sign on to a petition to recall the entire IESG.     In any 
>>>>>> case, the answer is probably yes, the RSE should refuse to 
>>>>>> publish the document as an Internet standard.   That assumes that 
>>>>>> the RSE - with the appropriate technical advisors - has the 
>>>>>> skillset to determine said document is "harmful to the Internet".
>>>>>>
>>>>> I think we can appreciate that the example was chosen to be 
>>>>> fantastical so as to not focus discussion on the technical matter 
>>>>> as much as the degree of control the RSE is afforded over the 
>>>>> technical contents of a document.
>>>>> Now, I do recall a recent anecdote about Postel himself heatedly 
>>>>> refusing to publish a specification he felt was technically 
>>>>> misguided [1], so this authority did exist with the position at 
>>>>> some point. Although never explicitly revoked, RFC 4844, section 
>>>>> 4.1 et seq makes it pretty clear that the RSE has approval 
>>>>> authority over precisely one stream (the Independent Submission 
>>>>> stream). To the extent that the IAB had authority to publish RFC 
>>>>> 4844, I think it makes it clear that the scope of authority had 
>>>>> been pared back substantially since the "I am not going to publish 
>>>>> a faulty specification as an RFC" days of 1991.
>>>>> I'm not entirely sure my analysis above is all that useful, 
>>>>> though, as this is the "rfced-future" discussion rather than the 
>>>>> "rfced-history" discussion, and so it seems more sensible to focus 
>>>>> on meeting the needs of the Internet community in 2020 and beyond 
>>>>> than is is to lean on the historical narrative.
>>>>> And so more to the point: I think that the IETF community writ 
>>>>> large would be floored if a working group produced a document, the 
>>>>> IETF found consensus on it during last call, the IESG approved it, 
>>>>> and then the RSE refused to publish it (or imposed technical 
>>>>> changes on its contents). Ditto for the IRTF and their documents. 
>>>>> So, if we're matching authority with community expectations -- at 
>>>>> least for a large swath of the relevant community -- I think the 
>>>>> answer above of "the RSE should refuse to publish the document" is 
>>>>> exactly wrong.
>>>>> /a
>>>>> ____
>>>>> [1] 
>>>>> https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/
>>>> -- 
>>>> Rfced-future mailing list
>>>> Rfced-future@iab.org 
>>>> https://www.iab.org/mailman/listinfo/rfced-future
>


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


  
    
  
  
    
I believe it would be reasonable for
      the stream manager to make such a request when circumstances
      warrant (and I seem to recall a passage in an RFC that explicitly
      makes this suggestion at least for the IESG, but I can't find it
      on a quick search). Assuming that we agree that the RSE has
      editorial control over the series, I think the ultimate
      decision-making authority on editorial issues would lie with the
      RSE. As with the discussion about technical issues, I would hope
      that there would be a substantial, good-faith effort to reach a
      mutually agreeable conclusion in a collegial and consultative way;
      but ultimately, one single entity needs to own the decision.

    

    


    

    
/a

    

    


    

    
On 5/14/2020 3:59 PM, Colin Perkins
      wrote:

    

    

      
      Yes, certainly – but should the stream manager eventually
      be able to overrule the RSE and say “publish it, the editorial
      quality is good enough”?
      


      

      
Colin

      


      

      


      

      


        


          

            
On 12 May 2020, at 23:15, Adam Roach <adam@nostrum.com> wrote:

            

            

              
Right. I apologize if it was unclear that I
                was speaking strictly about the technical contents of a
                document. Personally, I'd be happy if the RSE/RPC were
                more liberal about sending things back as too poorly
                written to economically edit.

                

                /a

                

                On 5/12/2020 5:05 PM, Ben Campbell wrote:

                
I was mentally
                  composing a reply to the effect of “The RSE should not
                  be able to veto an IETF stream document approved
                  through normal procedures on technical grounds, but
                  could conceivably need to do so on editorial grounds.”
                   But Joel beat me to it.

                  

                  Ben.

                  

                  
On May 12, 2020, at
                    4:57 PM, Joel M. Halpern <jmh@joelhalpern.com>
                    wrote:

                    

                    Can we step this down?

                    

                    On the one hand, no, I do not think the RSE should
                    have the authority to tell the IESG that the IETF
                    can not publish particular technical content on
                    technical grounds.

                    On the other hand, if a technically competent RSE is
                    that concerned about a document, I think we probably
                    have a whole lot of other problems that need to be
                    addressed.  Whether the RSE actually publishes that
                    document or not is probably the least of our
                    worries.

                    

                    And I do think the RSE should have the authority to
                    say to any stream "turn this into proper English
                    before the RPC will process it."

                    

                    Yours,

                    Joel

                    

                    
On 5/12/2020 5:30
                      PM, Adam Roach wrote:

                      
On 5/12/2020 3:25
                        PM, Michael StJohns wrote:

                        On 5/12/2020 4:16 PM, Eric Rescorla wrote:

                        
In Tue, May 12,
                          2020 at 10:55 AM Michael StJohns <msj@nthpermutation.com
                          <mailto:msj@nthpermutation.com>>
                          wrote:

                          
Mark (in
                            another email) is correct that the level of
                            independence of the

                            current RSE is not the same as in the past -
                            but I consider that a bug

                            rather than a feature as it means that its
                            possible for a small subset

                            of the IETF community to affect the culture
                            of the RFC series in ways

                            that may not represent the interests of the
                            broader community.

                          

                          I want to zero in on this point, because I
                          think it's useful to scope

                          out people's views of "independence".

                          

                          Let me try to start with what's hopefully a
                          simple case: suppose

                          that the IETF produces and the IESG approves a
                          document to be

                          published as RFC that the RSE believes is
                          harmful to the Internet

                          for technical reasons (it redefines IPv6 to
                          have an 8 bit address,

                          say). Do you believe that the RSE should be
                          able to refuse to

                          publish such a document?

                          

                          -Ekr

                        

                        Oooh   tricky.   I'd either have the RSE refer
                        it to the ISE as publication as an April Fool's
                        RFC, or I'd probably be the first to sign on to
                        a petition to recall the entire IESG.     In any
                        case, the answer is probably yes, the RSE should
                        refuse to publish the document as an Internet
                        standard.   That assumes that the RSE - with the
                        appropriate technical advisors - has the
                        skillset to determine said document is "harmful
                        to the Internet".

                        

                      

                      I think we can appreciate that the example was
                      chosen to be fantastical so as to not focus
                      discussion on the technical matter as much as the
                      degree of control the RSE is afforded over the
                      technical contents of a document.

                      Now, I do recall a recent anecdote about Postel
                      himself heatedly refusing to publish a
                      specification he felt was technically misguided
                      [1], so this authority did exist with the position
                      at some point. Although never explicitly revoked,
                      RFC 4844, section 4.1 et seq makes it pretty clear
                      that the RSE has approval authority over precisely
                      one stream (the Independent Submission stream). To
                      the extent that the IAB had authority to publish
                      RFC 4844, I think it makes it clear that the scope
                      of authority had been pared back substantially
                      since the "I am not going to publish a faulty
                      specification as an RFC" days of 1991.

                      I'm not entirely sure my analysis above is all
                      that useful, though, as this is the "rfced-future"
                      discussion rather than the "rfced-history"
                      discussion, and so it seems more sensible to focus
                      on meeting the needs of the Internet community in
                      2020 and beyond than is is to lean on the
                      historical narrative.

                      And so more to the point: I think that the IETF
                      community writ large would be floored if a working
                      group produced a document, the IETF found
                      consensus on it during last call, the IESG
                      approved it, and then the RSE refused to publish
                      it (or imposed technical changes on its contents).
                      Ditto for the IRTF and their documents. So, if
                      we're matching authority with community
                      expectations -- at least for a large swath of the
                      relevant community -- I think the answer above of
                      "the RSE should refuse to publish the document" is
                      exactly wrong.

                      /a

                      ____

                      [1] https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/

                    

                    -- 

                    Rfced-future mailing list

                    Rfced-future@iab.org

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

                  

                

              

            

          

        

        

      

    

    


    

  


--------------C29085405606CD67B3F201CD--


From nobody Thu May 14 14:50: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 3A1F13A0DBA for ; Thu, 14 May 2020 14:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkmMIvNcFWMo for ; Thu, 14 May 2020 14:50:18 -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 994273A0DAB for ; Thu, 14 May 2020 14:50:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49NQFP34Vpz6GDyL; Thu, 14 May 2020 14:50:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1589493017; bh=TW+R90zWrthVLnMb1J6ybJOAfkTkEucRZjcARfUH4Ec=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=M8kfH8VntKWGTByl92FBJu6Keb1F+Ca39mjfTjXODXxb2s/V824CBrOaHd2MkR0MK euc6ysQlY7KOqx+IaDpldF2QBCBpQJ/zlmMQ2x2wd8m9L8CCuNLzkoR2Rwyqsu10A0 9C/VmWSQDD1Rfru0bTm0OFYqgf1ZyFEGzFqw0qbM=
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 49NQFN6Bswz6G9Hg; Thu, 14 May 2020 14:50:16 -0700 (PDT)
To: Adam Roach 
Cc: rfced-future@iab.org
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com> <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>    <1E256A4B9BDC8328CEDFE50F@PSB> <8b82bcba-6003-e67d-521e-68d874584c51@nostrum.com> <04FA4F5354E5D6EA839E1088@PSB> <23a53aa3-91ec-b094-b72b-ec5bac8a8bbf@nostrum.com>
From: "Joel M. Halpern" 
Message-ID: <9d213be4-ef1b-b13c-2005-55b28ace7cd6@joelhalpern.com>
Date: Thu, 14 May 2020 17:50:15 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <23a53aa3-91ec-b094-b72b-ec5bac8a8bbf@nostrum.com>
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-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 21:50:28 -0000

The assumption when we did 6635 was that it was not possible to define 
resolution for all possible conflicts.  Which is why the RFC specifies a 
decision procedure for sorting out conflicts.

I do think that the rules as we have written them (streams own the 
technical content, the RSE owns the editorial content and editorial 
quality) is the right basis.  To a significant degree, given that as the 
existing definition, I can not understand why we are even discussing it 
from that angle.

Yours,
Joel

On 5/14/2020 5:02 PM, Adam Roach wrote:
> On 5/14/2020 3:48 PM, John C Klensin wrote:
>> That is the sense in which Mike's example is more realistic: it
>> is not hard to imagine "not" being accidentally omitted (or
>> inserted) and the eyes of everyone in the in-stream review
>> process being sufficiently glazed over to not catch it.  But
>> that is an even more clear case in which the normal process (at
>> AUTH48 or earlier) might be expected to catch the problem with a
>> vanishingly small possibility of someone pushing back on the fix.
> 
> 
> Definitely. My point is that they're not *interesting*. We know exactly 
> what's supposed to happen, and I don't think there's going to be much 
> contention on that point.
> 
> Given the complete lack of engagement about the less cut-and-dried 
> conflicts I've described, I'm inferring a discomfort in this group at 
> even thinking about the cases where actual conflicts might arise. If all 
> we do in this effort is answer the easy questions without even broaching 
> the hard ones, I don't think we've achieved anything.
> 
> /a
> 


From nobody Thu May 14 14:56: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 D23E63A0D8E for ; Thu, 14 May 2020 14:56:45 -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, 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 HqQZmdwwKMAA for ; Thu, 14 May 2020 14:56:44 -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 A95673A0D84 for ; Thu, 14 May 2020 14:56:44 -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.15.2/8.15.2) with ESMTPSA id 04ELugmF032016 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 16:56:43 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589493404; bh=dO6esgEF1TlkJnJ9RvR1+4Pv74idCRHgxsUswb0IGFQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=mBSGnF4TeyxAc2zU3VLfJ7OB/aOsBWAT95DoNNDlx/b4eYnVnOaQHWzMIthCS1Fdk Eb04ZK3cGAY22jwqtWQBu5WrOdeUH8kLVIC4Sw8JYLBae1qAD6/0LL+g1AjikKL5Es 9ugRKzHOSKPd20VLh/G72bk3aio8O5yX6ecZaYXA=
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: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <56ffa4db-49f4-f360-e3bd-f9fb169b206b@huitema.net>    <1E256A4B9BDC8328CEDFE50F@PSB> <8b82bcba-6003-e67d-521e-68d874584c51@nostrum.com> <04FA4F5354E5D6EA839E1088@PSB> <23a53aa3-91ec-b094-b72b-ec5bac8a8bbf@nostrum.com> <9d213be4-ef1b-b13c-2005-55b28ace7cd6@joelhalpern.com>
From: Adam Roach 
Message-ID: <68e21433-4dde-0104-f4a5-f74f561c50cb@nostrum.com>
Date: Thu, 14 May 2020 16:56:36 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <9d213be4-ef1b-b13c-2005-55b28ace7cd6@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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 21:56:46 -0000

On 5/14/2020 4:50 PM, Joel M. Halpern wrote:
> I do think that the rules as we have written them (streams own the 
> technical content, the RSE owns the editorial content and editorial 
> quality) is the right basis.  To a significant degree, given that as 
> the existing definition, I can not understand why we are even 
> discussing it from that angle. 


Yes! Exactly! As far as I understand this is the status quo, this is 
what is expected by the community, and this is how I think things should 
work in the future. My engagement on this topic has exclusively been in 
response to assertions that imply that the outcome of this effort is 
something other than "streams own the technical content, the RSE owns 
the editorial content and editorial quality." Like you, I'm a bit 
distressed that we're having the conversation in the first place.

/a


From nobody Thu May 14 16:48:58 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85EB3A0736 for ; Thu, 14 May 2020 16:48:56 -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 jz-Y5HB5FuFM for ; Thu, 14 May 2020 16:48:55 -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 E2B6C3A067A for ; Thu, 14 May 2020 16:48:54 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jZNan-0002qj-Fq; Thu, 14 May 2020 19:48:45 -0400
Date: Thu, 14 May 2020 19:48:39 -0400
From: John C Klensin 
To: Adam Roach , Colin Perkins 
cc: rfced-future@iab.org, Ben Campbell , "Joel M. Halpern" 
Message-ID: <8D4A093E072A55C263AAD194@PSB>
In-Reply-To: <03ef5dba-0f70-5ee2-3877-7c8594d5ec70@nostrum.com>
References:   <52c04df7-a629-6109-5e71-ce7e2a68720f@nostrum.com> <2E652F7D-B451-4C36-A8B8-559A93FDF457@csperkins.org> <03ef5dba-0f70-5ee2-3877-7c8594d5ec70@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] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 May 2020 23:48:57 -0000

--On Thursday, May 14, 2020 16:15 -0500 Adam Roach
 wrote:

> I believe it would be reasonable for the stream manager to
> make such a request when circumstances warrant (and I seem to
> recall a passage in an RFC that explicitly makes this
> suggestion at least for the IESG, but I can't find it on a
> quick search).

That is the text I'm quite certain I've seen too but haven't
been able to find either.   Good to have company :-)

> Assuming that we agree that the RSE has
> editorial control over the series, I think the ultimate
> decision-making authority on editorial issues would lie with
> the RSE.

But, in the passage I think I remember, the solution (at least
for the IETF Stream) was to give the IETF Stream Manager (e.g.,
the IESG) the final authority if they decided to exercise but
allow the RSE to attach a disclaimer to the effect that the
document was published unedited as requested.  Not a perfect
compromise and it would be really bad if it had to be used very
often (but it has been used approximately never, so that is
apparently not a huge problem although a different RSE might
push back harder and more firmly), but workable.

> As with the discussion about technical issues, I
> would hope that there would be a substantial, good-faith
> effort to reach a mutually agreeable conclusion in a collegial
> and consultative way; but ultimately, one single entity needs
> to own the decision.

That effort to reach such a conclusion is exactly what I read
RFCs 5620 and 6635/8728 as asking for (see Section 4.1.1 of the
former and 4.3 of the latter).  The question, which I think is
more or less the same as your "who owns the decision is whether
the provisions of those document for last-resort resolution in
those documents are both appropriate and workable.  IMO, if the
decision has to be made by a committee or panel (as is now
supposed to be the case), that body must include both
significant publications and technical expertise.  If it does
not, "appropriate" is questionable and "workable" is more so.
But, again, the number of times those mechanisms have been used
calls the priority of sorting them out into question (even
though I believe that sorting them out eventually is key to the
accountability questions and therefore important).

   john


From nobody Thu May 14 18:51: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 C915E3A02C1 for ; Thu, 14 May 2020 18:51: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiGVlSpPlEFA for ; Thu, 14 May 2020 18:51:20 -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 910353A02BB for ; Thu, 14 May 2020 18:51:20 -0700 (PDT)
Received: (qmail 65226 invoked from network); 15 May 2020 01:51:18 -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=fec8.5ebdf596.k2005; bh=DC0HYvuaWr69Xz4qCK2fD59yvigaclFTuBNsxoqVVOs=; b=cqCLCJMmqv/cVt0wc1gpO8qMQp4VAIHMpd5dpKOTjpnOh2nGSFdvmFFhRvwHOAwXnQ9LcIWF5U2CLrbudo6NLYf0Xzc9dzHErR40UOs8x8MY1FFiLUZ9bFarRivZUek1GZ4zIbxqdTMMPb9QN//cfA5clD3GXHjxtjUxInoXFNOT3aALjHZ5k/Vmc/f9vA8vJfwFEnDYD8DZ7RtcMJShbZZfYtVvNQHqKzlOpGL2dmQBEHXlSkvLkfYntsX1YTGu
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 15 May 2020 01:51:17 -0000
Received: by ary.qy (Postfix, from userid 501) id CA9281959535; Thu, 14 May 2020 21:51:17 -0400 (EDT)
Date: 14 May 2020 21:51:17 -0400
Message-Id: <20200515015117.CA9281959535@ary.qy>
From: "John Levine" 
To: rfced-future@iab.org
Cc: mnot@mnot.net
In-Reply-To: <4AA6462F-3495-40D4-9398-4343434E2090@mnot.net>
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-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 01:51:24 -0000

In article <4AA6462F-3495-40D4-9398-4343434E2090@mnot.net> you write:
>
>> On 14 May 2020, at 11:05 am, Michael StJohns  wrote:
>> 
>> an RSE has to be able to say something like this without fear of retribution, or with
>sufficient protections against retribution.
>
>Why?

It's increasingly clear that a mandatory attribute for an RSE is that
he or she doesn't really need the job.

-- 
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 May 14 19:11: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 334F73A041E for ; Thu, 14 May 2020 19:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=vyc5mbwI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q61QKzwD
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff9uDK83mDs0 for ; Thu, 14 May 2020 19:11:01 -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 E7E353A041A for ; Thu, 14 May 2020 19:11:00 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 057E0731; Thu, 14 May 2020 22:10:59 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 14 May 2020 22:11:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=E 78mHqMEA7D7aza3bioCoQIj6Ppv8KZBcweoUJoq6Zs=; b=vyc5mbwIvqou2G7ly HTzT0Hv1yupdRfaazqO9Mwluxr7RokUTRgOwi7TF0Arlj4BmsIcZlutma+Ehaf/6 3Hk5XYvyeyXL70NGOCgpnlRrEVll+N57vhOzCt2zKWFZBLGahKewijihaqt0BZQb sSCsoHgnz646EOX5RMjqIbj8D4yJ5ov1CYIh37pTUbZ7BhDbPOBouQww9ZhZEWWe hcEkBCXP+R//7DnWEljho8q0DWpAIKObVKhzxJop/AYRO+P6Q5SFhg4GStlXPqu4 RyGbhhppO/kMi5GPj/SbRzMtq9i2xEvXSxUXIIYO5UN3X5EPcuoyY2uqmK0+jYlq pQvMw==
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=fm2; bh=E78mHqMEA7D7aza3bioCoQIj6Ppv8KZBcweoUJoq6 Zs=; b=q61QKzwDoyc/BorGXDvfvB4IKzg0WmTg4Cckiy5ZsCtZjLWIz5IP31nu/ wsvjn/2v8TJcO2DcrZIDpDmh61O277vzDPyQNrzPuCxHtXKW7lQ2uY9zHGNnUsxC +VrfzT4Rgo++NIcEV4aYxufVCMxyQVbKQeO+vFdgTf48qFrRm4QYFQfWzUeGO/Ds qN82NMWmna1HH3YIgbGaRcnsoug+ZrgvU8RwTt40TXqR5hwESq02OQBjbXqRI4Ma 87FRoIweqi3ynfwVk5g9FCQqfYKLTHzjWqVol4KkzMR7F0Hg+4BxfAj/knczrsPe WG7t9CfZeO3kxpc/9lEErS9fTuypA==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleejgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhe dunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 945C5328005D; Thu, 14 May 2020 22:10:57 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: <20200515015117.CA9281959535@ary.qy>
Date: Fri, 15 May 2020 12:10:45 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <85431508-2FEB-4117-9F9D-72A820D94345@mnot.net>
References: <20200515015117.CA9281959535@ary.qy>
To: John Levine 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 02:11:03 -0000

On 15 May 2020, at 11:51 am, John Levine  wrote:
>=20
>>> an RSE has to be able to say something like this without fear of =
retribution, or with
>> sufficient protections against retribution.
>>=20
>> Why?
>=20
> It's increasingly clear that a mandatory attribute for an RSE is that
> he or she doesn't really need the job.

If we structure this as a paid position, we'll either need to make sure =
that's not true, or compensate them accordingly. I note that we don't =
have this kind of conversation about (for example) the IETF Chair.

That said, if we have an RSE that refuses to do their job, there should =
be consequences.=20

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


From nobody Thu May 14 21:05: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 DA9CF3A08A6 for ; Thu, 14 May 2020 21:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level: 
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdZY2qokG91g for ; Thu, 14 May 2020 21:05:42 -0700 (PDT)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1313A08A9 for ; Thu, 14 May 2020 21:05:42 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.71.33]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 04F45MWJ000477 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2020 21:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1589515536; x=1589601936; i=@elandsys.com; bh=b+o4M/DBmFZEBB6E2/Mjs4Odg0Lzoo+n0h985SHZOyw=; h=Date:To:From:Subject:In-Reply-To:References; b=OAn22U51BX6g/sQpXYpSDZK7yLgY1zOsMS7a0ggm2pZK0d737alGfpFB+UMrcgate I7z2+vBFoudq8/ywz7uhlbRIDdj/XuNjLVVOyxdTOhvDmNMAGfDp5Gg4qY2t5WAmzH HF/QC5+Vx1EBBW7PfzWEjLvjAcpFuqWyCielwVtU=
Message-Id: <6.2.5.6.2.20200514202848.0abc9778@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 14 May 2020 21:05:06 -0700
To: Adam Roach , rfced-future@iab.org
From: S Moonesamy 
In-Reply-To: <5252fcf9-5d48-6df0-9875-341c7861d275@nostrum.com>
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <0fbc5bd7-2133-7d47-090c-7e81c2783fc6@nthpermutation.com>  <2a7a83bb-e41b-793b-bb8b-fa4cf01d276d@nthpermutation.com> <5252fcf9-5d48-6df0-9875-341c7861d275@nostrum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 04:05:45 -0000

Hi Adam,
At 08:46 PM 13-05-2020, Adam Roach wrote:
>Let's tease this out by making it a little less abstract.
>
>Imagine TLS 1.3 were still under development, and that its 
>publication request came under the future model we're developing. 
>For whatever reason, the newly-installed RSE has decided that the 
>various new security properties in TLS 1.3 are problematic for law 
>enforcement's surveillance activities. They've extrapolated this to 
>an increase in the chances of a terror attack to such a degree that 
>they're willing to stake their professional credibility on making 
>sure it does not get published in the form that the working group, 
>the IETF at large, and the IESG agreed to.
>
>So they respond to the IETF with "I can't publish this document at 
>this time because it lacks interception-related features. Please fix 
>it, and until you do, I can't publish it."
>
>If you think that the system we're developing here makes this the 
>final word on that technical matter -- either we insert 
>interception-related features in TLS 1.3, or it simply doesn't get 
>an RFC number -- please be sure to say so clearly and unambiguously.

I replaced RSE" with IETF Area Director for the above.  The case is 
either unrealistic or a sign of systemic failure.  Would an IETF Area 
Director point that out or appeal against the decision?  After 
considering the historic information available, I would say no.

>But if the ultimate conclusion here is that the RSE is removed from 
>their post (ignoring for a moment who makes the decision to perform 
>such removal) and the RFC is published with the technical content 
>generated by the IETF, is that retribution? Or is that holding the 
>RSE accountable for failing to perform their duties?

It can be either option.

Regards,
S. Moonesamy 


From nobody Fri May 15 01:09: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 B0D8A3A0841 for ; Fri, 15 May 2020 01:09:04 -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 e9nNUoNHXSIc for ; Fri, 15 May 2020 01:09:01 -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 3FEBE3A0843 for ; Fri, 15 May 2020 01:09:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6906; q=dns/txt; s=iport; t=1589530141; x=1590739741; h=from:mime-version:subject:message-id:date:to; bh=ZAOhyGAJEhiBjkRlq+IaAbCbUr2ZhNShIq4REPtAlSo=; b=Qn0GyowfYKJdxzRhVNWyDi5IKN9QwBi1IHoM8aJTSqByNBX/eA70ftBy p48sQhIgNYkNoHy3Cf1YNP18FmZKNZdSqE9CfkFrawSEawlPdf6VOAuEH ydcCuQVpegfyYNf5dZA1hX7KFVCa3YYyd6ydEGJAwIdwGhK2xXuqei3jt Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDBwAKTb5e/xbLJq1mHgEBCxIMhXc?= =?us-ascii?q?gEoRRiQGbYIgNCwEBAQwBAS8EAQGEPwOCPjgTAgMBAQsBAQUBAQECAQUEbYV?= =?us-ascii?q?ihhsEgS8CgQaDEoJ9ojeOEHZ/M4VRhTSBOIxcggCBOByCHwEBiEwzgi0Ejny?= =?us-ascii?q?kC4JYBIJvimlPihcdgl2Ib4RbjSmqQINGAgQGBQIVgWkigVYzGggbFWUBgj8?= =?us-ascii?q?9EhgNnwo/A2cCBgEHAQEDCY8zAQE?=
X-IronPort-AV: E=Sophos; i="5.73,394,1583193600"; d="scan'208,217"; a="26224672"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 May 2020 08:08:56 +0000
Received: from [10.61.173.247] ([10.61.173.247]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04F88ust009366 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 May 2020 08:08:56 GMT
From: Eliot Lear 
Content-Type: multipart/alternative; boundary="Apple-Mail=_CBFA64D4-3640-435C-B1FE-916C4BEC1C07"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Fri, 15 May 2020 10:08:55 +0200
To: rfced-future@iab.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.173.247, [10.61.173.247]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: [Rfced-future] Some notes from our virtual meeting
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 08:09:05 -0000

--Apple-Mail=_CBFA64D4-3640-435C-B1FE-916C4BEC1C07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks to all who participated in the virtual meeting.  Here are some of =
the high points.

There are some folk who believe that it is important to establish what =
the purpose of the series is, in order to clearly understand who we need =
to run it.  Mike St.Johns and John Levine in particular took action =
items to write down their thoughts on this subject.  They should =
indicate how their vision differs from where we are today, and why.  Of =
course, anyone else is more than welcome to do this as well.  I would =
ask that such messages be sent prior to our next virtual meeting.

When we spoke of Slide 8 (top topics), the question came up: do we as a =
group need to even look at any of those questions, or is that the job of =
the RSE, to lead the community in discussions around evolving the =
series?  If it is the job of the RSE, then we would need to state the =
job as such, and endow that person with sufficient authority to carry =
out the job.  And there are shades of grey, here.  For instance, what =
does accountability mean if the RSE is charged with leading the =
community to evolve the strategy of the series, versus when the =
community arrogates that role to itself?

This led to an action I took, which was to ask this group that question. =
 I propose to do so in another form of a poll, but before people answer, =
I want to confirm the question first.  I think what I want to ask is the =
following:

For each question below, indicate who is responsible for its answer:
(a) The RSE leads the community to get the answer
(b) This group must answer it
(c)  Someone else (please specify)

The questions:
To whom is each role accountable?
How is that accountability expressed?
Who sets strategy?
Who owns the series?
Who has the authority to impose minimum standards for editing of docs?
Who is responsible for setting and insuring compliance with publishing =
standards?
Who has overall tooling responsibility?
What do we want from the series?
Again, the goal isn=E2=80=99t to answer these questions now, but to =
determine who should.  In answering these questions, we should keep in =
mind RFCs 8728 and 8729, both what is in them, and how they came to be, =
in terms of who wrote them and who approved them.

So for instance, one might answer (1)->a, (2)->a,(3)->a, (4)->c, (5)->b, =
(6)->c, (7)->b

The more we choose (a) the more work we take on.  The more we choose (b) =
the more we delegate to the RSE.

Or one might answer across the board one way or the other.

Do I have the question form correct?

Eliot



--Apple-Mail=_CBFA64D4-3640-435C-B1FE-916C4BEC1C07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thanks to all who participated in the virtual meeting. =
 Here are some of the high points.

There are some folk who believe that it =
is important to establish what the purpose of the series is, in order to =
clearly understand who we need to run it.  Mike St.Johns and John =
Levine in particular took action items to write down their thoughts on =
this subject.  They should indicate how their vision differs from =
where we are today, and why.  Of course, anyone else is more than =
welcome to do this as well.  I would ask that such messages be sent =
prior to our next virtual meeting.

When we spoke of Slide 8 =
(top topics), the question came up: do we as a group need to even look =
at any of those questions, or is that the job of the RSE, to lead the =
community in discussions around evolving the series?  If it is the =
job of the RSE, then we would need to state the job as such, and endow =
that person with sufficient authority to carry out the job.  And =
there are shades of grey, here.  For instance, what does =
accountability mean if the RSE is charged with leading the community to =
evolve the strategy of the series, versus when the community arrogates =
that role to itself?

This led to an action I took, which was to ask this group =
that question.  I propose to do so in another form of a poll, but =
before people answer, I want to confirm the question first.  I =
think what I want to ask is the following:

For each question below, indicate who =
is responsible for its answer:
(a) The RSE leads =
the community to get the answer
(b) This group must =
answer it
(c)  Someone else (please =
specify)

The =
questions:
  1. To whom=
 is each role accountable?
  2. How is that =
accountability expressed?
  3. Who sets =
strategy?
  4. Who owns the series?
  5. Who has the authority to impose minimum standards for =
editing of docs?
  6. Who is responsible for setting =
and insuring compliance with publishing standards?
  7. Who has overall tooling responsibility?
  8. What do we want from the series?
Again, the goal isn=E2=80=99t to answer these questions now, =
but to determine who should.  In answering these questions, we =
should keep in mind RFCs 8728 and 8729, both what is in them, and how =
they came to be, in terms of who wrote them and who approved =
them.

So =
for instance, one might answer (1)->a, (2)->a,(3)->a, =
(4)->c, (5)->b, (6)->c, (7)->b

The more we choose (a) the more work we =
take on.  The more we choose (b) the more we delegate to the =
RSE.

Or one =
might answer across the board one way or the other.

Do I have the question =
form correct?

Eliot


=

--Apple-Mail=_CBFA64D4-3640-435C-B1FE-916C4BEC1C07--


From nobody Fri May 15 02:29: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 B01203A082B for ; Fri, 15 May 2020 02:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKPaRs-vVfEZ for ; Fri, 15 May 2020 02:29:26 -0700 (PDT)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400118.outbound.protection.outlook.com [40.107.140.118]) (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 0A5D43A0803 for ; Fri, 15 May 2020 02:29:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n70UXuxzKf6is3FOQRgtwO522H/341mirrRGL3sTpJXe1r2zjH4bEbvyLEGCJKvjPQDf7dqqlfPhwGnkm8orSfFuiEj+p7DHypZKSkyNPj079dNm4TVUWw2JqW/PzK43EJAfkgrt8uKhXS7X5+BUjZ0ImmyZ7aSawC+qJMH47Ua4MyF8UVBh2F4G7d49Ts08kEfjTNu+eTpEeQASKDChH2ncPj0mPKkCiQvFBnN48rlFbV2F/wN7bRNFRjKh4EqzQrn+/89AwGwpNTVV8Evx4ifxnT3tJ24ukDPPNmh+iaUAMJPY8vPWEnMWl/8dLdF5mXpLSy07/XRb4i5xmZ9oAg==
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=4Tu6o6n8cAGTk1I5Vpl8Tx8KEabDJFNXopNcCj0+ZSs=; b=ScCFMqXuUiw/zmcj0i9nqVJ4TXR8Hc1LXhAlhI4KOG6LYXWvMfoGNoyYjbKH7fIAata5JO7YcITAacvB7+FT7yuKHS1UlA7/Pl+QIVYQCwurrr9teHZek7Ju0ehmVKrgH+XkKEo2srJ56aGYEV+wAZEmU4SJqzGD+/UNKZX9hAM4d8qJ264rCdr29JAfAiahKwTnmIQcOJKE8jdCUB0oXv3PvSoUwTY8oRXt3yfyMDzbmA8PoJs9p5B29MXdfMcteLLX2xKdVITYJxSFQ+Y2W+DCXAeXGUq6OjlNXMS/q9+m9JW/1G/tVPOddkQoOU0BCOUKHi9iLHbr2iA1GDWsAw==
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=4Tu6o6n8cAGTk1I5Vpl8Tx8KEabDJFNXopNcCj0+ZSs=; b=ftHAnDEchzNLdmboImMpkpOJ5ELCTCSjFrT2zDkXRAnItl0zFg8KMGCVmbM1dR1toCZj/c6lyVs9iXlmVx0HDP+98HLZJGWSP0u2a0eqVsjABd3XTWJWiSlyO2f96pJcwA3SSH7laHfNlrdwALXr3wJ0tQBd4+OXlj4+ZC0hxqI=
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 (52.134.254.141) by OSBPR01MB2181.jpnprd01.prod.outlook.com (52.134.243.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.26; Fri, 15 May 2020 09:29:23 +0000
Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::80a8:73bf:9ca8:7aae]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::80a8:73bf:9ca8:7aae%5]) with mapi id 15.20.2979.033; Fri, 15 May 2020 09:29:23 +0000
To: Eliot Lear , rfced-future@iab.org
References: 
From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: 
Date: Fri, 15 May 2020 18:29:21 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: TYAPR01CA0037.jpnprd01.prod.outlook.com (2603:1096:404:28::25) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.6] (125.203.82.4) by TYAPR01CA0037.jpnprd01.prod.outlook.com (2603:1096:404:28::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.24 via Frontend Transport; Fri, 15 May 2020 09:29:23 +0000
X-Originating-IP: [125.203.82.4]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 77d646e4-0198-4025-c1e2-08d7f8b27411
X-MS-TrafficTypeDiagnostic: OSBPR01MB2181:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 04041A2886
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: vikgS2JuXAYuy7AUe4n0YhTs6fq37Jk0a/jYY6/L7rm4GvKTj8NZAwaD73Bs8yr5With6WTryCefbR4zu03r2c2hK/NCugJlOQ9lPj7h536vZ702sRii838d3C4cMVmJNFxbJF6da8H9Q9NSl1uTPTCxgeyuoHiX/gZNHLkD0C4VjevX3wQ6CXj+onBwf4RkCoR5cHpJfZr7NETnMX79DJ0FxtWM5zjajst3m/o8TwS65XsdoFMN0fjIEtsC86uJhBDgg6DTpFaEduJnB1Ses+7fn8L1c0s6Bc6xI0JtXVhivKfLg20EOycDTwW4ISO6dJivnzn6158/qSM3HbiA793pCqtcvrOaXcQCKcG5A99vmajoGOpHMehIgEweXRNRBqZ17DU5HtlZsqlTZIPOoLA75SLWIdAJq6kCb9bQesJRs6i3+BVg+d7qcUsbmWN/SZquYMuAeZqyUC76w6U/4938wbN+IhImyWeN7CiqYBEyHhoTcaWvobKo+yIoogiz
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(366004)(376002)(136003)(346002)(396003)(39850400004)(31686004)(52116002)(6486002)(36916002)(8676002)(8936002)(508600001)(86362001)(31696002)(16576012)(786003)(316002)(5660300002)(26005)(16526019)(186003)(53546011)(66556008)(2616005)(956004)(66476007)(66946007)(2906002)(43740500002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData: GheUwQD6caFu9rql8xwbAzfE6f14TrSsSQL78PbQ8j0kztQ/n30lSIukC1kjVCrdpIS4q6W3zYbEWfo5O0gNfNjKkBJuy5x42Zj1gu9yLi8XFn0Skxr/OFdfCLAzQ4VScn1YWPti5dCMW+z4Sd2d5gpBUPGjAxKjHqDgkoC6Q3uT0+ZSKC1z21vyRArKaK6+VrLzSudyd7/93GuY900IfTj0rOvDM2352mKE6WO09AmFBJs0efhkIcwA72bOWa2CGL2E44GLYE8MJB0EongWiIzc+3nIRO7dxMFeqzyUSFj8XqLfhKqg2c8Cpg3QIdfcgifBEevLTyvO8CmGs7gZkHTY6ITbdzEedJ1SFt3r3vYD3vglMPPzi1HtX/REM93udgf2M2hNgIeUaoJOOGom85bCQuGa83Xc5+FGqg9ZtM7/iwcZfmqikl0xqyU5E17g21GSSxB2LCvhwPg8QYv9v7uQPFakYl+BGYF6YR6NBrs=
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 77d646e4-0198-4025-c1e2-08d7f8b27411
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2020 09:29:23.3091 (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: guhZInOPiypsvk9UwzmULfADKPs7cKxMV+8A9t4lL82pdYqLN/HZdZFqIK4ROCfglrlKWuf49h+cBUz4sFG9Ig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2181
Archived-At: 
Subject: Re: [Rfced-future] Some notes from our virtual meeting
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 09:29:28 -0000

Hello Eliot,

Very small point towards the end.

On 15/05/2020 17:08, Eliot Lear wrote:
> Thanks to all who participated in the virtual meeting.  Here are some of the high points.
> 
> There are some folk who believe that it is important to establish what the purpose of the series is, in order to clearly understand who we need to run it.  Mike St.Johns and John Levine in particular took action items to write down their thoughts on this subject.  They should indicate how their vision differs from where we are today, and why.  Of course, anyone else is more than welcome to do this as well.  I would ask that such messages be sent prior to our next virtual meeting.
> 
> When we spoke of Slide 8 (top topics), the question came up: do we as a group need to even look at any of those questions, or is that the job of the RSE, to lead the community in discussions around evolving the series?  If it is the job of the RSE, then we would need to state the job as such, and endow that person with sufficient authority to carry out the job.  And there are shades of grey, here.  For instance, what does accountability mean if the RSE is charged with leading the community to evolve the strategy of the series, versus when the community arrogates that role to itself?
> 
> This led to an action I took, which was to ask this group that question.  I propose to do so in another form of a poll, but before people answer, I want to confirm the question first.  I think what I want to ask is the following:
> 
> For each question below, indicate who is responsible for its answer:
> (a) The RSE leads the community to get the answer
> (b) This group must answer it
> (c)  Someone else (please specify)
> 
> The questions:
> To whom is each role accountable?
> How is that accountability expressed?
> Who sets strategy?
> Who owns the series?
> Who has the authority to impose minimum standards for editing of docs?
> Who is responsible for setting and insuring compliance with publishing standards?
> Who has overall tooling responsibility?
> What do we want from the series?
> Again, the goal isn’t to answer these questions now, but to determine who should.  In answering these questions, we should keep in mind RFCs 8728 and 8729, both what is in them, and how they came to be, in terms of who wrote them and who approved them.
> 
> So for instance, one might answer (1)->a, (2)->a,(3)->a, (4)->c, (5)->b, (6)->c, (7)->b
> 
> The more we choose (a) the more work we take on.  The more we choose (b) the more we delegate to the RSE.

The labels in your list above seem to have it the other way around (i.e. 
The more we choose (b), the more work we take on.)

Regards,   Martin.

> Or one might answer across the board one way or the other.
> 
> Do I have the question form correct?
> 
> Eliot
> 
> 


From nobody Fri May 15 03:27: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 DEF853A08AD for ; Fri, 15 May 2020 03:27:23 -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 ucUM-Sb5Odwr for ; Fri, 15 May 2020 03:27:22 -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 42C3E3A08A9 for ; Fri, 15 May 2020 03:27:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4540; q=dns/txt; s=iport; t=1589538442; x=1590748042; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=0Rfqp+RhFo9D20ceD7PdHg+0ynJ7cdHqiriNFhCQHBA=; b=VV5A9iP8kF08F79432QzhBji7AkGT//piU2hsMhzobBbWh8QOe5s+Jpf dDFxD9h8gLb2y8n7LdbyaOQ/dB6pGYrmoUYtlWxNYuVROpjznOAadS/H2 Lw2LCUp0JcheoDW6qgjoFKqeUqcbRJ7bfK6nS5c6DTxHL8k0q/MwGWBB1 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFEQDdbb5e/xbLJq1mDg4BAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBggcCgSOCSyASLIQliQGHYiWTV4YTgXoLAQEBDAEBLwQBAYR?= =?us-ascii?q?EAoI6OwMNAgMBAQsBAQUBAQECAQUEbYVihXEBAQEBAgEjVgULCxgqAgJXBhO?= =?us-ascii?q?DJoJdILBBdoEyhVGFC4E4hSuHMYIAgTgMEIIfLj6HYjOCLQSicJAXgliCc5V?= =?us-ascii?q?PHZAnjSmpdkqDRgIEBgUCFYF8AQ6BVjMaCBsVOyoBgj4+EhgNnkpAPwMwNwI?= =?us-ascii?q?GAQcBAQMJjzMBAQ?=
X-IronPort-AV: E=Sophos; i="5.73,394,1583193600"; d="scan'208,217"; a="26167651"
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; 15 May 2020 10:27:18 +0000
Received: from [10.61.173.247] ([10.61.173.247]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04FARHkP011740 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 May 2020 10:27:18 GMT
From: Eliot Lear 
Message-Id: <796F0A1C-6172-42DA-891D-B95B2280F562@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_78F8337F-170B-4CB2-8C48-01CF94983BB0"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 15 May 2020 12:27:16 +0200
In-Reply-To: 
Cc: rfced-future@iab.org
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
References:  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.173.247, [10.61.173.247]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] Some notes from our virtual meeting
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 10:27:24 -0000

--Apple-Mail=_78F8337F-170B-4CB2-8C48-01CF94983BB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 15 May 2020, at 11:29, Martin J. D=C3=BCrst =
 wrote:
>=20
> Hello Eliot,
>=20
> Very small point towards the end.
>=20
> The labels in your list above seem to have it the other way around =
(i.e. The more we choose (b), the more work we take on.)
>=20

Thanks for catching that.

Eliot


--Apple-Mail=_78F8337F-170B-4CB2-8C48-01CF94983BB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 15 May 2020, at 11:29, Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:

Hello Eliot,

Very small point towards the =
end.

The labels in your list above seem to have it the other way =
around (i.e. The more we choose (b), the more work we take =
on.)


Thanks =
for catching that.

Eliot
=

--Apple-Mail=_78F8337F-170B-4CB2-8C48-01CF94983BB0--


From nobody Fri May 15 14:41:11 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C280E3A099B for ; Fri, 15 May 2020 14:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cQcPpeeUaGh for ; Fri, 15 May 2020 14:41:06 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C223A09C3 for ; Fri, 15 May 2020 14:41:02 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id f15so1447851plr.3 for ; Fri, 15 May 2020 14:41:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=dl4QZwW8lPWY99xNlsFGoafPJlb3xWQ+LvLlH5Cf3No=; b=J8ARNb/bckT7V/RcLmOIlm3ml1J++KQXwsLMLmC5iwowBSLrIi89DUjsOuz5Xxi/Qv vClL4AedU4HiQftsylYNdMDfVZfDNySP2gPCwF0lfLpasY6pJvWBuEPNN3StNqqvhV5K AdbWJwSk62QjzZf0xIvRS8d2Idi0rLgQ6V1/SLzZ2tiXDFZpQ77fe6RH4De4piuujvDp QpPz3lWVOS7CbLuqt4JRi8hllOgx/goy/7ZQ+Vmuch1G+1OxwHzyIFfVgnwUPW/U+mwb DKCrNfvZfHPN06cbUjvpzMC3iHrF3vbLF3fswoq9dMTDELikulDwEMDTWrXl7eA7DoHh yBiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=dl4QZwW8lPWY99xNlsFGoafPJlb3xWQ+LvLlH5Cf3No=; b=N9HiYMgJ8efQ5Fl0RujTPfZ4VPybzoPTugU2EtMp2kB/iqPoflmL+I7Vfc1e0L9U1D 3B1gYcIl/6W1dqk0wWU9fVl8x6sXchHK6hCiXIpbSG7oJDr8M5I6Oe4xdRysa2QHfkjD Ld1DGAHkVc0Cea1hoAToKoYoCfiir5LiNZapCtdDh0HyKF+ezkdy/HYpYxHUeLZktWgL gQ5FmYe6YWx96yWdSYIPC/TLKn0+CN9p4F9+Bp7ZBanQ5H+xiz3N7nr3G7x3cSKmnd+n 0wsxu7LqC3dXZF5dExxcfxMhCgVxIoSjZajoFMPBuBesfTLjN/DmG7GoDNJid6eWve7g uktA==
X-Gm-Message-State: AOAM530dysBDr2ZzVL3od1yiVUMW1yjsTCTfmZDCwvu6riJtJm6h+U0m lmSVev0+tilJRuQtJYvoIKE=
X-Google-Smtp-Source: ABdhPJyOByj+zMwZgPOgXx+/3byHPylwuh0R1CRjWJHqvKbG/wA6AJi23x2onTlsR+9Llz9SG+E9kw==
X-Received: by 2002:a17:902:9043:: with SMTP id w3mr5252878plz.250.1589578861558;  Fri, 15 May 2020 14:41:01 -0700 (PDT)
Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id f11sm1343186pfa.32.2020.05.15.14.41.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2020 14:41:00 -0700 (PDT)
Sender: Larry Masinter 
From: Larry Masinter 
X-Google-Original-From: "Larry Masinter" 
To: "'Eliot Lear'" , 
References: 
In-Reply-To: 
Date: Fri, 15 May 2020 14:41:00 -0700
Message-ID: <019d01d62b01$872ad060$95807120$@acm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_019E_01D62AC6.DACC94A0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKj12lJ/2JoUxFs8q7fPB6Xq7KoGqcOTn2Q
Content-Language: en-us
Archived-At: 
Subject: Re: [Rfced-future] Some notes from our virtual meeting
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 May 2020 21:41:08 -0000

This is a multipart message in MIME format.

------=_NextPart_000_019E_01D62AC6.DACC94A0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Who manages the completion of the transition to XML, v3, and answering =
questions about canonical vs archival?

=20

I think it has to be (a).

=20

Consider the possibility that the transition needs significantly more =
development, oh, to format an RFC with a multipage image or table or =
diagram. Who should decide on the tooling to adopt or adapt?

=20

think regeneration of the derivative forms (HTML, PDF, text) should be =
an event with some documentation and perhaps even staging and archival =
of old generations. So as not to lose the virtual =E2=80=9Cchain of =
custody=E2=80=9D

=20

Who should decide on such a policy?

=20

=20

=20

From: Rfced-future  On Behalf Of Eliot =
Lear
Sent: Friday, May 15, 2020 1:09 AM
To: rfced-future@iab.org
Subject: [Rfced-future] Some notes from our virtual meeting

=20

Thanks to all who participated in the virtual meeting.  Here are some of =
the high points.

=20

There are some folk who believe that it is important to establish what =
the purpose of the series is, in order to clearly understand who we need =
to run it.  Mike St.Johns and John Levine in particular took action =
items to write down their thoughts on this subject.  They should =
indicate how their vision differs from where we are today, and why.  Of =
course, anyone else is more than welcome to do this as well.  I would =
ask that such messages be sent prior to our next virtual meeting.

=20

When we spoke of Slide 8 (top topics), the question came up: do we as a =
group need to even look at any of those questions, or is that the job of =
the RSE, to lead the community in discussions around evolving the =
series?  If it is the job of the RSE, then we would need to state the =
job as such, and endow that person with sufficient authority to carry =
out the job.  And there are shades of grey, here.  For instance, what =
does accountability mean if the RSE is charged with leading the =
community to evolve the strategy of the series, versus when the =
community arrogates that role to itself?

=20

This led to an action I took, which was to ask this group that question. =
 I propose to do so in another form of a poll, but before people answer, =
I want to confirm the question first.  I think what I want to ask is the =
following:

=20

For each question below, indicate who is responsible for its answer:

(a) The RSE leads the community to get the answer

(b) This group must answer it

(c)  Someone else (please specify)

=20

The questions:

1.	To whom is each role accountable?
2.	How is that accountability expressed?
3.	Who sets strategy?
4.	Who owns the series?
5.	Who has the authority to impose minimum standards for editing of =
docs?
6.	Who is responsible for setting and insuring compliance with =
publishing standards?
7.	Who has overall tooling responsibility?
8.	What do we want from the series?

Again, the goal isn=E2=80=99t to answer these questions now, but to =
determine who should.  In answering these questions, we should keep in =
mind RFCs 8728 and 8729, both what is in them, and how they came to be, =
in terms of who wrote them and who approved them.

=20

So for instance, one might answer (1)->a, (2)->a,(3)->a, (4)->c, (5)->b, =
(6)->c, (7)->b

=20

The more we choose (a) the more work we take on.  The more we choose (b) =
the more we delegate to the RSE.

=20

Or one might answer across the board one way or the other.

=20

Do I have the question form correct?

=20

Eliot

=20

=20


------=_NextPart_000_019E_01D62AC6.DACC94A0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Who =
manages the completion of the transition to XML, v3, and answering =
questions about canonical vs archival?
 
I think it =
has to be (a).
 
Consider the =
possibility that the transition needs significantly more development, =
oh, to format an RFC with a multipage image or table or diagram. Who =
should decide on the tooling to adopt or adapt?
 
think =
regeneration of the derivative forms (HTML, PDF, text) should be an =
event with some documentation and perhaps even staging and archival of =
old generations. So as not to lose the virtual =E2=80=9Cchain of =
custody=E2=80=9D
 
Who should =
decide on such a policy?
 
 
 
From: =
Rfced-future <rfced-future-bounces@iab.org> On Behalf Of =
Eliot Lear
Sent: Friday, May 15, 2020 1:09 =
AM
To: rfced-future@iab.org
Subject: [Rfced-future] =
Some notes from our virtual meeting
 
Thanks to =
all who participated in the virtual meeting.  Here are some of the =
high points.
 
There are some folk who believe that it is important =
to establish what the purpose of the series is, in order to clearly =
understand who we need to run it.  Mike St.Johns and John Levine in =
particular took action items to write down their thoughts on this =
subject.  They should indicate how their vision differs from where =
we are today, and why.  Of course, anyone else is more than welcome =
to do this as well.  I would ask that such messages be sent =
prior to our next virtual =
meeting.
 
When we spoke of Slide 8 (top topics), the question =
came up: do we as a group need to even look at any of those questions, =
or is that the job of the RSE, to lead the community in discussions =
around evolving the series?  If it is the job of the RSE, then we =
would need to state the job as such, and endow that person with =
sufficient authority to carry out the job.  And there are shades of =
grey, here.  For instance, what does accountability mean if the RSE =
is charged with leading the community to evolve the strategy of the =
series, versus when the community arrogates that role to =
itself?
 
This led to an action I took, which was to ask this =
group that question.  I propose to do so in another form of a poll, =
but before people answer, I want to confirm the question first.  I =
think what I want to ask is the following:
 
For each question below, indicate who is responsible =
for its answer:
(a) The =
RSE leads the community to get the answer
(b) This group must answer =
it
(c)  Someone else =
(please specify)
 
The questions:
  1. To whom is each role accountable?
  2. How is that accountability =
expressed?
  3. Who sets strategy?
  4. Who owns the series?
  5. Who has the authority to impose minimum standards for =
editing of docs?
  6. Who is responsible for setting and insuring compliance =
with publishing standards?
  7. Who has overall =
tooling responsibility?
  8. What do we want from the =
series?
Again, the goal =
isn=E2=80=99t to answer these questions now, but to determine who =
should.  In answering these questions, we should keep in mind RFCs =
8728 and 8729, both what is in them, and how they came to be, in terms =
of who wrote them and who approved =
them.
 
So for instance, one might answer (1)->a, =
(2)->a,(3)->a, (4)->c, (5)->b, (6)->c, =
(7)->b
 
The more we choose (a) the more work we take on. =
 The more we choose (b) the more we delegate to the =
RSE.
 
Or one might answer across the board one way or the =
other.
 
Do I have the question form =
correct?
 
Eliot
 
 

------=_NextPart_000_019E_01D62AC6.DACC94A0--


From nobody Sun May 17 20:13: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 C60E83A0885 for ; Sun, 17 May 2020 20:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 hmZJdAB1aUWo for ; Sun, 17 May 2020 20:13:54 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 5DBD73A0884 for ; Sun, 17 May 2020 20:13:54 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id b12so3619723plz.13 for ; Sun, 17 May 2020 20:13:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=choKH7FFFTTWKNW8GlJiG0laO02vMkeNjeiLXBYpX+I=; b=GjYWz4nYtqwBRDjqr27SxpuKVmWglMmX1DeaVqKB1rJ6ivQZjYx9G7D8ZaKG+9iCps ppQMc9aqAqU1R3lY7cQwfIp4BD/ioY2dHjZt0F/nUbPYjqM47RH06UWw9Rus1yqhBq/r 4VvvVquMNcV9Vnx5mxbRhRnodG1V36oe4np/wLJfdk+8wzuexqC5zYkGyL9KJWhQZaFr 70nRyfw2R1qY6vleeb60Tulj4KhX9PL9Mo7dRWH3knDGA2tyTb43MPq24QvCl24izVeu BPbRvjp71J09G5RRX39s0mR5jtHRWd2WqTjoOjJwWHOuNAwfqigBbULczS/p8R3y9POE LJuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=choKH7FFFTTWKNW8GlJiG0laO02vMkeNjeiLXBYpX+I=; b=mgDI0agzo7Z2YZbitPkBVD3PvakNcAmC6ld5aP3StqwNUYmnplC8tI8zmI7816THQG mzrHgF/fcH9yHA9IVm/lPYknGks30G9TeWjnTmmACR3iQkzq/opK0hTHctqlhLEz27ru pmHo2xcwp3frJ/y8xpeo05ag59MGz2q7AAtGBlzpXdx5XdZsbZR8Um/wEZd2ZQeWN+PE AvpEljs8dVW+Y8XXSqnsUiHZOh/NBkCCf/aqPlJtw/esHYHorxa9P5NMyoB0vIel/3G7 SM7uKBFeXJSU2LRhl45BOGJXACi1NOnuzWnfkz6UMYbuTTb5Wsj1bowJRVwG/53Ij1Ds pp9A==
X-Gm-Message-State: AOAM530SkUJDv0CsJtLE/DyPtX3PPHfhoew459GqzJFIF4m1E4mAPl50 +fvFKaVTN7aNmqL0T+gXt5glz85h
X-Google-Smtp-Source: ABdhPJyzToMS19RRfMW4TJrgKz4TXX+yjbj9uJk2RK1zmJyKUEe2G4CjLP+R7BdRUHbK50jnk1EVHA==
X-Received: by 2002:a17:90a:ad08:: with SMTP id r8mr4492635pjq.154.1589771633335;  Sun, 17 May 2020 20:13:53 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id a2sm7267598pfl.28.2020.05.17.20.13.51 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 May 2020 20:13:52 -0700 (PDT)
References: <158977114119.21769.9648461727863646464@ietfa.amsl.com>
To: rfced-future@iab.org
From: Brian E Carpenter 
X-Forwarded-Message-Id: <158977114119.21769.9648461727863646464@ietfa.amsl.com>
Message-ID: <545fb6ac-c8db-dca4-72ac-f7077e3ed7d3@gmail.com>
Date: Mon, 18 May 2020 15:13:49 +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: <158977114119.21769.9648461727863646464@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Rfced-future] Fwd: I-D Action: draft-carpenter-rfc-principles-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, 18 May 2020 03:13:56 -0000

Updated according to my interpretation of the long, complicated thread.
More comments welcome, of course.

Prettiest version:
https://www.ietf.org/id/draft-carpenter-rfc-principles-01.html

    Brian

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-rfc-principles-01.txt
Date: Sun, 17 May 2020 20:05:41 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Principles of the Request for Comments Series
        Author          : Brian Carpenter
	Filename        : draft-carpenter-rfc-principles-01.txt
	Pages           : 10
	Date            : 2020-05-17

Abstract:
   This document discusses the underlying principles of the Internet
   technical community's Request for Comments document Series.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-rfc-principles/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-rfc-principles-01
https://datatracker.ietf.org/doc/html/draft-carpenter-rfc-principles-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-rfc-principles-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From nobody Sun May 17 21:16: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 D9F733A08ED for ; Sun, 17 May 2020 21:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=g8oThljc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RfrUDmyc
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCUBnsN9LluJ for ; Sun, 17 May 2020 21:16:11 -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 DE8623A08E9 for ; Sun, 17 May 2020 21:16:11 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DBCBA5DB5; Mon, 18 May 2020 00:16:10 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 18 May 2020 00:16:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=8 LQxNhADRKL6pPVtjHokeMvixpVi5o8ON7dF9Brb92M=; b=g8oThljc/Oj7/JjWB 8TftUHTyE35/AAV7CZqCk8hoRxTiZifAbseRNEDlgpn+HmhP/FnQi0KrkIzoKnPm apusOXKiCeRy8cS/KfTT/ZHCyCcmQkQxQ8FgOZ8JRDxSo1gIwieBQGCrslriXbot afQvkfBXyGXUT3lu3liDKUTWK9e7vuIU0Nzjd9rXlG1Pf+mcN7wuoNLHzSnabMAu 2L9A+SCE7LbU0hE91vUJ6h1fa8vsxJ8HJ18S5UIslJb0OCf/l1JH1zKOcnHpd0n9 d7G/vtO4mPI3+5Aob2gIFWfyGZs9eCKF8bgNkpRgvNA5cBeJMbbioC/HceySc3T1 xiPHw==
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=fm2; bh=8LQxNhADRKL6pPVtjHokeMvixpVi5o8ON7dF9Brb9 2M=; b=RfrUDmycTQGbeQssKupmqAeIegytgibR28HGUPSUvlrFD8cnGT9HIkc7z E1ZqZtQ0fd23WPUnsNMkUxUrEV9iwMPYbABvxyHWaLJ+es8IbLbLnCllEV43RRcO UDTx+SWpHPRfrGZGsTgkl00JOHZHuSvEti6fa/cP9bFEbGjuRRU3VuMafkSYlPqu mmgWQi/WFexU/UMll/bVRBC80xpHFwTZyXXtvmorM1bZ4hSFqQ4YBdOXNpSD4oFi i9LCw1r+GoAOwl7zBRxZB7rCBfLHhN4UbUMrNZBLFBxflP3YJxsrAGf2WLJFKKCE i7sJa6csvbakazusY8Jp8+3kvq4LA==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtgedgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeeiteduuddvudfftedtuddvgeehtdeuheehjeegledtleekvefgffehfefffeff gfenucffohhmrghinhepihgvthhfrdhorhhgpdhirggsrdhorhhgpdhmnhhothdrnhgvth enucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id C9F2D30663E2; Mon, 18 May 2020 00:16:08 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: <545fb6ac-c8db-dca4-72ac-f7077e3ed7d3@gmail.com>
Date: Mon, 18 May 2020 14:16:02 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <158977114119.21769.9648461727863646464@ietfa.amsl.com> <545fb6ac-c8db-dca4-72ac-f7077e3ed7d3@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-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, 18 May 2020 04:16:14 -0000

Hi Brian,

A good document improved.

A few notes from a quick read:

* S 3.2 says the RSE '[l]eads the community in the design of =
improvements to the RFC Series.' It seems a bit odd to say that this =
position leads the community when we don't yet have a definition of the =
community or any idea how it makes decisions. Perhaps we should figure =
out the leadership afterwards?

* Ibid, the RSE '[i]s responsible for planning and overseeing the =
execution of improvements in the RFC Editor production and access =
processes, in collaboration with IETF LLC as appropriate.' The mention =
of the LLC makes the absence of the community seem deliberate here -- is =
that the case?

* S 5 states: `An assumption in our community is that all actors act in =
good faith, subject of course to normal human failures.  As far as =
possible, the RFC Editor regime needs to be immune to malicious acts of =
any kind. For that reason, it is important that appropriate =
organisational checks and balances are in place.'  This seems odd to me; =
AFAICT we don't stress such immunity in the definition of any other =
leadership positions, and no mention is made of the other reason for =
'appropriate ... checks and balances' -- to assure that the RSE's powers =
are appropriate used.

Cheers,


> On 18 May 2020, at 1:13 pm, Brian E Carpenter =
 wrote:
>=20
> Updated according to my interpretation of the long, complicated =
thread.
> More comments welcome, of course.
>=20
> Prettiest version:
> https://www.ietf.org/id/draft-carpenter-rfc-principles-01.html
>=20
>    Brian
>=20
> -------- Forwarded Message --------
> Subject: I-D Action: draft-carpenter-rfc-principles-01.txt
> Date: Sun, 17 May 2020 20:05:41 -0700
> From: internet-drafts@ietf.org
> Reply-To: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
>        Title           : Principles of the Request for Comments Series
>        Author          : Brian Carpenter
> 	Filename        : draft-carpenter-rfc-principles-01.txt
> 	Pages           : 10
> 	Date            : 2020-05-17
>=20
> Abstract:
>   This document discusses the underlying principles of the Internet
>   technical community's Request for Comments document Series.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-carpenter-rfc-principles/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-carpenter-rfc-principles-01
> =
https://datatracker.ietf.org/doc/html/draft-carpenter-rfc-principles-01
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-carpenter-rfc-principles-01
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

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


From nobody Sun May 17 21:48: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 6EA073A045B for ; Sun, 17 May 2020 21:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 iPyMIsQYDvGm for ; Sun, 17 May 2020 21:48:38 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E2C3A041D for ; Sun, 17 May 2020 21:48:38 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id cx22so1120382pjb.1 for ; Sun, 17 May 2020 21:48:38 -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=/qEiB9MPKUcV7dUpsbVCtMy82T2PXxnwtatDMCuRQao=; b=C5RuCFRghtIfSL19ONkRpWMuAXbhAmWXYdKBojfYNk+sePRr5XikhqOSkh6VfbQBHM gCGE61FQNbkT2BqxXgmd0mKoBTYsPvphvHtUFIzE9/AC70EsJ4JuBbWhMf1K6IwerpYX 943UQhMaZhHaLyIvyupQx9GGBWNn+2fbHJdyrEG93vRrfYFLm46UQE3PO7+ByfJz22EP XM6eRlZszr57DBMHKyyIrRBLJwlvaquSyp4jl5e1nhXOhoC1osdUxUCpXQA2i72vhGkJ n7PUD60nDXUhFDk23N5MdejWJOV5oy3dm9FFT+mFupYhIbZidcPjHMiQaGidXCEw5vkL l4sg==
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=/qEiB9MPKUcV7dUpsbVCtMy82T2PXxnwtatDMCuRQao=; b=Prz1fPnA+mwVIjsJ0TMpCNR9ePxcdVBzPYo4s6pFGu9MueUXahyf/uDQXvWBT73kNg qg4fvWKnpFirwKeCj6tnJQRqR1xTVTCFG2603V/q23lx6JeslW3qVxG87VkmaAChsVvx dv4ZX2SFZMxxsF1LwOwYfUY7+nf/FMDcsJTWRhcGu+SXfrxRZQ4pGsAB8gCoPOwWVgYk Ckg/IsmcsEW2/nOmrK6NHw9n+V2wqQjII2MYQaktwooE7a2jGZHLL1oDw5kstExI2uGY 7ngmWTXMsGZmg/mK+Sft24OoTawPClcMWeZ7STowJNRNQLmMdtRcQNrZh8y2+3nLYwc3 ecMw==
X-Gm-Message-State: AOAM530Sl7oFNdgavdtTk1rOzKJ83z1g2WtqDf5rg48cq+cA6+UrjyHc neORzB1MOUMbZr7bKtXgT5R4Ih88
X-Google-Smtp-Source: ABdhPJzR5XoORVALO8/YU2Vafyoc9x7rC7IEK7t7RsuhtDEbJi/6lmxsPT2KdfcGN3KifQQ78a9m0A==
X-Received: by 2002:a17:90a:2e82:: with SMTP id r2mr17754733pjd.128.1589777317958;  Sun, 17 May 2020 21:48:37 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id m5sm2462207pjn.56.2020.05.17.21.48.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 May 2020 21:48:37 -0700 (PDT)
To: Mark Nottingham 
Cc: rfced-future@iab.org
References: <158977114119.21769.9648461727863646464@ietfa.amsl.com> <545fb6ac-c8db-dca4-72ac-f7077e3ed7d3@gmail.com> 
From: Brian E Carpenter 
Message-ID: <134e18c0-be9d-e2e1-113e-985d8b2d9fd7@gmail.com>
Date: Mon, 18 May 2020 16:48: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: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-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, 18 May 2020 04:48:40 -0000

On 18-May-20 16:16, Mark Nottingham wrote:
> Hi Brian,
> 
> A good document improved.
> 
> A few notes from a quick read:
> 
> * S 3.2 says the RSE '[l]eads the community in the design of improvements to the RFC Series.' It seems a bit odd to say that this position leads the community when we don't yet have a definition of the community or any idea how it makes decisions. Perhaps we should figure out the leadership afterwards?

Well, yes, this is a bit of a chicken-and-egg situation. As you may realise, I lifted this text from the existing model. But somebody has to be the proxy for the community consensus.
 
> * Ibid, the RSE '[i]s responsible for planning and overseeing the execution of improvements in the RFC Editor production and access processes, in collaboration with IETF LLC as appropriate.' The mention of the LLC makes the absence of the community seem deliberate here -- is that the case?

Not really. But since it's the LLC that holds the budget and the contracts, they can't be out of the loop. We will have a slightly double-headed monster as a result.
 
> * S 5 states: `An assumption in our community is that all actors act in good faith, subject of course to normal human failures.  As far as possible, the RFC Editor regime needs to be immune to malicious acts of any kind. For that reason, it is important that appropriate organisational checks and balances are in place.'  This seems odd to me; AFAICT we don't stress such immunity in the definition of any other leadership positions, and no mention is made of the other reason for 'appropriate ... checks and balances' -- to assure that the RSE's powers are appropriate used.

I'll leave that to Carsten who suggested this point. Maybe s/immune to/protected against/ ?

Regards
    Brian

> 
> Cheers,
> 
> 
>> On 18 May 2020, at 1:13 pm, Brian E Carpenter  wrote:
>>
>> Updated according to my interpretation of the long, complicated thread.
>> More comments welcome, of course.
>>
>> Prettiest version:
>> https://www.ietf.org/id/draft-carpenter-rfc-principles-01.html
>>
>>    Brian
>>
>> -------- Forwarded Message --------
>> Subject: I-D Action: draft-carpenter-rfc-principles-01.txt
>> Date: Sun, 17 May 2020 20:05:41 -0700
>> From: internet-drafts@ietf.org
>> Reply-To: internet-drafts@ietf.org
>> To: i-d-announce@ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>>        Title           : Principles of the Request for Comments Series
>>        Author          : Brian Carpenter
>> 	Filename        : draft-carpenter-rfc-principles-01.txt
>> 	Pages           : 10
>> 	Date            : 2020-05-17
>>
>> Abstract:
>>   This document discusses the underlying principles of the Internet
>>   technical community's Request for Comments document Series.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-carpenter-rfc-principles/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-carpenter-rfc-principles-01
>> https://datatracker.ietf.org/doc/html/draft-carpenter-rfc-principles-01
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-carpenter-rfc-principles-01
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> -- 
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 


From nobody Tue May 19 06:14: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 DFF1F3A00D4 for ; Tue, 19 May 2020 06:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level: 
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iivWBY8oCjc0 for ; Tue, 19 May 2020 06:14:38 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE04B3A0A1D for ; Tue, 19 May 2020 06:14:37 -0700 (PDT)
Received: from p200300dee7007a00818703b5b143a604.dip0.t-ipconnect.de ([2003:de:e700:7a00:8187:3b5:b143:a604]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jb24n-0004LQ-P2; Tue, 19 May 2020 15:14:33 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mirja Kuehlewind 
In-Reply-To: <9C534529-4D57-49A9-A8A2-EA1DFEECDA04@mnot.net>
Date: Tue, 19 May 2020 15:14:32 +0200
Cc: Brian E Carpenter , rfced-future@iab.org, Adam Roach , Stephen Farrell 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <158900073744.13624.17132280974290551869@ietfa.amsl.com>  <2a37f6e7-e317-27b4-4810-9ceac2d35670@cs.tcd.ie>  <023601d6285d$587bdb70$09739250$@olddog.co.uk>   <54141152-b9c5-9506-6e4b-5846ad26e3bf@nthpermutation.com>   <61308DBE-53A4-4BBE-8477-850B4B8A23D3@mnot.net>   <943c769e-7966-4572-b426-22ed0ac7c009@www.fastmail.com> <30f06f03-f51a-4063-f782-c179e7a660e4@gmail.com> <237309e0-03b6-630f-9a02-582ac9395457@nostrum.com> <59EEF7E4-263F-4481-B47D-07DCAFE9091A@mnot.net>  <56e855da-6886-b0d4-2264-11123da1f2b8@gmail.com> <9C534529-4D57-49A9-A8A2-EA1DFEECDA04@mnot.net>
To: Mark Nottingham 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1589894078;da75584f;
X-HE-SMSGID: 1jb24n-0004LQ-P2
Archived-At: 
Subject: Re: [Rfced-future] I-D Action: draft-carpenter-rfc-principles-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 13:14:43 -0000

I haven=E2=80=99t been very active yet, as I have the feeling that I =
can=E2=80=99t contribute any thing new at this point of the discussion =
that haven=E2=80=99t been said yet in order to get a common =
understanding of issues/the problem. However, I would like to +1 the =
point below because that also something I have been thinking when =
reading various mails (but goes more into finding a solution than =
describing the problem).


> On 14. May 2020, at 01:44, Mark Nottingham  wrote:
>=20
> IMO we should be looking at devolving the responsibilities of this =
role to multiple people, rather than piling more on. I think it's much =
more tractable if we had, for example, one person who's in charge of =
finding what the consensus of the community regarding strategy is, and =
another to execute that strategy. I suspect those two people with =
different skill sets would be much easier to find than one super-human =
with all of them.


From nobody Sun May 24 17:35: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 9F5D23A0E76 for ; Sun, 24 May 2020 17:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A67CMKqoZCUz for ; Sun, 24 May 2020 17:35:08 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 E39E73A0E74 for ; Sun, 24 May 2020 17:35:07 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id x13so7432281qvr.2 for ; Sun, 24 May 2020 17:35:07 -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-language; bh=eeMF15KBqsAHpt4fXQoZM9IoqrYlllwIn4Ta5bKv45o=; b=UkjkdPPnHy4OPAbiSZRNPfL3wciA0xrqlVaARXO9rDpFQkvnBObrwBsPb4Y88o6718 cTcLYAp0/nM/yKfNenpDzpesmrHl7xMnAVnsj+NVM0WJOKTD+TEvwiBl/L+J2l/LETN2 K748KG3iycaQOE5RLkXvBzNUoL1Jv4+cv9pdla2IuC2QoDtw82W8W0XDaGedYTAWZXk7 xG70bo9KE5sx79J33an0DURTHj6H9Q06kUcpDL3QgIGXu59HnI93G8J+ierZJX9a3TmT AVevjBiTgnLk6KzMX090NR/53X9xqZVmL4+EcBUEFoDWaFq2Qbcs1S84yNyyhWXcTQ4/ tO/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=eeMF15KBqsAHpt4fXQoZM9IoqrYlllwIn4Ta5bKv45o=; b=SPsnGTFR0LpM0uVCEvzZqjxeF4jEPm4NsTRalmzELR6V1qcSmzS8iP01g+cnmU8d2s jUQ9fMzcqRRd70qNM0X9AQJ7x6F+RI+1GzPRLtettPqoK8t/GCv0ma0a/xzpQ4Q/5d95 208DLXDgs6fYE7tGis7eOK07Ueg/Tc+lR9bialkaEt2O4rJ7p3Kr8g/L3AViFlTp8gDF aYLB0usKxpG4fx7Wc49J9UJsKZ+H7JVkXlSPtBKfxJQ4mOZt+otObuVZVp6VC3Fw4h6H bnzFDezlPO5Iy9iRNSFX9qLPXXJuYsSD1vv+9WzAP/423hRwluzAumFNrEY/YgyaxiOa TCtg==
X-Gm-Message-State: AOAM530RNE97v0YVOIQzRqHJm+p/RA4WtMBznA+8W6+3IYc+ggF4hozM mYysMZSdKY9mYnKp4cc4ED7qqyi3WJ0=
X-Google-Smtp-Source: ABdhPJypiKpntoFpSuvkAU+0/UN2CtbED76qOfwAFHvz+8v8J6reW0QW0U3+Pp8aPFKXd2fT21WXaQ==
X-Received: by 2002:a0c:f445:: with SMTP id h5mr12517190qvm.151.1590366906202;  Sun, 24 May 2020 17:35:06 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id o66sm7476115qka.60.2020.05.24.17.35.04 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 May 2020 17:35:05 -0700 (PDT)
To: rfced-future@iab.org
From: Michael StJohns 
Message-ID: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
Date: Sun, 24 May 2020 20:35:03 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------2BB3DFEAD91409BF32B4F618"
Content-Language: en-US
Archived-At: 
Subject: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 00:35:11 -0000

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

Hi - Elliot asked me to write my thought on what elements I might want 
from the outcome of this process - ideally as a delta to the current 
system.   It took me a while to go through the existing documents to get 
an idea of the written baseline.  RFC8728 and RFC8729 mainly.  I found 
myself in agreement with quite a large portion of those documents, 
especially with respect to the actual RFC Series Editor and RPC roles.  
What I found myself less sanguine with were the various sections that 
dealt with "oversight".  To be blunt, I believe that having either the 
IAB or IESG directly manage other resources  or contracts is not 
tenable.  The criteria of "able to manage a contract or employee" is not 
and has never been a criteria for selection of either an IESG or IAB 
member and the delegation of that responsibility to the RSOC does not 
appear to have been successful.

  * My general desire is to see an RFC publication system  that retains
    and perhaps expands its global impact and the generally wide respect
    for its quality and reach.
  * I'd like the people who make up the system to be professionals with
    the ability to continue to help this community publish a wide range
    of documents that help "make the Internet work better by ...
    influenc[ing] the way people design, use, and manage the Internet".
  * I'd like us to treat said professionals at least as well as we treat
    ourselves.
  * I'd like a system that evolves over time, and that is relatively
    immune to influence from relatively few people over a relatively
    short period of time.
  * I'd like a system that's responsible and accountable to the
    community directly rather than through the two layers of indirection
    we currently have.
  * I'd like some large measure of independence to be retained by this
    publication system and that the member's of that system voices are
    heard and honored as full partners and not "just a contractor[s]".
  * I'd like the RFC publication system to be stable in the face of
    unforeseen challenges and be able to gain (or regain) and retain
    institutional memory.
  * I'd really prefer that we don't have to do this again for another 10
    years.
  * I'd also prefer that once we have an RSE, we assume we keep them
    (after a probationary period) until they get tired of us, or they
    really mess up.

Those are my desires and I could stop there.   But I though I'd provide 
a sketch of how things might be restructured - this is provided not as a 
fleshed out proposal, but as a thought experiment to show that I think 
it's possible to have both independence and accountability:


___________________________________

The oversight for the RFC Publication System shall vest in an RFC Series 
editorial board (RSEB) consisting of 4 at large members selected through 
the Nomcom process for staggered 4 year terms (with a maximum of 1 
renewal) plus the RSE as the chair, plus the Stream managers (who must 
not be the chair of the particular board that appoints them).  The 
senior at-large member is the deputy chair and acts as chair in any 
matter in which the RSE is recused or not available.  The RSEB shall act 
by voting, but shall try to achieve consensus.

The RPC shall appoint a non-voting observer to the RSEB.    The RSEB may 
select an Executive Director or secretary for the RSEB.

The RSE may recommend that any document not be published and with a 
majority vote by the RSEB prohibit publication.   This shall generally 
be a last resort after negotiation with the publication stream over 
perceived problems.

The RSEB (minus the RSE) is the search committee for new RSEs.  They 
make the hiring recommendation to the LLC board.

The at-large members are selected for their experience in the IETF and 
their experience with publication systems with the latter given more 
weight.  They are selected through the normal Nomcom process, and 
approved by the LLC.

The at-large members must approve the ISE (who is nominated by the 
IAB).  Tie votes are broken by the RSE.

The stream managers for the IAB, IRTF and IESG(Standards) represent the 
groups that they come from, and are expected to consult with them on any 
non-routine matters.  They are reappointed each year as their respective 
bodies reform after the Nomcom process.

Each stream manager (including the ISE) shall provide a PUBLIC annual 
assessment of at least a page of how the RSE/RFC publication system is 
meeting or not meeting their needs.

The RSE shall provide an annual public report of the numbers and types 
of problems corrected on submitted documents.  This report shall be 
broken down by stream and shall be used to identify remedial actions for 
the production of documents from each stream.

The RSEB will consider the public assessments and provide a PUBLIC 
annual response approved by a majority of the board.

The RSEB (minus the RSE) will make a private recommendation to the LLC 
not later than 6 months prior to contract renewal (if the RSE is a 
contractor) or not more often than every 2 years (if an employee) on the 
continuance of the RSE.  The recommendation must be approved by the 
majority of the RSEB but may contain additional comments by any member 
for or against the recommendation and identified as originating from 
them. If the RSEB is unable to approve the report due to a lack of a 
majority, the report shall be forwarded without the recommendation but 
with any individual commentary. If the recommendation is for termination 
or non-renewal, the LLC shall share a redacted summary of the 
recommendation including any vote counts to the RSE, but not the actual 
positions taken by any member of the board.  The RSE is allowed to make 
a public or a private statement to the LLC with respect to the 
recommendation.

The LLC is the hiring entity for the RSE and bears all responsibilities 
normally attributed to a hiring entity.  The LLC is solely responsible 
for accepting or rejecting the recommendation of the RSEB with respect 
to the hiring or continuation of the RSE.   The LLC must make its own 
evaluation of the RSE performance rather than rely on the RSEB 
recommendation.

The RSEB by a 3/4 vote and with concurrence of the LLC (who must sign 
off on any costs) may add or remove streams.  Streams may be proposed by 
any entity in the form of an Informational RFC on the Independent stream.

Documents that touch on the RSE or RFC Publication System models shall 
be published after a community wide last call and with the majority 
approval of the RSEB.  Any document that changes the roles or 
responsibilities of the RSE or RPC which would require contract or job 
description changes also requires approval of the LLC.

____________________

As you may guess, the above is mostly to fix what I perceive is a 
problem with the IAB and RSOC oversight of the RFC series.   You may 
have other ideas or may hate mine.   Feel free to take exception to the 
broad strokes or propose your own, but for now let's try and avoid 
twiddling the fine points (e.g. "I really think there should be 3 at 
large members" would be twiddling the fine points).

Later, Mike




--------------2BB3DFEAD91409BF32B4F618
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Hi - Elliot asked me to write my thought on what elements I might
      want from the outcome of this process - ideally as a delta to the
      current system.   It took me a while to go through the existing
      documents to get an idea of the written baseline.  RFC8728 and
      RFC8729 mainly.  I found myself in agreement with quite a large
      portion of those documents, especially with respect to the actual
      RFC Series Editor and RPC roles.  What I found myself less
      sanguine with were the various sections that dealt with
      "oversight".  To be blunt, I believe that having either the IAB or
      IESG directly manage other resources  or contracts is not
      tenable.  The criteria of "able to manage a contract or employee"
      is not and has never been a criteria for selection of either an
      IESG or IAB member and the delegation of that responsibility to
      the RSOC does not appear to have been successful.  

    

    
    
      
  • My general desire is to see an RFC publication system  that
        retains and perhaps expands its global impact and the generally
        wide respect for its quality and reach.  
    
      
    • 
      
  • I'd like the people who make up the system to be professionals
        with the ability to continue to help this community publish a
        wide range of documents that help "make the Internet work better by ...
            influenc[ing] the way people design, use, and manage the
            Internet". 
    
          
    • 
      
  • I'd like us to treat
            said professionals at least as well as we treat ourselves.  
            
    
          
    • 
      
  • I'd like a system
            that evolves over time, and that is relatively immune to
            influence from relatively few people over a relatively short
            period of time.  
    
          
    • 
      
  • I'd like a system
            that's responsible and accountable to the community directly
            rather than through the two layers of indirection we
            currently have.  
    
          
    • 
      
  • I'd like some large
            measure of independence to be retained by this publication
            system and that the member's of that system voices are heard
            and honored as full partners and not "just a
            contractor[s]".  
    
          
    • 
      
  • I'd like the RFC
            publication system to be stable in the face of unforeseen
            challenges and be able to gain (or regain) and retain
            institutional memory.  
    
          
    • 
      
  • I'd really prefer
            that we don't have to do this again for another 10 years.  
    
          
    • 
      
  • I'd also prefer that
            once we have an RSE, we assume we keep them (after a
            probationary period) until they get tired of us, or they
            really mess up.
    
          
    • 
    

    
Those are my desires
          and I could stop there.   But I though I'd provide a sketch of
          how things might be restructured - this is provided not as a
          fleshed out proposal, but as a thought experiment to show that
          I think it's possible to have both independence and
          accountability:

    


        

    
___________________________________

        

    
The oversight for the
          RFC Publication System shall vest in an RFC Series editorial
          board (RSEB) consisting of 4 at large members selected through
          the Nomcom process for staggered 4 year terms (with a maximum
          of 1 renewal) plus the RSE as the chair, plus the Stream
          managers (who must not be the chair of the particular board
          that appoints them).  The senior at-large member is the deputy
          chair and acts as chair in any matter in which the RSE is
          recused or not available.  The RSEB shall act by voting, but
          shall try to achieve consensus.

    
The RPC shall appoint a
          non-voting observer to the RSEB.    The RSEB may select an
          Executive Director or secretary for the RSEB. 

        

    
The RSE may recommend
          that any document not be published and with a majority vote by
          the RSEB prohibit publication.   This shall generally be a
          last resort after negotiation with the publication stream over
          perceived problems.

        

    
The RSEB (minus the
          RSE) is the search committee for new RSEs.  They make the
          hiring recommendation to the LLC board. 

        

    
The at-large members
          are selected for their experience in the IETF and their
          experience with publication systems with the latter given more
          weight.  They are selected through the normal Nomcom process,
          and approved by the LLC.  

        

    
The at-large members
          must approve the ISE (who is nominated by the IAB).  Tie votes
          are broken by the RSE.

    
The stream managers for
          the IAB, IRTF and IESG(Standards) represent the groups that
          they come from, and are expected to consult with them on any
          non-routine matters.  They are reappointed each year as their
          respective bodies reform after the Nomcom process.

        

    
Each stream manager
          (including the ISE) shall provide a PUBLIC annual assessment
          of at least a page of how the RSE/RFC publication system is
          meeting or not meeting their needs.  

        

    
The RSE shall provide
          an annual public report of the numbers and types of problems
          corrected on submitted documents.  This report shall be broken
          down by stream and shall be used to identify remedial actions
          for the production of documents from each stream.

        

    
The RSEB will consider
          the public assessments and provide a PUBLIC annual response
          approved by a majority of the board.

    
The RSEB (minus the
          RSE) will make a private recommendation to the LLC not later
          than 6 months prior to contract renewal (if the RSE is a
          contractor) or not more often than every 2 years (if an
          employee) on the continuance of the RSE.  The recommendation
          must be approved by the majority of the RSEB but may contain
          additional comments by any member for or against the
          recommendation and identified as originating from them.   If the RSEB is unable to
          approve the report due to a lack of a majority, the report
          shall be forwarded without the recommendation but with any
          individual commentary. If the recommendation is for termination or
          non-renewal, the LLC shall share a redacted summary of the
          recommendation including any vote counts to the RSE, but not
          the actual positions taken by any member of the board.  The
          RSE is allowed to make a public or a private statement to the
          LLC with respect to the recommendation. 

        

    
The LLC is the hiring
          entity for the RSE and bears all responsibilities normally
          attributed to a hiring entity.  The LLC is solely responsible
          for accepting or rejecting the recommendation of the RSEB with
          respect to the hiring or continuation of the RSE.   The LLC
          must make its own evaluation of the RSE performance rather
          than rely on the RSEB recommendation.

        

    
The RSEB by a 3/4 vote
          and with concurrence of the LLC (who must sign off on any
          costs) may add or remove streams.  Streams may be proposed by
          any entity in the form of an Informational RFC on the
          Independent stream.

        

    
Documents that touch on
          the RSE or RFC Publication System models shall be published
          after a community wide last call and with the majority
          approval of the RSEB.  Any document that changes the roles or
          responsibilities of the RSE or RPC which would require
          contract or job description changes also requires approval of
          the LLC.

        

    
____________________

    
As you may guess, the
          above is mostly to fix what I perceive is a problem with the
          IAB and RSOC oversight of the RFC series.   You may have other
          ideas or may hate mine.   Feel free to take exception to the
          broad strokes or propose your own, but for now let's try and
          avoid twiddling the fine points (e.g. "I really think there
          should be 3 at large members" would be twiddling the fine
          points).

    
Later, Mike

    


        

    


    

  


--------------2BB3DFEAD91409BF32B4F618--


From nobody Sun May 24 18:06: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 6B8D73A0C1D for ; Sun, 24 May 2020 18:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=UzIJ6Euq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Uy5u7MnE
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVZJG42U4vHt for ; Sun, 24 May 2020 18:06:35 -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 81E9B3A0AE4 for ; Sun, 24 May 2020 18:06:35 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C96735C0062; Sun, 24 May 2020 21:06:34 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 24 May 2020 21:06:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=r TWk5rsnE9lyuBlm8O+616fe1bUWvspmop8k1YG0l3c=; b=UzIJ6Euq5GckIQRJ3 O8HuzFDQiRhr9te3X213eModxZpXzDLgAkb2D+2epHwD66vctXUEm8bQzwZ3RzuJ 5X8I+cDclA/FoKeZMHCvbysjnYASBDZnG4/7QssD6WvUT9b+72VzgkJRtxs6oETU AJBK1KVYuGH2rgG1hgZ1tdOzRZYSpeV0eH+b7QEMP3uY0pEdZD68kXtoxytf5qGB bcH5K0UAoF1R0e7GrHZOwQlFbDYlIAj4kZTBuRRA5XN4cCpNvqYXMEP6NIhrbeX4 3lkXRjcMGDbRiJeKajGXj1PzHnE1WwMQD8Y/Ll/BWGXewdDyFMDE64+qIxxI8gKU q4C4Q==
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=fm2; bh=rTWk5rsnE9lyuBlm8O+616fe1bUWvspmop8k1YG0l 3c=; b=Uy5u7MnEHrvY5Y6wlQrvgRyDmuXYi1ksNj3quJreNSRuVvjYCOUnkopNN +4qEZLKF+an2QZhIqYA4GkUDIYids5sf/MM9nYjD/D4XTbWKsxNWqtJt2PEVMyvS iurFxxU62OjVK1IAu85SualBMtHpIJpU0XspBT1YZt/9ZqINPRbdt/EfWwueqlty DGBqk5VH4NWGkWxM1qCC565/R/eGgg2aQtI6oGYttfSGvFF2rnAwohn6PBQOazy+ 4+1Z7a+NiIepNDB6TewqwBBqkxnO4AqEudsAzdXqEp2/acAAesg1gLyAfSHOm5B3 vYuG96lcfRZJ9ZlwLkMrKuErvBRAw==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduledggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepteefleffjeffhfehheeffeegudelgf eujedukeeigedvgeehffefvdehffeileeknecuffhomhgrihhnpehmnhhothdrnhgvthen ucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id A3EE3328005D; Sun, 24 May 2020 21:06:32 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
Date: Mon, 25 May 2020 11:06:29 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <47B122E0-C69A-40CB-AE2A-B0B378367743@mnot.net>
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
To: Michael StJohns 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 01:06:39 -0000

Hi Mike,

> On 25 May 2020, at 10:35 am, Michael StJohns  =
wrote:
>=20
> Hi - Elliot asked me to write my thought on what elements I might want =
from the outcome of this process - ideally as a delta to the current =
system.   It took me a while to go through the existing documents to get =
an idea of the written baseline.  RFC8728 and RFC8729 mainly.  I found =
myself in agreement with quite a large portion of those documents, =
especially with respect to the actual RFC Series Editor and RPC roles.  =
What I found myself less sanguine with were the various sections that =
dealt with "oversight".  To be blunt, I believe that having either the =
IAB or IESG directly manage other resources  or contracts is not =
tenable.  The criteria of "able to manage a contract or employee" is not =
and has never been a criteria for selection of either an IESG or IAB =
member and the delegation of that responsibility to the RSOC does not =
appear to have been successful. =20
>=20
> 	=E2=80=A2 My general desire is to see an RFC publication system  =
that retains and perhaps expands its global impact and the generally =
wide respect for its quality and reach. =20
> 	=E2=80=A2 I'd like the people who make up the system to be =
professionals with the ability to continue to help this community =
publish a wide range of documents that help "make the Internet work =
better by ... influenc[ing] the way people design, use, and manage the =
Internet".=20

I think I agree with all of the above. It does make me think that we =
might be more successful if the decision-making / leadership role were =
carved away from the "contracting" role (i.e., the publisher-centric =
aspects); that might help avoid the need to have a special oversight =
function for the contractor/specialist.

> 	=E2=80=A2 I'd like us to treat said professionals at least as =
well as we treat ourselves.  =20

This is a low bar; we treat ourselves pretty badly.

> 	=E2=80=A2 I'd like a system that evolves over time, and that is =
relatively immune to influence from relatively few people over a =
relatively short period of time. =20

If I parse correctly, I think I agree.=20

> 	=E2=80=A2 I'd like a system that's responsible and accountable =
to the community directly rather than through the two layers of =
indirection we currently have. =20

Agreed, as long as that's transparent. Having someone who goes and talks =
to different parts of the community and then makes a decision based upon =
those conversations isn't accountable; they get to choose their facts =
(deliberately or not). We need a system where the consensus of the =
community can be judged by all because we have a shared discourse about =
the series, rather than a piecemeal one.

> 	=E2=80=A2 I'd like some large measure of independence to be =
retained by this publication system and that the member's of that system =
voices are heard and honored as full partners and not "just a =
contractor[s]". =20

I think we still need to explore this notion of independence and what it =
brings. Asserting that it's important isn't adequate.

> 	=E2=80=A2 I'd like the RFC publication system to be stable in =
the face of unforeseen challenges and be able to gain (or regain) and =
retain institutional memory. =20
> 	=E2=80=A2 I'd really prefer that we don't have to do this again =
for another 10 years. =20
> 	=E2=80=A2 I'd also prefer that once we have an RSE, we assume we =
keep them (after a probationary period) until they get tired of us, or =
they really mess up.

I'd hope so.

> Those are my desires and I could stop there.   But I though I'd =
provide a sketch of how things might be restructured - this is provided =
not as a fleshed out proposal, but as a thought experiment to show that =
I think it's possible to have both independence and accountability:
>=20
>=20
>=20
> ___________________________________
>=20
> The oversight for the RFC Publication System shall vest in an RFC =
Series editorial board (RSEB) consisting of 4 at large members selected =
through the Nomcom process for staggered 4 year terms (with a maximum of =
1 renewal) plus the RSE as the chair, plus the Stream managers (who must =
not be the chair of the particular board that appoints them).  The =
senior at-large member is the deputy chair and acts as chair in any =
matter in which the RSE is recused or not available.  The RSEB shall act =
by voting, but shall try to achieve consensus.
>=20
> The RPC shall appoint a non-voting observer to the RSEB.    The RSEB =
may select an Executive Director or secretary for the RSEB.=20
>=20
> The RSE may recommend that any document not be published and with a =
majority vote by the RSEB prohibit publication.   This shall generally =
be a last resort after negotiation with the publication stream over =
perceived problems.

If you're not constraining this to editorial matters, you're talking =
about a radical change in how the RFC Series works -- one that I think =
would be surprising and undesirable to the vast majority of the =
community.

If you really want to pursue this, let's put the question to the =
community and see what the reactions are. Even in this limited group so =
far, you're pretty much a lone voice on this, AFAICT.

> The RSEB (minus the RSE) is the search committee for new RSEs.  They =
make the hiring recommendation to the LLC board.=20
>=20
> The at-large members are selected for their experience in the IETF and =
their experience with publication systems with the latter given more =
weight.  They are selected through the normal Nomcom process, and =
approved by the LLC.
>=20
> The at-large members must approve the ISE (who is nominated by the =
IAB).  Tie votes are broken by the RSE.

Is this in scope for this program? I suspect not.

> The stream managers for the IAB, IRTF and IESG(Standards) represent =
the groups that they come from, and are expected to consult with them on =
any non-routine matters.  They are reappointed each year as their =
respective bodies reform after the Nomcom process.
>=20
> Each stream manager (including the ISE) shall provide a PUBLIC annual =
assessment of at least a page of how the RSE/RFC publication system is =
meeting or not meeting their needs. =20

That sounds useful, but still a really indirect way of getting feedback =
from the community to the RSE.

> The RSE shall provide an annual public report of the numbers and types =
of problems corrected on submitted documents.  This report shall be =
broken down by stream and shall be used to identify remedial actions for =
the production of documents from each stream.

We should get feedback from the RPC about how much extra work keeping =
these numbers will be, and how hard it is to categorise them.

> The RSEB will consider the public assessments and provide a PUBLIC =
annual response approved by a majority of the board.
>=20
> The RSEB (minus the RSE) will make a private recommendation to the LLC =
not later than 6 months prior to contract renewal (if the RSE is a =
contractor) or not more often than every 2 years (if an employee) on the =
continuance of the RSE.  The recommendation must be approved by the =
majority of the RSEB but may contain additional comments by any member =
for or against the recommendation and identified as originating from =
them.  If the RSEB is unable to approve the report due to a lack of a =
majority, the report shall be forwarded without the recommendation but =
with any individual commentary. If the recommendation is for termination =
or non-renewal, the LLC shall share a redacted summary of the =
recommendation including any vote counts to the RSE, but not the actual =
positions taken by any member of the board.  The RSE is allowed to make =
a public or a private statement to the LLC with respect to the =
recommendation.=20
>=20
> The LLC is the hiring entity for the RSE and bears all =
responsibilities normally attributed to a hiring entity.  The LLC is =
solely responsible for accepting or rejecting the recommendation of the =
RSEB with respect to the hiring or continuation of the RSE.   The LLC =
must make its own evaluation of the RSE performance rather than rely on =
the RSEB recommendation.
>=20
> The RSEB by a 3/4 vote and with concurrence of the LLC (who must sign =
off on any costs) may add or remove streams.  Streams may be proposed by =
any entity in the form of an Informational RFC on the Independent =
stream.

This is a surprising amount of power to give to relatively few people; =
one where mistakes will be very difficult to correct.

> Documents that touch on the RSE or RFC Publication System models shall =
be published after a community wide last call and with the majority =
approval of the RSEB.  Any document that changes the roles or =
responsibilities of the RSE or RPC which would require contract or job =
description changes also requires approval of the LLC.
>=20
> ____________________
>=20
> As you may guess, the above is mostly to fix what I perceive is a =
problem with the IAB and RSOC oversight of the RFC series.   You may =
have other ideas or may hate mine.   Feel free to take exception to the =
broad strokes or propose your own, but for now let's try and avoid =
twiddling the fine points (e.g. "I really think there should be 3 at =
large members" would be twiddling the fine points).

Fair enough.

Your proposal is indeed pretty focused on that one perceived problem; =
AFACT it's basically taking the RSOC out of the IAB's hands and making =
it Nomcom-selected, with some accountability measures.

That might address the problems that you perceive, but on first reading, =
it doesn't address a number of the problems that I perceive. So, I'll =
try to write something along the same lines this week, and we'll see =
where that gets us.

Cheers,

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


From nobody Sun May 24 18:55: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 E1F2B3A003E for ; Sun, 24 May 2020 18:55: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, 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 SmCuBf41vuEP for ; Sun, 24 May 2020 18:55:03 -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 D46973A00E2 for ; Sun, 24 May 2020 18:55:02 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id ci23so7864800pjb.5 for ; Sun, 24 May 2020 18:55:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=GxQ70Hn908x3OhFPNAWuRo7jH5DZR+9SJAmlaYhEcGI=; b=YiVpB/Y1A9CgT+8//4dXCxuuiF84+trDNnSvivuoChZ5e3P7mRxGrqhC8UIufbBcV+ 3o+QXrFqamaqioYk6XpX7rGYBW3/iUgDQT/YYkCyK4nHfsmR1PGGFOSE/1/HRwBIoY9G ipfX+e+K3ETp7DaBnec7n41QO2F6Z1LjF2t258pMLvVzactdOf4OfMh836seukJKugVb wsGfdYDDNf43ISx3BEp+8e8Y1+NrJ1ZOy14WhwiPRc6105ucDHaZjdPJyROMFart++Y3 VOIV91DNX990R6O+y80P0z280Z45EmH5qZ8Rr3HaQk1dBQk86q/GoNCnsxQDhdiKo+SC Li5Q==
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=GxQ70Hn908x3OhFPNAWuRo7jH5DZR+9SJAmlaYhEcGI=; b=BRidGAVD4ryJRlr3nHlhBOscygfKFywJyfm8qV26OB3qR+ZPxcwEIjv8Q3zRGJJVVU zveyYiWSiTFQB17J/IaQdVy0erEePKh+UCgZOmQZjxDS5PYP2GpRufVxDXU6ZYLknPIw TSQhY4+4BIy6dQlhsutUtQA2H+vt/Cr4xUWgyzTjNR/dV0pCjJx9QuRYy6v2ILebIGL3 oDTjIYmFs4+Rj89uwrpwadlJ8J+1CSIYPuzJ31tkT1pvSWxeHWagCrNv0HaEZ2H84gUy 3FxnsR23S15fZxp789chd/CdsOkM4TLZFr5jX7FmNZ+Ii7DgMyKLuz9t9P2sE6BX7RjS h21w==
X-Gm-Message-State: AOAM532FBr3H+GeVrKTp97t2r0ft+pT71Nsqg7IOpUFyHb5Ub/mZxk4p Lf/+iDx4Mw2hyKzkW/2pbtfazUdp
X-Google-Smtp-Source: ABdhPJx5m1A22Wf3FzL51SI7tbntsoMZYPSYQc93wGyXPXd7fcGrCmlckyuyKIwcL6TmeNznwFv8gg==
X-Received: by 2002:a17:90a:19c9:: with SMTP id 9mr18508720pjj.77.1590371701719;  Sun, 24 May 2020 18:55:01 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id 10sm11642414pfx.138.2020.05.24.18.54.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 May 2020 18:55:01 -0700 (PDT)
To: Michael StJohns , rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
From: Brian E Carpenter 
Message-ID: <5c33a5fe-1fe4-1bfa-7382-9c1ca9f4f345@gmail.com>
Date: Mon, 25 May 2020 13:54: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: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 01:55:05 -0000

So, Mike, take this as a friendly challenge, since I generally like what =
you wrote:

>  a system that's responsible and accountable to the community directly

Yes, more or less what my draft says too.

> The at-large members are selected for their experience in the IETF and =
their experience with publication systems with the latter given more weig=
ht.  They are selected through the normal Nomcom process

How do we reach the whole candidate pool? Where do we send the call for n=
ominations? We clearly want a wider spread than traditionally, if we are =
really trying to cover the whole RFC-using community. In fact, I don't se=
e why IETF experience is the first criterion. Experience writing code or =
running networks based on RFCs seems equally important.

Regards
   Brian Carpenter

On 25-May-20 12:35, Michael StJohns wrote:
> Hi - Elliot asked me to write my thought on what elements I might want =
from the outcome of this process - ideally as a delta to the current syst=
em.=C2=A0=C2=A0 It took me a while to go through the existing documents t=
o get an idea of the written baseline.=C2=A0 RFC8728 and RFC8729 mainly.=C2=
=A0 I found myself in agreement with quite a large portion of those docum=
ents, especially with respect to the actual RFC Series Editor and RPC rol=
es.=C2=A0 What I found myself less sanguine with were the various section=
s that dealt with "oversight".=C2=A0 To be blunt, I believe that having e=
ither the IAB or IESG directly manage other resources=C2=A0 or contracts =
is not tenable.=C2=A0 The criteria of "able to manage a contract or emplo=
yee" is not and has never been a criteria for selection of either an IESG=
 or IAB member and the delegation of that responsibility to the RSOC does=
 not appear to have been successful.=C2=A0
>=20
>   * My general desire is to see an RFC publication system=C2=A0 that re=
tains and perhaps expands its global impact and the generally wide respec=
t for its quality and reach.=C2=A0
>   * I'd like the people who make up the system to be professionals with=
 the ability to continue to help this community publish a wide range of d=
ocuments that help "make the Internet work better by ... influenc[ing] th=
e way people design, use, and manage the Internet".
>   * I'd like us to treat said professionals at least as well as we trea=
t ourselves.=C2=A0=C2=A0
>   * I'd like a system that evolves over time, and that is relatively im=
mune to influence from relatively few people over a relatively short peri=
od of time.=C2=A0
>   * I'd like a system that's responsible and accountable to the communi=
ty directly rather than through the two layers of indirection we currentl=
y have.=C2=A0
>   * I'd like some large measure of independence to be retained by this =
publication system and that the member's of that system voices are heard =
and honored as full partners and not "just a contractor[s]".=C2=A0
>   * I'd like the RFC publication system to be stable in the face of unf=
oreseen challenges and be able to gain (or regain) and retain institution=
al memory.=C2=A0
>   * I'd really prefer that we don't have to do this again for another 1=
0 years.=C2=A0
>   * I'd also prefer that once we have an RSE, we assume we keep them (a=
fter a probationary period) until they get tired of us, or they really me=
ss up.
>=20
> Those are my desires and I could stop there.=C2=A0=C2=A0 But I though I=
'd provide a sketch of how things might be restructured - this is provide=
d not as a fleshed out proposal, but as a thought experiment to show that=
 I think it's possible to have both independence and accountability:
>=20
>=20
> ___________________________________
>=20
> The oversight for the RFC Publication System shall vest in an RFC Serie=
s editorial board (RSEB) consisting of 4 at large members selected throug=
h the Nomcom process for staggered 4 year terms (with a maximum of 1 rene=
wal) plus the RSE as the chair, plus the Stream managers (who must not be=
 the chair of the particular board that appoints them).=C2=A0 The senior =
at-large member is the deputy chair and acts as chair in any matter in wh=
ich the RSE is recused or not available.=C2=A0 The RSEB shall act by voti=
ng, but shall try to achieve consensus.
>=20
> The RPC shall appoint a non-voting observer to the RSEB.=C2=A0 =C2=A0 T=
he RSEB may select an Executive Director or secretary for the RSEB.
>=20
> The RSE may recommend that any document not be published and with a maj=
ority vote by the RSEB prohibit publication.=C2=A0=C2=A0 This shall gener=
ally be a last resort after negotiation with the publication stream over =
perceived problems.
>=20
> The RSEB (minus the RSE) is the search committee for new RSEs.=C2=A0 Th=
ey make the hiring recommendation to the LLC board.
>=20
> The at-large members are selected for their experience in the IETF and =
their experience with publication systems with the latter given more weig=
ht.=C2=A0 They are selected through the normal Nomcom process, and approv=
ed by the LLC.=C2=A0
>=20
> The at-large members must approve the ISE (who is nominated by the IAB)=
=2E=C2=A0 Tie votes are broken by the RSE.
>=20
> The stream managers for the IAB, IRTF and IESG(Standards) represent the=
 groups that they come from, and are expected to consult with them on any=
 non-routine matters.=C2=A0 They are reappointed each year as their respe=
ctive bodies reform after the Nomcom process.
>=20
> Each stream manager (including the ISE) shall provide a PUBLIC annual a=
ssessment of at least a page of how the RSE/RFC publication system is mee=
ting or not meeting their needs.=C2=A0
>=20
> The RSE shall provide an annual public report of the numbers and types =
of problems corrected on submitted documents.=C2=A0 This report shall be =
broken down by stream and shall be used to identify remedial actions for =
the production of documents from each stream.
>=20
> The RSEB will consider the public assessments and provide a PUBLIC annu=
al response approved by a majority of the board.
>=20
> The RSEB (minus the RSE) will make a private recommendation to the LLC =
not later than 6 months prior to contract renewal (if the RSE is a contra=
ctor) or not more often than every 2 years (if an employee) on the contin=
uance of the RSE.=C2=A0 The recommendation must be approved by the majori=
ty of the RSEB but may contain additional comments by any member for or a=
gainst the recommendation and identified as originating from them.=C2=A0 =
If the RSEB is unable to approve the report due to a lack of a majority, =
the report shall be forwarded without the recommendation but with any ind=
ividual commentary. If the recommendation is for termination or non-renew=
al, the LLC shall share a redacted summary of the recommendation includin=
g any vote counts to the RSE, but not the actual positions taken by any m=
ember of the board.=C2=A0 The RSE is allowed to make a public or a privat=
e statement to the LLC with respect to the recommendation.
>=20
> The LLC is the hiring entity for the RSE and bears all responsibilities=
 normally attributed to a hiring entity.=C2=A0 The LLC is solely responsi=
ble for accepting or rejecting the recommendation of the RSEB with respec=
t to the hiring or continuation of the RSE.=C2=A0=C2=A0 The LLC must make=
 its own evaluation of the RSE performance rather than rely on the RSEB r=
ecommendation.
>=20
> The RSEB by a 3/4 vote and with concurrence of the LLC (who must sign o=
ff on any costs) may add or remove streams.=C2=A0 Streams may be proposed=
 by any entity in the form of an Informational RFC on the Independent str=
eam.
>=20
> Documents that touch on the RSE or RFC Publication System models shall =
be published after a community wide last call and with the majority appro=
val of the RSEB.=C2=A0 Any document that changes the roles or responsibil=
ities of the RSE or RPC which would require contract or job description c=
hanges also requires approval of the LLC.
>=20
> ____________________
>=20
> As you may guess, the above is mostly to fix what I perceive is a probl=
em with the IAB and RSOC oversight of the RFC series.=C2=A0=C2=A0 You may=
 have other ideas or may hate mine.=C2=A0=C2=A0 Feel free to take excepti=
on to the broad strokes or propose your own, but for now let's try and av=
oid twiddling the fine points (e.g. "I really think there should be 3 at =
large members" would be twiddling the fine points).
>=20
> Later, Mike
>=20
>=20
>=20
>=20


From nobody Sun May 24 18:56: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 F3D333A0045 for ; Sun, 24 May 2020 18:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIB_v5qRAaro for ; Sun, 24 May 2020 18:56:23 -0700 (PDT)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469CE3A003E for ; Sun, 24 May 2020 18:56:23 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id o13so12780051otl.5 for ; Sun, 24 May 2020 18:56:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kuz33OU5MswuPAEHHm14OjUw0CWigIHTHqL4hVfK/6M=; b=r4xjUzVgtv7a4H+YbecOtaCx1BsXefN5D7qHjr8gS+RUUPw52VIDc3NFy9fUhWGx68 qk+JA3seDC8QCm2eQfJgC2V4nvlNIZfPWi/vqzNSTAueuLSksvzUy2aMrcGcPxzM7lDR qIah0jOHXjyXFBt++PuR4BRL6R7EkchjM7wtezJVBLYzPxlsf1ujUA3f7dbIWyzyeeWl wSKguU3UYImg9hoEkp0FHsteHz62HSze3DsGD2kCld0X2GhYU16GVXdOdbTULH6eVsRE 2BzJDbp85eB8TuV7CacafgE/zYqelJTgy3Y/5JszVuTwQfiNU2CIWDFN9bpAKIalNIRn FezA==
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=Kuz33OU5MswuPAEHHm14OjUw0CWigIHTHqL4hVfK/6M=; b=amlcIipanZjRZVJ/0qFA3WypMGZ4Twi03aP5JsFXoNc4RVLMqY30pH4qR5oHoA/QZo V9wDa0/zd0zgyhps1MfeICaRImnupmQraDz2veKuH0UxNzmNGAIDCuf3kwnm26fA0Z9a /noCHAWNGWTRJxegLLraZDsRnVu08F3qugGKy6NdIJ9BpqGeeVuwUZrVoPVSYD0OptYW TxnY0ofvDqmMZ+uiB3xwwmrnHVLuWCjSJfnFhATMpQ89AoKbR5QOvFB9Nq8IyTQX57TF tdR9MdHJbKK5ZE3TSKwnEf+zaht/+JAJXIfrwvFnRsacsULfO4hXFLgtDjWFkEBZi+5P 3o7g==
X-Gm-Message-State: AOAM533vu2yBqrBezPMwFbx5vq3gjy7BsiUFtjEw8+XDMzbLtmQUfbls MDK7Zl3jm6fev36dGXBsv0To8BA32kLAHKeQh2GEFcL6b94=
X-Google-Smtp-Source: ABdhPJw7eZoT5uc80TpObZjhRJ8k+vz0ZhwzYHLr3D3yWI5arf87j8DYNtMAq2lowtizyzfMCv1cJhrXTIkJINqj7nM=
X-Received: by 2002:a05:6830:d3:: with SMTP id x19mr19837656oto.158.1590371782567;  Sun, 24 May 2020 18:56:22 -0700 (PDT)
MIME-Version: 1.0
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
In-Reply-To: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
From: Tim Wicinski 
Date: Sun, 24 May 2020 21:56:11 -0400
Message-ID: 
To: Michael StJohns 
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000002929fa05a66f4990"
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 01:56:26 -0000

--0000000000002929fa05a66f4990
Content-Type: text/plain; charset="UTF-8"

Michael

I really agree with your first section.  You talk about making them full
partners, and I can see this going
another step.  I see the RFC publication system not just work on documents,
but be our voice in other corners of other
technical communities. People ask me at times "so why are the IETF RFCs so
much better than other systems", and
I can say a few words, then I struggle to speak eloquently on the topic.
This role should be empowered (and funded)
to do so.

I still need to work through your second section.

thanks
tim

On Sun, May 24, 2020 at 8:35 PM Michael StJohns 
wrote:

> Hi - Elliot asked me to write my thought on what elements I might want
> from the outcome of this process - ideally as a delta to the current
> system.   It took me a while to go through the existing documents to get an
> idea of the written baseline.  RFC8728 and RFC8729 mainly.  I found myself
> in agreement with quite a large portion of those documents, especially with
> respect to the actual RFC Series Editor and RPC roles.  What I found myself
> less sanguine with were the various sections that dealt with "oversight".
> To be blunt, I believe that having either the IAB or IESG directly manage
> other resources  or contracts is not tenable.  The criteria of "able to
> manage a contract or employee" is not and has never been a criteria for
> selection of either an IESG or IAB member and the delegation of that
> responsibility to the RSOC does not appear to have been successful.
>
>    - My general desire is to see an RFC publication system  that retains
>    and perhaps expands its global impact and the generally wide respect for
>    its quality and reach.
>    - I'd like the people who make up the system to be professionals with
>    the ability to continue to help this community publish a wide range of
>    documents that help "make the Internet work better by ...
>    influenc[ing] the way people design, use, and manage the Internet".
>    - I'd like us to treat said professionals at least as well as we treat
>    ourselves.
>    - I'd like a system that evolves over time, and that is relatively
>    immune to influence from relatively few people over a relatively short
>    period of time.
>    - I'd like a system that's responsible and accountable to the
>    community directly rather than through the two layers of indirection we
>    currently have.
>    - I'd like some large measure of independence to be retained by this
>    publication system and that the member's of that system voices are heard
>    and honored as full partners and not "just a contractor[s]".
>    - I'd like the RFC publication system to be stable in the face of
>    unforeseen challenges and be able to gain (or regain) and retain
>    institutional memory.
>    - I'd really prefer that we don't have to do this again for another 10
>    years.
>    - I'd also prefer that once we have an RSE, we assume we keep them
>    (after a probationary period) until they get tired of us, or they really
>    mess up.
>
> Those are my desires and I could stop there.   But I though I'd provide a
> sketch of how things might be restructured - this is provided not as a
> fleshed out proposal, but as a thought experiment to show that I think it's
> possible to have both independence and accountability:
>
>
> ___________________________________
>
> The oversight for the RFC Publication System shall vest in an RFC Series
> editorial board (RSEB) consisting of 4 at large members selected through
> the Nomcom process for staggered 4 year terms (with a maximum of 1 renewal)
> plus the RSE as the chair, plus the Stream managers (who must not be the
> chair of the particular board that appoints them).  The senior at-large
> member is the deputy chair and acts as chair in any matter in which the RSE
> is recused or not available.  The RSEB shall act by voting, but shall try
> to achieve consensus.
>
> The RPC shall appoint a non-voting observer to the RSEB.    The RSEB may
> select an Executive Director or secretary for the RSEB.
>
> The RSE may recommend that any document not be published and with a
> majority vote by the RSEB prohibit publication.   This shall generally be a
> last resort after negotiation with the publication stream over perceived
> problems.
>
> The RSEB (minus the RSE) is the search committee for new RSEs.  They make
> the hiring recommendation to the LLC board.
>
> The at-large members are selected for their experience in the IETF and
> their experience with publication systems with the latter given more
> weight.  They are selected through the normal Nomcom process, and approved
> by the LLC.
>
> The at-large members must approve the ISE (who is nominated by the IAB).
> Tie votes are broken by the RSE.
>
> The stream managers for the IAB, IRTF and IESG(Standards) represent the
> groups that they come from, and are expected to consult with them on any
> non-routine matters.  They are reappointed each year as their respective
> bodies reform after the Nomcom process.
>
> Each stream manager (including the ISE) shall provide a PUBLIC annual
> assessment of at least a page of how the RSE/RFC publication system is
> meeting or not meeting their needs.
>
> The RSE shall provide an annual public report of the numbers and types of
> problems corrected on submitted documents.  This report shall be broken
> down by stream and shall be used to identify remedial actions for the
> production of documents from each stream.
>
> The RSEB will consider the public assessments and provide a PUBLIC annual
> response approved by a majority of the board.
>
> The RSEB (minus the RSE) will make a private recommendation to the LLC not
> later than 6 months prior to contract renewal (if the RSE is a contractor)
> or not more often than every 2 years (if an employee) on the continuance of
> the RSE.  The recommendation must be approved by the majority of the RSEB
> but may contain additional comments by any member for or against the
> recommendation and identified as originating from them.  If the RSEB is
> unable to approve the report due to a lack of a majority, the report shall
> be forwarded without the recommendation but with any individual commentary. If
> the recommendation is for termination or non-renewal, the LLC shall share a
> redacted summary of the recommendation including any vote counts to the
> RSE, but not the actual positions taken by any member of the board.  The
> RSE is allowed to make a public or a private statement to the LLC with
> respect to the recommendation.
>
> The LLC is the hiring entity for the RSE and bears all responsibilities
> normally attributed to a hiring entity.  The LLC is solely responsible for
> accepting or rejecting the recommendation of the RSEB with respect to the
> hiring or continuation of the RSE.   The LLC must make its own evaluation
> of the RSE performance rather than rely on the RSEB recommendation.
>
> The RSEB by a 3/4 vote and with concurrence of the LLC (who must sign off
> on any costs) may add or remove streams.  Streams may be proposed by any
> entity in the form of an Informational RFC on the Independent stream.
>
> Documents that touch on the RSE or RFC Publication System models shall be
> published after a community wide last call and with the majority approval
> of the RSEB.  Any document that changes the roles or responsibilities of
> the RSE or RPC which would require contract or job description changes also
> requires approval of the LLC.
>
> ____________________
>
> As you may guess, the above is mostly to fix what I perceive is a problem
> with the IAB and RSOC oversight of the RFC series.   You may have other
> ideas or may hate mine.   Feel free to take exception to the broad strokes
> or propose your own, but for now let's try and avoid twiddling the fine
> points (e.g. "I really think there should be 3 at large members" would be
> twiddling the fine points).
>
> Later, Mike
>
>
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

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



M=
ichael
I real=
ly agree with your first section.=C2=A0 You talk about making them full par=
tners, and I can see this going=C2=A0
another step.=C2=A0 I see the RFC publication =
system not just work on documents, but be our voice in other corners of oth=
er
techni=
cal communities. People ask me at times "so why are the IETF RFCs so m=
uch better than other systems", and
I can say a few words, then I struggle to s=
peak eloquently=C2=A0on the topic.=C2=A0 This role should be empowered (and=
 funded)
=
to do so.=C2=A0

I still need to work through your second section.=C2=A0=C2=A0

thanks
tim

On Sun, May 24, 2020 at=
 8:35 PM Michael StJohns <msj@=
nthpermutation.com> wrote:

 =20

   =20
 =20
  

    
Hi - Elliot asked me to write my thought on what elements I might
      want from the outcome of this process - ideally as a delta to the
      current system.=C2=A0=C2=A0 It took me a while to go through the exis=
ting
      documents to get an idea of the written baseline.=C2=A0 RFC8728 and
      RFC8729 mainly.=C2=A0 I found myself in agreement with quite a large
      portion of those documents, especially with respect to the actual
      RFC Series Editor and RPC roles.=C2=A0 What I found myself less
      sanguine with were the various sections that dealt with
      "oversight".=C2=A0 To be blunt, I believe that having eithe=
r the IAB or
      IESG directly manage other resources=C2=A0 or contracts is not
      tenable.=C2=A0 The criteria of "able to manage a contract or emp=
loyee"
      is not and has never been a criteria for selection of either an
      IESG or IAB member and the delegation of that responsibility to
      the RSOC does not appear to have been successful.=C2=A0 

    

    
    
      
  • My general desire is to see an RFC publication system=C2=A0 that
        retains and perhaps expands its global impact and the generally
        wide respect for its quality and reach.=C2=A0 
    
      
    • 
      
  • I'd like the people who make up the system to be professional=
s
        with the ability to continue to help this community publish a
        wide range of documents that help "make the Intern=
et work better by ...
            influenc[ing] the way people design, use, and manage the
            Internet". 
    
          
    • 
      
  • I'd like us to treat
            said professionals at least as well as we treat ourselves.=C2=
=A0=C2=A0
            
    
          
    • 
      
  • I'd like a system
            that evolves over time, and that is relatively immune to
            influence from relatively few people over a relatively short
            period of time.=C2=A0 
    
          
    • 
      
  • I'd like a system
            that's responsible and accountable to the community directl=
y
            rather than through the two layers of indirection we
            currently have.=C2=A0 
    
          
    • 
      
  • I'd like some large
            measure of independence to be retained by this publication
            system and that the member's of that system voices are hear=
d
            and honored as full partners and not "just a
            contractor[s]".=C2=A0 
    
          
    • 
      
  • I'd like the RFC
            publication system to be stable in the face of unforeseen
            challenges and be able to gain (or regain) and retain
            institutional memory.=C2=A0 
    
          
    • 
      
  • I'd really prefer
            that we don't have to do this again for another 10 years.=
=C2=A0 
    
          
    • 
      
  • I'd also prefer that
            once we have an RSE, we assume we keep them (after a
            probationary period) until they get tired of us, or they
            really mess up.
    
          
    • 
    

    
Those are my desires
          and I could stop there.=C2=A0=C2=A0 But I though I'd provide =
a sketch of
          how things might be restructured - this is provided not as a
          fleshed out proposal, but as a thought experiment to show that
          I think it's possible to have both independence and
          accountability:

    


        

    
___________________________________

        

    
The oversight for the
          RFC Publication System shall vest in an RFC Series editorial
          board (RSEB) consisting of 4 at large members selected through
          the Nomcom process for staggered 4 year terms (with a maximum
          of 1 renewal) plus the RSE as the chair, plus the Stream
          managers (who must not be the chair of the particular board
          that appoints them).=C2=A0 The senior at-large member is the depu=
ty
          chair and acts as chair in any matter in which the RSE is
          recused or not available.=C2=A0 The RSEB shall act by voting, but
          shall try to achieve consensus.

    
The RPC shall appoint a
          non-voting observer to the RSEB.=C2=A0 =C2=A0 The RSEB may select=
 an
          Executive Director or secretary for the RSEB. 

        

    
The RSE may recommend
          that any document not be published and with a majority vote by
          the RSEB prohibit publication.=C2=A0=C2=A0 This shall generally b=
e a
          last resort after negotiation with the publication stream over
          perceived problems.

        

    
The RSEB (minus the
          RSE) is the search committee for new RSEs.=C2=A0 They make the
          hiring recommendation to the LLC board. 

        

    
The at-large members
          are selected for their experience in the IETF and their
          experience with publication systems with the latter given more
          weight.=C2=A0 They are selected through the normal Nomcom process=
,
          and approved by the LLC.=C2=A0 

        

    
The at-large members
          must approve the ISE (who is nominated by the IAB).=C2=A0 Tie vot=
es
          are broken by the RSE.

    
The stream managers for
          the IAB, IRTF and IESG(Standards) represent the groups that
          they come from, and are expected to consult with them on any
          non-routine matters.=C2=A0 They are reappointed each year as thei=
r
          respective bodies reform after the Nomcom process.

        

    
Each stream manager
          (including the ISE) shall provide a PUBLIC annual assessment
          of at least a page of how the RSE/RFC publication system is
          meeting or not meeting their needs.=C2=A0 

        

    
The RSE shall provide
          an annual public report of the numbers and types of problems
          corrected on submitted documents.=C2=A0 This report shall be brok=
en
          down by stream and shall be used to identify remedial actions
          for the production of documents from each stream.

        

    
The RSEB will consider
          the public assessments and provide a PUBLIC annual response
          approved by a majority of the board.

    
The RSEB (minus the
          RSE) will make a private recommendation to the LLC not later
          than 6 months prior to contract renewal (if the RSE is a
          contractor) or not more often than every 2 years (if an
          employee) on the continuance of the RSE.=C2=A0 The recommendation
          must be approved by the majority of the RSEB but may contain
          additional comments by any member for or against the
          recommendation and identified as originating from them.=C2=A0  If the RSEB is unable to
          approve the report due to a lack of a majority, the report
          shall be forwarded without the recommendation but with any
          individual commentary. If the recommend=
ation is for termination or
          non-renewal, the LLC shall share a redacted summary of the
          recommendation including any vote counts to the RSE, but not
          the actual positions taken by any member of the board.=C2=A0 The
          RSE is allowed to make a public or a private statement to the
          LLC with respect to the recommendation. 

        

    
The LLC is the hiring
          entity for the RSE and bears all responsibilities normally
          attributed to a hiring entity.=C2=A0 The LLC is solely responsibl=
e
          for accepting or rejecting the recommendation of the RSEB with
          respect to the hiring or continuation of the RSE.=C2=A0=C2=A0 The=
 LLC
          must make its own evaluation of the RSE performance rather
          than rely on the RSEB recommendation.

        

    
The RSEB by a 3/4 vote
          and with concurrence of the LLC (who must sign off on any
          costs) may add or remove streams.=C2=A0 Streams may be proposed b=
y
          any entity in the form of an Informational RFC on the
          Independent stream.

        

    
Documents that touch on
          the RSE or RFC Publication System models shall be published
          after a community wide last call and with the majority
          approval of the RSEB.=C2=A0 Any document that changes the roles o=
r
          responsibilities of the RSE or RPC which would require
          contract or job description changes also requires approval of
          the LLC.

        

    
____________________

    
As you may guess, the
          above is mostly to fix what I perceive is a problem with the
          IAB and RSOC oversight of the RFC series.=C2=A0=C2=A0 You may hav=
e other
          ideas or may hate mine.=C2=A0=C2=A0 Feel free to take exception t=
o the
          broad strokes or propose your own, but for now let's try and
          avoid twiddling the fine points (e.g. "I really think there
          should be 3 at large members" would be twiddling the fine
          points).

    
Later, Mike

    


        

    


    

  


-- 

Rfced-future mailing list

Rfced-future@iab.=
org

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




--0000000000002929fa05a66f4990--


From nobody Sun May 24 18:58: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 5875E3A011F for ; Sun, 24 May 2020 18:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS2gHpkpWe1s for ; Sun, 24 May 2020 18:58:35 -0700 (PDT)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 2377B3A003E for ; Sun, 24 May 2020 18:58:35 -0700 (PDT)
Received: by mail-oi1-x234.google.com with SMTP id d191so14848452oib.12 for ; Sun, 24 May 2020 18:58:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8lp4kqcIIuaIOCosWaG6TrfDLuqJiTb+nyOp6vlMeQk=; b=PE1/f5QLXR8X2VrR1g+shkyVJjIoVf0PZJnVqmrh9CpuD6SMha5lqiCO323+n4A0VY ShkErzqGThE3t/TP/IMKmMmkSDFtvr5rreZhaGWkjmnG08kJ9nH4ZMwQ5rvuCXbl5z1R MshTkC8OiQy6J5ZXP7d1dko0R7JZH6A2xSpKIbPtfHzLIipN6ElO2lK90rT6nrI1mABg M7rW4kkEW2kKPO6s3Pi1iwvE+3hHJ0l4PnC5byrhxKwlFzodYHKSrX0Blk4QX6SVxIFB tPw+4d1uCHwwo0m81WaTm8FNYKUH3hlu702SGjq3U7rAsYmtPSfSGHlVCIHbh18xRsZe 9bRg==
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=8lp4kqcIIuaIOCosWaG6TrfDLuqJiTb+nyOp6vlMeQk=; b=kDpgtGAXgGU9wQRDneVI0t9wBa7Vj5BIFICeYcUCe+2c/uRnIJ4T1XI/YVcrHXSBJ5 8DZlJxk1JJUwyCCxFzH56ReeNLcE5NyhtBGrxmZ0XXP5rx2KOdNSQRmpselxloP0UGjo FaIHq2GMKk/xIp2/RVzsnt5Cwpa8lvLRynEgkpjw/1hvVSqY0wda1FM+BvFJElN9BtvK ONPXVmUTWT1Kl5AIQ7tf8bTuKjn00BGK8XFnRV0zeK9bD1aAWktkrDb6lt8LHLbT65fk tmQkS7jyaVUiHZ1koPRosxMq42YppYeLcXkXALjBjbzzVaDm8D2FRMGNARAuAAbvEkuh uVhA==
X-Gm-Message-State: AOAM530WTZGl1hWNA3kyZXCJYNNInXOdW1efQsIDOlQp46xAcFsedtcR AXobn+QrH3VUEyNmMUEg3QtaIPJRVkmR9swjMLw=
X-Google-Smtp-Source: ABdhPJzZ/QGax5moyXqJSMtBAw27C+ZBVXwN0OT9YAsAz/T2shY//AERZEj4IdD+OFBKNOKqfYwRG3JJ+flSoEKushQ=
X-Received: by 2002:aca:518c:: with SMTP id f134mr9999701oib.6.1590371913421;  Sun, 24 May 2020 18:58:33 -0700 (PDT)
MIME-Version: 1.0
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <5c33a5fe-1fe4-1bfa-7382-9c1ca9f4f345@gmail.com>
In-Reply-To: <5c33a5fe-1fe4-1bfa-7382-9c1ca9f4f345@gmail.com>
From: Tim Wicinski 
Date: Sun, 24 May 2020 21:58:22 -0400
Message-ID: 
To: Brian E Carpenter 
Cc: Michael StJohns , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000f5d6a505a66f501e"
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 01:58:36 -0000

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

On Sun, May 24, 2020 at 9:55 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> So, Mike, take this as a friendly challenge, since I generally like what
> you wrote:
>
> >  a system that's responsible and accountable to the community directly
>
> Yes, more or less what my draft says too.
>
> > The at-large members are selected for their experience in the IETF and
> their experience with publication systems with the latter given more
> weight.  They are selected through the normal Nomcom process
>
> How do we reach the whole candidate pool? Where do we send the call for
> nominations? We clearly want a wider spread than traditionally, if we are
> really trying to cover the whole RFC-using community. In fact, I don't see
> why IETF experience is the first criterion. Experience writing code or
> running networks based on RFCs seems equally important.
>
> Regards
>    Brian Carpenter
>
>
Agree with Brian on the candidate pool.  We need to include folks who use
our documents and have an outside perspective

tim

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




On Sun, May 24, 2020 at 9:55 PM Brian E Carpe=
nter <brian.e.carpenter@g=
mail.com> wrote:
So, Mike, take this as a friendly challenge, since I generally like=
 what you wrote:



>=C2=A0 a system that's responsible and accountable to the community=
 directly



Yes, more or less what my draft says too.



> The at-large members are selected for their experience in the IETF and=
 their experience with publication systems with the latter given more weigh=
t.=C2=A0 They are selected through the normal Nomcom process



How do we reach the whole candidate pool? Where do we send the call for nom=
inations? We clearly want a wider spread than traditionally, if we are real=
ly trying to cover the whole RFC-using community. In fact, I don't see =
why IETF experience is the first criterion. Experience writing code or runn=
ing networks based on RFCs seems equally important.



Regards

=C2=A0 =C2=A0Brian Carpenter



Agree with Brian on the candidate pool.=C2=A0 We need to =
include folks who use our documents and have an outside perspective

tim


--000000000000f5d6a505a66f501e--


From nobody Sun May 24 20:15: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 DD7E53A0A53 for ; Sun, 24 May 2020 20:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59D4TY4eTO5e for ; Sun, 24 May 2020 20:15:20 -0700 (PDT)
Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 E89C23A0A52 for ; Sun, 24 May 2020 20:15:19 -0700 (PDT)
Received: by mail-vk1-xa34.google.com with SMTP id p7so3949064vkf.5 for ; Sun, 24 May 2020 20:15:19 -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=SlV8hZrE2XUxy4SE/LmDUgHD0z4Bk24zqtfhfB3KQsw=; b=tnilv1mrF/3w2SzCljQID6Cet3W9Sx6QogAQInH6G67g32Li//h9bgLNtjehx83Ni6 thmict5PIvNuuyK5ooHATflDIgHEo4uGoVUUg2iSjoZQMnxtaBvnHk2JjK7nc4awAeFF qXrXXsz0Ntzp8tBM0Fa0yFMN/DZ3EDE2XzCQ1shEtfZNzqrFn9xy5BgO+SEffqwQ0M3y y405M2vNqIJx4LYCijhPMyeyi9QrxAAHnEsJG2WwWJ1fcFZ9MIiBjE4bOlg6Rexv8Ay6 22I2lAjEmh4SM4YszJfSMTD2njcg+DcAwpJLYAW9BSt0wuAXFASHwMxGmjrcdYZg0vb4 MEcA==
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=SlV8hZrE2XUxy4SE/LmDUgHD0z4Bk24zqtfhfB3KQsw=; b=Pgp5ui14HApmwOVPJOBb6q25u/GBw0bTK7rqrGCFlRqthmKn9/zX2fDJ5gVhYLb9pI Brp8z8/ZEQR/A2geiLrpbKIOVwe7cERfBKwwD1U7mtqonlwcZHTQHc+x1WqdaHNdAlFF CbGLjICwqocfC5u7rvBWkvj87g+RDQYUAI2WWUuEFkknjRJ/WrSIgnG60jGQIVxyZ/QM 9szVQCcqiFeMk3xTqa54zbizDBHmu9A2bn5a2mQ1MAFQsPuXJS19Z0XIZ8HD6Rt3xMDw cvk10+EAkLf/MCauRotFyn5HLQvVLVBvBcLks7c5o+D8OBe9Mv3gRysGxdaUpLKrgmaO pbKw==
X-Gm-Message-State: AOAM533XbLANwpdOV8KUxj+PgS5/J7QzScuKrUremYbqByEAJEyNnIHY DlS5GI/d+vIA+QnAbFsgCjl3KHtbr2Ke7EJu8t27sjb2+XM=
X-Google-Smtp-Source: ABdhPJwpEELIc76OHv6sNw7xLBFa95P1SbLe3VJg3Ac56z6jgl3k1X8XvwXvrWcbnvLOAzSCVke5opdHjMre4v0wi1Q=
X-Received: by 2002:a1f:25d7:: with SMTP id l206mr18344561vkl.53.1590376518032;  Sun, 24 May 2020 20:15:18 -0700 (PDT)
MIME-Version: 1.0
From: Nevil Brownlee 
Date: Mon, 25 May 2020 15:14:51 +1200
Message-ID: 
To: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000006aa13305a67063f7"
Archived-At: 
Subject: [Rfced-future] New Draft: Changes to the RFC Series and RS
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 03:15:23 -0000

--0000000000006aa13305a67063f7
Content-Type: text/plain; charset="UTF-8"

Hi all:

I've just posted a draft setting out my thoughts on these topics, you can
see it at
https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-00.html

Just after I'd posted it I looked again at the rfced-future list; I see
that Mike has posted some more of his ideas.  It's great to see more text
exploring this, but clearly there's a long way to go yet before we reach a
consensus!!

Cheers, Nevil

-----------------------------------
Nevil Brownlee, Taupo, NZ

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


Hi all:

I've just posted=
 a draft setting out my thoughts on these topics, you can see it at https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-00.ht=
ml

Just after I'd posted it I looked again=
 at the rfced-future list; I see that Mike has posted some more of his idea=
s.=C2=A0 It's great to see more text exploring this, but clearly there&=
#39;s a long way to go yet before we reach a consensus!!

=

Cheers, Nevil
=C2=A0
-----------------------------------
Ne=
vil Brownlee, Taupo, NZ


--0000000000006aa13305a67063f7--


From nobody Mon May 25 02:58: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 E514F3A0A8E for ; Mon, 25 May 2020 02:58:36 -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 QwK8QWe-llvB for ; Mon, 25 May 2020 02:58:35 -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 F23A13A0A8C for ; Mon, 25 May 2020 02:58:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4167; q=dns/txt; s=iport; t=1590400715; x=1591610315; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=4S2vxpAYjG1uga+XUi7OBaRvOQQcBSpx7g/w+LmBWbk=; b=S4j/4/Vpq3YS6+VjGQBF04hAqIFk+EB3xO1stiQ928uPjGff/Kb/yYAy YCcyEfA1dJZOgu6VLCOBG2tNo+XwQU03ovbyyN2Dco8HY4Ty83sDYFZ0C KULv0MEkwFg5jlI5zTWKNa6z7+GcSEHJJeHgzbWXkVmx/E6DoIbyygIGJ g=;
X-IPAS-Result: =?us-ascii?q?A0DJAAA4lste/xbLJq1mHAEBAQEBAQcBARIBAQQEAQGBd?= =?us-ascii?q?gQBAQsBg24BIBKEUYkBiAmTVogQCwEBAQwBAS8EAQGERAKCRDcGDgIDAQEBA?= =?us-ascii?q?wIDAQEBAQUBAQECAQUEbYUqBjKFcwEEASNWBQsLBD4CAlcGgzmCXSCrUHaBM?= =?us-ascii?q?oVRhQ+BOAGMXYIAgREnHIIfLj6EJoM8M4ItBIUnrX+CXoJ0lWgdgmOJAoRhJ?= =?us-ascii?q?40VqmeDSQIEBgUCFYFoI4FWMxoIGxVlAYI/PRIYDY1pkSE/A2cCBgEHAQEDC?= =?us-ascii?q?YsRgkQBAQ?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.73,433,1583193600"; d="scan'208,217"; a="24158861"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 May 2020 09:58:30 +0000
Received: from [10.61.236.200] ([10.61.236.200]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 04P9wTZA032484 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 May 2020 09:58:30 GMT
From: Eliot Lear 
Message-Id: <28BE2C74-D8A8-470B-A33F-F5A4A37BFBEA@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B091075E-F881-49A7-A958-8DEAAA27B295"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 25 May 2020 11:58:29 +0200
In-Reply-To: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
Cc: rfced-future@iab.org, Mark Nottingham 
To: Michael StJohns 
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.236.200, [10.61.236.200]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 09:58:37 -0000

--Apple-Mail=_B091075E-F881-49A7-A958-8DEAAA27B295
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mike,

Thank you for having taken the time to detail your views.  This is very =
helpful, even if one doesn=E2=80=99t agree with everything you wrote.  =
You clearly drew out what you believed the problem to be, and how you =
would address it.  Your proposal is interesting and will help us =
crystalize our views.=20

On Mark Nottingham=E2=80=99s question of scope:

> [=E2=80=A6]
> The at-large members must approve the ISE (who is nominated by the =
IAB).  Tie votes are broken by the RSE.
>=20

Mark asserted that appointment/approval of the ISE is not in scope for =
this effort.  As I read our charter, I would tend to agree, although it =
is a fine line.  Rather than get into a tussle over the charter, because =
nobody has raised issues about the management of the stream managers, =
let=E2=80=99s limit our scope to how the RSE and RPC interacts with or =
is accountable to them.  We already have enough to be getting on with.

On this point:

> The RSE may recommend that any document not be published and with a =
majority vote by the RSEB prohibit publication.   This shall generally =
be a last resort after negotiation with the publication stream over =
perceived problems.

In my view, based on the discussion that previously occurred, the =
overwhelming consensus is against you.  If people other than Mike agree =
with the above text, please say so now.

Eliot


--Apple-Mail=_B091075E-F881-49A7-A958-8DEAAA27B295
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Mike,

Thank=
 you for having taken the time to detail your views.  This is very =
helpful, even if one doesn=E2=80=99t agree with everything you wrote. =
 You clearly drew out what you believed the problem to be, and how =
you would address it.  Your proposal is interesting and will help =
us crystalize our views. 

On Mark Nottingham=E2=80=99s question =
of scope:

[=E2=80=A6]
The=
 at-large members
          must approve the ISE (who is nominated by the IAB).  Tie =
votes
          are broken by the =
RSE.

Mark asserted that appointment/approval of the ISE is =
not in scope for this effort.  As I read our charter, I would tend =
to agree, although it is a fine line.  Rather than get into a =
tussle over the charter, because nobody has raised issues about the =
management of the stream managers, let=E2=80=99s limit our scope to how =
the RSE and RPC interacts with or is accountable to them.  We =
already have enough to be getting on with.

On this point:

The RSE may =
recommend that any document not be published and with a majority vote by =
the RSEB prohibit publication.   This shall generally be a =
last resort after negotiation with the publication stream over perceived =
problems.

In my view, based on the discussion =
that previously occurred, the overwhelming consensus is against you. =
 If people other than Mike agree with the =
above text, please say so now.

Eliot

=

--Apple-Mail=_B091075E-F881-49A7-A958-8DEAAA27B295--


From nobody Mon May 25 07:08: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 5D75E3A0C46 for ; Mon, 25 May 2020 07:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=YIsS98G+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pLq+Soec
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXTinGfuuzj5 for ; Mon, 25 May 2020 07:08:35 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65EF73A0C1B for ; Mon, 25 May 2020 07:08:34 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A5A455C0075 for ; Mon, 25 May 2020 10:08:32 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 25 May 2020 10:08:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=DCfgNHe lXYavtoaH5JA368HD5uvMPvypaLCFUAFS5Qk=; b=YIsS98G+5MCU/5aFiWu/UTq 5wVcXH3sCTS6du5Fu6oherr6sRYoUSpx4ShsTRYSiBscLeJSfXZEEd+qDlLkYfvl Jb+ph5fkxgRRTDZ9P6bwk0CP5G91jguHCpPbHOr/xsR+nHGzY6sp61dI7/WuOXns JrQtxovL4IDWMmvWgA52G6nqf2WNSCEruPdfOJH5uuKxHv/5eXwq/x+f+f2agaC1 NEN2JOnn5A1DfvOaY8UicMyZPftoohHPgtLioAED9BfOPk17jyzLokzRC3AXfs7/ UiU2/Mpfy4fSNz40GY1OAY+w+9VzQU3FC+2kFpwDEieyjwTi8BUjhAysZ8o49Ww= =
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=fm2; bh=DCfgNH elXYavtoaH5JA368HD5uvMPvypaLCFUAFS5Qk=; b=pLq+SoeckfvpF852iuSWxX TDP4vJM/d4FUBo2LfEhfTQalcbdmeD2Awq4DKxgnbhoFtRQ4bD2IjAv3FwALqOFg uQDsrd/3cMYjNFgaPYf5mBxH6UFmx4/mOJpnc2vlT0fvNEkjpCXtzYOHX433jhNW yIJvP5oSHuUE0smeqivRWbAt7kxzfSLXvVqLKphKrufVpYUua+YrUQreD/dXC7L3 NtXBFsYqvs91iklSQHwKoecILHP8aEK1VuDg1PTbrr6bbX4RalG2GaSlY8TO9UJk jiu/KFh0ECVvck5MPq7DHd04BQHHmqEAX8jDIJB8LFBQWUuQzKm0ypvCH+dv4m2g ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvtddgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvudeuieehgf dvheeuueejjeeuudfgiefgveetfeelteeffffgtdejjefgueduvdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4336A180091; Mon, 25 May 2020 10:08:32 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-488-g9249dd4-fm-20200522.001-g9249dd48
Mime-Version: 1.0
Message-Id: <53f690a7-9477-47a7-a256-75139aae269f@dogfood.fastmail.com>
In-Reply-To: <28BE2C74-D8A8-470B-A33F-F5A4A37BFBEA@cisco.com>
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <28BE2C74-D8A8-470B-A33F-F5A4A37BFBEA@cisco.com>
Date: Tue, 26 May 2020 00:08:12 +1000
From: "Bron Gondwana" 
To: rfced-future@iab.org
Content-Type: multipart/alternative; boundary=dfeb40a88e434fbd9e1d8095683db3c6
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 14:08:38 -0000

--dfeb40a88e434fbd9e1d8095683db3c6
Content-Type: text/plain

On Mon, May 25, 2020, at 19:58, Eliot Lear wrote:
> 
>> The RSE may recommend that any document not be published and with a majority vote by the RSEB prohibit publication. This shall generally be a last resort after negotiation with the publication stream over perceived problems.
> 
> In my view, based on the discussion that previously occurred, the overwhelming consensus is against you. If people *other* than Mike agree with the above text, please say so now.

I have not yet commented on this, but I believe I am with the overwhelming here.

This issue only occurs in the situation where the RSE has said "I don't want to publish this document for reasons X, Y, Z" and the elected representatives of the IETF have said "regardless, we have reasons which override those concerns and insist that you publish".

At this point, the remedy for the RSE is to resign rather than publish under their watch. They must have this option open to them, but that is the ultimate remedy available to the RSE.

Refusal to publish and retaining the role is not tenable. The RSE and the RFC series exist to serve the streams, not the other way around.

The role of the RSE is to ensure that high quality documents are created which accurately represent the intent of the stream owners.

Eliot - you are quite correct that this is the first key question we need to have consensus on in order to describe this role: who will have ultimate authority to determine which documents are published.

Regards,

Bron.

P.S. There also needs to be a way to deal with RSE filibustering, and/or tarpitting - either undue delay in publishing a document they don't like, or running out the clock and then sending it back with minor edits over and and over.

P.P.S. I will provide some justification for why I take this position. It is along the lines of "The Net interprets censorship as damage and routes around it." - I don't wish to see fragmentation where the IAB or IETF find themselves needing to publish a separate stream of documents and start treating them as authoritative.

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


--dfeb40a88e434fbd9e1d8095683db3c6
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


On Mon, May 25, 2020, at 19:58, Eliot Lear wrote:

The RSE may=
 recommend that any document not be published and with a majority vote b=
y the RSEB prohibit publication.   This shall generally be a l=
ast resort after negotiation with the publication stream over perceived =
problems.

In my view, based on the discussion that previously occurred, the over=
whelming consensus is against you.  If people othe=
r than Mike agree with the above text, please say so now.

I have not yet commented on this, but I bel=
ieve I am with the overwhelming here.

This issue only occ=
urs in the situation where the RSE has said "I don't want to publish thi=
s document for reasons X, Y, Z" and the elected representatives of the I=
ETF have said "regardless, we have reasons which override those concerns=
 and insist that you publish".

At this point, the remedy =
for the RSE is to resign rather than publish under their watch.  Th=
ey must have this option open to them, but that is the ultimate remedy a=
vailable to the RSE.

Refusal to publish and retaining the=
 role is not tenable.  The RSE and the RFC series exist to serve th=
e streams, not the other way around.

The role of the RSE =
is to ensure that high quality documents are created which accurately re=
present the intent of the stream owners.

Eliot - you are =
quite correct that this is the first key question we need to have consen=
sus on in order to describe this role: who will have ultimate authority =
to determine which documents are published.

Regards,
<=
/div>

Bron.

P.S. There also needs to be a way to dea=
l with RSE filibustering, and/or tarpitting - either undue delay in publ=
ishing a document they don't like, or running out the clock and then sen=
ding it back with minor edits over and and over.

P.P.S. I=
 will provide some justification for why I take this position. It is alo=
ng the lines of "The Net interprets censorship as damage and routes arou=
nd it." - I don't wish to see fragmentation where the IAB or IETF find t=
hemselves needing to publish a separate stream of documents and start tr=
eating them as authoritative.

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




--dfeb40a88e434fbd9e1d8095683db3c6--


From nobody Mon May 25 08:38: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 B0F943A0D2E for ; Mon, 25 May 2020 08:38:25 -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 i7_mWvhGOvuJ for ; Mon, 25 May 2020 08:38:23 -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 720873A0C66 for ; Mon, 25 May 2020 08:38:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10016; q=dns/txt; s=iport; t=1590421103; x=1591630703; h=from:mime-version:subject:message-id:references:to:date; bh=zAq3QqwIM5AwHNbha02qVGtnpQvx8UZvdH5Cg29v6OE=; b=R8rSbp8Jl7u5IEJRVm1/YOvMyzuAZRJsT4IJN+8P33indH2yq6zQlxzl h1qi+Inw6NlCmtz8VMWhAVJzojk0mXsHD1W3rKMXda/hxAvesoaUQ75IV Bq+zQJFDZgBQXyC5nMGPKZa3GSblLW4IYUDy5+0nZayn2viqRAqJ8Jtl3 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAQDQ5cte/xbLJq1MGhsBAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQGCB4MbVAEgEiyEJYkBiAeTVogQCwEBAQwBARgBDAo?= =?us-ascii?q?EAQGERAKCRTgTAgMBAQsBAQUBAQECAQUEbYVWDIVyAQECAgEBASFLEAscAwE?= =?us-ascii?q?CGQwGAgInHwkIGYMmAYJcIA88q0N2gTKDTYIEhQQGgTiMXoIAgREnHIVyAQE?= =?us-ascii?q?CGoEkdIIaKzOCEhsEsyaCXgSCcIU1kDMWB5BGiD+EfZo8kCuDSQIEBgUCFYF?= =?us-ascii?q?pIoFWMxoIGxU7KgGCPj4SGA1VjGCDFxeDT4UUhUQ/AzACNQIGAQcBAQMJizm?= =?us-ascii?q?CHwEB?=
X-IronPort-AV: E=Sophos; i="5.73,433,1583193600"; d="scan'208,217"; a="26434820"
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; 25 May 2020 15:38:19 +0000
Received: from [10.61.236.200] ([10.61.236.200]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04PFcIPu023998 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 25 May 2020 15:38:19 GMT
From: Eliot Lear 
Content-Type: multipart/alternative; boundary="Apple-Mail=_14270FB8-B6A0-4EFE-8AC8-7D46F784BB37"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
References: <158922073357.16246.16854029162770313933@ietfa.amsl.com>
To: rfced-future@iab.org
Date: Mon, 25 May 2020 17:38:18 +0200
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.236.200, [10.61.236.200]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: [Rfced-future] Agenda for Wednesday
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 15:38:26 -0000

--Apple-Mail=_14270FB8-B6A0-4EFE-8AC8-7D46F784BB37
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

A reminder, we will gather virtually on Wednesday.  See below for timing =
and coordinates.

Proposed agenda:

Take up where we left off tow weeks ago.  That was as follows:

What issues does the RSE decide and what issues does this group decide?
A little bit of organizing as to how we should go forward

The first item was meant to be a poll, but I haven=E2=80=99t been able =
to send it out yet, and am still looking for feedback.=20

On the second item, we now have several drafts in the draft directory =
(Brian=E2=80=99s and Nevil=E2=80=99s), and we have several people who =
have provided quite detailed views on what they want from the series.  =
We have choices as to how to proceed.  Before we do that we have to have =
clarity on the first question.

For people=E2=80=99s benefit, the minutes to the previous meeting have =
been posted in the data tracker.

While it is tempting to take up Mike St. John=E2=80=99s proposal, and =
others, the hour is not particularly convenient for him or others from =
the East Coast to join in, so we=E2=80=99ll hold off on that for now.

Eliot

> Begin forwarded message:
>=20
> From: IAB Executive Administrative Manager 
> Subject: [Rfced-future] RFC Editor Future Development Program Virtual =
Meeting: 2020-05-27
> Date: 11 May 2020 at 20:12:14 CEST
> To: "IETF Announcement List" 
> Cc: rfced-future@iab.org
> Reply-To: rfced-future@iab.org
>=20
> The RFC Editor Future Development Program will hold a virtual meeting.
>=20
> When: 27 May 2020 06:00 UTC
>=20
> Local times:
>=20
>  Pacific/Auckland; 27 May 18:00
>  Australia/Sydney: 27 May 16:00
>  Asia/Kolkata: 27 May 11:30am
>  Europe/Berlin: 27 May 8:00am
>  Europe/London: 27 May 7:00am
>  North America/New York: 27 May 02:00
>  North America/Chicago: 27 May 01:00
>  North America/Los Angeles: 26 May 23:00
>=20
> Duration: 90 minutes
>=20
> Webex Information:=20
> =
https://ietf.webex.com/ietf/j.php?MTID=3Dm1dd4253db4bdf3a30ef9f3aabc64ac75=

> Meeting number (access code): 618 437 612
> Meeting password: rfcefdp
>=20
> Agenda:
>=20
> We will continue a roundtable exchange of people=E2=80=99s views on =
the future=20
> of the RFC Series Editor. We will further develop the agenda there.  =
All=20
> are invited to participate, and to join the list, which can be found =
at=20
> https://www.iab.org/mailman/listinfo/rfced-future.  The meeting will =
be=20
> recorded.  Current information on the program can be found at=20
> https://github.com/intarchboard/rfced-future.
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


--Apple-Mail=_14270FB8-B6A0-4EFE-8AC8-7D46F784BB37
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

A =
reminder, we will gather virtually on Wednesday.  See below for =
timing and coordinates.

Proposed agenda:

Take up where we left off tow weeks ago.  That was as =
follows:

  • What issues does the RSE decide and =
what issues does this group decide?
  • A little bit of =
organizing as to how we should go forward

The first item was meant =
to be a poll, but I haven=E2=80=99t been able to send it out yet, and am =
still looking for feedback. 

On the second item, we now have several =
drafts in the draft directory (Brian=E2=80=99s and Nevil=E2=80=99s), and =
we have several people who have provided quite detailed views on what =
they want from the series.  We have choices as to how to proceed. =
 Before we do that we have to have clarity on the first =
question.

For =
people=E2=80=99s benefit, the minutes to the previous meeting have been =
posted in the data tracker.

While it is tempting to take up Mike St. John=E2=80=99s =
proposal, and others, the hour is not particularly convenient for him or =
others from the East Coast to join in, so we=E2=80=99ll hold off on that =
for now.

Eliot

Begin forwarded =
message:

From: =
IAB Executive Administrative =
Manager <execd@iab.org>
Subject: =
[Rfced-future] =
RFC Editor Future Development Program Virtual Meeting: 2020-05-27
Date: =
11 May 2020 at 20:12:14 CEST
To: =
"IETF Announcement List" <ietf-announce@ietf.org>
Cc: rfced-future@iab.org
Reply-To: =
rfced-future@iab.org

The RFC Editor Future =
Development Program will hold a virtual meeting.

When: 27 May 2020 06:00 UTC

Local =
times:

  Pacific/Auckland; 27 May =
18:00
  Australia/Sydney: 27 May 16:00
 =
 Asia/Kolkata: 27 May 11:30am
  Europe/Berlin: =
27 May 8:00am
  Europe/London: 27 May 7:00am
  North America/New York: 27 May 02:00
 =
 North America/Chicago: 27 May 01:00
  North =
America/Los Angeles: 26 May 23:00

Duration: =
90 minutes

Webex Information: 
https://ietf.webex.com/ietf/j.php?MTID=3Dm1dd4253db4bdf3a30ef9f=
3aabc64ac75
Meeting number (access code): 618 437 =
612
Meeting password: rfcefdp

Agenda:

We will continue a =
roundtable exchange of people=E2=80=99s views on the future 
of the RFC Series Editor. We will further develop the agenda =
there.  All 
are invited to participate, and to join =
the list, which can be found at 
https://www.iab.org/mailman/listinfo/rfced-future.  The =
meeting will be 
recorded.  Current information on =
the program can be found at 
https://github.com/intarchboard/rfced-future.
-- 
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

=

--Apple-Mail=_14270FB8-B6A0-4EFE-8AC8-7D46F784BB37--


From nobody Mon May 25 08:39: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 678703A0C56 for ; Mon, 25 May 2020 08:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level: 
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Wi2FD63i; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0K8Jx6uO
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwldDvnxEpRX for ; Mon, 25 May 2020 08:39:42 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3776E3A0A5F for ; Mon, 25 May 2020 08:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9109; q=dns/txt; s=iport; t=1590421182; x=1591630782; h=from:to:subject:date:message-id:mime-version; bh=1IK6L3H5zRZ4Yd+PymD0H+HZQ/YsqJH2VV9gtq0sY9s=; b=Wi2FD63i7hAaYM1WhNs9v3Fp2iuzJyfD1F85K3duqng7gnlXl/akKu0y 5Z6Po6GKwwRx1GF+s0pgnh3fBvsr/qzWHBsGJHlNxKL5Fh/Yt02mbPcYg kOjf0ClrJ4oPzQ/nYHivKRMSRgn/m3YnBEBKZ24USG4kbALk5RP9vPBJJ I=;
X-IPAS-Result: =?us-ascii?q?A0AyAwC35cte/51dJa1MGhwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFHgVRRB29YLyyEJViCbgOle4JSA1ULAQEBCQMBARgNCAIEAQGERAIXggokO?= =?us-ascii?q?BMCAwEBAQMCAwEBAQEFAQEBAgEFBG2FVgELhXIBAgEEARARHQEBLAwRARkDA?= =?us-ascii?q?QIZDAYCBCULFAkJAQQTCBqDBYJLAy4BDjyhJQKBOYhhdAKBMoMBAQEFRYRfG?= =?us-ascii?q?IIHBwMGgTiCZIlgGoFBP4ERQ4VyAQECGn0nJ02CGiszghIbkWaGJJsgCoJUi?= =?us-ascii?q?CmQUJkFhH2QToluk3QCBAIEBQIOAQEFgWkigVZwFTuCaVAYDVWMYIMLDBeDT?= =?us-ascii?q?4UUhUJ0AjUCBggBAQMJfIo9gh8BAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3A4v1TnRRqg+oxlTGg2g+V4t6gA9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN2J6vtOze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/bleUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.73,433,1583193600"; d="scan'208";a="472483342"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 May 2020 15:39:41 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 04PFdfkD032150 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 May 2020 15:39:41 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 25 May 2020 10:39:41 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 25 May 2020 10:39:40 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 25 May 2020 11:39:40 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PfPcF6osndhjwm0LMIPi5kOl0uYWGjcWv0YrWKYnxgTIPaHHgzE1+MRHMolWgVecjzohKRUkH647/BYBcDwl08D3vssaYY5nW9acIEBMzITlQaJ5e7xK0BHpQEetRkb3bmfUwU+fbSjHkRtazfRyoMGDCEvyfg+kEIIfUrUEbXj5InwypMNgFU3ZG0LSoYnYahwJ/MBimKjJ88pP50TflKwsSxEMUt5rgJIrq7xpsDCql2TDKb+c6GUVNpyJiMMWBI1GKt5+ruzH3rGcGyhFnZ8NDH/SpEKMlVpDf9xvppLJFZHwrD2rifFahPnT7bUg5zbVKBRMyPqcmZgKFM4/mg==
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=9yLkbh/nJQq4Ccm4tl+s3/0BtfI5sAAQGbdNHEHffRY=; b=fxnzFBKIP/XLpPM1X9ihRaUcCS+yM1HxDTKx69Kofwcno1n3zLDpsGD2XvOjC4I7fX1ZAJd6UeRYbtbPSF+HOwpAocz2oh8xI+h1v0LWSvkuExUqP2aV8BZuM7cihh09MWjd1OPNa6iAtyiyNtB/nowfwn3Hr1l7zLCGywIuU+XMUBI+wXZVniayBE1loh0P8s85Moc3gJxyTCwFn6ll8ChVWhXvtk6sjIThHQzfFs/WxQFeBouavuN0T5GsuB5lha50FR+Mu/ZqXz/hhLsbylk7V3vGs5LQcsReaDPBcG/rxtY7gGPsqpzBc424sll8dmPgvhRwbR97jtA0265w/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9yLkbh/nJQq4Ccm4tl+s3/0BtfI5sAAQGbdNHEHffRY=; b=0K8Jx6uO5yalmqrs2XXKQkhqknBVDJZ6CUxZ5er9mplSpPg1wGXx6Hp/WvbhLbRanWZoygjMML6tHE1qc+4WgW1VDI0dZgHnq4I6KNVOjbRL/JjcBw/syu+DwXoMFvL0Wa0/1iCi6BR1teP8T9I8Dd3i8Oir8G6BfVGXt5bUtEQ=
Received: from BY5PR11MB4211.namprd11.prod.outlook.com (2603:10b6:a03:1ba::10) by BY5PR11MB4404.namprd11.prod.outlook.com (2603:10b6:a03:1c3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Mon, 25 May 2020 15:39:39 +0000
Received: from BY5PR11MB4211.namprd11.prod.outlook.com ([fe80::68c1:8669:246e:618]) by BY5PR11MB4211.namprd11.prod.outlook.com ([fe80::68c1:8669:246e:618%2]) with mapi id 15.20.3021.029; Mon, 25 May 2020 15:39:39 +0000
From: "Eliot Lear (elear)" 
To: "rfced-future@iab.org" 
Thread-Topic: RFC Editor Future Directions Program Interim
Thread-Index: AdYyqrJdDVEKMm0L/EumsCXaBLbe7g==
Date: Mon, 25 May 2020 15:39:38 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-publictraffictype: Email
authentication-results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=cisco.com;
x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAAEI5NDE2RTFELUU1RUMtNDZFRC1BOTQyLTBGQ0U3RjcyNDk1RAA=
x-originating-ip: [2a02:aa15:4101:2a80:7869:3670:6cde:619c]
x-ms-office365-filtering-correlation-id: cac6f037-ce7b-4e34-aa81-08d800c1d5f3
x-ms-traffictypediagnostic: BY5PR11MB4404:MeetingMessage
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0414DF926F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WInXX1FCDDo9xEeHNYZbP1EzOhWFaaLImi6IjEJu/bTMLcMA4ejkbLaqn41Y8VQu+IeerJzEY0J9sa3xs37hZbddLkKSxiAsVQ9vwU+QmhzTjV9wH7AIhyO3lIIYBbGUdQS9H21VPYQYzRg+Vt2JwHCjHqiCxRvJZ29CbkIM2gu7v6aX49e28Gd1F+fTd5MpFNCP/nPNykC4vAjSwj4DsEnu5lJb0kRZfXBpa3GzSmiCaWwgAmSDTf9LUQ+gR0n+Ke+6vn/9w89a2cE3nkUKyIiwxfI7XQQvlO9REkr4CpYK4auseSJIkiMaxSMkgvFVZchN+oL6X2z1bFObxZp97zGHjZG/x5P9yHsV/zGsVTj+GrAHB8i4gl0fE26Aeg/hX86DbuxgVXA+X/wFgeazow==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BY5PR11MB4211.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(396003)(346002)(376002)(366004)(39860400002)(136003)(71200400001)(55016002)(9686003)(6916009)(8676002)(5660300002)(186003)(2906002)(8936002)(86362001)(316002)(6506007)(33656002)(7696005)(66556008)(64756008)(66946007)(66476007)(66446008)(478600001)(16799955002)(966005)(91956017)(52536014)(76116006); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: dZE3MKe3qKHCITv5C0jzywyx9JObcB/jd+LpKAUodgrcyj1wX0W2ZoNkDPfUbqFmBA1wYL2/0VW/Y52bz3+Zlq1f0c+u/VLmfZoz2mK5QxduXu5pj55QN9q5/iEJcGyJkia/nwMIhBdUCpTQ2Ce5+zxg6x5Ev6tNh0rHD/wAU/1n/pXmGClkDBhVbsNmMu/kRHkGXzgRCwYGQViUCB25BB62Cys/z2asl1VhqBz8ZOEMfsGPQm7CiNu+/Q9J1UEMg72ZmIiLbAR5abgN/w33vWvai1TbhvYaWR+TljbSdiWfYmspb83wSJVw523aSHjLkiVMdeTnvCXAzWW8N2YoigtDJXitGVvPyEVLXYxUMr8mpu95pt6MiPOJ8SUmVpGN355qEqHei1sfuVk84ajVcwTZPgeFBVo7h7ohM6Zk0KkKedARknzuApdqh/uSzyGdqJYS0j5MrYN2BBS5RW+LPuW2OhdKT7XJEwkn1chjn99ZVHnPLyr8o3SLfdLqB/evbX9iSobrIl9vtv4zRTm1eTreQbYmoPdbnkX0QQANwcBhL4LUNiSlKTmpsk4lIQV9
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_002_BY5PR11MB421154928980606CA7109365BFB30BY5PR11MB4211namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cac6f037-ce7b-4e34-aa81-08d800c1d5f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2020 15:39:38.9640 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8SJbBC1D3rkEKNY/rJbAIvSkAGdE9eDTwbwi8gn4Iop3pHMFXpz8Fzmp+bIcVGLL
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4404
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: [Rfced-future] RFC Editor Future Directions Program 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: Mon, 25 May 2020 15:39:45 -0000

--_002_BY5PR11MB421154928980606CA7109365BFB30BY5PR11MB4211namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

See below for timing and coordinates.=0A=
=0A=
Proposed agenda:=0A=
=0A=
Take up where we left off tow weeks ago.  That was as follows:=0A=
=0A=
What issues does the RSE decide and what issues does this group decide?=0A=
A little bit of organizing as to how we should go forward=0A=
=0A=
The first item was meant to be a poll, but I haven=92t been able to send it=
 out yet, and am still looking for feedback. =0A=
=0A=
On the second item, we now have several drafts in the draft directory (Bria=
n=92s and Nevil=92s), and we have several people who have provided quite de=
tailed views on what they want from the series.  We have choices as to how =
to proceed.  Before we do that we have to have clarity on the first questio=
n.=0A=
=0A=
For people=92s benefit, the minutes to the previous meeting have been poste=
d in the data tracker.=0A=
=0A=
While it is tempting to take up Mike St. John=92s proposal, and others, the=
 hour is not particularly convenient for him or others from the East Coast =
to join in, so we=92ll hold off on that for now.=0A=
=0A=
Eliot=0A=
=0A=
Begin forwarded message:=0A=
=0A=
From: IAB Executive Administrative Manager =0A=
Subject: [Rfced-future] RFC Editor Future Development Program Virtual Meeti=
ng: 2020-05-27=0A=
Date: 11 May 2020 at 20:12:14 CEST=0A=
To: "IETF Announcement List" =0A=
Cc: rfced-future@iab.org=0A=
Reply-To: rfced-future@iab.org=0A=
=0A=
The RFC Editor Future Development Program will hold a virtual meeting.=0A=
=0A=
When: 27 May 2020 06:00 UTC=0A=
=0A=
Local times:=0A=
=0A=
 Pacific/Auckland; 27 May 18:00=0A=
 Australia/Sydney: 27 May 16:00=0A=
 Asia/Kolkata: 27 May 11:30am=0A=
 Europe/Berlin: 27 May 8:00am=0A=
 Europe/London: 27 May 7:00am=0A=
 North America/New York: 27 May 02:00=0A=
 North America/Chicago: 27 May 01:00=0A=
 North America/Los Angeles: 26 May 23:00=0A=
=0A=
Duration: 90 minutes=0A=
=0A=
Webex Information: =0A=
https://ietf.webex.com/ietf/j.php?MTID=3Dm1dd4253db4bdf3a30ef9f3aabc64ac75=
=0A=
Meeting number (access code): 618 437 612=0A=
Meeting password: rfcefdp=0A=
=0A=
Agenda:=0A=
=0A=
We will continue a roundtable exchange of people=92s views on the future =
=0A=
of the RFC Series Editor. We will further develop the agenda there.  All =
=0A=
are invited to participate, and to join the list, which can be found at =0A=
https://www.iab.org/mailman/listinfo/rfced-future.  The meeting will be =0A=
recorded.  Current information on the program can be found at =0A=
https://github.com/intarchboard/rfced-future.=0A=
=0A=
-- =0A=
Rfced-future mailing list=0A=
Rfced-future@iab.org=0A=
https://www.iab.org/mailman/listinfo/rfced-future=0A=
=0A=
-- =0A=
Rfced-future mailing list=0A=
Rfced-future@iab.org=0A=
https://www.iab.org/mailman/listinfo/rfced-future=

--_002_BY5PR11MB421154928980606CA7109365BFB30BY5PR11MB4211namp_
Content-Type: text/calendar; charset="utf-8"; method=REQUEST
Content-Transfer-Encoding: base64

QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n
ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpXLiBFdXJv
cGUgU3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDMwMDAw
DQpUWk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClJSVUxFOkZSRVE9WUVBUkxZ
O0lOVEVSVkFMPTE7QllEQVk9LTFTVTtCWU1PTlRIPTEwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB
WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9G
RlNFVFRPOiswMjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllN
T05USD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5J
WkVSO0NOPUVsaW90IExlYXIgKGVsZWFyKTptYWlsdG86ZWxlYXJAY2lzY28uY29tDQpBVFRFTkRF
RTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NO
PXJmY2VkLWZ1dHUNCiByZUBpYWIub3JnOm1haWx0bzpyZmNlZC1mdXR1cmVAaWFiLm9yZw0KREVT
Q1JJUFRJT047TEFOR1VBR0U9ZW4tVVM6U2VlIGJlbG93IGZvciB0aW1pbmcgYW5kIGNvb3JkaW5h
dGVzLlxuXG5Qcm9wb3NlDQogZCBhZ2VuZGE6XG5cblRha2UgdXAgd2hlcmUgd2UgbGVmdCBvZmYg
dG93IHdlZWtzIGFnby4gIFRoYXQgd2FzIGFzIGZvbGxvd3MNCiA6XG5cbldoYXQgaXNzdWVzIGRv
ZXMgdGhlIFJTRSBkZWNpZGUgYW5kIHdoYXQgaXNzdWVzIGRvZXMgdGhpcyBncm91cCBkZWNpZA0K
IGU/XG5BIGxpdHRsZSBiaXQgb2Ygb3JnYW5pemluZyBhcyB0byBob3cgd2Ugc2hvdWxkIGdvIGZv
cndhcmRcblxuVGhlIGZpcnN0DQogIGl0ZW0gd2FzIG1lYW50IHRvIGJlIGEgcG9sbFwsIGJ1dCBJ
IGhhdmVu4oCZdCBiZWVuIGFibGUgdG8gc2VuZCBpdCBvdXQgeWUNCiB0XCwgYW5kIGFtIHN0aWxs
IGxvb2tpbmcgZm9yIGZlZWRiYWNrLiBcblxuT24gdGhlIHNlY29uZCBpdGVtXCwgd2Ugbm93IGhh
dg0KIGUgc2V2ZXJhbCBkcmFmdHMgaW4gdGhlIGRyYWZ0IGRpcmVjdG9yeSAoQnJpYW7igJlzIGFu
ZCBOZXZpbOKAmXMpXCwgYW5kIHdlDQogIGhhdmUgc2V2ZXJhbCBwZW9wbGUgd2hvIGhhdmUgcHJv
dmlkZWQgcXVpdGUgZGV0YWlsZWQgdmlld3Mgb24gd2hhdCB0aGV5IHcNCiBhbnQgZnJvbSB0aGUg
c2VyaWVzLiAgV2UgaGF2ZSBjaG9pY2VzIGFzIHRvIGhvdyB0byBwcm9jZWVkLiAgQmVmb3JlIHdl
IGRvIA0KIHRoYXQgd2UgaGF2ZSB0byBoYXZlIGNsYXJpdHkgb24gdGhlIGZpcnN0IHF1ZXN0aW9u
LlxuXG5Gb3IgcGVvcGxl4oCZcyBiZW5lDQogZml0XCwgdGhlIG1pbnV0ZXMgdG8gdGhlIHByZXZp
b3VzIG1lZXRpbmcgaGF2ZSBiZWVuIHBvc3RlZCBpbiB0aGUgZGF0YSB0cmENCiBja2VyLlxuXG5X
aGlsZSBpdCBpcyB0ZW1wdGluZyB0byB0YWtlIHVwIE1pa2UgU3QuIEpvaG7igJlzIHByb3Bvc2Fs
XCwgYW5kIA0KIG90aGVyc1wsIHRoZSBob3VyIGlzIG5vdCBwYXJ0aWN1bGFybHkgY29udmVuaWVu
dCBmb3IgaGltIG9yIG90aGVycyBmcm9tIHRoDQogZSBFYXN0IENvYXN0IHRvIGpvaW4gaW5cLCBz
byB3ZeKAmWxsIGhvbGQgb2ZmIG9uIHRoYXQgZm9yIG5vdy5cblxuRWxpb3RcblwNCiBuQmVnaW4g
Zm9yd2FyZGVkIG1lc3NhZ2U6XG5cbkZyb206IElBQiBFeGVjdXRpdmUgQWRtaW5pc3RyYXRpdmUg
TWFuYWdlciA8ZQ0KIHhlY2RAaWFiLm9yZz5cblN1YmplY3Q6IFtSZmNlZC1mdXR1cmVdIFJGQyBF
ZGl0b3IgRnV0dXJlIERldmVsb3BtZW50IFByb2dyDQogYW0gVmlydHVhbCBNZWV0aW5nOiAyMDIw
LTA1LTI3XG5EYXRlOiAxMSBNYXkgMjAyMCBhdCAyMDoxMjoxNCBDRVNUXG5UbzogIkkNCiBFVEYg
QW5ub3VuY2VtZW50IExpc3QiIDxpZXRmLWFubm91bmNlQGlldGYub3JnPlxuQ2M6IHJmY2VkLWZ1
dHVyZUBpYWIub3JnXA0KIG5SZXBseS1UbzogcmZjZWQtZnV0dXJlQGlhYi5vcmdcblxuVGhlIFJG
QyBFZGl0b3IgRnV0dXJlIERldmVsb3BtZW50IFByb2dyDQogYW0gd2lsbCBob2xkIGEgdmlydHVh
bCBtZWV0aW5nLlxuXG5XaGVuOiAyNyBNYXkgMjAyMCAwNjowMCBVVENcblxuTG9jYWwgdGkNCiBt
ZXM6XG5cbiBQYWNpZmljL0F1Y2tsYW5kXDsgMjcgTWF5IDE4OjAwXG4gQXVzdHJhbGlhL1N5ZG5l
eTogMjcgTWF5IDE2OjAwXA0KIG4gQXNpYS9Lb2xrYXRhOiAyNyBNYXkgMTE6MzBhbVxuIEV1cm9w
ZS9CZXJsaW46IDI3IE1heSA4OjAwYW1cbiBFdXJvcGUvTG9uDQogZG9uOiAyNyBNYXkgNzowMGFt
XG4gTm9ydGggQW1lcmljYS9OZXcgWW9yazogMjcgTWF5IDAyOjAwXG4gTm9ydGggQW1lcmljYS8N
CiBDaGljYWdvOiAyNyBNYXkgMDE6MDBcbiBOb3J0aCBBbWVyaWNhL0xvcyBBbmdlbGVzOiAyNiBN
YXkgMjM6MDBcblxuRHVyYXRpbw0KIG46IDkwIG1pbnV0ZXNcblxuV2ViZXggSW5mb3JtYXRpb246
IFxuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01UDQogSUQ9bTFkZDQyNTNkYjRi
ZGYzYTMwZWY5ZjNhYWJjNjRhYzc1XG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2MTgg
NDMNCiA3IDYxMlxuTWVldGluZyBwYXNzd29yZDogcmZjZWZkcFxuXG5BZ2VuZGE6XG5cbldlIHdp
bGwgY29udGludWUgYSByb3VuZHRhYg0KIGxlIGV4Y2hhbmdlIG9mIHBlb3BsZeKAmXMgdmlld3Mg
b24gdGhlIGZ1dHVyZSBcbm9mIHRoZSBSRkMgU2VyaWVzIEVkaXRvci4gDQogV2Ugd2lsbCBmdXJ0
aGVyIGRldmVsb3AgdGhlIGFnZW5kYSB0aGVyZS4gIEFsbCBcbmFyZSBpbnZpdGVkIHRvIHBhcnRp
Y2lwYXQNCiBlXCwgYW5kIHRvIGpvaW4gdGhlIGxpc3RcLCB3aGljaCBjYW4gYmUgZm91bmQgYXQg
XG5odHRwczovL3d3dy5pYWIub3JnL21haQ0KIGxtYW4vbGlzdGluZm8vcmZjZWQtZnV0dXJlLiAg
VGhlIG1lZXRpbmcgd2lsbCBiZSBcbnJlY29yZGVkLiAgQ3VycmVudCBpbmZvDQogcm1hdGlvbiBv
biB0aGUgcHJvZ3JhbSBjYW4gYmUgZm91bmQgYXQgXG5odHRwczovL2dpdGh1Yi5jb20vaW50YXJj
aGJvYXJkL3INCiBmY2VkLWZ1dHVyZS5cblxuLS0gXG5SZmNlZC1mdXR1cmUgbWFpbGluZyBsaXN0
XG5SZmNlZC1mdXR1cmVAaWFiLm9yZ1xuaHR0cA0KIHM6Ly93d3cuaWFiLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3JmY2VkLWZ1dHVyZVxuXG4tLSBcblJmY2VkLWZ1dHVyZSBtYWlsaW5nDQogIGxpc3Rc
blJmY2VkLWZ1dHVyZUBpYWIub3JnXG5odHRwczovL3d3dy5pYWIub3JnL21haWxtYW4vbGlzdGlu
Zm8vcmZjZWQtZnUNCiB0dXJlDQpVSUQ6Qjk0MTZFMUQtRTVFQy00NkVELUE5NDItMEZDRTdGNzI0
OTVEDQpTVU1NQVJZO0xBTkdVQUdFPWVuLVVTOlJGQyBFZGl0b3IgRnV0dXJlIERpcmVjdGlvbnMg
UHJvZ3JhbSBJbnRlcmltDQpEVFNUQVJUO1RaSUQ9Vy4gRXVyb3BlIFN0YW5kYXJkIFRpbWU6MjAy
MDA1MjdUMDgwMDAwDQpEVEVORDtUWklEPVcuIEV1cm9wZSBTdGFuZGFyZCBUaW1lOjIwMjAwNTI3
VDA5MDAwMA0KQ0xBU1M6UFVCTElDDQpQUklPUklUWTo1DQpEVFNUQU1QOjIwMjAwNTI1VDE1Mzkz
N1oNClRSQU5TUDpPUEFRVUUNClNUQVRVUzpDT05GSVJNRUQNClNFUVVFTkNFOjANCkxPQ0FUSU9O
O0xBTkdVQUdFPWVuLVVTOldlYmV4IChzZWUgYmVsb3cpDQpYLU1JQ1JPU09GVC1DRE8tQVBQVC1T
RVFVRU5DRTowDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6MjExODUwMzU3OQ0KWC1NSUNS
T1NPRlQtQ0RPLUJVU1lTVEFUVVM6VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURT
VEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JPU09G
VC1DRE8tSU1QT1JUQU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6MA0KWC1NSUNST1NP
RlQtRE9OT1RGT1JXQVJETUVFVElORzpGQUxTRQ0KWC1NSUNST1NPRlQtRElTQUxMT1ctQ09VTlRF
UjpGQUxTRQ0KWC1NSUNST1NPRlQtTE9DQVRJT05TOlt7IkRpc3BsYXlOYW1lIjoiV2ViZXggKHNl
ZSBiZWxvdykiXCwiTG9jYXRpb25Bbm5vdGF0DQogaW9uIjoiIlwsIkxvY2F0aW9uVXJpIjoiIlws
IkxvY2F0aW9uU3RyZWV0IjoiIlwsIkxvY2F0aW9uQ2l0eSI6IiJcLCJMb2NhdGkNCiBvblN0YXRl
IjoiIlwsIkxvY2F0aW9uQ291bnRyeSI6IiJcLCJMb2NhdGlvblBvc3RhbENvZGUiOiIiXCwiTG9j
YXRpb25GdWxsQQ0KIGRkcmVzcyI6IiJ9XQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K

--_002_BY5PR11MB421154928980606CA7109365BFB30BY5PR11MB4211namp_--


From nobody Mon May 25 09:52: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 6A2183A0DD7 for ; Mon, 25 May 2020 09:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHbiCzRPOL_5 for ; Mon, 25 May 2020 09:52:03 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066473A0DCD for ; Mon, 25 May 2020 09:52:02 -0700 (PDT)
Received: (qmail 4004 invoked from network); 25 May 2020 16:52:01 -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=f9f.5ecbf7b1.k2005; bh=PJ8xQAObbXaQnZP1s2ZzuLxHmp0sVV+j6GNug9Pj9Ck=; b=jAYwvZ+h0QG7V1Ou4MO/he5ORoxfa4OvAxLGD0wMkVfDHoPyax44AOchBi5bCdUvw01Csi8w183PpMDM1Ccr35UvDTqrw6oIrE4j1ghUc/riYyMizeJD/IqL8GOZiVAdB7Q0DrqAmWHJLMN/PGj/ApUN5n6pqCYdAnlN1Ro9hvNjefmFYV89/N8+E9HQtm0tvF2qBSKHFOf8NUyid3eVWBD6NlD5RQsNHmyjREZZEnx1g2+2vcUmMhJVMV8ElmWg
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 25 May 2020 16:52:01 -0000
Received: by ary.qy (Postfix, from userid 501) id D76EC199A58B; Mon, 25 May 2020 12:52:00 -0400 (EDT)
Date: 25 May 2020 12:52:00 -0400
Message-Id: <20200525165200.D76EC199A58B@ary.qy>
From: "John Levine" 
To: rfced-future@iab.org
Cc: brong@fastmailteam.com
In-Reply-To: <53f690a7-9477-47a7-a256-75139aae269f@dogfood.fastmail.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 16:52:07 -0000

In article <53f690a7-9477-47a7-a256-75139aae269f@dogfood.fastmail.com> you write:
>At this point, the remedy for the RSE is to resign rather than publish under their watch. They must have this option open
>to them, but that is the ultimate remedy available to the RSE.

Agreed.  The point of a having a nuclear option is to force people on each side to think really
carefully before pushing the button.

>P.S. There also needs to be a way to deal with RSE filibustering, and/or tarpitting - either undue delay in publishing a
>document they don't like, or running out the clock and then sending it back with minor edits over and and over.

I think the solution to that is don't appoint an RSE who is a jerk,
rather than to try to invent meta-meta-rules for bad faith situations
unlikely to arise in practice. We have had RSEs for decades and as far
as I know filibustering has never been a problem.

R's,
John


From nobody Mon May 25 10:49: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 83A503A0E7A for ; Mon, 25 May 2020 10:49:28 -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 SGfXxkYHjcRC for ; Mon, 25 May 2020 10:49:26 -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 1A4443A0E8D for ; Mon, 25 May 2020 10:49:25 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id m44so14243250qtm.8 for ; Mon, 25 May 2020 10:49:25 -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=Lp85GIPl3kX2mys2Aw4DO8DQkzsfZ+ccXi3x51q3BGY=; b=jrG2L+NaXppiJ2xGdMQ61nXF3CKt7LwxfYGIYb0SLAq6GF6e21PUzRFvTTTCADvKAT grt2JRacPUKpxFH7gjBcxxVlZEIMOYG38/EWw4y90zpGK07nIDjF4c9V5aKswHfv1M+S 1lmxgtWA43/CK0y0ZmI4dI7E25tcTHwqSr729y8TNGpkzBi5hAVifD5wH7SvFMtSb7zp qHqqfR6sbJvj6zP2yzhqqG2CEh4WQmW+Fd/eNcZtv/oBy+eYInQG3joYwHrcDwUEdFpJ ll8gbSWvSYLlGYgwSGqMKgwkj2JAMTQ6M0NrqKpRnxpigewQfROgUZ1yL0042KyjEJ8w KRjQ==
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=Lp85GIPl3kX2mys2Aw4DO8DQkzsfZ+ccXi3x51q3BGY=; b=f1cOalqXKC3qQHxSUDA+RRN3mVVGm/nnwdqjIveZ9iJFlAPa1UB9RxMYsn5j89++H7 cmV8Ud29XP1nCMWVp88UPPCAk3/9ffayGlzw6EmdQW16gXLb2rYsOcwCSfbQ1+PkTJG4 ryGYUtmnj8nff+KOz7nmLR9wchnGouQv3peW1PdwvG/GJ1yBFxowZSnl6+wCjS4pfp35 s1plduvtIAUMO3FwQXgRVWBSU4xx9++PEsd1UX/GILDG3gTChnNzjzxVczOWsp0dKUPU /79evL75WQFqIsjlEcg8x0idvqeqkYZWBMfHQ/czP+glaN3N0oRiTyNdoIEGtU8QPK58 vMDA==
X-Gm-Message-State: AOAM533FGnnZauvijgA8Y/OhOlSWO3DPPg+LH+FS+XnVZX9lrKXSNyNB PNTocaPcQgGAiv3j67ZUYt2LmjV4ajI=
X-Google-Smtp-Source: ABdhPJxJMuxFPGYOrGM/s545QHn/rlpHrVhDMZYOvBmBmdX8TqGih+wMuqPMgCQ6NiIb3L0JUKIZLQ==
X-Received: by 2002:ac8:fb4:: with SMTP id b49mr6467810qtk.323.1590428964505;  Mon, 25 May 2020 10:49:24 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id 137sm1701511qkf.44.2020.05.25.10.49.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 10:49:23 -0700 (PDT)
To: Brian E Carpenter , rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <5c33a5fe-1fe4-1bfa-7382-9c1ca9f4f345@gmail.com>
From: Michael StJohns 
Message-ID: 
Date: Mon, 25 May 2020 13:49:22 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <5c33a5fe-1fe4-1bfa-7382-9c1ca9f4f345@gmail.com>
Content-Type: multipart/alternative; boundary="------------8B58F94C8F2552857633658E"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 17:49:29 -0000

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

On 5/24/2020 9:54 PM, Brian E Carpenter wrote:
>> The at-large members are selected for their experience in the IETF and their experience with publication systems with the latter given more weight.  They are selected through the normal Nomcom process
> How do we reach the whole candidate pool? Where do we send the call for nominations? We clearly want a wider spread than traditionally, if we are really trying to cover the whole RFC-using community. In fact, I don't see why IETF experience is the first criterion. Experience writing code or running networks based on RFCs seems equally important.

Oops - temporary myopia on my part.  I agree mostly.  I think this is 
the goal, but may take a few years to get there.

Mike



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


  
    
  
  
    
On 5/24/2020 9:54 PM, Brian E Carpenter
      wrote:

    

    

      

        
The at-large members are selected for their experience in the IETF and their experience with publication systems with the latter given more weight.  They are selected through the normal Nomcom process


      

      
How do we reach the whole candidate pool? Where do we send the call for nominations? We clearly want a wider spread than traditionally, if we are really trying to cover the whole RFC-using community. In fact, I don't see why IETF experience is the first criterion. Experience writing code or running networks based on RFCs seems equally important.

    

    
Oops - temporary myopia on my part.  I agree mostly.  I think
      this is the goal, but may take a few years to get there.  

    

    
Mike

    


    

  


--------------8B58F94C8F2552857633658E--


From nobody Mon May 25 11: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 61DE53A0EC4 for ; Mon, 25 May 2020 11:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DVsee8jjV7RK for ; Mon, 25 May 2020 11:09:31 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969DB3A0EC1 for ; Mon, 25 May 2020 11:09:31 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id c185so4050331qke.7 for ; Mon, 25 May 2020 11:09:31 -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=dUBNDwmOaiQWjUFu2V3GsN4vEYXU/oIF7RCyOvmXtZY=; b=uPXdgQB8Bgc5dUOkA9CYNWUUrD5cZWm4pCx5ZKinFHaMX3KCI1nUIsOh3yCBfx2Hmb 6P2NLaDoM3w9TfZt4vqIj/oY3hWqWnvlHmwXUr5LfvoWDdVTgegr0mqpoHA/JAl8+uFN hX8UBKaf/RdYRubjHZtXhhQhSvtKuTqVxxo+Ae7lubWCWxNmv6tOpsnHJssHwpGndpZw 3qSe0RJBbBUneUXnUCXrvag5RV7vNPrKcHvk/xZhgHU9eMWWo5dsAKlQv8PJ01djq7vP Z/k9GqlkdKcYKfg/iup1/SKlfEH/dVGxJ+DiHNPLUKqokeSPaYiN7K31sQznZX7n7ePM PKKg==
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=dUBNDwmOaiQWjUFu2V3GsN4vEYXU/oIF7RCyOvmXtZY=; b=Ezn5zyOdTSPupCYDpr3S/imjBSYaPRUspPljT4DlCcB1QwiT2hgSGRLldgmj34h10o LByMBHKu/sugxmslrPZcic0oEnByUbdFXpsC8fh1CT59M79BT8uaYFgLDEHUFGvEu3PJ oHTNzpb8VvmOw5g55l36T/NuvzmYir5Ka2yf5oPbMGHZoVNtsgcD6CFonL83O+03hJd8 UjvFD/ktWJrpZPJ01LjPdTJzOnYW/WpRTRQSos8xsbPATmaGqAZxGiR7QByRoBEG4+6J kjotcK0Rn+DzLzGYTyVOmWzDBhHnfjwd9Dp3vzOHV8tkdovhC4R6MMPhftCacYC9R2O3 7BZg==
X-Gm-Message-State: AOAM533jMj6Etho+UI3JluxZQvqlOSTbVIiJjac2GL7nPHdIaHAz77Wp 5QstjrzvdXTCPtYg/it/kAlQRA==
X-Google-Smtp-Source: ABdhPJx0Ex7biXqMAIXLjaKSNIEHyosPPJ2zgqYJlDxOkTNEY9wAY7XNoUTcglasQ/jtKXE8tGpRsQ==
X-Received: by 2002:a37:9f09:: with SMTP id i9mr13806051qke.60.1590430169463;  Mon, 25 May 2020 11:09:29 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id z60sm15030239qtc.30.2020.05.25.11.09.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 11:09:28 -0700 (PDT)
To: Eliot Lear 
Cc: rfced-future@iab.org, Mark Nottingham 
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <28BE2C74-D8A8-470B-A33F-F5A4A37BFBEA@cisco.com>
From: Michael StJohns 
Message-ID: 
Date: Mon, 25 May 2020 14:09:28 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <28BE2C74-D8A8-470B-A33F-F5A4A37BFBEA@cisco.com>
Content-Type: multipart/alternative; boundary="------------E27970A1C7F3D774E7907E97"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 18:09:34 -0000

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

On 5/25/2020 5:58 AM, Eliot Lear wrote:
>>
>> The at-large members must approve the ISE (who is nominated by the 
>> IAB).  Tie votes are broken by the RSE.
>>
>
> Mark asserted that appointment/approval of the ISE is not in scope for 
> this effort.  As I read our charter, I would tend to agree, although 
> it is a fine line.  Rather than get into a tussle over the charter, 
> because nobody has raised issues about the management of the stream 
> managers, let’s limit our scope to how the RSE and RPC interacts with 
> or is accountable to them.  We already have enough to be getting on with.


Firstly, on the matter of in charter-out of charter, this is in.   We 
re-organized the RFC system 10 years ago and the splitting out of the 
ISE from the RSE was one of the results.  It makes sense to take another 
look at whether that needs to continue or whether the ISE is properly 
chartered or circumscribed and whether in some circumstances it might 
make sense to fold the ISE back into the RSE.   I don't actually think 
that latter is the best approach, but its something that should be 
considered - at least as it effects the RSE roles and responsibilities.  
Note that as of right now both the ISE and RSE are funded positions, and 
that any protections we provide with respect to oversight of the RSE may 
also need to apply with respect to the ISE.

Secondly, on the matter of who appoints the ISE, it would be helpful if 
you consider the context in which I suggested this. My suggestions were 
meant to devolve the IAB from overall control of the RFC System and the 
change in appointment/approval of the ISE was in that vein.   Right now, 
the IAB appoints the RSE, the ISE and the IAB stream manager.  They also 
appoint the IRTF chair who appoints the IRTF stream manager.  In other 
words, out of 5 people, the IAB appoints or indirectly appoints 4.     
This proposal is in support of

"I'd like a system that evolves over time, and that is relatively immune to influence from relatively few people over a relatively short period of time."

Keep in mind, my baseline is the point where ISI transitioned out of the 
RFC SE role; we've had 10 years of experience with most of the changes 
from that point, and actually evaluating how they've worked out ought to 
be part of the information feeding into the process of this group.

Later, Mike



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


  
    
  
  
    
On 5/25/2020 5:58 AM, Eliot Lear wrote:

    

    

      

        

          

            
The
                  at-large members must approve the ISE (who is
                  nominated by the IAB).  Tie votes are broken by the
                  RSE.

          

        

      

      


      

      Mark asserted that appointment/approval of the ISE is not in scope
      for this effort.  As I read our charter, I would tend to agree,
      although it is a fine line.  Rather than get into a tussle over
      the charter, because nobody has raised issues about the management
      of the stream managers, let’s limit our scope to how the RSE and
      RPC interacts with or is accountable to them.  We already have
      enough to be getting on with.

    


    

    
Firstly, on the matter of in charter-out of charter, this is
      in.   We re-organized the RFC system 10 years ago and the
      splitting out of the ISE from the RSE was one of the results.  It
      makes sense to take another look at whether that needs to continue
      or whether the ISE is properly chartered or circumscribed and
      whether in some circumstances it might make sense to fold the ISE
      back into the RSE.   I don't actually think that latter is the
      best approach, but its something that should be considered - at
      least as it effects the RSE roles and responsibilities.  Note that
      as of right now both the ISE and RSE are funded positions, and
      that any protections we provide with respect to oversight of the
      RSE may also need to apply with respect to the ISE.

    

    
Secondly, on the matter of who appoints the ISE, it would be
      helpful if you consider the context in which I suggested this.  
      My suggestions were meant to devolve the IAB from overall control
      of the RFC System and the change in appointment/approval of the
      ISE was in that vein.   Right now, the IAB appoints the RSE, the
      ISE and the IAB stream manager.  They also appoint the IRTF chair
      who appoints the IRTF stream manager.  In other words, out of 5
      people, the IAB appoints or indirectly appoints 4.     This
      proposal is in support of 

    

    
"I'd like a system that evolves over time, and that is relatively immune to influence from relatively few people over a relatively short period of time."



    
Keep in mind, my baseline is the point where ISI transitioned out
      of the RFC SE role; we've had 10 years of experience with most of
      the changes from that point, and actually evaluating how they've
      worked out ought to be part of the information feeding into the
      process of this group.

    
Later, Mike

    
 

    

  


--------------E27970A1C7F3D774E7907E97--


From nobody Mon May 25 12:49: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 0C3923A0442 for ; Mon, 25 May 2020 12:49:25 -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 KnDJt9La89Vq for ; Mon, 25 May 2020 12:49:23 -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 432383A0440 for ; Mon, 25 May 2020 12:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3444; q=dns/txt; s=iport; t=1590436162; x=1591645762; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=c2PGorFGijMxWseKP+UfVOVt9p7ulh7WSmYs+GlTH0o=; b=TWkn+/ZyuHZHPFoxgD9HCQ61klMp5cyBm7riN+VU94O029uEodmi+xMi TJE+uGNyL6CNhbPPDb1pr+lKszsjvcBXHCpgbZBQjJkZxwnW5GSqSChqV iLL8n2vQzXSniUt9RD2CxF7JbXJlDlhI110WfxPBaLroZCMdcSac/5de8 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AAC1IMxe/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBdgQBAQsBg24BIBKEUYkBh2Qlk1aIEAsBAQEMAQEvBAEBhEQ?= =?us-ascii?q?CgkU3Bg4CAwEBCwEBBQEBAQIBBQRthWKFcwEEASNWBQsLBD4CAlcGgzmCXSC?= =?us-ascii?q?tAXaBMoVRhSGBOAGMXYIAgREnDBCCHy4+h2Izgi0EjwakIIJegnSVaB2CY4k?= =?us-ascii?q?ChGGNPKpng0kCBAYFAhWBaCOBVjMaCBsVZQGCPz0SGA2fCj8DZwIGAQcBAQM?= =?us-ascii?q?JjVgBAQ?=
X-IronPort-AV: E=Sophos; i="5.73,434,1583193600"; d="scan'208,217"; a="26438202"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 May 2020 19:49:17 +0000
Received: from [10.61.236.200] ([10.61.236.200]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04PJnHf4017494 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 May 2020 19:49:17 GMT
From: Eliot Lear 
Message-Id: <4DB5E967-061D-4778-9FFF-EE0F38427B48@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5927D465-6DD5-4E35-A1D8-732990BF7664"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 25 May 2020 21:49:17 +0200
In-Reply-To: 
Cc: rfced-future@iab.org, Mark Nottingham 
To: Michael StJohns 
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <28BE2C74-D8A8-470B-A33F-F5A4A37BFBEA@cisco.com> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.236.200, [10.61.236.200]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 19:49:26 -0000

--Apple-Mail=_5927D465-6DD5-4E35-A1D8-732990BF7664
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Mike,

> Secondly, on the matter of who appoints the ISE, it would be helpful =
if you consider the context in which I suggested this.   My suggestions =
were meant to devolve the IAB from overall control of the RFC System and =
the change in appointment/approval of the ISE was in that vein.   Right =
now, the IAB appoints the RSE, the ISE and the IAB stream manager.  They =
also appoint the IRTF chair who appoints the IRTF stream manager.  In =
other words, out of 5 people, the IAB appoints or indirectly appoints 4.
>=20

For one to take this view, one has to be of the opinion that the streams =
are part of the RFC Editor function.  I don=E2=80=99t see it that way.  =
I see the streams as interacting with that function.  This is why I view =
discussion of the ISE as out of scope.  That is not to say that I =
believe the IAB MUST continue to appoint and manage the ISE as they do =
today, but simply that it is not the task at hand in this group now.  =
Again, if others disagree with me, please say so.

This is also not to say that we can't adjust stream responsibilities =
relating to the RSE/RPC etc, as you have done in your interesting early =
proposal.  That I view as very much in scope.

Eliot=

--Apple-Mail=_5927D465-6DD5-4E35-A1D8-732990BF7664
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Mike,

Secondly, on the matter of who appoints the ISE, it would be
      helpful if you consider the context in which I suggested =
this.  
      My suggestions were meant to devolve the IAB from overall control
      of the RFC System and the change in appointment/approval of the
      ISE was in that vein.   Right now, the IAB appoints the =
RSE, the
      ISE and the IAB stream manager.  They also appoint the IRTF =
chair
      who appoints the IRTF stream manager.  In other words, out of =
5
      people, the IAB appoints or indirectly appoints =
4.

For one to =
take this view, one has to be of the opinion that the streams are part =
of the RFC Editor function.  I don=E2=80=99t see it that way. =
 I see the streams as interacting with that function.  This is =
why I view discussion of the ISE as out of scope.  That is not to =
say that I believe the IAB MUST continue to appoint and manage the ISE =
as they do today, but simply that it is not the task at hand in this =
group now.  Again, if others disagree with me, please say =
so.

This is also not to say that we =
can't adjust stream responsibilities relating to the RSE/RPC etc, as you =
have done in your interesting early proposal.  That I view as very =
much in scope.

Eliot
=

--Apple-Mail=_5927D465-6DD5-4E35-A1D8-732990BF7664--


From nobody Mon May 25 13:42: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 D599E3A0418 for ; Mon, 25 May 2020 13:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=kDZEDLCN; dkim=pass (1536-bit key) header.d=taugh.com header.b=jHBh/Hs5
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXGsaosXqSgC for ; Mon, 25 May 2020 13:42:08 -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 1D5FA3A02BB for ; Mon, 25 May 2020 13:42:04 -0700 (PDT)
Received: (qmail 55772 invoked from network); 25 May 2020 20:42:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=d9d9.5ecc2d9a.k2005; i=johnl-iecc.com@submit.iecc.com; bh=9V4o2srdnI4YbK2p25Yeuy/Sb22B6iwS7FxF+MW9vkU=; b=kDZEDLCNb6iQXK8gV7jjD9QGRpL2eiOCiyWY2LFUGp+qXGxk+3kTDRuZTQ9tDmZzj4Fxi2GGXf+1BDy5wEibZUecEgU8HleMXi8OlVvTqgH0DhBacIqbl7EY11bg4zOICv1EQVzJBQwU0XRZz5iNbsn0j81blRBMtJ2G+PDMDd7H3ymuaduTf7i1D8NZA1mNybvXA95U82R9k0p4rR3MYzgxSoqGlOY8oAjx4R3D2ipBqdp8IDOFUc/QGNqvVRcW
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=d9d9.5ecc2d9a.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=9V4o2srdnI4YbK2p25Yeuy/Sb22B6iwS7FxF+MW9vkU=; b=jHBh/Hs5JG7N5N9nCdvBI9DNB4RnTQAl2Ga1BeTzQMOa6YCQEmIU+aBxKlxMBOeR7k9mdUK/DVXyS/eS+ueXttGjhjfGHQWQKJGTwo8bOk7HpZWM8gz8cbsy6vB8mJDgmSsV1JkZnUcPrrRFyNOxzdfoE9CG7viG85UadbwDDB11A0Tgcx6lbP2nFXBsvMtrtOn6dVdd0M99TYJOPscKY13inQjOvSD+ULzwbuUHqsdT3/94sMIfpS4xWsgbJIO7
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; 25 May 2020 20:42:02 -0000
Date: 25 May 2020 16:42:02 -0400
Message-ID: 
From: "John R Levine" 
To: Rfced-future@iab.org
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: 
Subject: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 20:42:14 -0000

The RFC series is two things: it's a stable archival set of documents 
about the technology and history of the Internet, and it's where you find 
Internet standards and related specs like BCPs. For the vast majority of 
people likely to look at RFCs, the latter aspect is what matters. If we 
were just publishing a series of historical papers, that would be fine but 
there's no way it would merit the amount we spend editing and publishing 
RFCs.

The problem is that the RFC series does a lousy job of publishing 
technical specs. If someone wants to write an SMTP server or a DNS server, 
there's a long list of RFCs that overlap and rewrite each other, there's a 
zillion errata not part of the RFCs that you need to know to look for and 
see if they matter, and there is a great deal of folklore to know which 
RFCs are important and which you can ignore. (For example, RFC 3865 
defines an SMTP extension that we knew nobody would ever use other than to 
make a political point.)

I believe there were two key reasons our specs have succeeded: one is that 
they do work if you can figure them out, and the other is that unlike most 
other SDOs we have always given them away for free.  Open access is now 
increasingly common, so it would be a good idea to make them easier to use 
or at the least easier to find the ones you need.

I am not proposing specific changes other than to say that the model of 
RFCs solely as independent immutable documents no longer makes sense. 
While I do not suggest we go to WHATWG style living documents, I do think 
that for our specifications we need to find a more modern way to collect 
the material into a small number of places with stable names (perhaps 
using version numbers like everyone else does), and to make discrete low 
cost updates as we find errors or make partial updates.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Mon May 25 13:48:29 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE743A05A0 for ; Mon, 25 May 2020 13:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sehd3VysQWmY for ; Mon, 25 May 2020 13:48:25 -0700 (PDT)
Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 E3D223A053F for ; Mon, 25 May 2020 13:48:24 -0700 (PDT)
Received: by mail-oo1-xc2c.google.com with SMTP id q6so3819115oot.0 for ; Mon, 25 May 2020 13:48:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ErzZtknHMblSU57Ckl+tCRLCzp8UyVOfS1/fhxwebpU=; b=geZI43CNxBCacv8e8nISmjUwqqv42C35QYXERXiA2zlafafXu9bG7trgKFjGXq5Sh/ oNXD8r0/0Tw3Or9fZId9DLpxTAAnsm3ol2+a0LSLdipXImPoYNzzTW/RCu1kRQc9GPXN iPGs//POk+8JvBFaM+YeFz6uPPqQGJkGAkRj6ySgcttk0z3iereHRW3MQXqe14NQREVb NGa/HQjT1P6PfpFadPutb4tyKjKkZIVn7PvOmTX4vztyYaG6B8QyHVQtxE8bO9cWFlEn eWb1FnOrSSv9ixTr5KGkwFYghZP0on6fSPO8jmt+e6zXKOXmpI0dE5WNBzyvC7zAkj/V 17eg==
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=ErzZtknHMblSU57Ckl+tCRLCzp8UyVOfS1/fhxwebpU=; b=alrbqxs/LKzAcch+bH2XxSzzdWqqVnGSjPH3lIZFwK4ws65OQHfpVcEloaioQVPpiM NIQ/D8m/Ma6DxS/5JmQkIaoP4yq/G2PV3o3qZNvAYqo6uMCBRgKwtJyAaFanTxIt/GKc SW+9+pdIbxiP5tHW3t3qFlNMykKa9Z0G2Hg00gKsom8aud7xFrhfTb0R6ZBJAtobscDO aBQJaJricmJRwglkoFg8jIvxNPmbNVVKiCQLuRoB54DsRDiFTkJ4jfCY1r4KGzb7ezD/ bOrBhIcTxe7kmTC3BgC2YXy+hlVz2HEG27cN0eQOlEon1fNSsWMNZCaDp1iQ9nhGUkDS cx/A==
X-Gm-Message-State: AOAM530MTibSEdInwQXamOmoIwNdREqOtYeJ9C0+dA03YUU8nORdMqpI dbqsdQG/zvWjZozZieWeih92JsIBjLoiFYhZKl0=
X-Google-Smtp-Source: ABdhPJwW4ZQMtFpgrYMNL7lAfcFQYRFWj3tx/LUuTXnaRDwB2+fnQR/IfOts9JXWbBk8sgQ4uFcJifbCiEVPwBxsqC4=
X-Received: by 2002:a4a:9e54:: with SMTP id w20mr12423898ook.66.1590439702958;  Mon, 25 May 2020 13:48:22 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Tim Wicinski 
Date: Mon, 25 May 2020 16:48:11 -0400
Message-ID: 
To: John R Levine 
Cc: Rfced-future@iab.org
Content-Type: multipart/alternative; boundary="00000000000088153305a67f190f"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 20:48:28 -0000

--00000000000088153305a67f190f
Content-Type: text/plain; charset="UTF-8"

I am not proposing specific changes other than to say that the model of
RFCs solely as independent immutable documents no longer makes sense.

If there is anything I wish to get from this program, it is to get the IETF
to accept this position.  Once we accept this, we can start to plan on how
to get there.



tim


On Mon, May 25, 2020 at 4:42 PM John R Levine  wrote:

> The RFC series is two things: it's a stable archival set of documents
> about the technology and history of the Internet, and it's where you find
> Internet standards and related specs like BCPs. For the vast majority of
> people likely to look at RFCs, the latter aspect is what matters. If we
> were just publishing a series of historical papers, that would be fine but
> there's no way it would merit the amount we spend editing and publishing
> RFCs.
>
> The problem is that the RFC series does a lousy job of publishing
> technical specs. If someone wants to write an SMTP server or a DNS server,
> there's a long list of RFCs that overlap and rewrite each other, there's a
> zillion errata not part of the RFCs that you need to know to look for and
> see if they matter, and there is a great deal of folklore to know which
> RFCs are important and which you can ignore. (For example, RFC 3865
> defines an SMTP extension that we knew nobody would ever use other than to
> make a political point.)
>
> I believe there were two key reasons our specs have succeeded: one is that
> they do work if you can figure them out, and the other is that unlike most
> other SDOs we have always given them away for free.  Open access is now
> increasingly common, so it would be a good idea to make them easier to use
> or at the least easier to find the ones you need.
>
> I am not proposing specific changes other than to say that the model of
> RFCs solely as independent immutable documents no longer makes sense.
> While I do not suggest we go to WHATWG style living documents, I do think
> that for our specifications we need to find a more modern way to collect
> the material into a small number of places with stable names (perhaps
> using version numbers like everyone else does), and to make discrete low
> cost updates as we find errors or make partial updates.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

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



I am not proposing specific cha=
nges other than to say that the model of
RFCs solely as independent immutable documents no longer=
 makes sense.

If there is anything I wish to get from th=
is program, it is to get the IETF
to accept this position.=C2=A0 Once we accept th=
is, we can start to plan on how
to get there.=C2=A0



tim=C2=A0


On Mon, May 25, 2020 at 4:42 PM John R Le=
vine <johnl@taugh.com> wrote:<=
br>
The RFC series i=
s two things: it's a stable archival set of documents 

about the technology and history of the Internet, and it's where you fi=
nd 

Internet standards and related specs like BCPs. For the vast majority of 
people likely to look at RFCs, the latter aspect is what matters. If we 
were just publishing a series of historical papers, that would be fine but =


there's no way it would merit the amount we spend editing and publishin=
g 

RFCs.



The problem is that the RFC series does a lousy job of publishing 

technical specs. If someone wants to write an SMTP server or a DNS server, =


there's a long list of RFCs that overlap and rewrite each other, there&=
#39;s a 

zillion errata not part of the RFCs that you need to know to look for and <=
br>
see if they matter, and there is a great deal of folklore to know which 
RFCs are important and which you can ignore. (For example, RFC 3865 

defines an SMTP extension that we knew nobody would ever use other than to =


make a political point.)



I believe there were two key reasons our specs have succeeded: one is that =


they do work if you can figure them out, and the other is that unlike most =


other SDOs we have always given them away for free.=C2=A0 Open access is no=
w 

increasingly common, so it would be a good idea to make them easier to use =


or at the least easier to find the ones you need.



I am not proposing specific changes other than to say that the model of 
RFCs solely as independent immutable documents no longer makes sense. 

While I do not suggest we go to WHATWG style living documents, I do think <=
br>
that for our specifications we need to find a more modern way to collect 
the material into a small number of places with stable names (perhaps 

using version numbers like everyone else does), and to make discrete low 
cost updates as we find errors or make partial updates.



Regards,

John Levine, johnl@tau=
gh.com, Taughannock Networks, Trumansburg NY

Please consider the environment before reading this e-mail. https://jl.ly



-- 

Rfced-future mailing list

Rfced-future@iab.=
org

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




--00000000000088153305a67f190f--


From nobody Mon May 25 13:51:59 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3E3A045B for ; Mon, 25 May 2020 13:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmEMDnjYz7n6 for ; Mon, 25 May 2020 13:51:54 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 3B0AD3A0764 for ; Mon, 25 May 2020 13:51:54 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id j145so16989912oib.5 for ; Mon, 25 May 2020 13:51:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uAZ65++8+1wVDqdhkOzGpdr6MeDcBKZAGXBWQwNMltQ=; b=a/3OnhvWdLgaMfTMg53fCQmgxAEcYazW+ueI5PaYkDfY+OkoKUBGWSQU0HnwPY/Kb1 +wV/nOhprT/IFqQM2sqAceVplV775/VX0MjraS1Ey5DGADNvMXI16eNL017fxVruM5Yi McIkzwr0ijMkZq6nZG9CYI+msbx2MCGTvLKCEQJ1DzvqRxkA/lsouHBE+88Q/3UULQlI cNE3t9c4LBBcnm1KbtI6vFYMZqfOOuy9SnGh9knGsn/QaTlZNwzUh7COIZrrqI1lbmIT yL6gMy4FEKvr+4B3wqX7bffABx9GUofl/RbXuVwE7mImUp4XzcrRiqdB9u0wqZRDth8r nnrQ==
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=uAZ65++8+1wVDqdhkOzGpdr6MeDcBKZAGXBWQwNMltQ=; b=YlLZy1+0AdU1kT9GpxpZYZ+DkM5lRD7C3h3k0ZbK7d+ZEfxgwIXx7bsam8lYIBscmu mB4aW4E8RBgPRORtHHmZXltFE3agEBKRQ2xbM4begXhnVkDn9VbkhRvYXIXfA+FbzSnK 3CbVDXoq3hrGmM4xTw7JNDM+6uO2q4Ikb1On1b9IuePxvBFV9KVpt97MjWxsT03JygtD YKWC7MgOfrbDjZNjZVHZjWuHDiPYUnFHcYyOhq1eauu4LyPT1HMvRfFVpOAYMA9PkPFv OjjJFj6faVL6DSnK/I+G4nJZ338SwNZ4jV9Qy19+9HSaNdOL8+QaH7t+LDMWR5EmvM2o DeJA==
X-Gm-Message-State: AOAM530JNEcvYBXObF1JnnNEpTBRYcQLMqj0KVcz2arBYN1amFhAlFdw 5KVPNXC82xtBzT5hmNsTwdX0M1dU9U2IOuEjOVlgWHoZ
X-Google-Smtp-Source: ABdhPJyPCQ/RIM6WfP0tVcuECvdMHEd5dt+yWqHhG/5+Y1OpFdrjwbOhA6INmSe6KHVWCs/bAjrjhjqUSbSg5Wu4tEw=
X-Received: by 2002:aca:bd08:: with SMTP id n8mr11742892oif.173.1590439912397;  Mon, 25 May 2020 13:51:52 -0700 (PDT)
MIME-Version: 1.0
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <28BE2C74-D8A8-470B-A33F-F5A4A37BFBEA@cisco.com>  <4DB5E967-061D-4778-9FFF-EE0F38427B48@cisco.com>
In-Reply-To: <4DB5E967-061D-4778-9FFF-EE0F38427B48@cisco.com>
From: Tim Wicinski 
Date: Mon, 25 May 2020 16:51:41 -0400
Message-ID: 
To: Eliot Lear 
Cc: Michael StJohns , rfced-future@iab.org,  Mark Nottingham 
Content-Type: multipart/alternative; boundary="00000000000003ddfd05a67f266b"
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 20:51:57 -0000

--00000000000003ddfd05a67f266b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Eliot

Even if you take the opinion that the streams interact with the RFC Editor
function, I would still argue that the
RFC Editor function should have a larger role in the appointment/approval
of the stream managers.

tim

On Mon, May 25, 2020 at 3:49 PM Eliot Lear 
wrote:

> Hi Mike,
>
> Secondly, on the matter of who appoints the ISE, it would be helpful if
> you consider the context in which I suggested this.   My suggestions were
> meant to devolve the IAB from overall control of the RFC System and the
> change in appointment/approval of the ISE was in that vein.   Right now,
> the IAB appoints the RSE, the ISE and the IAB stream manager.  They also
> appoint the IRTF chair who appoints the IRTF stream manager.  In other
> words, out of 5 people, the IAB appoints or indirectly appoints 4.
>
>
> For one to take this view, one has to be of the opinion that the streams
> are part of the RFC Editor function.  I don=E2=80=99t see it that way.  I=
 see the
> streams as interacting with that function.  This is why I view discussion
> of the ISE as out of scope.  That is not to say that I believe the IAB MU=
ST
> continue to appoint and manage the ISE as they do today, but simply that =
it
> is not the task at hand in this group now.  Again, if others disagree wit=
h
> me, please say so.
>
> This is also not to say that we can't adjust stream responsibilities
> relating to the RSE/RPC etc, as you have done in your interesting early
> proposal.  That I view as very much in scope.
>
> Eliot
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

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


Eliot
=

Even=
 if you take the opinion that the streams interact with the RFC Editor func=
tion, I would still argue that the=C2=A0
RFC Editor function should have=
 a larger role in the=C2=A0appointment/approval of the stream managers.=C2=
=A0

<=
/div>
tim=C2=A0=


On Mon, May 25, 2020 at 3:49 PM Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:
Hi Mike,

Secondly, on the matter of who appoints the ISE, it =
would be
      helpful if you consider the context in which I suggested this.=C2=A0=
=C2=A0
      My suggestions were meant to devolve the IAB from overall control
      of the RFC System and the change in appointment/approval of the
      ISE was in that vein.=C2=A0=C2=A0 Right now, the IAB appoints the RSE=
, the
      ISE and the IAB stream manager.=C2=A0 They also appoint the IRTF chai=
r
      who appoints the IRTF stream manager.=C2=A0 In other words, out of 5
      people, the IAB appoints or indirectly appoints 4.

For one to take this view, one has to be of t=
he opinion that the streams are part of the RFC Editor function.=C2=A0 I do=
n=E2=80=99t see it that way.=C2=A0 I see the streams as interacting with th=
at function.=C2=A0 This is why I view discussion of the ISE as out of scope=
.=C2=A0 That is not to say that I believe the IAB MUST continue to appoint =
and manage the ISE as they do today, but simply that it is not the task at =
hand in this group now.=C2=A0 Again, if others disagree with me, please say=
 so.

This is also not to say that we can't adj=
ust stream responsibilities relating to the RSE/RPC etc, as you have done i=
n your interesting early proposal.=C2=A0 That I view as very much in scope.=


Eliot
-- 

Rfced-future mailing list

Rfced-future@iab.=
org

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




--00000000000003ddfd05a67f266b--


From nobody Mon May 25 14:06: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 D8A453A08F0 for ; Mon, 25 May 2020 14:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn8XANFi9ELs for ; Mon, 25 May 2020 14:06:35 -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 E84283A08EF for ; Mon, 25 May 2020 14:06:34 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id q24so352027pjd.1 for ; Mon, 25 May 2020 14:06:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RM5xV3Kf3uMTRz2s79ekL6rukhwARDpmS2N03dNS3Ws=; b=Gq4ix+b7myFliQxDSw9OCWgO5/7Kp+QLKIvb8myuuoOnTl/GUfGrhJ+d4uoetK3LV6 sOazZt79TcGqksahv3nAAJdsBKQv3n5PmXhpw2TwVe97fC5IuOgaRMCmOc7yKqIU6skl 6pK6p/d5BqkZ98bSTe3DPWDizaDbMAcafsji2dbUwjrS9SjGtS/Kau0KztrRNSCLRpMn Uzycfiuli3MDH2p0NwN9sLBguQ5mMV5TzyH87c15YQEH7bohMywI35mr9monsQiRnciq lA8mO3Aw66dna681V1a5WhxsrUv2yfrbasfGi5j1HgjXIPsHVPIlH7N7lZJJlw4Brbpv GdUA==
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=RM5xV3Kf3uMTRz2s79ekL6rukhwARDpmS2N03dNS3Ws=; b=gPypiFeENS3jZvYSWhoxf354ZZU9pQGjG7kNfcCGSxWrwNOTqiNfLvRvSpnCMxJgNg uJ6vLGKPanBYzIQPSwTtXazyKtaw4HW5eQD9Zu5AWHYNkx8ITJsq7+8a/fIl6o+sPYhU fE8xpoMcrkY1K2Los/aU4ZoXpxAPpD/IHbW/J7DHm/Bz9TYW4+gDabQRWGTc8cI4WeO1 7FtpPeBVXHTokdPg98wC8C5EkQmhqIF5/UVrpHxWgUwBhmW/xabTQlDOFeksmkdDlTkL kFPwhJ1sfsXlyMuhJqxS+sUG4iE7N1NxpAJGeosW8IYI4bHGX70oQWyZZ2zHFdiV1n+w z6gw==
X-Gm-Message-State: AOAM532QpWgmlpDmFIFjosaxrr4Uo+emaUy9/b74aSSJkP1Z9LPy9ask UZZgQUjQb2sJR+FrDNsu7oelysNd
X-Google-Smtp-Source: ABdhPJwnoe/tFxOYRP3tpD2c+QbO8iJ7UfSRv9Hb9RgHRLmrxgpOpyAB5FtAn1Vc44F2616vpr7Mjw==
X-Received: by 2002:a17:90a:71c2:: with SMTP id m2mr21478844pjs.21.1590440793143;  Mon, 25 May 2020 14:06:33 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id i3sm13658922pfe.44.2020.05.25.14.06.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 14:06:32 -0700 (PDT)
To: Bron Gondwana , rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <28BE2C74-D8A8-470B-A33F-F5A4A37BFBEA@cisco.com> <53f690a7-9477-47a7-a256-75139aae269f@dogfood.fastmail.com>
From: Brian E Carpenter 
Message-ID: 
Date: Tue, 26 May 2020 09:06:28 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <53f690a7-9477-47a7-a256-75139aae269f@dogfood.fastmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 21:06:40 -0000

On 26-May-20 02:08, Bron Gondwana wrote:
> On Mon, May 25, 2020, at 19:58, Eliot Lear wrote:
>>
>>> The RSE may recommend that any document not be published and with a m=
ajority vote by the RSEB prohibit publication. =C2=A0=C2=A0This shall gen=
erally be a last resort after negotiation with the publication stream ove=
r perceived problems.
>>
>> In my view, based on the discussion that previously occurred, the over=
whelming consensus is against you. =C2=A0If people *other*=C2=A0than Mike=
 agree with the above text, please say so now.
>=20
> I have not yet commented on this, but I believe I am with the overwhelm=
ing here.

Me too. My own draft suggests three principles here:

       *  The RFC Editor team has control of editorial matters, subject
          to review by the relevant stream and the document authors.  In
          particular, a badly written document may be returned to its
          stream for improvements if an abnormal amount of copy-editing
          is required.

       *  If an individual member of the RFC Editor team has personal
          comments on the technical content of a draft RFC, they must be
          handled in person, using the appropriate mechanism of the
          stream concerned, not as an RFC Editor matter.

       *  If the RFC Editor team believes that a draft RFC contains a
          serious technical flaw, which the stream declines to change,
          the RFC Editor cannot block the document indefinitely.  Note
          that there is more discussion of such disagreements in
          Section 4.3 of [RFC8728].

I intentionally made this a team matter, not a personal matter for the RS=
E.
If the RSE wants to argue for pi=3D22/7, they can do so as an individual
participant.

> This issue only occurs in the situation where the RSE has said "I don't=
 want to publish this document for reasons X, Y, Z" and the elected repre=
sentatives of the IETF have said "regardless, we have reasons which overr=
ide those concerns and insist that you publish".
>=20
> At this point, the remedy for the RSE is to resign rather than publish =
under their watch.=C2=A0 They must have this option open to them, but tha=
t is the ultimate remedy available to the RSE.
>=20
> Refusal to publish and retaining the role is not tenable.=C2=A0 The RSE=
 and the RFC series exist to serve the streams, not the other way around.=

>=20
> The role of the RSE is to ensure that high quality documents are create=
d which accurately represent the intent of the stream owners.
>=20
> Eliot - you are quite correct that this is the first key question we ne=
ed to have consensus on in order to describe this role: who will have ult=
imate authority to determine which documents are published.

The only good answer to that is "the community". And yes, I know that lea=
ves some uncertainty at the heart of the matter. The procedure in https:/=
/www.rfc-editor.org/rfc/rfc8728.html#name-disagreements-among-entitie goe=
s into this (but based on the IAB/RSOC model, which I assume we will be c=
hanging).

Regards
    Brian

>=20
> Regards,
>=20
> Bron.
>=20
> P.S. There also needs to be a way to deal with RSE filibustering, and/o=
r tarpitting - either undue delay in publishing a document they don't lik=
e, or running out the clock and then sending it back with minor edits ove=
r and and over.
>=20
> P.P.S. I will provide some justification for why I take this position. =
It is along the lines of "The Net interprets censorship as damage and rou=
tes around it." - I don't wish to see fragmentation where the IAB or IETF=
 find themselves needing to publish a separate stream of documents and st=
art treating them as authoritative.
>=20
> --
> =C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd
> =C2=A0 brong@fastmailteam.com
>=20
>=20
>=20


From nobody Mon May 25 14:07:11 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A443A08EF for ; Mon, 25 May 2020 14:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0QxdlaYXgIQ for ; Mon, 25 May 2020 14:07:01 -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 D54203A08F0 for ; Mon, 25 May 2020 14:07:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49W8mP4kLbz6GD8w; Mon, 25 May 2020 14:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590440821; bh=jUv4/ty6N39ObuR+FVGsso+axezy/ohC5Yr7Rf8aF6U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NwBEvdKtQv0wM2K4bG/gWSIg2T0WGVRB97vlbmNOBdLkkO7OWqKaImNdvGMxO9PtX zsUhsfdX7SOzQO/iSaCoOg0EDFticXlPXQ+LbfWXbWlLdDyDZcPsA7Meb+Al4Sf6o7 qhXQzsPi/L8IAIszcaTDYlAPMi4WnAKJs6DzJuhI=
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 49W8mP1GD6z6GD8s; Mon, 25 May 2020 14:07:01 -0700 (PDT)
To: John R Levine , Rfced-future@iab.org
References: 
From: "Joel M. Halpern" 
Message-ID: 
Date: Mon, 25 May 2020 17:06:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 21:07:04 -0000

Personally, I find coupling the difficulty (real) with people finding 
the set of documents about a topic to the question of whether RFCs 
should be immutable to be a mixing of very different concepts.  As has 
been noted in other discussions, the question documents into subjects, 
and how to determine what set of RFCs go with what problem is 
non-trivial.  Is it worth addressing?  Yes.  But it is much cleaner to 
keep the bundling separate from the actual technical specifications. 
This is particularly true because in many cases the way the protocol is 
actually used turns out to be quite different from the expectations when 
it was published.  (One of the reasons it took Scott and me years to 
kill RIP, and it still came back, is that it was used very differently 
from other routing protocols.)

One can try to argue that the question of such bundling should be part 
of the RSE / RPC / ... work space.  I would find this quite surprising, 
since it turns out to be a significant technical task, and only 
secondarily a publication or editorial task.  I will grant that if the 
RSE is knoweldgable about information structuring (librarian science as 
it was once known, a skill Heather did have) they are a good source of 
input to designing the process.  But that still would not make them the 
party to execute such a process.

Net: no, I do not believe this valid question sheds light on whether 
RFCs should be immutable.  And I do not think it sheds much light on 
what we want from an RSE.

Yours,
Joel

On 5/25/2020 4:42 PM, John R Levine wrote:
> The RFC series is two things: it's a stable archival set of documents 
> about the technology and history of the Internet, and it's where you 
> find Internet standards and related specs like BCPs. For the vast 
> majority of people likely to look at RFCs, the latter aspect is what 
> matters. If we were just publishing a series of historical papers, that 
> would be fine but there's no way it would merit the amount we spend 
> editing and publishing RFCs.
> 
> The problem is that the RFC series does a lousy job of publishing 
> technical specs. If someone wants to write an SMTP server or a DNS 
> server, there's a long list of RFCs that overlap and rewrite each other, 
> there's a zillion errata not part of the RFCs that you need to know to 
> look for and see if they matter, and there is a great deal of folklore 
> to know which RFCs are important and which you can ignore. (For example, 
> RFC 3865 defines an SMTP extension that we knew nobody would ever use 
> other than to make a political point.)
> 
> I believe there were two key reasons our specs have succeeded: one is 
> that they do work if you can figure them out, and the other is that 
> unlike most other SDOs we have always given them away for free.  Open 
> access is now increasingly common, so it would be a good idea to make 
> them easier to use or at the least easier to find the ones you need.
> 
> I am not proposing specific changes other than to say that the model of 
> RFCs solely as independent immutable documents no longer makes sense. 
> While I do not suggest we go to WHATWG style living documents, I do 
> think that for our specifications we need to find a more modern way to 
> collect the material into a small number of places with stable names 
> (perhaps using version numbers like everyone else does), and to make 
> discrete low cost updates as we find errors or make partial updates.
> 
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> 


From nobody Mon May 25 14:10: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 5AF123A0930 for ; Mon, 25 May 2020 14:10:43 -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 xOXPKljpGV7B for ; Mon, 25 May 2020 14:10:41 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 D31453A0903 for ; Mon, 25 May 2020 14:10:40 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id q2so22044648ljm.10 for ; Mon, 25 May 2020 14:10:40 -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=2A2QBwNRJKIAaiZyNsEUnqPR8VvFnbq1zYe/02/JAtI=; b=ot0bsWsYeglyp/UCV0XIb1daiVYTqUN3ZaRw+y5qUbnkTRexXqKo1loU9SUVnPHWRm 9ZMstMxN+V6w7kinxWaHb0/yGKWIt6U0bF8gdXXrly1MLBe3+1K2NUO4JY/CsB1iZCNw /ErsmzWX9KwAttBVWq2mudX3EHd1S6BkLeGM7u3kZXQ/6ilI8p62XZOWvMMJCWfVdUIg TsLk9pQYEHM4Gl/gBVBtYZse50Tn2Wh6/qg3WuMkIko9QQ1gV7hYj+MXTD7JCup1bQNi +VCkwZkWIJAsw2YXYW1mBzQFibgjAe1y+QE73qsd48TCYmY8jUAC0MRG1/s1rUIB9Jnl QgIQ==
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=2A2QBwNRJKIAaiZyNsEUnqPR8VvFnbq1zYe/02/JAtI=; b=NcNuSycC7UJskRCszUkOTsOv0NQx3yzxorFUzzfuqXrovj1mSeJeTsX1Fr8xGpcoO8 j3w0KvRvavPINYxWc1sbowcEfBOFDz0yz7JpY5atMDiAdVm67ucUtM62xGJCyCcBgB8E oOKnYDCN848Mcslt604cZb+athvppvMkLjT7HEF9SYMStWk2KQpAN+WSoTm5GnEQTb4x pUc7CGGoPQmEFxsOvdYhmcQ32rJFEUdGB5XjXQyvxIC8MMglD6MU/VXCnhfrf/d8qiXk nDG8IpDtGqK9WnrB5kAN27JHb1xPY8UERPaEeS9+ITTTqOzUPqD8rlt3XVRbbsP21WkS xjTw==
X-Gm-Message-State: AOAM532D3vMTQ/URd7z4NjlX3y1liad2jdOXLw2xcnomQxFGud38YRcd kQxJvRqKlMWk7ltQNTERRwhj0NmqE/mN/x4SYehdrtK3GSU=
X-Google-Smtp-Source: ABdhPJzaq/nqPTaqEFZo7tRhBk0DSqSBfRz9OmvKAoDiDyrHlEGEDO7arMdCHMRUHQzUWYhnV0eQHuXE5JWVHZ+7p4I=
X-Received: by 2002:a2e:3201:: with SMTP id y1mr6682881ljy.13.1590441038791; Mon, 25 May 2020 14:10:38 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Eric Rescorla 
Date: Mon, 25 May 2020 14:10:02 -0700
Message-ID: 
To: John R Levine 
Cc: Rfced-future@iab.org
Content-Type: multipart/alternative; boundary="00000000000027601d05a67f6916"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 21:10:44 -0000

--00000000000027601d05a67f6916
Content-Type: text/plain; charset="UTF-8"

On Mon, May 25, 2020 at 1:42 PM John R Levine  wrote:

> The RFC series is two things: it's a stable archival set of documents
> about the technology and history of the Internet, and it's where you find
> Internet standards and related specs like BCPs. For the vast majority of
> people likely to look at RFCs, the latter aspect is what matters. If we
> were just publishing a series of historical papers, that would be fine but
> there's no way it would merit the amount we spend editing and publishing
> RFCs.
>
> The problem is that the RFC series does a lousy job of publishing
> technical specs. If someone wants to write an SMTP server or a DNS server,
> there's a long list of RFCs that overlap and rewrite each other, there's a
> zillion errata not part of the RFCs that you need to know to look for and
> see if they matter, and there is a great deal of folklore to know which
> RFCs are important and which you can ignore. (For example, RFC 3865
> defines an SMTP extension that we knew nobody would ever use other than to
> make a political point.)
>
> I believe there were two key reasons our specs have succeeded: one is that
> they do work if you can figure them out, and the other is that unlike most
> other SDOs we have always given them away for free.  Open access is now
> increasingly common, so it would be a good idea to make them easier to use
> or at the least easier to find the ones you need.
>
> I am not proposing specific changes other than to say that the model of
> RFCs solely as independent immutable documents no longer makes sense.
> While I do not suggest we go to WHATWG style living documents, I do think
> that for our specifications we need to find a more modern way to collect
> the material into a small number of places with stable names (perhaps
> using version numbers like everyone else does), and to make discrete low
> cost updates as we find errors or make partial updates.
>

I wanted to +1 this and perhaps expand upon it.

>From my perspective as a document author and consumer of documents,
there are several classes of changes one might wish to make to those
documents:

- Editorial changes. In our current system, these are basically
  impossible. People of course file errata, but it's very unlikely
  we will publish a new version of the document just to fix this
  kind of issue. This is perhaps not that big a deal for truly
  editorial issues (spelling, etc.) but it's not uncommon for
  the document to be somewhat unclear on some semantic point
  but there actually to be pretty good consensus on what the
  text is intended to mean. In the current environment, we're
  just left with ambiguity.

- Extensions. A large number of our protocols are actually frameworks
  with a pile of extensions, some of which are mostly irrelevant
  (e.g., TLS status_request_v2) and some of which are practically core
  pieces of the protocol (e.g., TLS elliptic curve cipher suites for
  TLS 1.2).  In principle, of course, one can chase through the IANA
  registries, but as a practical matter it's largely a matter of lore
  what's important and what's not. In an ideal world, we would present
  the core specification, including the important extensions, as a
  coherent whole, but the current structure gets in the way of that.

- Technical changes. Finally, there are settings in which one wishes
  to make technical changes. For instance, TLS 1.2 includes backward
  compatibility modes for versions of SSL we now prohibit. But you
  have to read some other document to find that out, as opposed to
  just reading the current recommendations in the main spec.

If we believe our objective here is to publish working technical
specifications, then addressing these points (and perhaps others)
should be a high priority.


I'd also like to briefly address the notion of "archival" here.
I see the term used a lot but at least from my perspective, it
potentially covers a set of different properties:

- Being able to be read well into the future.
- Capturing the history of the development of the protocol/document
- Being able to refer unambiguously to a specific point in the
  development of the protocol

I agree that these are valuable properties. However, I believe that
there is another valuable property, which is the ability to easily
refer to the *current* state of the protocol. This is not well served
by the existing structure. Perhaps in the past these were in tension,
however due to technological improvements (some combination of cheaper
storage and bandwidth and modern version control tools), we should be
able to preserve both the ability to easily know what the current
state is and to trace the entire history of the protocol. This
is something we routinely do for software systems and we should
be able to define a way to do so for our technical specifications
as well.

-Ekr

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




=

On Mon, May 25, 2020 at 1:42 PM John =
R Levine <johnl@tau=
gh.com> wrote:
The RFC series is two things: it's a stable archival set of docum=
ents 

about the technology and history of the Internet, and it's where you fi=
nd 

Internet standards and related specs like BCPs. For the vast majority of 
people likely to look at RFCs, the latter aspect is what matters. If we 
were just publishing a series of historical papers, that would be fine but =


there's no way it would merit the amount we spend editing and publishin=
g 

RFCs.



The problem is that the RFC series does a lousy job of publishing 

technical specs. If someone wants to write an SMTP server or a DNS server, =


there's a long list of RFCs that overlap and rewrite each other, there&=
#39;s a 

zillion errata not part of the RFCs that you need to know to look for and <=
br>
see if they matter, and there is a great deal of folklore to know which 
RFCs are important and which you can ignore. (For example, RFC 3865 

defines an SMTP extension that we knew nobody would ever use other than to =


make a political point.)



I believe there were two key reasons our specs have succeeded: one is that =


they do work if you can figure them out, and the other is that unlike most =


other SDOs we have always given them away for free.=C2=A0 Open access is no=
w 

increasingly common, so it would be a good idea to make them easier to use =


or at the least easier to find the ones you need.



I am not proposing specific changes other than to say that the model of 
RFCs solely as independent immutable documents no longer makes sense. 

While I do not suggest we go to WHATWG style living documents, I do think <=
br>
that for our specifications we need to find a more modern way to collect 
the material into a small number of places with stable names (perhaps 

using version numbers like everyone else does), and to make discrete low 
cost updates as we find errors or make partial updates.

I wanted to +1 this and perhaps expand upon it.

From my =
perspective as a document author and consumer of documents,
there are se=
veral classes of changes one might wish to make to those
documents:

- Editorial changes. In our current system, these are ba=
sically
=C2=A0 impossible. People of course file errata, but it's ve=
ry unlikely
=C2=A0 we will publish a new version of the document just to=
 fix this
=C2=A0 kind of issue. This is perhaps not that big a deal for =
truly
=C2=A0 editorial issues (spelling, etc.) but it's not uncommon=
 for
=C2=A0 the document to be somewhat unclear on some semantic point=C2=A0 but there actually to be pretty good consensus on what the
=C2=
=A0 text is intended to mean. In the current environment, we're
=C2=
=A0 just left with ambiguity. =C2=A0

- Extensions. A large number of=
 our protocols are actually frameworks
=C2=A0 with a pile of extensions,=
 some of which are mostly irrelevant
=C2=A0 (e.g., TLS status_request_v2=
) and some of which are practically core
=C2=A0 pieces of the protocol (=
e.g., TLS elliptic curve cipher suites for
=C2=A0 TLS 1.2).=C2=A0 In pri=
nciple, of course, one can chase through the IANA
=C2=A0 registries, but=
 as a practical matter it's largely a matter of lore
=C2=A0 what'=
;s important and what's not. In an ideal world, we would present
=C2=
=A0 the core specification, including the important extensions, as a
=C2=
=A0 coherent whole, but the current structure gets in the way of that.
=
=C2=A0 =C2=A0 
- Technical changes. Finally, there are settings in which=
 one wishes
=C2=A0 to make technical changes. For instance, TLS 1.2 incl=
udes backward
=C2=A0 compatibility modes for versions of SSL we now proh=
ibit. But you
=C2=A0 have to read some other document to find that out, =
as opposed to
=C2=A0 just reading the current recommendations in the mai=
n spec.

If we believe our objective here is to publish working techn=
ical
specifications, then addressing these points (and perhaps others)should be a high priority.


I'd also like to briefly addres=
s the notion of "archival" here.
I see the term used a lot but=
 at least from my perspective, it
potentially covers a set of different =
properties:

- Being able to be read well into the future.
- Captu=
ring the history of the development of the protocol/document
- Being abl=
e to refer unambiguously to a specific point in the
=C2=A0 development o=
f the protocol 

I agree that these are valuable properties. However,=
 I believe that
there is another valuable property, which is the ability=
 to easily
refer to the *current* state of the protocol. This is not wel=
l served
by the existing structure. Perhaps in the past these were in te=
nsion,
however due to technological improvements (some combination of ch=
eaper
storage and bandwidth and modern version control tools), we should=
 be
able to preserve both the ability to easily know what the currentstate is and to trace the entire history of the protocol. This
is somet=
hing we routinely do for software systems and we should
be able to defin=
e a way to do so for our technical specifications
as well.

-Ekr


--00000000000027601d05a67f6916--


From nobody Mon May 25 14:11: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 7B2113A0930 for ; Mon, 25 May 2020 14:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBl3I180PFHl for ; Mon, 25 May 2020 14:11:14 -0700 (PDT)
Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (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 F07A83A0903 for ; Mon, 25 May 2020 14:11:13 -0700 (PDT)
Received: by mail-pj1-x1042.google.com with SMTP id t8so351375pju.3 for ; Mon, 25 May 2020 14:11:13 -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=feghLROQ467UkllISQQEs8Aorwm02PyTzNp//Yyw2oY=; b=cimtMLDanzdH7IJmHnT27jibTkPIAxRdPwA5lyMq6xE4U4W3TAbH98axy0wyZgDuNk cBs5xZLeLRevbfEzCyg8dmDn2bEBZfExRBbBxeWZ2Xg8CugtmBUf6EdIAAmglcDEeMu3 As5SvkfDBHfg6SLaNvLChR1a0Qxg2S3OMy0CkeJ4FT5a//HJ0eE1rMWdWCjQ/8B+kwd6 FCPEww62mz3ObjPy3ORaxm0AWuoVIX5KlAqQr4SuTaR41HMkz9sN7J6nG+DXx56h23oX G8GKFdXaidMZJ2vh7z+dMFEHZga4U48vkk8WDcl+VNkgNiMmibMuj5YbJfuqFV/qzs8j Wv0A==
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=feghLROQ467UkllISQQEs8Aorwm02PyTzNp//Yyw2oY=; b=D/VB5YDNauzF+15wW8PUIIYDrKgbDtrRHn8jyVNAz799qBsIbgZ05GWAEU3qJotCv9 TeJbQD/+sXezrKwm7wHYrWi1+1nnfsF0yiP2wyD66rMefUniaAhLl3VAB1B4sjqa/cZF lIVjFFqa+Yxyq6JoPFGTZSOsVEIo6fRrhxu9rC08KdZk3j1eIMqC03ZsUEeQuNeNaUU9 EhRfrz2tFqwgoUU8pp/EzpklpZzsMk2ao3RM1tkTjG7SzRapM3vSQvlldYqCUeU24+JC 1LoP0MgP1NIqFtKNiYm2H5JMVhVaWsxlvUzQHJ8zaUUtnr9crLaql61sL+CNBgoW41Xy WYeQ==
X-Gm-Message-State: AOAM53015TanRfGfSQ2uf56gwvCFM1yYLv47ZDF+JioifimKbkmv4OKx 7a3t99IkQl30OWBPzMrBdiDcR/y1
X-Google-Smtp-Source: ABdhPJxswwltnB//zDsw+ulFjEgnf8H4t8JJ9M2XduYtHbAVKa/YDsRFBhZTqMI43IiB6GAQNN7w4Q==
X-Received: by 2002:a17:90a:f292:: with SMTP id fs18mr4696074pjb.37.1590441073283;  Mon, 25 May 2020 14:11:13 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id e26sm12306284pgl.27.2020.05.25.14.11.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 14:11:12 -0700 (PDT)
To: John R Levine , Rfced-future@iab.org
References: 
From: Brian E Carpenter 
Message-ID: 
Date: Tue, 26 May 2020 09:11:09 +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] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 21:11:19 -0000

On 26-May-20 08:42, John R Levine wrote:
...
> I am not proposing specific changes other than to say that the model of 
> RFCs solely as independent immutable documents no longer makes sense. 
> While I do not suggest we go to WHATWG style living documents, I do think 
> that for our specifications we need to find a more modern way to collect 
> the material into a small number of places with stable names (perhaps 
> using version numbers like everyone else does), and to make discrete low 
> cost updates as we find errors or make partial updates.

Writing as one of those who bloodied their noses on this problem some
15 years ago, I completely agree, but it is an IETF problem, and the IETF
has been remarkably resistant to discussing it, let alone fixing it.

And I *think* it's orthogonal to our problem here, although if the IETF
would get its house in order, our problem might be easier.

Regards
    Brian


From nobody Mon May 25 14:12: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 1E8D23A0945 for ; Mon, 25 May 2020 14:12: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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 15GtY5DGqzO3 for ; Mon, 25 May 2020 14:12:48 -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 102203A0936 for ; Mon, 25 May 2020 14:12:47 -0700 (PDT)
Received: from [172.16.42.112] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49W8tz2Pzgzyg6; Mon, 25 May 2020 23:12:43 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: 
Date: Mon, 25 May 2020 23:12:42 +0200
Cc: Rfced-future@iab.org
X-Mao-Original-Outgoing-Id: 612133962.550801-4517bffa984a506bbf3bd3b26a48076e
Content-Transfer-Encoding: quoted-printable
Message-Id: <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>
References: 
To: John R Levine 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 21:12:53 -0000

On 2020-05-25, at 22:42, John R Levine  wrote:
>=20
> I am not proposing specific changes other than to say that the model =
of RFCs solely as independent immutable documents no longer makes sense. =
While I do not suggest we go to WHATWG style living documents, I do =
think that for our specifications we need to find a more modern way to =
collect the material into a small number of places with stable names =
(perhaps using version numbers like everyone else does), and to make =
discrete low cost updates as we find errors or make partial updates.

The diagnosis appears to presume a therapy here.

However, most of the problems are with the high-energy approval process =
of the IETF stream, which makes it impractical to do actual revisions of =
documents without exposing previous consensus to new attacks and =
subjecting it to current political and technical fashions.

So we publish updates to updates to updates, and almost never do =
consolidated versions like they are being done in lawmaking.

We also don=E2=80=99t have a lot of roadmap documents (*).  Nobody gets =
points for writing them.  The IESG loathes having to review them as =
consensus documents, so informational documents of this kind are =
discouraged instead of encouraged.  (Really, no WG should be chartered =
without securing the energy to write up how its output works together =
with existing specifications!)

Not much of that is a consequence of the RFC process, it is really a =
stream issue.

(We could try to repair the stream by exerting pressure from the output =
end, but I=E2=80=99m not sure that would work very well.  **We need to =
be able to actually do the work**, first!)

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

(*) On 2020-04-17, I wrote:
Yes, we have had a few roadmap documents (RFC 4614/7414 comes to mind, =
or RFC 6071).
The TCP roadmap is the only example I can find where such a roadmap was =
actually published again as revised RFC.
Because of the immense effort needed to generate a consensus RFC with =
this information, some roadmaps never were pushed to RFC (e.g., =
draft-bormann-6lo-6lowpan-roadmap-00.txt, =
draft-bormann-core-roadmap-05.txt); others were just published as =
articles (the ultimate fate of the latter roadmap was =
https://DOI.org/10.1109/MIC.2012.29).

We never developed roadmapping into an element of our culture, but we =
could.


From nobody Mon May 25 14:13: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 8270C3A0958 for ; Mon, 25 May 2020 14:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSs4e5rWASL7 for ; Mon, 25 May 2020 14:13:32 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 9DA2E3A0945 for ; Mon, 25 May 2020 14:13:32 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id b3so16951869oib.13 for ; Mon, 25 May 2020 14:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nPxXK9Z6xkiYZjJcwi1smnSZ/O4wmWgPBwk9nu2kOec=; b=qNpmZj7+ikeYsZwmcijr69NHxj0j5y+N3aqLKTSGh1mVZ7tXkR94xcuTAtuMLn1Gq/ C+vbjzrFFIP4rFqJZPtOmwmNqCck5dShlK75rATkQCtPEglm2xfyl2e6tjPWIk0QqL5I hVH6vgfZBZa/h7H2s7cLSdqf8PFxv+rMJrpF3oHsx9wXUqY1w1bqwAuaGxRWy8eCR1F2 CEgfQEqfZOljmZlxYHIW7EQmkKexjd3a5atDdm5BspwVJrNg5AA5n70CTmqhMFpOJ7xk m3lfcpfE9i3nhSQkn+G9PRBCZbhlvmq7Jhfq19gT+V69aHKr/hzPUQwdUscIyMAhoms0 lxSw==
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=nPxXK9Z6xkiYZjJcwi1smnSZ/O4wmWgPBwk9nu2kOec=; b=Hex6vVd5GqQ1+cEl1Cuh4FYQTXIJ1Fscd1Qn24zsw+y0QB0SA67KcW2Os6Smpp1/2x PkvHUqUQlZ5rOFjqGq7G9OuYWocdyGPTnmERB5h/5GAtBQaXsCrckI3isQ5Y8uNJgczO AMilCe860lrl/kfuO6Bkj8h16semHBP7wV+1Z3/mMXu0wV+5hFSV2SP4ngS7BXGhA20X /y4o9D+rspkoTqSOrt5s3SfwhZ1M+gTqsaXMUrcr8X1R80PEBwODwVq6juLyuwlaLHIm /ghDVlRI6TbtJts1UjPBdUqZ25/Z58k/Y74hxIbxMfUhkcI0gsWZtWQ3j4XzQhaWowjx utVQ==
X-Gm-Message-State: AOAM532PTysIBsOxsKLSa96q9b/TLfkNGsekK2S0uhtDxoZNXG6imtVl flrXaLRbHhA1egoiOE8ghe8dfXte0yyF/R8ehT0=
X-Google-Smtp-Source: ABdhPJyPRx1lqnUHk3xyQve45zWRmd4IHdlOYRzp63qG+9S9Rc5n9OfaRV8c07VAKW5fhGd42gfyxdeAzGR4MEF1ExI=
X-Received: by 2002:aca:c590:: with SMTP id v138mr7642212oif.132.1590441212006;  Mon, 25 May 2020 14:13:32 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Tim Wicinski 
Date: Mon, 25 May 2020 17:13:21 -0400
Message-ID: 
To: Brian E Carpenter 
Cc: John R Levine , Rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000007a561505a67f73e1"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 21:13:35 -0000

--0000000000007a561505a67f73e1
Content-Type: text/plain; charset="UTF-8"

Brian

While it is an IETF problem, I would like to see an RFC Editor function
that is empowered to tackle this problem.

tim


On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 26-May-20 08:42, John R Levine wrote:
> ....
> > I am not proposing specific changes other than to say that the model of
> > RFCs solely as independent immutable documents no longer makes sense.
> > While I do not suggest we go to WHATWG style living documents, I do
> think
> > that for our specifications we need to find a more modern way to collect
> > the material into a small number of places with stable names (perhaps
> > using version numbers like everyone else does), and to make discrete low
> > cost updates as we find errors or make partial updates.
>
> Writing as one of those who bloodied their noses on this problem some
> 15 years ago, I completely agree, but it is an IETF problem, and the IETF
> has been remarkably resistant to discussing it, let alone fixing it.
>
> And I *think* it's orthogonal to our problem here, although if the IETF
> would get its house in order, our problem might be easier.
>
> Regards
>     Brian
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

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



B=
rian

=

While it=
 is an IETF problem, I would like to see an RFC Editor function
that is empowered to=
 tackle this problem.=C2=A0

tim


On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter <<=
a href=3D"mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com> wrote:
On=
 26-May-20 08:42, John R Levine wrote:

....

> I am not proposing specific changes other than to say that the model o=
f 

> RFCs solely as independent immutable documents no longer makes sense. =


> While I do not suggest we go to WHATWG style living documents, I do th=
ink 

> that for our specifications we need to find a more modern way to colle=
ct 

> the material into a small number of places with stable names (perhaps =


> using version numbers like everyone else does), and to make discrete l=
ow 

> cost updates as we find errors or make partial updates.



Writing as one of those who bloodied their noses on this problem some

15 years ago, I completely agree, but it is an IETF problem, and the IETF
has been remarkably resistant to discussing it, let alone fixing it.



And I *think* it's orthogonal to our problem here, although if the IETF=


would get its house in order, our problem might be easier.



Regards

=C2=A0 =C2=A0 Brian



-- 

Rfced-future mailing list

Rfced-future@iab.=
org

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




--0000000000007a561505a67f73e1--


From nobody Mon May 25 14:20:02 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA353A097F for ; Mon, 25 May 2020 14:20: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 TC_u7J19stfi for ; Mon, 25 May 2020 14:19:57 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 ADF133A0968 for ; Mon, 25 May 2020 14:19:56 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id c11so19945852ljn.2 for ; Mon, 25 May 2020 14:19:56 -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=Y776jBqYx8sX7cLYSapJ1ws+PKQik76C16kT4pFKsp8=; b=zrKNJipLL1JFjXGkmQ58SCQWvHwrRKPL6jDH3V/3hVcgv8/OMeCnRh3Fa7StsOzTVb LMiM/hlfovOj6LgMPGR1lO6Bgf8tHmn5HMo3jiOlvJy7RrXqUYlmq62XElKpAj/W8cVM btP7KwHv5aQuBaBOeQA4cGFjcwA9kMi0AcTS2NsnDh+g0gelNmFFTGO+a1b+rGvcYqm2 /dD3brkREnVGOj440CQ40IDfD4HoCyIDtfJRVknBJ7vrpWGE1OQqq1jr2MTxDMFUe3Un rxMH6MjQ20PDTnjE6NF9cW0jFHeImYQ6AsCeZXlz0Qu+576DfXyPqQOXkP8f8jEVMYv5 MgsQ==
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=Y776jBqYx8sX7cLYSapJ1ws+PKQik76C16kT4pFKsp8=; b=KiUBO/huz4rfO5K+uXUzu3TAk6/wFKJeoXGDhoX51HU+gjvit9iudbsIAaiRv4XQDi slfrDLuCtbul3BaIrsfx8TDcUyw2RwZaeM+Htig1Sg61AeQwXIUgqegfo1fEmIZtjIVS O8YTUUB+e5bkgVdWsJ3l9HMXQIHmtg6sNbzpQKLSsRED6Q5RgqQO4+9uepoeqSyLLYg/ 0PNoPU01JEBfYtwIDkZLo8v7NV+qVIY+k0ZoASFZfjj/FAbRbETjNUcbU7B1+9rBFGes 7E9G4pYse4+9DcfkPbNg4qCqCERCEVzmb/BwjJ4OaDO9lYkwo9fypODI1DzyBdsH303e ctIQ==
X-Gm-Message-State: AOAM533hXLek5kESanpIauvDj3tKS//XiR34uCDfaU5fGJnTnl1haa8h 4mOH4j+QRozSSG7/cvMJD5NkJdA8niQJPsRozkpG0/u5r3e98w==
X-Google-Smtp-Source: ABdhPJyJ3m2LmZg1jbtVuWro/QurHBYBlTK8HMKnHsbn1O2o3Yr3zG98z67MBFAb/QrAbhCWeGUlVRvndaXY72JOGtM=
X-Received: by 2002:a2e:8897:: with SMTP id k23mr14628264lji.184.1590441594956;  Mon, 25 May 2020 14:19:54 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Eric Rescorla 
Date: Mon, 25 May 2020 14:19:19 -0700
Message-ID: 
To: Tim Wicinski 
Cc: Brian E Carpenter , Rfced-future@iab.org,  John R Levine 
Content-Type: multipart/alternative; boundary="0000000000004dc48d05a67f8af7"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 21:20:00 -0000

--0000000000004dc48d05a67f8af7
Content-Type: text/plain; charset="UTF-8"

I think whether this is an IETF problem depends on one's priors.

At a high level, it seems likely that we need some kind of
two-layer system of references:

- A reference that points to the current state (e.g., "TLS
  with all the recommended extensions, etc.").

- A reference that points to a specific historical state
  (in version control, we'd call this a hash or a version
  number depending on the system).

Now, if you assume that RFC #s are the lower layer (i.e., that RFC
XXXX always points to the same content), then yes, it seems like the
IETF would need to layer something new on top and this becomes an IETF
problem. However, if one treats RFC #s as the higher layer (perhaps
with a version number suffix as the lower layer) then this becomes
an RFC series problem.

-Ekr



On Mon, May 25, 2020 at 2:13 PM Tim Wicinski  wrote:

>
> Brian
>
> While it is an IETF problem, I would like to see an RFC Editor function
> that is empowered to tackle this problem.
>
> tim
>
>
> On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
>
>> On 26-May-20 08:42, John R Levine wrote:
>> .....
>> > I am not proposing specific changes other than to say that the model of
>> > RFCs solely as independent immutable documents no longer makes sense.
>> > While I do not suggest we go to WHATWG style living documents, I do
>> think
>> > that for our specifications we need to find a more modern way to
>> collect
>> > the material into a small number of places with stable names (perhaps
>> > using version numbers like everyone else does), and to make discrete
>> low
>> > cost updates as we find errors or make partial updates.
>>
>> Writing as one of those who bloodied their noses on this problem some
>> 15 years ago, I completely agree, but it is an IETF problem, and the IETF
>> has been remarkably resistant to discussing it, let alone fixing it.
>>
>> And I *think* it's orthogonal to our problem here, although if the IETF
>> would get its house in order, our problem might be easier.
>>
>> Regards
>>     Brian
>>
>> --
>> 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
>

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


I think whether this is an IETF problem depends on one'=
;s priors.

At a high level, it seems likely that we need some kind o=
f
two-layer system of references:

- A reference that points to th=
e current state (e.g., "TLS
=C2=A0 with all the recommended extensi=
ons, etc.").
=C2=A0 
- A reference that points to a specific his=
torical state
=C2=A0 (in version control, we'd call this a hash or a=
 version
=C2=A0 number depending on the system).

Now, if you assu=
me that RFC #s are the lower layer (i.e., that RFC
XXXX always points to=
 the same content), then yes, it seems like the
IETF would need to layer=
 something new on top and this becomes an IETF
problem. However, if one =
treats RFC #s as the higher layer (perhaps
with a version number suffix =
as the lower layer) then this becomes
an RFC series problem.

-Ekr=




On Mon, May 25, 2020 at 2:13 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:

Brian

While it is an IETF problem, I would like=
 to see an RFC Editor function
that is empowered to tackle this problem.=C2=A0
=


tim


On Mon, May 2=
5, 2020 at 5:11 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 26-May-20 08:4=
2, John R Levine wrote:

.....

> I am not proposing specific changes other than to say that the model o=
f 

> RFCs solely as independent immutable documents no longer makes sense. =


> While I do not suggest we go to WHATWG style living documents, I do th=
ink 

> that for our specifications we need to find a more modern way to colle=
ct 

> the material into a small number of places with stable names (perhaps =


> using version numbers like everyone else does), and to make discrete l=
ow 

> cost updates as we find errors or make partial updates.



Writing as one of those who bloodied their noses on this problem some

15 years ago, I completely agree, but it is an IETF problem, and the IETF
has been remarkably resistant to discussing it, let alone fixing it.



And I *think* it's orthogonal to our problem here, although if the IETF=


would get its house in order, our problem might be easier.



Regards

=C2=A0 =C2=A0 Brian



-- 

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



--0000000000004dc48d05a67f8af7--


From nobody Mon May 25 14:21: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 E97053A09AA for ; Mon, 25 May 2020 14:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y4wt6UsjBLQy; Mon, 25 May 2020 14:21:37 -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 C27613A09A2; Mon, 25 May 2020 14:21:35 -0700 (PDT)
From: Jay Daley 
Message-Id: <3AD194F4-9449-43DB-8A85-652B1AC8E02C@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_91397196-A90D-44BF-AB5F-B8A2D66C2ED9"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 26 May 2020 09:21:33 +1200
In-Reply-To: 
Cc: Brian E Carpenter , Rfced-future@iab.org, John R Levine 
To: Tim Wicinski 
References:   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 21:21:40 -0000

--Apple-Mail=_91397196-A90D-44BF-AB5F-B8A2D66C2ED9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 26/05/2020, at 9:13 AM, Tim Wicinski  wrote:
>=20
>=20
> Brian
>=20
> While it is an IETF problem, I would like to see an RFC Editor =
function
> that is empowered to tackle this problem.=20

As I understand it the RSE is empowered to tackle that as per this from =
RFC 8728: "Leads the community in the design of improvements to the RFC =
Series.  The question perhaps ought to be - what happens if the RSE =
firmly wants feature X of the RFC Series to stay as it is and doesn=E2=80=99=
t want to open up a process that might change that?

Jay

>=20
> tim
>=20
>=20
> On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter =
> =
wrote:
> On 26-May-20 08:42, John R Levine wrote:
> .....
> > I am not proposing specific changes other than to say that the model =
of=20
> > RFCs solely as independent immutable documents no longer makes =
sense.=20
> > While I do not suggest we go to WHATWG style living documents, I do =
think=20
> > that for our specifications we need to find a more modern way to =
collect=20
> > the material into a small number of places with stable names =
(perhaps=20
> > using version numbers like everyone else does), and to make discrete =
low=20
> > cost updates as we find errors or make partial updates.
>=20
> Writing as one of those who bloodied their noses on this problem some
> 15 years ago, I completely agree, but it is an IETF problem, and the =
IETF
> has been remarkably resistant to discussing it, let alone fixing it.
>=20
> And I *think* it's orthogonal to our problem here, although if the =
IETF
> would get its house in order, our problem might be easier.
>=20
> Regards
>     Brian
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org 
> https://www.iab.org/mailman/listinfo/rfced-future =

> --=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=_91397196-A90D-44BF-AB5F-B8A2D66C2ED9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 26/05/2020, at 9:13 AM, Tim Wicinski <tjw.ietf@gmail.com> =
wrote:


Brian

While it is an IETF problem, I would =
like to see an RFC Editor function
that is empowered to tackle this =
problem. 

As I understand it the RSE is empowered to tackle =
that as per this from RFC 8728: "Leads the community in the design of =
improvements to the RFC Series.  The question perhaps ought to be - =
what happens if the RSE firmly wants feature X of the RFC Series to stay =
as it is and doesn=E2=80=99t want to open up a process that might change =
that?

Jay


tim


On Mon, May 25, 2020 at 5:11 PM Brian E =
Carpenter <brian.e.carpenter@gmail.com> wrote:
On 26-May-20 08:42, John R Levine =
wrote:

.....

> I am not proposing specific changes other than to say that the =
model of 

> RFCs solely as independent immutable documents no longer makes =
sense. 

> While I do not suggest we go to WHATWG style living documents, I do =
think 

> that for our specifications we need to find a more modern way to =
collect 

> the material into a small number of places with stable names =
(perhaps 

> using version numbers like everyone else does), and to make =
discrete low 

> cost updates as we find errors or make partial updates.



Writing as one of those who bloodied their noses on this problem some

15 years ago, I completely agree, but it is an IETF problem, and the =
IETF

has been remarkably resistant to discussing it, let alone fixing it.



And I *think* it's orthogonal to our problem here, although if the =
IETF

would get its house in order, our problem might be easier.



Regards

    Brian



-- 

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



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




=

--Apple-Mail=_91397196-A90D-44BF-AB5F-B8A2D66C2ED9--


From nobody Mon May 25 14:56: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 0DB1A3A0ADD for ; Mon, 25 May 2020 14:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level: 
X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YofFA9ZzTdQU for ; Mon, 25 May 2020 14:56:39 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15F13A0AE5 for ; Mon, 25 May 2020 14:56:33 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id n15so9272197pfd.0 for ; Mon, 25 May 2020 14:56:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dMJ9e16XxRPiMApN8nvhn9D5wfyS1bCaSQ8Uuu4WFXo=; b=NV++hdiQjYKiqp4eeoJ8CezPsttEcbQxLHBYQz1Ga7Z7VIgaHwGy+BuNUYwufh/MU8 IiZflN9sT9R32L2c88rOF9zu8uEE40AqDvfhW/jPVNc2tIWzt6c6Wu8FTdTysumnU4Td QrYUR14eA5Xy7oy4zDcwdnMWFUiwAm+5McF1AWKTtDM81X6j5uOQQWjbSlmcOeLosoi1 KpWdNIu/VYr6TggZhEWPuYdv2n0Tq1cw50weziI67jK1yxmV6TbQ2OWxDRaPsBkLqcfW 59+9CrMHH70WMFPTXGxqNQmydNL/D5vUak7UhnrdLlkNFr3olvbfuDMFU2aj76Yr69U1 5xvw==
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=dMJ9e16XxRPiMApN8nvhn9D5wfyS1bCaSQ8Uuu4WFXo=; b=ZSoGgGl/y181r61e27wqKbXgg8NGxszME+32Jt2rgK9pPjujIHMnZcEtbkh8eI3Yhw shqHbFbnOp9F3CUwdAkqjQWK4Fus3GHZKtENcM1zG1uPDQieK35gMXDf4qRA2fxrXydT B671GzKZsUkh4eY/8bXJQ2Azt8oh1pW81ZkBjHWkBHHLb564SLnNmBmUsyFCC+BEAqrL tyJJ1zHfWyntPNP4g3ZxGnI8ocDdtKNelXaGeuDNC7liIJ5a+5DfDBeMtFjddXf/x2Cr zweWJNNUPDlP2891pwapZKvYKt5avO8/RENzX1qLrvZj4BJ/dfmDI4PgvZMU3c6n5t0L HYjw==
X-Gm-Message-State: AOAM5311RV1fBb00IoIQICkWIJK+Gfx9ES8Etn6Dwo8OC3ruoyrPJhkO dvEJw+6MS5NqoWG4XJjpE20=
X-Google-Smtp-Source: ABdhPJxkvS4AvQVdHNFRZpfBjgWJI3F4+5ThmxBfKQaFYMUUML3BAwcqcszzOy4JhVFVo8wiFa70/g==
X-Received: by 2002:a63:d602:: with SMTP id q2mr3804281pgg.23.1590443792735; Mon, 25 May 2020 14:56:32 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id m188sm14060574pfd.67.2020.05.25.14.56.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 14:56:32 -0700 (PDT)
To: Eric Rescorla , Tim Wicinski 
Cc: Rfced-future@iab.org, John R Levine 
References:    
From: Brian E Carpenter 
Message-ID: 
Date: Tue, 26 May 2020 09:56:26 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 21:56:43 -0000

Let me challenge that with a question.

What would really be better if RFC8200 was actually called RFC1883.3?

Or if RFC8446 was RFC2246.4?

I think the problem is much deeper (see the newtrk archive).

Regards
   Brian Carpenter

On 26-May-20 09:19, Eric Rescorla wrote:
> I think whether this is an IETF problem depends on one's priors.
>=20
> At a high level, it seems likely that we need some kind of
> two-layer system of references:
>=20
> - A reference that points to the current state (e.g., "TLS
> =C2=A0 with all the recommended extensions, etc.").
> =C2=A0
> - A reference that points to a specific historical state
> =C2=A0 (in version control, we'd call this a hash or a version
> =C2=A0 number depending on the system).
>=20
> Now, if you assume that RFC #s are the lower layer (i.e., that RFC
> XXXX always points to the same content), then yes, it seems like the
> IETF would need to layer something new on top and this becomes an IETF
> problem. However, if one treats RFC #s as the higher layer (perhaps
> with a version number suffix as the lower layer) then this becomes
> an RFC series problem.
>=20
> -Ekr
>=20
>=20
>=20
> On Mon, May 25, 2020 at 2:13 PM Tim Wicinski > wrote:
>=20
>=20
>     Brian
>=20
>     While it is an IETF problem, I would like to see an RFC Editor func=
tion
>     that is empowered to tackle this problem.=C2=A0
>=20
>     tim
>=20
>=20
>     On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter > wrote:
>=20
>         On 26-May-20 08:42, John R Levine wrote:
>         .....
>         > I am not proposing specific changes other than to say that th=
e model of
>         > RFCs solely as independent immutable documents no longer make=
s sense.
>         > While I do not suggest we go to WHATWG style living documents=
, I do think
>         > that for our specifications we need to find a more modern way=
 to collect
>         > the material into a small number of places with stable names =
(perhaps
>         > using version numbers like everyone else does), and to make d=
iscrete low
>         > cost updates as we find errors or make partial updates.
>=20
>         Writing as one of those who bloodied their noses on this proble=
m some
>         15 years ago, I completely agree, but it is an IETF problem, an=
d the IETF
>         has been remarkably resistant to discussing it, let alone fixin=
g it.
>=20
>         And I *think* it's orthogonal to our problem here, although if =
the IETF
>         would get its house in order, our problem might be easier.
>=20
>         Regards
>         =C2=A0 =C2=A0 Brian
>=20
>         --=20
>         Rfced-future mailing list
>         Rfced-future@iab.org 
>         https://www.iab.org/mailman/listinfo/rfced-future
>=20
>     --=20
>     Rfced-future mailing list
>     Rfced-future@iab.org 
>     https://www.iab.org/mailman/listinfo/rfced-future
>=20


From nobody Mon May 25 15:04: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 7FDED3A0A8E for ; Mon, 25 May 2020 15:04: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ElqrQyGI; dkim=pass (1536-bit key) header.d=taugh.com header.b=yGY1JmoX
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK6-p_FnKDlP for ; Mon, 25 May 2020 15:04:16 -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 915283A0A74 for ; Mon, 25 May 2020 15:04:16 -0700 (PDT)
Received: (qmail 88692 invoked from network); 25 May 2020 22:04:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15a6d.5ecc40df.k2005; i=johnl-iecc.com@submit.iecc.com; bh=wVMjHe1WKfvrPdrvJSJAcMmOMtHEJnJPTnG+kZp3PF4=; b=ElqrQyGI9pxRpMXpasGqZB2YuzQ2dhnu7SJIRPNAIceDQX2s9OeTvdGk/O2dPXmvGr9KJ+25cHRjfM4524zOjdOITOiL2ZWwgIiTaQtdQVAwHb0CsPhgIaTaqlZllPQtyXnMlOcR3t5pmqRjD6Wh4jtbU/WvomMq1a/eVDx23lOZCgpWl90WZedFM07fKx9tMkCiSMF+T6RuGfQ1sVy9PNo8hy3Khj/cbpKyar8IySAcHFgoFZR81SN7b7VCuvMG
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:user-agent; s=15a6d.5ecc40df.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=wVMjHe1WKfvrPdrvJSJAcMmOMtHEJnJPTnG+kZp3PF4=; b=yGY1JmoXL3EMhDVdj2wp2oT3xH84b6K5J4c7B2guXHdMQAq1xRsh8YRzlhgD8eI0KnN2wRBG5Cxe4UXQ0OQobt+QTedAZIeqwEBIyvXw3Qtx7lLHv+WlVfEK5gV2/bEXPpSS5+2p3AF14HxlphsURBfDGpQjaSqDMO/t3KhR7PQ/feQFj7CXOOEQkm6embAhEbGRDz53wxA+YUy5jYyDsYOUNxxJnVOZLdoU9OAQcrT0EoUDn8VnAMqeCV+a9H0H
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; 25 May 2020 22:04:14 -0000
Date: 25 May 2020 18:04:14 -0400
Message-ID: 
From: "John R Levine" 
To: "Brian E Carpenter" 
Cc: Rfced-future@iab.org
In-Reply-To: 
References:     
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:04:19 -0000

On Tue, 26 May 2020, Brian E Carpenter wrote:
> Let me challenge that with a question.
>
> What would really be better if RFC8200 was actually called RFC1883.3?
>
> Or if RFC8446 was RFC2246.4?

Without a better way to do minor updates, I agree that changing the names 
isn't likely to make any difference.  I note that it took 19 years to 
update RFC 2460 to RFC 8200 which perhaps suggests some underlying issues.

RFC 5321 needs an update but we are reluctant to do it because as soon as 
you open the can even a little bit, all the worms swarm out and bite you.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Mon May 25 15:06:11 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E370D3A0A92 for ; Mon, 25 May 2020 15:06:08 -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 GLMsCZ_4mV2j for ; Mon, 25 May 2020 15:06:02 -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 E9C403A0A9B for ; Mon, 25 May 2020 15:06:01 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id z13so12519563ljn.7 for ; Mon, 25 May 2020 15:06:01 -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=uRT3Wk6yNE7OL9GWiYP4LDRSDSWWZUo0tOqsHFIkbSI=; b=gXzG04ZimbmDt9sUjTcIgHSMlwwNyiHKUvsDS7RRC2g5usDZLbJImHqx9ik17e6MhY +EoD8shW3Deo3g5SqZMaGRy2V8L+1+AnIs+ZCdjrq2UPUfZaAZh0v5Zb1mJY6aJz3S8K t/qD3ETpDz2k8spsmcrNThtJA+xo9eS4NeiSwQ7uoy7/U4YANkho0l7jDR7uXokLjJDv izT4Dk16s7ztrv93+JWL8WWkCssFNeR/e9/H24/DnYBAsR+7LwWghQ3Dg/sR5lXlZfqO fmrdlwe6wfnjYT4vTXq8JqDl9n0jrI6+pEC5rMn3Hu/wmbFdxhUREkuzAhgFag08QtUp TWXw==
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=uRT3Wk6yNE7OL9GWiYP4LDRSDSWWZUo0tOqsHFIkbSI=; b=G7ikwUisETC8Lb7cAeRBIrGhvrmm4mJPtkZsSUJdaVSYYlbOuv0HsuUbwf5QCeShcP UMkkKiHKgQIqvBDdTbyvZ+XgGPKw6I3qJsaofxB+D8ChCZMe6Tc6N+qTCbURDdZnhrIe sPTzcdeNRjlVxTR7MWSIkE91hTCKbFrhQP76+bKlTNll9mDP8lyB2tDAWiW9GVK+F4Bd f+5zpT/8JESbZaYQr8QTKomUISiGL/NoacvM5E9jdQAQcZqHFh6PEAcriBlMgQKxFbby vi8go8z4pW2btXZveXxn3dWnuhlo+OMKHOrFRHHZ3W0Y/7Fo2f+lOuDTbUhGljptbjzb VLFQ==
X-Gm-Message-State: AOAM533R9tdYL6VjiPTzZofgk7Y6eLAy0eh1ABocTdR7GwGzCYyJFnlg s3Ud72iWLpuXKIhgr/Hgoj+roXdtP4pGilBLlxaPzQ==
X-Google-Smtp-Source: ABdhPJze6v5ipah+czQucLD+x/LtPCwQoL8Vb15Vi8DKbu1uTEtXTxmNjI1+cfrp06c84eWS5CQp8oNNDY6vXL8wSag=
X-Received: by 2002:a05:651c:2c6:: with SMTP id f6mr12289954ljo.371.1590444358829;  Mon, 25 May 2020 15:05:58 -0700 (PDT)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: Eric Rescorla 
Date: Mon, 25 May 2020 15:05:22 -0700
Message-ID: 
To: Brian E Carpenter 
Cc: Tim Wicinski , Rfced-future@iab.org,  John R Levine 
Content-Type: multipart/alternative; boundary="0000000000000b1cf005a6802ff8"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:06:10 -0000

--0000000000000b1cf005a6802ff8
Content-Type: text/plain; charset="UTF-8"

On Mon, May 25, 2020 at 2:56 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Let me challenge that with a question.
>
> What would really be better if RFC8200 was actually called RFC1883.3?
>

I don't understand v6 well enough, but quite possibly.


Or if RFC8446 was RFC2246.4?
>

No, I think that TLS 1.2 is a specific thing and so is TLS 1.3.

However, I think that it would be better if the bazillion documents that
you actually needed to implement TLS 1.2 were referred to by the name "RFC
2246" and that most people never had to engage with the specific
differences between RFC 2246.5 and RFC 2246.6.

Similarly, I think that it would be better if TLS 1.3 + the already filed
errata plus the various update documents currently in process (ESNI,
importers, ...) were referred to as RCC 8446.

Just to make sure we are on the same page, my thesis is that people would
generally not reference specific RFC dot versions. This is what happens in
the Web platform, for instance: one can in principle refer to specific
versions of the HTML5 spec, but as a practical matter, people do not need
to do so.

-Ekr


Regards
>    Brian Carpenter
>
> On 26-May-20 09:19, Eric Rescorla wrote:
> > I think whether this is an IETF problem depends on one's priors.
> >
> > At a high level, it seems likely that we need some kind of
> > two-layer system of references:
> >
> > - A reference that points to the current state (e.g., "TLS
> >   with all the recommended extensions, etc.").
> >
> > - A reference that points to a specific historical state
> >   (in version control, we'd call this a hash or a version
> >   number depending on the system).
> >
> > Now, if you assume that RFC #s are the lower layer (i.e., that RFC
> > XXXX always points to the same content), then yes, it seems like the
> > IETF would need to layer something new on top and this becomes an IETF
> > problem. However, if one treats RFC #s as the higher layer (perhaps
> > with a version number suffix as the lower layer) then this becomes
> > an RFC series problem.
> >
> > -Ekr
> >
> >
> >
> > On Mon, May 25, 2020 at 2:13 PM Tim Wicinski  > wrote:
> >
> >
> >     Brian
> >
> >     While it is an IETF problem, I would like to see an RFC Editor
> function
> >     that is empowered to tackle this problem.
> >
> >     tim
> >
> >
> >     On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com > wrote:
> >
> >         On 26-May-20 08:42, John R Levine wrote:
> >         .....
> >         > I am not proposing specific changes other than to say that the
> model of
> >         > RFCs solely as independent immutable documents no longer makes
> sense.
> >         > While I do not suggest we go to WHATWG style living documents,
> I do think
> >         > that for our specifications we need to find a more modern way
> to collect
> >         > the material into a small number of places with stable names
> (perhaps
> >         > using version numbers like everyone else does), and to make
> discrete low
> >         > cost updates as we find errors or make partial updates.
> >
> >         Writing as one of those who bloodied their noses on this problem
> some
> >         15 years ago, I completely agree, but it is an IETF problem, and
> the IETF
> >         has been remarkably resistant to discussing it, let alone fixing
> it.
> >
> >         And I *think* it's orthogonal to our problem here, although if
> the IETF
> >         would get its house in order, our problem might be easier.
> >
> >         Regards
> >             Brian
> >
> >         --
> >         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
> >
>
>

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




=

On Mon, May 25, 2020 at 2:56 PM Brian=
 E Carpenter <brian.e.carpenter@gmail.com> wrote:
Let me challenge that with a question.


What would really be better if RFC8200 was actually called RFC1883.3?

I don't understand v6 well enough, but q=
uite possibly.

 

Or if RFC8446 was RFC2246.4?

No, I thin=
k that TLS 1.2 is a specific thing and so is TLS 1.3. 

However, I think that it would be better if the bazillion document=
s that you actually needed to implement TLS 1.2 were referred to by the nam=
e "RFC 2246" and that most people never had to engage with the sp=
ecific differences between RFC 2246.5 and RFC 2246.6.

<=
div>Similarly, I think that it would be better if TLS 1.3 + the already fil=
ed errata plus the various update documents currently in process (ESNI, imp=
orters, ...) were referred to as RCC 8446.
=C2=A0
Just =
to make sure we are on the same page, my thesis is that people would genera=
lly not reference specific RFC dot versions. This is what happens in the We=
b platform, for instance: one can in principle refer to specific versions o=
f the HTML5 spec, but as a practical matter, people do not need to do so.

-Ekr



Regards

=C2=A0 =C2=A0Brian Carpenter



On 26-May-20 09:19, Eric Rescorla wrote:

> I think whether this is an IETF problem depends on one's priors.
> 

> At a high level, it seems likely that we need some kind of

> two-layer system of references:

> 

> - A reference that points to the current state (e.g., "TLS

> =C2=A0 with all the recommended extensions, etc.").

> =C2=A0

> - A reference that points to a specific historical state

> =C2=A0 (in version control, we'd call this a hash or a version

> =C2=A0 number depending on the system).

> 

> Now, if you assume that RFC #s are the lower layer (i.e., that RFC

> XXXX always points to the same content), then yes, it seems like the
> IETF would need to layer something new on top and this becomes an IETF=


> problem. However, if one treats RFC #s as the higher layer (perhaps
> with a version number suffix as the lower layer) then this becomes

> an RFC series problem.

> 

> -Ekr

> 

> 

> 

> On Mon, May 25, 2020 at 2:13 PM Tim Wicinski <tjw.ietf@gmail.com <mailto:tjw.ietf@gmail.com>=
;> wrote:

> 

> 

>=C2=A0 =C2=A0 =C2=A0Brian

> 

>=C2=A0 =C2=A0 =C2=A0While it is an IETF problem, I would like to see an=
 RFC Editor function

>=C2=A0 =C2=A0 =C2=A0that is empowered to tackle this problem.=C2=A0

> 

>=C2=A0 =C2=A0 =C2=A0tim

> 

> 

>=C2=A0 =C2=A0 =C2=A0On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter &=
lt;brian.e=
.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 26-May-20 08:42, John R Levine wro=
te:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.....

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I am not proposing specific chan=
ges other than to say that the model of

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> RFCs solely as independent immut=
able documents no longer makes sense.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> While I do not suggest we go to =
WHATWG style living documents, I do think

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> that for our specifications we n=
eed to find a more modern way to collect

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the material into a small number=
 of places with stable names (perhaps

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> using version numbers like every=
one else does), and to make discrete low

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> cost updates as we find errors o=
r make partial updates.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Writing as one of those who bloodied =
their noses on this problem some

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015 years ago, I completely agree, but=
 it is an IETF problem, and the IETF

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been remarkably resistant to disc=
ussing it, let alone fixing it.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0And I *think* it's orthogonal to =
our problem here, although if the IETF

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would get its house in order, our pro=
blem might be easier.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Brian

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rfced-future mailing list

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rfced-future@iab.org <mailto:Rfced-future@iab.org>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.i=
ab.org/mailman/listinfo/rfced-future

> 

>=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

> 






--0000000000000b1cf005a6802ff8--


From nobody Mon May 25 15:13: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 E2B663A0AC9 for ; Mon, 25 May 2020 15:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.077
X-Spam-Level: 
X-Spam-Status: No, score=-1.077 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, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 967GAkhCCIjR for ; Mon, 25 May 2020 15:12:58 -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 76B253A0ABE for ; Mon, 25 May 2020 15:12:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49WBDV2sstz6G9GK for ; Mon, 25 May 2020 15:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590444778; bh=L8TzdLbhCtsG0q3PEQCXdYDz/MEvZd5tMEqn4T5r5GA=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=p5vCVbNM0MrJvb2o4axefOUvtSDulLM4E3wpqoa7a1EONW0ziOtAETaYg5sCP/xwP aKll1DYHJDkgSVgnKmRw6B04b40U10Ciz6a/wgGMT2Ts9jBzAXabDAoHBdBUucVPZi 7CrrM4gfDxGW1bezyYVgaHconlvQdt71AKq8mFWw=
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 49WBDV059wz6G8MP for ; Mon, 25 May 2020 15:12:57 -0700 (PDT)
Cc: Rfced-future@iab.org
References:     
From: "Joel M. Halpern" 
Message-ID: <25e006c2-978a-f607-a77b-a7eae996c005@joelhalpern.com>
Date: Mon, 25 May 2020 18:12:43 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:13:00 -0000

I have to strongly agree with Brian on this.

Yours,
Joel

On 5/25/2020 5:56 PM, Brian E Carpenter wrote:
> Let me challenge that with a question.
> 
> What would really be better if RFC8200 was actually called RFC1883.3?
> 
> Or if RFC8446 was RFC2246.4?
> 
> I think the problem is much deeper (see the newtrk archive).
> 
> Regards
>     Brian Carpenter
> 
> On 26-May-20 09:19, Eric Rescorla wrote:
>> I think whether this is an IETF problem depends on one's priors.
>>
>> At a high level, it seems likely that we need some kind of
>> two-layer system of references:
>>
>> - A reference that points to the current state (e.g., "TLS
>>    with all the recommended extensions, etc.").
>>   
>> - A reference that points to a specific historical state
>>    (in version control, we'd call this a hash or a version
>>    number depending on the system).
>>
>> Now, if you assume that RFC #s are the lower layer (i.e., that RFC
>> XXXX always points to the same content), then yes, it seems like the
>> IETF would need to layer something new on top and this becomes an IETF
>> problem. However, if one treats RFC #s as the higher layer (perhaps
>> with a version number suffix as the lower layer) then this becomes
>> an RFC series problem.
>>
>> -Ekr
>>
>>
>>
>> On Mon, May 25, 2020 at 2:13 PM Tim Wicinski > wrote:
>>
>>
>>      Brian
>>
>>      While it is an IETF problem, I would like to see an RFC Editor function
>>      that is empowered to tackle this problem.
>>
>>      tim
>>
>>
>>      On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter > wrote:
>>
>>          On 26-May-20 08:42, John R Levine wrote:
>>          .....
>>          > I am not proposing specific changes other than to say that the model of
>>          > RFCs solely as independent immutable documents no longer makes sense.
>>          > While I do not suggest we go to WHATWG style living documents, I do think
>>          > that for our specifications we need to find a more modern way to collect
>>          > the material into a small number of places with stable names (perhaps
>>          > using version numbers like everyone else does), and to make discrete low
>>          > cost updates as we find errors or make partial updates.
>>
>>          Writing as one of those who bloodied their noses on this problem some
>>          15 years ago, I completely agree, but it is an IETF problem, and the IETF
>>          has been remarkably resistant to discussing it, let alone fixing it.
>>
>>          And I *think* it's orthogonal to our problem here, although if the IETF
>>          would get its house in order, our problem might be easier.
>>
>>          Regards
>>              Brian
>>
>>          --
>>          Rfced-future mailing list
>>          Rfced-future@iab.org 
>>          https://www.iab.org/mailman/listinfo/rfced-future
>>
>>      --
>>      Rfced-future mailing list
>>      Rfced-future@iab.org 
>>      https://www.iab.org/mailman/listinfo/rfced-future
>>
> 


From nobody Mon May 25 15:14: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 B50303A0ACC for ; Mon, 25 May 2020 15:14:19 -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 vpT5DbURUN05 for ; Mon, 25 May 2020 15:14:17 -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 4426E3A0AC9 for ; Mon, 25 May 2020 15:14:17 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id v16so22236685ljc.8 for ; Mon, 25 May 2020 15:14: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=v7ucK8uoen/IFjZTKYxc0nYTS6TMrLJ9JPKXGl2JK9c=; b=KB6dnQG0JUXeVbHTcnOMsxMGr28uemhZetJOdE6DHniCED9rBYv5bGzGOUH3Pmnnnb KbfAEKwUSV0CUNzIshUcJdaDC1rIIE2whLuBnKvbs92envlkp2jLpXyqAUM2zgXTR+pu ki1zd+7jiP5j+9Q909y5X/eLYd9XWosAt3kO+5C6gMDAuTsCubbfxLLTj+xvYS1In+Uf OGRzF3EAvkgfnHsXCxv6GFhZUD1q/tisLwswFMeuLVjBakz+tm0Pb0p3ePq2qjgsf1Fi bXH1x80swxVSdT2g58/mtfL++1ySYON741Cm4vF2xUxyqFt6oEBXJe0ofnOAKfcxLSC4 HWYA==
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=v7ucK8uoen/IFjZTKYxc0nYTS6TMrLJ9JPKXGl2JK9c=; b=ajPbCMjW1EIvWNJBZ2UBK1gcyS8UmTEgHMzRcB0/Ll3HXtvXBXn5ZfpZ2ZUQvOUEsW 07z6DNSUtoUEgUCsQKaVWmy1CRvPf7CxLZ8qVP3de5D7mwFDEYvH4t4Ka5b5P5MuiSHl 1VsgLJgLNBHyBCshDiqk8OHfyIVHLPoGJblT4q9PfpVpAbxyQnPcpQ0gyYX+a+TfXmRV ANhGED63BpWgKIH6o6kTCQKFY+9Ll/bjNZK2NckEZ0lzVtzC+5THEDvzzSqJkyQen/D4 A6Udf0zQla+8DnYDmosXI61FUDFTDfjDPLNbOSpZ4IgEkHuICN/Qey727HyNVBOQVEP2 YqTw==
X-Gm-Message-State: AOAM531puN75KJ+TKMrQ5a2C8jyK1rb3Ao22gnw+gOb/zp8TB6MjY4UA YDeE34a5Qvjb1DlI/XlXncajhAl4xQ20UvBmKHA0YAedXmg=
X-Google-Smtp-Source: ABdhPJygsyAXPulZmdQfQfX0r79ff+WhddIjirqnyTdrutnRR2hT4UAaKwL8Qh9TijinEozUKlHEuG+l4dvjTJpzBjA=
X-Received: by 2002:a2e:8053:: with SMTP id p19mr14916983ljg.199.1590444855226;  Mon, 25 May 2020 15:14:15 -0700 (PDT)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Eric Rescorla 
Date: Mon, 25 May 2020 15:13:39 -0700
Message-ID: 
To: John R Levine 
Cc: Brian E Carpenter , Rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000a1888405a6804c7f"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:14:21 -0000

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

On Mon, May 25, 2020 at 3:04 PM John R Levine  wrote:

> On Tue, 26 May 2020, Brian E Carpenter wrote:
> > Let me challenge that with a question.
> >
> > What would really be better if RFC8200 was actually called RFC1883.3?
> >
> > Or if RFC8446 was RFC2246.4?
>
> Without a better way to do minor updates, I agree that changing the names
> isn't likely to make any difference.
>

This is a really important point, and in fact it's a positive feedback
loop. Because everyone knows it is super-expensive to make version N+1,
making version N becomes really expensive as people try to make it perfect.
If it were easier to make small changes (especially editorial ones) then we
could make AUTH48 much faster because people would know they could fix it
later.

-Ekr

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




=

On Mon, May 25, 2020 at 3:04 PM John =
R Levine <johnl@taugh.com> wro=
te:
On Tue, 26 M=
ay 2020, Brian E Carpenter wrote:

> Let me challenge that with a question.

>

> What would really be better if RFC8200 was actually called RFC1883.3?<=
br>
>

> Or if RFC8446 was RFC2246.4?



Without a better way to do minor updates, I agree that changing the names <=
br>
isn't likely to make any difference. 

This is a really important point, and in fact it's a positive feedba=
ck loop. Because everyone knows it is super-expensive to make version N+1, =
making version N becomes really expensive as people try to make it perfect.=
 If it were easier to make small changes (especially editorial ones) then w=
e could make AUTH48 much faster because people would know they could fix it=
 later. 

-Ekr



--000000000000a1888405a6804c7f--


From nobody Mon May 25 15:16: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 0CEB13A0AD0 for ; Mon, 25 May 2020 15:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG8lqG1b51xZ for ; Mon, 25 May 2020 15:16:04 -0700 (PDT)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B403A0ACC for ; Mon, 25 May 2020 15:16:03 -0700 (PDT)
Received: by mail-oi1-x22a.google.com with SMTP id o24so17141029oic.0 for ; Mon, 25 May 2020 15:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Az++KIuGgzAp4j/pu9W9Y5kFAdeT8/4IZNpPnRb2QAU=; b=oJxm8P82W9Cfrfl73541c/hM37l3jSKDW3syC3uJ9SHF8yDeahkeetVZ/WN6S3F3uG hsk0TkeYnE9lO6fenVr/sXhFaNefY1v4a3o2V8TIMv11uc67nVd2DlEfanZhra4oGZyu mrJkVpBRJk5BF9j3oljEsxdtAs38mb/nZ8Otdo9vx7QFJ5EU74Q69fMne+Z2qFK6+dBH rdZChevm3FgXPDIVNKxQ6jP2INw/ybWUFLq+H4zlGluk5qFsVIs9eQf4U8G/SVhhBnvH VFb8VDZu4lCCgHlprUHJz+Dn5bnHBvOyBIZ1y1NLhYzA2mJ6lLC6wW7aKbIHwWQxy+7w JpUg==
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=Az++KIuGgzAp4j/pu9W9Y5kFAdeT8/4IZNpPnRb2QAU=; b=OULja7nE6HL6Y4Kr9ePdQOHK1QLFSMfPkV0xEI66PynezKNSsZdDUu3GN8NP/8lQ9F d2txcUcZs0TmdsuoYnBC9oTo30XLYC8afuOLvicSoZe9wV0kgJP93MtkVFNMgm/kL+hi 8uX7TojTgSr00nVN0ytjUEDb/BPaLZnCBRYGBuBDZ0nQavIXUyhzjH/yPNdsXJO6MyqJ AmDINmnWxCUS20p391fBeDWwe4taM/EXLTKdSgS95XP/TFFJ00jIZn5Jk60fmtoZ8YBw w1l3n2Ayud6vckDVSIRe809N4eMeQj3Es6QwKpeX4fULqPIroI/0N223dmmb698i05x0 gXLA==
X-Gm-Message-State: AOAM531uUKlQcpVnsejYAIf7KE2tISG/cI34N7t6EcYm6DNwavOjhXrD C6vtqDGLROytnYdnVsGsonazEHNOQMOdCdPTPYU=
X-Google-Smtp-Source: ABdhPJy/eB5pkuZBY1isxGpCQtOILlRQ+W65I37a2XZVmEcHzz9roS758PHpCT4EzaxKogZ7eOSXFNWLTF18xcoQBpY=
X-Received: by 2002:aca:c590:: with SMTP id v138mr7772865oif.132.1590444962458;  Mon, 25 May 2020 15:16:02 -0700 (PDT)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Tim Wicinski 
Date: Mon, 25 May 2020 18:15:51 -0400
Message-ID: 
To: John R Levine 
Cc: Brian E Carpenter , Rfced-future@iab.org
Content-Type: multipart/alternative; boundary="00000000000005afe405a6805317"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:16:07 -0000

--00000000000005afe405a6805317
Content-Type: text/plain; charset="UTF-8"

A good data point on how ineffective the IETF is at updating our larger
technical specifications is the work involved in RFC793-bis coming out
of tcpm.   Wes started this in 2013, and ugh, still moving along.

I look at RFC1035 and I see a similar timeline.
tim


On Mon, May 25, 2020 at 6:04 PM John R Levine  wrote:

> On Tue, 26 May 2020, Brian E Carpenter wrote:
> > Let me challenge that with a question.
> >
> > What would really be better if RFC8200 was actually called RFC1883.3?
> >
> > Or if RFC8446 was RFC2246.4?
>
> Without a better way to do minor updates, I agree that changing the names
> isn't likely to make any difference.  I note that it took 19 years to
> update RFC 2460 to RFC 8200 which perhaps suggests some underlying issues.
>
> RFC 5321 needs an update but we are reluctant to do it because as soon as
> you open the can even a little bit, all the worms swarm out and bite you.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

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



A=
 good data point=C2=A0on how ineffective the IETF is at updating our larger=

technica=
l specifications is the work involved in RFC793-bis coming out
of tcpm.=C2=A0 =C2=A0=
Wes started this in 2013, and ugh, still moving along.=C2=A0=C2=A0

I look at RFC1035 and=
 I see a similar=C2=A0timeline.=C2=A0
tim


On Mon, May 25, 2020 at 6:04 PM John R Le=
vine <johnl@taugh.com> wrote:<=
br>
On Tue, 26 May 2=
020, Brian E Carpenter wrote:

> Let me challenge that with a question.

>

> What would really be better if RFC8200 was actually called RFC1883.3?<=
br>
>

> Or if RFC8446 was RFC2246.4?



Without a better way to do minor updates, I agree that changing the names <=
br>
isn't likely to make any difference.=C2=A0 I note that it took 19 years=
 to 

update RFC 2460 to RFC 8200 which perhaps suggests some underlying issues.<=
br>


RFC 5321 needs an update but we are reluctant to do it because as soon as <=
br>
you open the can even a little bit, all the worms swarm out and bite you.


Regards,

John Levine, johnl@tau=
gh.com, Taughannock Networks, Trumansburg NY

Please consider the environment before reading this e-mail. https://jl.ly



-- 

Rfced-future mailing list

Rfced-future@iab.=
org

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




--00000000000005afe405a6805317--


From nobody Mon May 25 15:17:02 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB483A0AD0 for ; Mon, 25 May 2020 15:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA9LzMrllNx2 for ; Mon, 25 May 2020 15:16:56 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 A56863A0ACC for ; Mon, 25 May 2020 15:16:56 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id 69so14806815otv.2 for ; Mon, 25 May 2020 15:16:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HgnliVL3Dx8ak5YZLaIySN36vwZ1gfw+sQwTN8fSqHc=; b=d5uyxdTkfPkNigQGZydGWYM8hsdRRkMe92PczDYw0QkLSjQGk3B4C0uRqO67zpn3qt dzc3s8gK6UjN++LL3Loorp3ZYQKJxAP20qLrll0WdhayaU0+n7Mm0b6NfVGHb5aQnxZM JV8qPe7AyU8hFP89YtWNL/UCSoJXs7jORJzMXqw1k5+mET4QZqIjXIvKU31flIP5aki0 FRQ+xeOrimo0fgRc+MBecVqyun2eDIzzIZRb3eeZO196l64EcGIyUJAGmMOeFw8eDHu2 fQ0joocpaN3ktmB55cuYVqiAQ9Lho76OSrdjg2UTBnPmoquWg5NbqylcXr2/psbPaJFA 0pGw==
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=HgnliVL3Dx8ak5YZLaIySN36vwZ1gfw+sQwTN8fSqHc=; b=gXznIcreMaX/NHQ1lkEUlk/Glxb2jIiTRprYhPp6XS1g0tQBr0INJTS+BaHpbBU+PQ CARHSrV4bGOqREdVTj7qBKFPbRpWyQXyNCnj0DBL6QjYTpt4puA1U1gP2kpkvCT00mtt 5PZ3PpV+peaMdJOVxPmcv8Ma6JpYmXyEC9KDGPkem4chh846AGgO7ZbA6Tvg7eLSt5tz vNIti6Gc7Rz+BZRGnWdHxDxkHcvw7myV61mxFbzsQvLBgzW83yOvaD+aDfpxKlIM44v8 JZu0LSW5l+OiBJsqKuTA61O9TBNoBGbJTeLdEQ2GY+RGRxkWavPoEM0p+oug/8w13FvP 6VPQ==
X-Gm-Message-State: AOAM53237jV7RK2mmyBjtkU2F0E4xvCEuc0z0ztvUQ08GbW6bKV0auyy BIbg37/LqXfZc8lF7XXgcvPWoD0YteAcTZiCfHI=
X-Google-Smtp-Source: ABdhPJy+cnoLHkH6PK38ZZuNI0xCbtYyeOKqVm2+1orVz/cheL1r6/KmjIOHhcJhrfim+r5AgrZdsT/9Y5RIOIvL3Zo=
X-Received: by 2002:a05:6830:3109:: with SMTP id b9mr18728844ots.41.1590445015362;  Mon, 25 May 2020 15:16:55 -0700 (PDT)
MIME-Version: 1.0
References:       
In-Reply-To: 
From: Tim Wicinski 
Date: Mon, 25 May 2020 18:16:44 -0400
Message-ID: 
To: Eric Rescorla 
Cc: John R Levine , Rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000002cf25a05a6805671"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:17:01 -0000

--0000000000002cf25a05a6805671
Content-Type: text/plain; charset="UTF-8"

Agree with Eric and John on the importance of better way to do minor
updates.

On Mon, May 25, 2020 at 6:14 PM Eric Rescorla  wrote:

>
>
> On Mon, May 25, 2020 at 3:04 PM John R Levine  wrote:
>
>> On Tue, 26 May 2020, Brian E Carpenter wrote:
>> > Let me challenge that with a question.
>> >
>> > What would really be better if RFC8200 was actually called RFC1883.3?
>> >
>> > Or if RFC8446 was RFC2246.4?
>>
>> Without a better way to do minor updates, I agree that changing the names
>> isn't likely to make any difference.
>>
>
> This is a really important point, and in fact it's a positive feedback
> loop. Because everyone knows it is super-expensive to make version N+1,
> making version N becomes really expensive as people try to make it perfect.
> If it were easier to make small changes (especially editorial ones) then we
> could make AUTH48 much faster because people would know they could fix it
> later.
>
> -Ekr
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

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



A=
gree with Eric and John on the importance of better way to do minor updates=
.=C2=A0

On Mon, May 25, 2020 at 6:14 PM Eric Rescorla <ekr@rtfm.com> wrote:


On M=
on, May 25, 2020 at 3:04 PM John R Levine <johnl@taugh.com> wrote:
On Tue, 26 May 2020, Brian E Carpent=
er wrote:

> Let me challenge that with a question.

>

> What would really be better if RFC8200 was actually called RFC1883.3?<=
br>
>

> Or if RFC8446 was RFC2246.4?



Without a better way to do minor updates, I agree that changing the names <=
br>
isn't likely to make any difference. 

This is a really important point, and in fact it's a positive feedba=
ck loop. Because everyone knows it is super-expensive to make version N+1, =
making version N becomes really expensive as people try to make it perfect.=
 If it were easier to make small changes (especially editorial ones) then w=
e could make AUTH48 much faster because people would know they could fix it=
 later. 

-Ekr


-- 

Rfced-future mailing list

Rfced-future@iab.=
org

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



--0000000000002cf25a05a6805671--


From nobody Mon May 25 15:18: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 5A9223A0ACC for ; Mon, 25 May 2020 15:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_1GfJVWdPy2 for ; Mon, 25 May 2020 15:18:02 -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 A80983A0AD5 for ; Mon, 25 May 2020 15:17:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49WBLD43Bbz6G8nj; Mon, 25 May 2020 15:17:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590445076; bh=jAp9bQicEESuGGnNySzyON9m5d9WdBqBCrWld2/oiow=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HB9MV8nuGkZLBq5RK3MYnyN9cMVsI+0N32cS/LH0zrS4B4w0gSyHrzwxuY+hM2dtu 1f3IXnkBZg6jBJetE/T1u0/c0jX8+qwVe6du7LhXpNdFc5DS7fkGINVSFL1SG1jl+n uRqlIJSP1nUD1+456htWLpRwOVSvd2SIKFozyq3Y=
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 49WBLD09b7z6G8MP; Mon, 25 May 2020 15:17:55 -0700 (PDT)
To: Eric Rescorla 
Cc: Rfced-future@iab.org
References:      
From: "Joel M. Halpern" 
Message-ID: 
Date: Mon, 25 May 2020 18:17:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:18:07 -0000

I have to disagree with this.

In almost every case that I know of, it is important to be clear as to 
what content one is referring to.  In a vendor describing a product, or 
a purhcaser requesting a product, or a PM laying out a feature plan, or 
... it is critical that the target be stable.

If I advertise support for "OSPF", that may be good enough for marketing 
collateral, but if someone is going to use it they need to know exactly 
what version of the protocols they care about I have implemented  (which 
is why operator RFPs are long and detailed. )

In fact, if I put aside the minor issue of the rare case where we make a 
substantive error in the RFC, I can see no case where it is important to 
refer to "the most current version of BGP" even if that were a 
well-defined thing.

Wanting to know  what the set of things I should consider for 
implementing (or using) BGP is reasonable.  But that is not addressed by 
giving a simple name to a vast collection of specification.  Whether 
that is roadmaps, IONs, or other descriptions, it is not the specifications.

Yours,
Joel

On 5/25/2020 6:05 PM, Eric Rescorla wrote:
> 
> 
> On Mon, May 25, 2020 at 2:56 PM Brian E Carpenter 
> > wrote:
> 
>     Let me challenge that with a question.
> 
>     What would really be better if RFC8200 was actually called RFC1883.3?
> 
> 
> I don't understand v6 well enough, but quite possibly.
> 
> 
>     Or if RFC8446 was RFC2246.4?
> 
> 
> No, I think that TLS 1.2 is a specific thing and so is TLS 1.3.
> 
> However, I think that it would be better if the bazillion documents that 
> you actually needed to implement TLS 1.2 were referred to by the name 
> "RFC 2246" and that most people never had to engage with the specific 
> differences between RFC 2246.5 and RFC 2246.6.
> 
> Similarly, I think that it would be better if TLS 1.3 + the already 
> filed errata plus the various update documents currently in process 
> (ESNI, importers, ...) were referred to as RCC 8446.
> Just to make sure we are on the same page, my thesis is that people 
> would generally not reference specific RFC dot versions. This is what 
> happens in the Web platform, for instance: one can in principle refer to 
> specific versions of the HTML5 spec, but as a practical matter, people 
> do not need to do so.
> 
> -Ekr
> 
> 
>     Regards
>         Brian Carpenter
> 
>     On 26-May-20 09:19, Eric Rescorla wrote:
>      > I think whether this is an IETF problem depends on one's priors.
>      >
>      > At a high level, it seems likely that we need some kind of
>      > two-layer system of references:
>      >
>      > - A reference that points to the current state (e.g., "TLS
>      >   with all the recommended extensions, etc.").
>      >
>      > - A reference that points to a specific historical state
>      >   (in version control, we'd call this a hash or a version
>      >   number depending on the system).
>      >
>      > Now, if you assume that RFC #s are the lower layer (i.e., that RFC
>      > XXXX always points to the same content), then yes, it seems like the
>      > IETF would need to layer something new on top and this becomes an
>     IETF
>      > problem. However, if one treats RFC #s as the higher layer (perhaps
>      > with a version number suffix as the lower layer) then this becomes
>      > an RFC series problem.
>      >
>      > -Ekr
>      >
>      >
>      >
>      > On Mon, May 25, 2020 at 2:13 PM Tim Wicinski            >> wrote:
>      >
>      >
>      >     Brian
>      >
>      >     While it is an IETF problem, I would like to see an RFC
>     Editor function
>      >     that is empowered to tackle this problem.
>      >
>      >     tim
>      >
>      >
>      >     On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter
>     
>          >> wrote:
>      >
>      >         On 26-May-20 08:42, John R Levine wrote:
>      >         .....
>      >         > I am not proposing specific changes other than to say
>     that the model of
>      >         > RFCs solely as independent immutable documents no
>     longer makes sense.
>      >         > While I do not suggest we go to WHATWG style living
>     documents, I do think
>      >         > that for our specifications we need to find a more
>     modern way to collect
>      >         > the material into a small number of places with stable
>     names (perhaps
>      >         > using version numbers like everyone else does), and to
>     make discrete low
>      >         > cost updates as we find errors or make partial updates.
>      >
>      >         Writing as one of those who bloodied their noses on this
>     problem some
>      >         15 years ago, I completely agree, but it is an IETF
>     problem, and the IETF
>      >         has been remarkably resistant to discussing it, let alone
>     fixing it.
>      >
>      >         And I *think* it's orthogonal to our problem here,
>     although if the IETF
>      >         would get its house in order, our problem might be easier.
>      >
>      >         Regards
>      >             Brian
>      >
>      >         --
>      >         Rfced-future mailing list
>      > Rfced-future@iab.org 
>     >
>      > https://www.iab.org/mailman/listinfo/rfced-future
>      >
>      >     --
>      >     Rfced-future mailing list
>      > Rfced-future@iab.org 
>     >
>      > https://www.iab.org/mailman/listinfo/rfced-future
>      >
> 
> 


From nobody Mon May 25 15:28:36 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9933A0AE7 for ; Mon, 25 May 2020 15:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_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 sqY7I22m2M0l for ; Mon, 25 May 2020 15:28:32 -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 906583A0AE5 for ; Mon, 25 May 2020 15:28:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49WBZS3VyQz6G8nj; Mon, 25 May 2020 15:28:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590445712; bh=XWOZEdx1s2it0s6U+RRuEbSaYdH0mShFNJEmQMtzS10=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=R8LrKsglw9wIh/MmY7vz5nQzTASgWyZzBssj8dBVRV01z3BCcix8wxm/VROtnPVgH JR/4NWqKJEc/Kj0Qn8YArg11ntg7l3z4okUrB8DEdwuX8TjNUGS0n+nQDHQXamFsMC QWG/iHqC1786G8wEp15oES9I77NBVbidU+6wqZl4=
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 49WBZR73qNz6G8nv; Mon, 25 May 2020 15:28:31 -0700 (PDT)
To: Tim Wicinski 
Cc: Rfced-future@iab.org
References:        
From: "Joel M. Halpern" 
Message-ID: 
Date: Mon, 25 May 2020 18:28:16 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:28:35 -0000

Tim, I think that there are two different (related, but different) 
problems here.

We do have difficulty updating documents.  In my experience this is 
caused by folks needing to relitigate the contentious agreements that 
led to the previous document.  The whole point of standards is to reach 
those agreements.  So yes, it is painful when they get re-opened.  There 
may be ways to improve that.  While there are problems with it, Adam had 
an interesting proposal to try to enable re-opening part of a document. 
We couldn't even figure out how to usefully discuss that.

The other problem is the one John pointed to initially.  We do not ahve 
good guides to have to use sets of our documents to solve problems.  How 
do you build a set of good software for any specific kind of protocol 
participant.  From history this has two different hard pieces itself. 
First, we do not actually have agreements on how to package these things 
up, and what the actual requirements are.  The efforts it took to 
produce the old Host Requirements and Router Requirements RFCs reflect 
this.  (I suspect Fred Baker still has scars from the later.)  And the 
second is that actual packaging is not as trivial as it looks.  Should 
we have a package for BGP, one for OSPF, one of IS-IS, ..?  Or should we 
have one for VPNs, one for TE, one for ...?  Or should we have a good 
indexing system that lets you ask the question either way?

Yours,
Joel

On 5/25/2020 6:16 PM, Tim Wicinski wrote:
> 
> Agree with Eric and John on the importance of better way to do minor 
> updates..
> 
> On Mon, May 25, 2020 at 6:14 PM Eric Rescorla  > wrote:
> 
> 
> 
>     On Mon, May 25, 2020 at 3:04 PM John R Levine      > wrote:
> 
>         On Tue, 26 May 2020, Brian E Carpenter wrote:
>          > Let me challenge that with a question.
>          >
>          > What would really be better if RFC8200 was actually called
>         RFC1883.3?
>          >
>          > Or if RFC8446 was RFC2246.4?
> 
>         Without a better way to do minor updates, I agree that changing
>         the names
>         isn't likely to make any difference.
> 
> 
>     This is a really important point, and in fact it's a positive
>     feedback loop. Because everyone knows it is super-expensive to make
>     version N+1, making version N becomes really expensive as people try
>     to make it perfect. If it were easier to make small changes
>     (especially editorial ones) then we could make AUTH48 much faster
>     because people would know they could fix it later.
> 
>     -Ekr
> 
>     -- 
>     Rfced-future mailing list
>     Rfced-future@iab.org 
>     https://www.iab.org/mailman/listinfo/rfced-future
> 
> 


From nobody Mon May 25 15:30:58 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7D93A0AEB for ; Mon, 25 May 2020 15:30:56 -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 iYOAmT4Uc7QT for ; Mon, 25 May 2020 15:30:53 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 302AA3A0AEE for ; Mon, 25 May 2020 15:30:53 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id o14so22292242ljp.4 for ; Mon, 25 May 2020 15:30:53 -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=Fd843GgrPwc6IeVg6qD3HtqrbxXloQBafYqZANERxKU=; b=hH5xTCRLQGSFNA2z0P/4to4t/3YH0Dxiwu/OV3gAm5HOQsNJfhdUoUWt6Sh0OnLGo0 qkkwJTzCnnm0s7jrPXHrncYqpgpS7qf5+ii08EW2PSceBq1p4djxD/LohKzh9GR/bNR8 CKIe9FxDha4ogzB7271Iya4FhYXfhzlh4hcaCGMKKM5d1pEQ36m8pFybLrdsdG80GEui AO0mgIr6MmAKePH5puOtlgtzmwAXuw9fPmpQzoCcLO7i/tXO0ZkDFP+jdUy49/o6Mvxh szu7rfuDNrubjHjLUy6xPWNHOOXwVrccDXlOHBYcqc5Yx4Gr/cwo7MGaH3f+auDYszGb lpYg==
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=Fd843GgrPwc6IeVg6qD3HtqrbxXloQBafYqZANERxKU=; b=Qm083hV65kKjqvRAz8Rp5pLOY7DMvGxb5WLGXDrxp1GuEDbuThfFM4/FPnnS9EDhZx GeIEz77DsLlQAF4/X6OyhDNCRM7uTdM9PhcExqmqADV/8o+7JZCnzvkx0jZUlZ43KWWR I86IiC06wLfR6e2T1I0L/lY9H77S+ZF5AFjXwNSTW6LzztiEW+8v4DDEX2AV9PuWgHJ3 1ODn+POC3DLmHWmejElEZtZzhE+8v1D+BbHMaZOhny0jcAv5OBxYjG86f0YbGKDiBjxx yMXQJ8BISAEP8QQLbi71aMj+WtnKjn1nZrxbUnKVAJG+N4r6qlsz+Z3SdNdAg5FohrA8 AaJQ==
X-Gm-Message-State: AOAM53178zrZJrNLtQ8uXgE923b0/+grRN7k6622u9SoMTslzNWJ7iLp agL2Inu6HKSXMC5K3USzb9+JTm0qBWZ+VE+MAiBbElR5FayFaA==
X-Google-Smtp-Source: ABdhPJxDR554GLliGntcXKiR72zM3YGjvkv90nO/ixge0763YkJFzih4xqIboTBDPFAwcWUsx45nG5xUxTc39+OxNv4=
X-Received: by 2002:a05:651c:1183:: with SMTP id w3mr15577455ljo.265.1590445850799;  Mon, 25 May 2020 15:30:50 -0700 (PDT)
MIME-Version: 1.0
References:       
In-Reply-To: 
From: Eric Rescorla 
Date: Mon, 25 May 2020 15:30:14 -0700
Message-ID: 
To: "Joel M. Halpern" 
Cc: Rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000f8c3f505a680875d"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:30:57 -0000

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

I agree that it's important to be able to refer to the precise
functionality that is implemented, however, I don't think that
necessarily means a specific set of documents. In the specifications I
am most familiar with (TLS, QUIC, HTML), we strive for stability of
features once they are built and the ability to negotiate/detect
certain features.

For instance, one might say one implemented TLS 1.3 with the Encrypted
Client Hello feature but not PSK Importers. Similarly, one might say
that one implemented HTML5 and localStorage but not Web Workers.
(Hence my answer to Brian that I don't think you would refer to TLS
1.3 with the same basic RFC # as TLS 1.2, because 1.3 is not an
extension of 1.2). And note that in these specifications, even
"extensions" in the main spec are not always mandatory.

Again, I don't have a problem with referring to concrete versions
of the RFCs, but in my experience the vast majority of the changes
(as before, editorial changes or optional extensions) actually
do not benefit from this treatment, and in fact are made much
harder by it.

-Ekr

On Mon, May 25, 2020 at 3:17 PM Joel M. Halpern  wrote:

> I have to disagree with this.
>
> In almost every case that I know of, it is important to be clear as to
> what content one is referring to.  In a vendor describing a product, or
> a purhcaser requesting a product, or a PM laying out a feature plan, or
> ... it is critical that the target be stable.
>
> If I advertise support for "OSPF", that may be good enough for marketing
> collateral, but if someone is going to use it they need to know exactly
> what version of the protocols they care about I have implemented  (which
> is why operator RFPs are long and detailed. )
>
> In fact, if I put aside the minor issue of the rare case where we make a
> substantive error in the RFC, I can see no case where it is important to
> refer to "the most current version of BGP" even if that were a
> well-defined thing.
>
> Wanting to know  what the set of things I should consider for
> implementing (or using) BGP is reasonable.  But that is not addressed by
> giving a simple name to a vast collection of specification.  Whether
> that is roadmaps, IONs, or other descriptions, it is not the
> specifications.
>
> Yours,
> Joel
>
> On 5/25/2020 6:05 PM, Eric Rescorla wrote:
> >
> >
> > On Mon, May 25, 2020 at 2:56 PM Brian E Carpenter
> > >
> wrote:
> >
> >     Let me challenge that with a question.
> >
> >     What would really be better if RFC8200 was actually called RFC1883.3?
> >
> >
> > I don't understand v6 well enough, but quite possibly.
> >
> >
> >     Or if RFC8446 was RFC2246.4?
> >
> >
> > No, I think that TLS 1.2 is a specific thing and so is TLS 1.3.
> >
> > However, I think that it would be better if the bazillion documents that
> > you actually needed to implement TLS 1.2 were referred to by the name
> > "RFC 2246" and that most people never had to engage with the specific
> > differences between RFC 2246.5 and RFC 2246.6.
> >
> > Similarly, I think that it would be better if TLS 1.3 + the already
> > filed errata plus the various update documents currently in process
> > (ESNI, importers, ...) were referred to as RCC 8446.
> > Just to make sure we are on the same page, my thesis is that people
> > would generally not reference specific RFC dot versions. This is what
> > happens in the Web platform, for instance: one can in principle refer to
> > specific versions of the HTML5 spec, but as a practical matter, people
> > do not need to do so.
> >
> > -Ekr
> >
> >
> >     Regards
> >         Brian Carpenter
> >
> >     On 26-May-20 09:19, Eric Rescorla wrote:
> >      > I think whether this is an IETF problem depends on one's priors.
> >      >
> >      > At a high level, it seems likely that we need some kind of
> >      > two-layer system of references:
> >      >
> >      > - A reference that points to the current state (e.g., "TLS
> >      >   with all the recommended extensions, etc.").
> >      >
> >      > - A reference that points to a specific historical state
> >      >   (in version control, we'd call this a hash or a version
> >      >   number depending on the system).
> >      >
> >      > Now, if you assume that RFC #s are the lower layer (i.e., that RFC
> >      > XXXX always points to the same content), then yes, it seems like
> the
> >      > IETF would need to layer something new on top and this becomes an
> >     IETF
> >      > problem. However, if one treats RFC #s as the higher layer
> (perhaps
> >      > with a version number suffix as the lower layer) then this becomes
> >      > an RFC series problem.
> >      >
> >      > -Ekr
> >      >
> >      >
> >      >
> >      > On Mon, May 25, 2020 at 2:13 PM Tim Wicinski  >       >     >> wrote:
> >      >
> >      >
> >      >     Brian
> >      >
> >      >     While it is an IETF problem, I would like to see an RFC
> >     Editor function
> >      >     that is empowered to tackle this problem.
> >      >
> >      >     tim
> >      >
> >      >
> >      >     On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter
> >     
> >      >     >> wrote:
> >      >
> >      >         On 26-May-20 08:42, John R Levine wrote:
> >      >         .....
> >      >         > I am not proposing specific changes other than to say
> >     that the model of
> >      >         > RFCs solely as independent immutable documents no
> >     longer makes sense.
> >      >         > While I do not suggest we go to WHATWG style living
> >     documents, I do think
> >      >         > that for our specifications we need to find a more
> >     modern way to collect
> >      >         > the material into a small number of places with stable
> >     names (perhaps
> >      >         > using version numbers like everyone else does), and to
> >     make discrete low
> >      >         > cost updates as we find errors or make partial updates.
> >      >
> >      >         Writing as one of those who bloodied their noses on this
> >     problem some
> >      >         15 years ago, I completely agree, but it is an IETF
> >     problem, and the IETF
> >      >         has been remarkably resistant to discussing it, let alone
> >     fixing it.
> >      >
> >      >         And I *think* it's orthogonal to our problem here,
> >     although if the IETF
> >      >         would get its house in order, our problem might be easier.
> >      >
> >      >         Regards
> >      >             Brian
> >      >
> >      >         --
> >      >         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
> >      >
> >
> >
>

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


I agree that it's important to be able to refer to the=
 precise
functionality that is implemented, however, I don't think t=
hat
necessarily means a specific set of documents. In the specifications=
 I
am most familiar with (TLS, QUIC, HTML), we strive for stability offeatures once they are built and the ability to negotiate/detect
certa=
in features.

For instance, one might say one implemented TLS 1.3 wit=
h the Encrypted
Client Hello feature but not PSK Importers. Similarly, o=
ne might say
that one implemented HTML5 and localStorage but not Web Wor=
kers.
(Hence my answer to Brian that I don't think you would refer t=
o TLS
1.3 with the same basic RFC # as TLS 1.2, because 1.3 is not anextension of 1.2). And note that in these specifications, even
"ex=
tensions" in the main spec are not always mandatory.

Again, I d=
on't have a problem with referring to concrete versions
of the RFCs,=
 but in my experience the vast majority of the changes
(as before, edito=
rial changes or optional extensions) actually
do not benefit from this t=
reatment, and in fact are made much
harder by it.

-Ekr
=


On Mon, May 25, 2020 at 3:17 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
I have to disagree with this.



In almost every case that I know of, it is important to be clear as to 

what content one is referring to.=C2=A0 In a vendor describing a product, o=
r 

a purhcaser requesting a product, or a PM laying out a feature plan, or 
... it is critical that the target be stable.



If I advertise support for "OSPF", that may be good enough for ma=
rketing 

collateral, but if someone is going to use it they need to know exactly 
what version of the protocols they care about I have implemented=C2=A0 (whi=
ch 

is why operator RFPs are long and detailed. )



In fact, if I put aside the minor issue of the rare case where we make a 
substantive error in the RFC, I can see no case where it is important to 
refer to "the most current version of BGP" even if that were a 
well-defined thing.



Wanting to know=C2=A0 what the set of things I should consider for 

implementing (or using) BGP is reasonable.=C2=A0 But that is not addressed =
by 

giving a simple name to a vast collection of specification.=C2=A0 Whether <=
br>
that is roadmaps, IONs, or other descriptions, it is not the specifications=
.



Yours,

Joel



On 5/25/2020 6:05 PM, Eric Rescorla wrote:

> 

> 

> On Mon, May 25, 2020 at 2:56 PM Brian E Carpenter 

> <b=
rian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wro=
te:

> 

>=C2=A0 =C2=A0 =C2=A0Let me challenge that with a question.

> 

>=C2=A0 =C2=A0 =C2=A0What would really be better if RFC8200 was actually=
 called RFC1883.3?

> 

> 

> I don't understand v6 well enough, but quite possibly.

> 

> 

>=C2=A0 =C2=A0 =C2=A0Or if RFC8446 was RFC2246.4?

> 

> 

> No, I think that TLS 1.2 is a specific thing and so is TLS 1.3.

> 

> However, I think that it would be better if the bazillion documents th=
at 

> you actually needed to implement TLS 1.2 were referred to by the name =


> "RFC 2246" and that most people never had to engage with the=
 specific 

> differences between RFC 2246.5 and RFC 2246.6.

> 

> Similarly, I think that it would be better if TLS 1.3 + the already 
> filed errata plus the various update documents currently in process 
> (ESNI, importers, ...) were referred to as RCC 8446.

> Just to make sure we are on the same page, my thesis is that people 
> would generally not reference specific RFC dot versions. This is what =


> happens in the Web platform, for instance: one can in principle refer =
to 

> specific versions of the HTML5 spec, but as a practical matter, people=
 

> do not need to do so.

> 

> -Ekr

> 

> 

>=C2=A0 =C2=A0 =C2=A0Regards

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian Carpenter

> 

>=C2=A0 =C2=A0 =C2=A0On 26-May-20 09:19, Eric Rescorla wrote:

>=C2=A0 =C2=A0 =C2=A0 > I think whether this is an IETF problem depen=
ds on one's priors.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > At a high level, it seems likely that we need=
 some kind of

>=C2=A0 =C2=A0 =C2=A0 > two-layer system of references:

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > - A reference that points to the current stat=
e (e.g., "TLS

>=C2=A0 =C2=A0 =C2=A0 > =C2=A0 with all the recommended extensions, e=
tc.").

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > - A reference that points to a specific histo=
rical state

>=C2=A0 =C2=A0 =C2=A0 > =C2=A0 (in version control, we'd call thi=
s a hash or a version

>=C2=A0 =C2=A0 =C2=A0 > =C2=A0 number depending on the system).

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > Now, if you assume that RFC #s are the lower =
layer (i.e., that RFC

>=C2=A0 =C2=A0 =C2=A0 > XXXX always points to the same content), then=
 yes, it seems like the

>=C2=A0 =C2=A0 =C2=A0 > IETF would need to layer something new on top=
 and this becomes an

>=C2=A0 =C2=A0 =C2=A0IETF

>=C2=A0 =C2=A0 =C2=A0 > problem. However, if one treats RFC #s as the=
 higher layer (perhaps

>=C2=A0 =C2=A0 =C2=A0 > with a version number suffix as the lower lay=
er) then this becomes

>=C2=A0 =C2=A0 =C2=A0 > an RFC series problem.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > -Ekr

>=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, May 25, 2020 at 2:13 PM Tim Wicinski =
<tjw.ietf@gmail.=
com

>=C2=A0 =C2=A0 =C2=A0<mailto:tjw..ietf@gmail.com> <mailto:tjw.ietf@gmail.com

>=C2=A0 =C2=A0 =C2=A0<mailto:tjw.ietf@gmail.com>>> wrote:

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Brian

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0While it is an IETF proble=
m, I would like to see an RFC

>=C2=A0 =C2=A0 =C2=A0Editor function

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that is empowered to tackl=
e this problem.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0tim

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On Mon, May 25, 2020 at 5:=
11 PM Brian E Carpenter

>=C2=A0 =C2=A0 =C2=A0<brian.e..carpenter@gmail.com <mailto:brian.e.carpenter@gmai=
l.com>

>=C2=A0 =C2=A0 =C2=A0<mailto:brian.e.carpenter@gmail.com

>=C2=A0 =C2=A0 =C2=A0<mailto:brian.e.carpenter@gmail.com>>> wrote:=


>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 26-May-20=
 08:42, John R Levine wrote:

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.....

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I am no=
t proposing specific changes other than to say

>=C2=A0 =C2=A0 =C2=A0that the model of

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> RFCs so=
lely as independent immutable documents no

>=C2=A0 =C2=A0 =C2=A0longer makes sense.

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> While I=
 do not suggest we go to WHATWG style living

>=C2=A0 =C2=A0 =C2=A0documents, I do think

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> that fo=
r our specifications we need to find a more

>=C2=A0 =C2=A0 =C2=A0modern way to collect

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the mat=
erial into a small number of places with stable

>=C2=A0 =C2=A0 =C2=A0names (perhaps

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> using v=
ersion numbers like everyone else does), and to

>=C2=A0 =C2=A0 =C2=A0make discrete low

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> cost up=
dates as we find errors or make partial updates.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Writing as o=
ne of those who bloodied their noses on this

>=C2=A0 =C2=A0 =C2=A0problem some

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015 years ago=
, I completely agree, but it is an IETF

>=C2=A0 =C2=A0 =C2=A0problem, and the IETF

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been rem=
arkably resistant to discussing it, let alone

>=C2=A0 =C2=A0 =C2=A0fixing it.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0And I *think=
* it's orthogonal to our problem here,

>=C2=A0 =C2=A0 =C2=A0although if the IETF

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would get it=
s house in order, our problem might be easier.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=
=A0 Brian

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rfced-future=
 mailing list

>=C2=A0 =C2=A0 =C2=A0 > Rfced-future@iab.org <mailto:Rfced-future@iab.org>

>=C2=A0 =C2=A0 =C2=A0<mailto:Rfced-future@iab.org <mailto:Rfced-future@iab.org>>

>=C2=A0 =C2=A0 =C2=A0 > https://www.iab.org/m=
ailman/listinfo/rfced-future

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Rfced-future mailing list<=
br>
>=C2=A0 =C2=A0 =C2=A0 > Rfced-future@iab.org <mailto:Rfced-future@iab.org>

>=C2=A0 =C2=A0 =C2=A0<mailto:Rfced-future@iab.org <mailto:Rfced-future@iab.org>>

>=C2=A0 =C2=A0 =C2=A0 > https://www.iab.org/m=
ailman/listinfo/rfced-future

>=C2=A0 =C2=A0 =C2=A0 >

> 

> 




--000000000000f8c3f505a680875d--


From nobody Mon May 25 15:47:11 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F463A0B0D for ; Mon, 25 May 2020 15:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ily0DXcEz_l0 for ; Mon, 25 May 2020 15:47: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 8653C3A0B0B for ; Mon, 25 May 2020 15:47:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 99FD3BE2F; Mon, 25 May 2020 23:47: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 GYbDNBdQkku9; Mon, 25 May 2020 23:47:03 +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 D6D5DBE39; Mon, 25 May 2020 23:47:02 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1590446822; bh=9WpXK+RXdvUgnOc9w2hDxMQiKzHI3oMrE6nmMwX4G4M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=26xbGR4xIDMZYM4PwkUo5KhrFIVZkAYcZZjtr1Ckf9qDT4tVF7ko6t2+z554j8vyE VaHMm5M6T4XP3+cWbltOOb4LG+wJIX08RQNDDH/l/DXyQ4q573dQpKyK0bSqWGsCAh mxsc8t0rKMz+T/uFzCpN9xNRYrHFf1TmRDjdAUQQ=
To: Eric Rescorla , John R Levine 
Cc: 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: Mon, 25 May 2020 23:47:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="N8Kele29ZzT2UQN83SlxfRATlKPrBkMPf"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:47:09 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--N8Kele29ZzT2UQN83SlxfRATlKPrBkMPf
Content-Type: multipart/mixed; boundary="DTaHmXVTTvwRhCjYeKeVSExhtGu2aHBou";
 protected-headers="v1"
From: Stephen Farrell 
To: Eric Rescorla , John R Levine 
Cc: Rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] Why the RFC series is important
References: 
 
 
 
 
 
 
In-Reply-To: 

--DTaHmXVTTvwRhCjYeKeVSExhtGu2aHBou
Content-Type: multipart/mixed;
 boundary="------------F143D46B06F6706CA201B82A"
Content-Language: en-US

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


Hiya,

Without taking a position on any solution to the
"point me at the DNS spec" problem (which is real)...

On 25/05/2020 23:13, Eric Rescorla wrote:
> If it were easier to make small changes (especially editorial ones) the=
n we
> could make AUTH48 much faster because people would know they could fix =
it
> later.

AUTH48 is not where we suffer delays. Nor is IESG
processing, in general. Documents being very slowly
processed by RGs or WGs or in finding/creating a WG is
where the long delays happen. (I recall someone doing
stats on that a few years back but don't have a ref,
sorry.)

If that is true (and I think it is), I think it's
safe to conclude that the too-hard-to-update problem,
which is very real, manifests inside the IETF really,
so I find it hard to see how the RSE can be the source
of the fix for that. An RSE could I guess in theory
make it harder to fix, but I reckon the impetus to fix
this needs to come from the IETF community. And ISTM
one amongst many barriers to that kind of ease-of-update
is that it'd need a level of tolerance for things with
which we disagree that I've not really seen be a feature
of the IETF community (myself included;-)

Cheers,
S.


--------------F143D46B06F6706CA201B82A
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-----

--------------F143D46B06F6706CA201B82A--

--DTaHmXVTTvwRhCjYeKeVSExhtGu2aHBou--

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

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

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7MSuYACgkQWrL68XsX
K+ojFQ/9EEujoe/tmaMcdWlz7QpVNsBmKlyJlX/QFC9G3G8CK5Dde0lXHD5iIXAi
5BS06JTgoNgy27eQ5BWYadDOm74R7awGo+1QNCquUEqYaXnPfYKwXMNwMNdaUCJk
x9SEw+6+feaPfoDk5vgkm0ycralcGAI5RkPHteZHGsaBpgZaiPFdaOQHh1vflYYt
/PDUyhs2/rPge6N8nZKLH/HXIStLahODYg5DCWWFGOTau+DpyD/Gmw77FgRnrchj
d7TXBMhePYgAbaOHYM+GXXEiYZno1/GYBcm8+gR/YK+Vt4Tv3SHY1uSvbrp2pmGC
uX4M/RrsMKwIzOVerDpOhbdq0JUUv6WanLjhc1k/bHLBtrwc5mcLBR0qyjmxiOFf
5BSHCXZBwIOTDvWrQYI8U6z3b4RtoOESstvGQR41Q0LDqm0fdv37cDGq46r5DoQf
EhNKUP1Wp9c45D93oaZBjIk13YjS/cZLza4bacGW5wUSmD5UtqAAhow0GwNQhisP
eZ5VMMhZO57OUkgR2sG2XbDwuylZZsVt1LcoMoNEWcb9MigjdJB4HgL6EyCkOVb+
oygh0vkQrbRVdz+nizOVw/yQcp86pZ3aQe9UIQcYEidrRjVhVvYMYMPBepr+IjyC
Yse2GHaYdar95bSUGQsJmyyG5x/Sm22MQ+Jl5CCaXc9QKj2xKWc=
=poYK
-----END PGP SIGNATURE-----

--N8Kele29ZzT2UQN83SlxfRATlKPrBkMPf--


From nobody Mon May 25 15:54: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 1B3B43A0B21 for ; Mon, 25 May 2020 15:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4MIU0VAmEpV for ; Mon, 25 May 2020 15:54:42 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 D62453A0B18 for ; Mon, 25 May 2020 15:54:41 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id m18so22266345ljo.5 for ; Mon, 25 May 2020 15:54:41 -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=hd3WifHNBhbZ5t230NSBd6YHy9AgQFHIMidbeNlNW3g=; b=TrXmk4gXqk6CxU4EQStdSrvHsfHs/1mSAlnsL+/aZoH3VcG7mUfv/zFDleK4hTqXie uqp/7QljRYsWsqoc3aVmwxGVJ1a4EbxzrC2fUCuN33srOQwN74jmE+X+QtZS+QiGunvL lB64DCKils0w5YW40m9hAOfQ93+TkwKInKZvB8izr61GG88DtdNlwq8MofaIesTYT6TN sLqXRiao8EswV8sUbMOfT/UCYcut18G4vLSxaVh9YyFhSnFpsGGFRFJA/kcrNfBtmPEU unOOg5IpSzi77B2WfieZ7Szr9W1jhjrC/wNLLqg4OsVBxhh/0inZNsxNHMCTv+B4qeRv uxYw==
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=hd3WifHNBhbZ5t230NSBd6YHy9AgQFHIMidbeNlNW3g=; b=hbYA90DuY3+4Vorjb0CtbE1co8nNOzjc1QSdOOgWhw3E8X8dwV4ZWCQpZ66mrV0P+Q rnVtOfA8ow3vM9INspJG8GVK6oB+vpQEM9rBDa0lhcx2lPHCB/YoJBaSj6qPdt5rBO1D gQgHcxo2/DktBSn6Ntzav+xaXgke3luSxsA+RYCGgDxwe1e3HhcYWgPALJnPXvAzPGOY cYcXnzbHXtkpqZ1eKr25UD3+UCmDRaIIWzeJgDzdCKKgdGE/rP7fLwzYFoFH00n/EAzi /FFe9lu9ONHUnIIFLEVC1cs1BnX/pUWvXrI/0qK1He2M1wRjcy7ACOmv3Fg1I9z3E92O B5Qg==
X-Gm-Message-State: AOAM532uLu2h1GVI0AcWCHNfUbpQ2iuZZxhWuC2O2r2WpkqxEMzCk9DW 5j95t7s9LwR6snbAVbEZLMUTTVl9D+s6WgnNxeW0fA==
X-Google-Smtp-Source: ABdhPJySdUrNoxg15dGCWtVew8AH3hg6WHPzIENLrTv6Q+wK8hH2k0zNkwivS4O5oCo3Y5w2zUDAvcGGmmnXqOl+HsA=
X-Received: by 2002:a2e:b4e2:: with SMTP id s2mr13967144ljm.17.1590447278576;  Mon, 25 May 2020 15:54:38 -0700 (PDT)
MIME-Version: 1.0
References:        
In-Reply-To: 
From: Eric Rescorla 
Date: Mon, 25 May 2020 15:54:02 -0700
Message-ID: 
To: Stephen Farrell 
Cc: John R Levine , Rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000182fd505a680dd84"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:54:45 -0000

--000000000000182fd505a680dd84
Content-Type: text/plain; charset="UTF-8"

On Mon, May 25, 2020 at 3:47 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> Without taking a position on any solution to the
> "point me at the DNS spec" problem (which is real)...
>
> On 25/05/2020 23:13, Eric Rescorla wrote:
> > If it were easier to make small changes (especially editorial ones) then
> we
> > could make AUTH48 much faster because people would know they could fix it
> > later.
>
> AUTH48 is not where we suffer delays.


Well, it's not the only place, but for instance TLS 1.3 spent 2 months in
AUTH48 in part because we felt we had to go through every word.


Nor is IESG
> processing, in general. Documents being very slowly
> processed by RGs or WGs or in finding/creating a WG is
> where the long delays happen. (I recall someone doing
> stats on that a few years back but don't have a ref,
> sorry.)
>
> If that is true (and I think it is), I think it's
> safe to conclude that the too-hard-to-update problem,
> which is very real, manifests inside the IETF really,
> so I find it hard to see how the RSE can be the source
> of the fix for that. An RSE could I guess in theory
> make it harder to fix, but I reckon the impetus to fix
> this needs to come from the IETF community. And ISTM
> one amongst many barriers to that kind of ease-of-update
> is that it'd need a level of tolerance for things with
> which we disagree that I've not really seen be a feature
> of the IETF community (myself included;-)
>

I think this conflates a bunch of different kinds of updates. To take the
easiest example right now we have an errata system in which the errata are
approved without WG intervention, IESG ballots, etc., but then they just
kind of go into space. If each approved erratum updated the existing
document, that in itself would be an improvement in clarity.

-Ekr


> Cheers,
> S.
>
>

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




=

On Mon, May 25, 2020 at 3:47 PM Steph=
en Farrell <stephen.farrell=
@cs.tcd.ie> wrote:


Hiya,



Without taking a position on any solution to the

"point me at the DNS spec" problem (which is real)...



On 25/05/2020 23:13, Eric Rescorla wrote:

> If it were easier to make small changes (especially editorial ones) th=
en we

> could make AUTH48 much faster because people would know they could fix=
 it

> later.



AUTH48 is not where we suffer delays. 

Well=
, it's not the only place, but for instance TLS 1.3 spent 2 months in A=
UTH48 in part because we felt we had to go through every word.
 
N=
or is IESG

processing, in general. Documents being very slowly

processed by RGs or WGs or in finding/creating a WG is

where the long delays happen. (I recall someone doing

stats on that a few years back but don't have a ref,

sorry.)



If that is true (and I think it is), I think it's

safe to conclude that the too-hard-to-update problem,

which is very real, manifests inside the IETF really,

so I find it hard to see how the RSE can be the source

of the fix for that. An RSE could I guess in theory

make it harder to fix, but I reckon the impetus to fix

this needs to come from the IETF community. And ISTM

one amongst many barriers to that kind of ease-of-update

is that it'd need a level of tolerance for things with

which we disagree that I've not really seen be a feature

of the IETF community (myself included;-)

I think this conflates a bunch of different kinds of updates. To take th=
e easiest example right now we have an errata system in which the errata ar=
e approved without WG intervention, IESG ballots, etc., but then they just =
kind of go into space. If each approved erratum updated the existing docume=
nt, that in itself would be an improvement in clarity.

-Ekr




Cheers,

S.






--000000000000182fd505a680dd84--


From nobody Mon May 25 15:57:15 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E633A00B2 for ; Mon, 25 May 2020 15:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2EBLpmdqd4p for ; Mon, 25 May 2020 15:57:12 -0700 (PDT)
Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (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 657963A005D for ; Mon, 25 May 2020 15:57:12 -0700 (PDT)
Received: by mail-qt1-x843.google.com with SMTP id o19so14771773qtr.10 for ; Mon, 25 May 2020 15:57:12 -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=jJQgny5dBS40O63ab+Od9t8HxvOdBkkdD69JyWqXJh0=; b=vfiv105sTh2xdawVUzRgvCw0eX4Aj0NLErzeZ7Bw6ePOgq4HblWOrsVVNUewgKICxO Clryns7zkVxv9RXarHbUyraACV1kU7jRbjX8DHVp8NSNsiSWPmmzQB2uyfKAL+agU+FU rrQI63/7bWCnVAbvQIh31w3KQSqTEopybbyj4dN/yGIuijZJEqFcJgMaJ5/vjhqwAy0y i8Q3VAL8b1kSXLXx1tlYVhhUeobAd+EdDuIyPK6xfSrBN57naIvizZYXQQFpWLnOLnIR qk9iWpCbVGvBIj/dQVE7eoow0QpLcEjD245DGZQ7Etu4666bsK7NInk4osOg3OWyUiBR TUoA==
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=jJQgny5dBS40O63ab+Od9t8HxvOdBkkdD69JyWqXJh0=; b=UGPXHDNDFac1nPq97pWdapoAuG1mM9mudHS+7EV6ilCTNLrz6K+/yMRsMnLawlGULF U5s0c2pd2Tqkp/69IXeYHTcQ9dJ+4NyiFHaa/QImAIb8qB7bTOi0K2unytLzS9DQPeMb 2zOqMvKou1IOJwJP/6vBp7ezPKlg7b+PI7ONr8iPtno69aXLnjzia2Qxn6YWLvu/L/Ds 5nbi7h4gLUgqANioWxaW9iZyUnF5n6GVn2uXHnGBIwsRAtZUlXYeGWj3+pE9z3Utv1gL 3WwCNSx3uSn4OsG56K6h3udcjzjiH+M2kUJbzjPGDPjmoexPnFKRX8mLDeLLfaMBHsSc 4ZxA==
X-Gm-Message-State: AOAM532It0nENpV5c8M4KUc8dnbJfpHegEuB+J0Q0qk6yGe1d2Mw9zud OJ/XLmlgn75tak9XRGjCuA96JWgpfMo=
X-Google-Smtp-Source: ABdhPJxrwmkw2LMwwxy0EE0N+LTDMCM8hHjWziTsfHW4V7CO4ZvXLtVCYHDo2lJ20nW9qfHbBhRrxQ==
X-Received: by 2002:ac8:4e50:: with SMTP id e16mr165222qtw.149.1590447430899;  Mon, 25 May 2020 15:57:10 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id o2sm16799837qtj.70.2020.05.25.15.57.10 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 15:57:10 -0700 (PDT)
To: rfced-future@iab.org
References:       
From: Michael StJohns 
Message-ID: 
Date: Mon, 25 May 2020 18:57:09 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------BA08499C33AEB56EE178B02B"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 22:57:14 -0000

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

On 5/25/2020 6:13 PM, Eric Rescorla wrote:
>
>
> On Mon, May 25, 2020 at 3:04 PM John R Levine  > wrote:
>
>     On Tue, 26 May 2020, Brian E Carpenter wrote:
>     > Let me challenge that with a question.
>     >
>     > What would really be better if RFC8200 was actually called
>     RFC1883.3?
>     >
>     > Or if RFC8446 was RFC2246.4?
>
>     Without a better way to do minor updates, I agree that changing
>     the names
>     isn't likely to make any difference.
>
>
> This is a really important point, and in fact it's a positive feedback 
> loop. Because everyone knows it is super-expensive to make version 
> N+1, making version N becomes really expensive as people try to make 
> it perfect. If it were easier to make small changes (especially 
> editorial ones) then we could make AUTH48 much faster because people 
> would know they could fix it later.

Um - wasn't that the point of the ID series?  (I actually know the 
answer - it was - it was specifically the reason that series was 
created).    There's always going to be the question of "what's an 
editorial change that doesn't require re-approval of the authors/WG 
chairs/WG/IESG?"  I'm not sure that this is an RFC Series Editor problem 
so much as it is perhaps a standards stream problem.

How would you differentiate between RFC9001 and RFC9001oops? Would 
RFC9001 just cease to exist?  Would there need to be some sort of 
rev/diff mechanism similar to GIT or SVN or Mecurial? Which version 
would the secretariat send out to the lawyers (I don't really care - but 
its a question that would need to be answered).

My take on this is that its probably as RFC 2026 revision that is needed 
to address your concerns and that's probably not directly tied to how 
the RFC editor is constituted.  That could come from a WG, or from a 
design team or even an IAB area.

Alternately, we can add this to the task list of things you want from 
the RFC Editor and figure out how to write SOW language that covers it.

I do understand there is a problem - what I'm not seeing are good 
proposals for resolving the problem.

Later, Mike



>
> -Ekr
>
>


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


  
    
  
  
    
On 5/25/2020 6:13 PM, Eric Rescorla
      wrote:

    

    

      
      

        


        

        

        

          
On Mon, May 25, 2020 at 3:04
            PM John R Levine <johnl@taugh.com> wrote:

          

          
On Tue, 26 May 2020,
            Brian E Carpenter wrote:

            > Let me challenge that with a question.

            >

            > What would really be better if RFC8200 was actually
            called RFC1883.3?

            >

            > Or if RFC8446 was RFC2246.4?

            

            Without a better way to do minor updates, I agree that
            changing the names 

            isn't likely to make any difference. 

          

          


          

          
This is a really important point, and in fact it's a
            positive feedback loop. Because everyone knows it is
            super-expensive to make version N+1, making version N
            becomes really expensive as people try to make it perfect.
            If it were easier to make small changes (especially
            editorial ones) then we could make AUTH48 much faster
            because people would know they could fix it later. 

          

        

      

    

    
Um - wasn't that the point of the ID series?  (I actually know
      the answer - it was - it was specifically the reason that series
      was created).    There's always going to be the question of
      "what's an editorial change that doesn't require re-approval of
      the authors/WG chairs/WG/IESG?"  I'm not sure that this is an RFC
      Series Editor problem so much as it is perhaps a standards stream
      problem.

    
How would you differentiate between RFC9001 and RFC9001oops?  
      Would RFC9001 just cease to exist?  Would there need to be some
      sort of rev/diff mechanism similar to GIT or SVN or Mecurial?
      Which version would the secretariat send out to the lawyers (I
      don't really care - but its a question that would need to be
      answered).   

    

    
My take on this is that its probably as RFC 2026 revision that is
      needed to address your concerns and that's probably not directly
      tied to how the RFC editor is constituted.  That could come from a
      WG, or from a design team or even an IAB area.

    

    
Alternately, we can add this to the task list of things you want
      from the RFC Editor and figure out how to write SOW language that
      covers it.

    
I do understand there is a problem - what I'm not seeing are good
      proposals for resolving the problem.

    
Later, Mike

    


    

    


    

    

      

        

          


          

          
-Ekr

          


          

        

      

      

      

    

    


    

  


--------------BA08499C33AEB56EE178B02B--


From nobody Mon May 25 16:04: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 06F0B3A0B30 for ; Mon, 25 May 2020 16:04:27 -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 9991G49CNQhw for ; Mon, 25 May 2020 16:04:25 -0700 (PDT)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 5AA7F3A0B29 for ; Mon, 25 May 2020 16:04:25 -0700 (PDT)
Received: by mail-qv1-xf2a.google.com with SMTP id l3so8654108qvo.7 for ; Mon, 25 May 2020 16:04:25 -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=5OnQTP5hk3U3LgB8yc5y6aGlMIvYWXzjBcYdsGtdAH4=; b=dk+8cy4GaL73szKt3fobrm3IkirUPPFmH5dfv9Z3oC9MFci5o2fWATzIsp6PT5Rws7 dV/2HCT+gLKMDwWkC9X8eK6eldNKUKNHhmJx7LhkIeOJkuR+dyzZ7e4gpEBjyjss6Km2 gwdw2+l4qGJx6J8bG2vgXTQm6DnL72GNAl6V4RKDRwMvp6UjTeBVUPMgNxo3sanAl1oE NSwfN58H73HKMRWNVlDAutwaie6uLgGK4irBUnhT02juYn+VmYaBUCsSi+p8CtwDvPLG sJgkw/miYXhz/48j4XkfpFJpp2/R1fxbqC9c1MEq8LpIyL5DsI0D9MgWD96L9WPLcSzR C/DA==
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=5OnQTP5hk3U3LgB8yc5y6aGlMIvYWXzjBcYdsGtdAH4=; b=ip9VMhK2gSCzkVRKeDKlnsqhV1kG4JJobVVeTVbEiw6hH1hHiDbD2eWQxyqKeQX9QN DaFg+4TmlUsPaXjkwZvKMl8MhjD9e7iEQyTr03V2HwkR2axeyJSTIdmX4DvVpmuptBLS WdgyA9CCcFMg4Xss4glSmMvqdxq0zNWTgEZz6OVoRZMsKpWiAN9Lie4GC21AqrkILSO1 Syj/ZaifuyaGWC6R+Ar5u0hhBa/yRcyBCbzMcO6gM+Dgkr9rQtK3yL5sFek4c1ZKkN+w N8sgL27tpS7oJkIxFmxYR+cWjvK1V0Z0QOk3CMr+UMWcTq+eipDYNtkZZj4jl19lCOsI qX1A==
X-Gm-Message-State: AOAM532fDPm1GjIB6W0EHN7iq5BXuDWXl2KWfdIoSFGwDfis4kzyUbnh XzRD1PS4etPFdsWB8r3AwHsLAkaqR14=
X-Google-Smtp-Source: ABdhPJyuUm9XN7vlYs7NIrPzs09FqcCxOgEifaF6G7bWKnYMmCxlmZEdtDojP6eSku1y6LU62gqaBw==
X-Received: by 2002:a0c:9141:: with SMTP id q59mr17303867qvq.58.1590447862934;  Mon, 25 May 2020 16:04:22 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id o31sm16953677qto.64.2020.05.25.16.04.22 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 16:04:22 -0700 (PDT)
To: rfced-future@iab.org
References:         
From: Michael StJohns 
Message-ID: <658b6564-9d0b-6c88-238d-9ef04b21678a@nthpermutation.com>
Date: Mon, 25 May 2020 19:04:21 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 23:04:27 -0000

On 5/25/2020 6:28 PM, Joel M. Halpern wrote:
> The efforts it took to produce the old Host Requirements and Router 
> Requirements RFCs reflect this.  (I suspect Fred Baker still has scars 
> from the later.)

Me too.

The arguments about whether a device with interfaces on two different 
networks was allowed to accept packets for an address tied to interface 
B but received on interface A were harrowing and painful.  Host 
requirements still holds the record as the longest sitting of a working 
group in one session (approx 9am to 2am with bathroom breaks and sending 
out for pizza).

> And the second is that actual packaging is not as trivial as it 
> looks.  Should we have a package for BGP, one for OSPF, one of IS-IS, 
> ..?  Or should we have one for VPNs, one for TE, one for ...?  Or 
> should we have a good indexing system that lets you ask the question 
> either way?

This turns out to be very complicated.   Using the example, trying to 
keep Host and Router requirements "pure" enough to not be interfering 
with each other was almost a sisyphean task.  And to be blunt, you're 
going to spend a lot more time that you anticipated ensuring consistency 
across the whole document set.

Later, Mike



From nobody Mon May 25 16:19: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 BAC623A0B48 for ; Mon, 25 May 2020 16:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=t8XyYB2W; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fQKuQQYF
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwLUtdGNbBQs for ; Mon, 25 May 2020 16:19:38 -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 DDA633A0B46 for ; Mon, 25 May 2020 16:19:37 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7D3CE5C0170; Mon, 25 May 2020 19:19:36 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 25 May 2020 19:19:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=m uM7k10y71xKFSG0Xg3I/sJ7cR4/a90Q0ZgmmeaD4/0=; b=t8XyYB2WyXt/Io4V1 NzJkVgHxv4DBtcKG5oT+ppkrJCE8AZY1YPAXpGf2B7ytvCktFOSEUckyLeTRHCTW r6+/gvUpcjfvHqdZIEAbfEQUiiMoSIpVqx2KKduL2R0f4lqyZzbDz0A1pBt/pNaK +G4BbpollIMJF1SqsVz+qBYnlpAHD0hBC437l951l0+mvBlwXmslwbt2RcLELdT+ KBDIzm79zjyNmupR7zeoprNHlR8bm9iA6iGfWPLFYfru1FaiagIwRBlpYHZnHcFa N5Pz5TplpzW6s4dibT7ON8f4EExxeI8RtHCbIiBSxT3IgljaXt6GGXKimH+1P75H 22pAg==
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=fm2; bh=muM7k10y71xKFSG0Xg3I/sJ7cR4/a90Q0ZgmmeaD4 /0=; b=fQKuQQYF0rex895OUaV1n9mnoGHHBmjVCbB5gmhF4NOxQ9z/5rcDSlzYh c1ey3kHTOUPB2BBTSnjCGfYFg4UnaMtNP0B5HT+9cQI8w5RJFOy2mUJhh7gHcjR8 IA1L8gQfD/YIImAwu5+SuqiO30Rp/etZdxs1PN4xJqAS72HU7XOO2f22LbnQcAND 2TOlk9O8tBBnOOh+6KByJ5/Uy8RosaqzCOR8tImgc5+tp7znYWqlSJLzk9x4vT8T qpBvKSA1fR6KBXMyNX9JgTp7xpF2fsPKybERrwMHn2u5gjLtci+iIpkv6UPxW6IK k9s96SSsyXyYu4JkMZwyiXvs5wOMw==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvuddgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 72496328005D; Mon, 25 May 2020 19:19:34 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: <20200525165200.D76EC199A58B@ary.qy>
Date: Tue, 26 May 2020 09:19:32 +1000
Cc: rfced-future@iab.org, Gondwana Bron 
Content-Transfer-Encoding: quoted-printable
Message-Id: <58E56141-3B74-4D7F-BF7A-ABF87B0F117F@mnot.net>
References: <20200525165200.D76EC199A58B@ary.qy>
To: John Levine 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 23:19:40 -0000

> On 26 May 2020, at 2:52 am, John Levine  wrote:
>=20
> I think the solution to that is don't appoint an RSE who is a jerk,
> rather than to try to invent meta-meta-rules for bad faith situations
> unlikely to arise in practice. We have had RSEs for decades and as far
> as I know filibustering has never been a problem.

Agreed. The best thing we can do here is to have clear guidance for both =
the RSE and the community about the nature of the role, so that =
expectations match.

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


From nobody Mon May 25 16:32: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 DE78B3A0B4C for ; Mon, 25 May 2020 16:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88d7a4_g2foS for ; Mon, 25 May 2020 16:32:16 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 2F2733A0B50 for ; Mon, 25 May 2020 16:32:16 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id u22so7905329plq.12 for ; Mon, 25 May 2020 16:32:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=3UfelKYHoOotVaBdLvubwnhDC6P07vI7gY3OrGC5eSQ=; b=InPiSHPW6SSXwlqsRMifOn4txZykwU/28R6XxoZwMgXoZlIadJlmvugP3YAUtJUnoN Iycl/SMyFlcCnwD9v+gxWgH8ThVOwBY8rQtJPPqsA09IANyuP1AXoKdmhGC6Yk6my5xx 8L1/BRmmZjsI65XFdkj9sxq9cwtcf9t2W/2xliVnUNsGzhSQcS0myAIWZdBnS7uSUUv2 vVfeFVw98rU2HpMKdHjpfe19KSOjXmVXwQG/TjkxxdHsnqU0SduLFZw/is0Mn3DCb2uR I4+wFBSk3O/uXvPY+DrV4ukX3E0BuP0Jh3aOrrblsLy119PLlcpN9RVottfx+tAI4v6H Xhqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=3UfelKYHoOotVaBdLvubwnhDC6P07vI7gY3OrGC5eSQ=; b=aVVUPr3za2SyL3HbXX2Yd4iK+U86mAuMEwe9DLAdyQDZlJFAvZNwXfGQXy8Rs7HwwF IRxoorrIIAF02Amcekft7w2YJX9ju2gi+ZOZX5mnVjTubsUjvqlNTxLjTNwoMM+A+riA ZmGz74R9QQcwzkeVXLD5OANcSPuGhgMD216kZLAGkHcdBmAwatgXlF3Bvlc/mikOD1Ww o7Gz55JnKyabcGjjK01kcXhV2pAyVgJkY3uPd0yFpTMUvoX5XA5nTxlyRqail6wI1TMF eq3YIqTCljS/lKnnW7E+TOe6R5f10Rn/7SeK8lI0fo2ZpQt7rEgwfNcfVKqxQBs0bpac CGtA==
X-Gm-Message-State: AOAM531Na2LDgKZr92cXXeGKnWjFCC/+nL/8239GOFbI0cvxbc90XJcl ZLOpVd9b7XO3fVk+OzVbibP520LpMheQdDQ=
X-Google-Smtp-Source: ABdhPJyFuq4lRBHwArmGl4P6VlQEzrTcot3mHFYwYxpXuta7CCdblStIsx2IGjRU06+Flx8u+TxU3A==
X-Received: by 2002:a17:902:8303:: with SMTP id bd3mr30751466plb.217.1590449534039;  Mon, 25 May 2020 16:32:14 -0700 (PDT)
Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id z20sm12431946pgv.52.2020.05.25.16.32.13 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 16:32:13 -0700 (PDT)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
Organization: http://SoftwareAndServices.NET
Message-ID: <18740cff-425c-f1cb-37d3-e3ea80bb343f@gmail.com>
Date: Mon, 25 May 2020 17:32:12 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
Content-Type: multipart/alternative; boundary="------------B0AB67B29774B01914A306D5"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2020 23:32:19 -0000

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

On 5/24/20 6:35 PM, Michael StJohns wrote:

  * I'd like some large measure of independence to be retained by this publication system and that the member's of that system voices are heard and honored as full partners and not "just a contractor[s]".

I have always seen them as hyper independent. As some cloud you tossed a draft to and hopped would rain the document back at you. I have been confused by their priorities and expectations. I trusted them. And I can't think of a failure. So that part, I think, should not change.

To these two:

  * I'd like a system that evolves over time, and that is relatively immune to influence from relatively few people over a relatively short period of time.

  * I'd really prefer that we don't have to do this again for another 10 years.

I have not tracked a specific draft through the process in a long time. I would think that transparency inside the process helps. Including why it is stalled would reduce the desire to change things from frustration or misinformation.

Influence - as in priorities? I would not think that the format of the documents would be at the whim of hidden people doing hidden communications.

In 10 years, I kinda hope some new awesome technology comes out and things have to get updated. Just because I like new tech.

-- 
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

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


  
    
  
  
    
On 5/24/20 6:35 PM, Michael StJohns
      wrote:
      
    
        
  • I'd like some
              large measure of independence to be retained by this
              publication system and that the member's of that system
              voices are heard and honored as full partners and not
              "just a contractor[s]".  
    
            
    • 
      

    

    
I have always seen them as hyper independent. As some cloud you
      tossed a draft to and hopped would rain the document back at you.
      I have been confused by their priorities and expectations. I
      trusted them. And I can't think of a failure. So that part, I
      think, should not change. 

    

    
To these two:

    

    
    
      
  • I'd like a system
            that evolves over time, and that is relatively immune to
            influence from relatively few people over a relatively short
            period of time. 
    
          
    • 
    

    
    
      
  • I'd really prefer
            that we don't have to do this again for another 10 years. 
    • 
    

    
I have not tracked a specific draft through the process in a long
      time. I would think that transparency inside the process helps.
      Including why it is stalled would reduce the desire to change
      things from frustration or misinformation. 

    

    
Influence - as in priorities? I would not think that the format
      of the documents would be at the whim of hidden people doing
      hidden communications. 

    

    
In 10 years, I kinda hope some new awesome technology comes out
      and things have to get updated. Just because I like new tech.

    
-- 

      Doug Royer - (http://DougRoyer.US)
      Douglas.Royer@gmail.com
      714-989-6135

  


--------------B0AB67B29774B01914A306D5--


From nobody Mon May 25 16:36: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 1A68F3A0B59 for ; Mon, 25 May 2020 16:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEFcAL15U2oO for ; Mon, 25 May 2020 16:36:08 -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 98BAB3A0B54 for ; Mon, 25 May 2020 16:36:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 97113BE39; Tue, 26 May 2020 00:36: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 fSm1Xc3u93rV; Tue, 26 May 2020 00:36:02 +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 5A23CBE2F; Tue, 26 May 2020 00:36:02 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1590449762; bh=g0xvJ8t+rXIpBKZvr+BaN/kaTvoCT3t+Vq85Dyzjbx0=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=s6xE58hFwtUm098J2QX+YXTxspVdnsf7HtW+iFl3jpTKwazaF7GTV42ygr4riXBhL BmZppEWN1qNmTQBamW2zInob+9mPeo8244tMw1t5KI7V+x1MR9Dud93ilZ+ilGTzEI YjU6j24ZsYguyUrSltYQ8efkfhTPiQO6jEKdvdtA=
To: Eric Rescorla 
Cc: John R Levine , 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: Tue, 26 May 2020 00:36:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wKVfhtTh68nS4eQWmiWgYb243IAJvQs6u"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 25 May 2020 23:36:11 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wKVfhtTh68nS4eQWmiWgYb243IAJvQs6u
Content-Type: multipart/mixed; boundary="pcERbMpw7b7PW2SKMu0oRIgcHCDbzIdsR";
 protected-headers="v1"
From: Stephen Farrell 
To: Eric Rescorla 
Cc: John R Levine , Rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] Why the RFC series is important
References: 
 
 
 
 
 
 
 
 
In-Reply-To: 

--pcERbMpw7b7PW2SKMu0oRIgcHCDbzIdsR
Content-Type: multipart/mixed;
 boundary="------------3222842EF59DE86F8A0A793B"
Content-Language: en-US

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


Hiya,

On 25/05/2020 23:54, Eric Rescorla wrote:
> Well, it's not the only place, but for instance TLS 1.3 spent 2 months =
in
> AUTH48 in part because we felt we had to go through every word.

Well, that's vs. 4 years in the WG though. [1] TLSv1.3
was important and tricky enough that I can easily see 2
(or even 3) of those years really being needed in that
case, but nonetheless the significant delays (and blockages
to doing minor updates) are in the WGs, be those justified
delays or not.

IESG, RFC editor queue and auth-48 delays are annoying
as hell after you've already jumped through a crap-load
of hoops, but they still aren't where we see the bigger
delays. And I'm not at all sure elapsed time is what
causes it to be too hard to do minor updates.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/rfc8446/

--------------3222842EF59DE86F8A0A793B
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-----

--------------3222842EF59DE86F8A0A793B--

--pcERbMpw7b7PW2SKMu0oRIgcHCDbzIdsR--

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

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

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7MVmAACgkQWrL68XsX
K+r7jBAAvDRT3ZWTM7vopFY1Qa1IU+8f/7YFTRy0UP77y7sm2EuqeiqzRM/PM1v8
Hmh0w9lT5TonqG38bIobI7cDMh7Pu6yfFC6pJlzbmPVhlOAz2/ql9NwgiMnEFwy3
ZmcWi4D/IWW09y5FVqNGIhsAZaISCTUEQdepHLdX/8sWt40iD/pc0imvvW70HjfM
MymU2hVqrWsVznnZU1r88k96FLQJhnZaHBhpn5ZLapHkcF4PAP54DXBFL09y4aid
9lLPqvhYcChaLOIEOF3LVopFHNTz0ADB45vA2wOOyaE0Zw+E2V+pbgk1+tLEpD3x
qav4uP1aXH5QTSOp+arHWiNDeCUXXItD3/8HwxXDwO55lsOxiGCgcVyXycTC+Dkv
fjzkZxSssq2B1Ofw7WYXfu1LbNUgIModPmJuNXKSU6tE67g5g8RAaLZsXCt9aJ5n
TKSyqGX1Iqa9pu/UYP5qpQI4HIYcilI1y+IGpzsTeIeyuPUZGLJfBtoF5v+iSN9n
axo4G8Pl02bokl3RtTKrHp5BWMaPa6lIX98aaFgt5uZcVn/luCQSY3RrTmBhXBZQ
0hVeuzG3UOcoGlRbjNcbdArDetAFupugEjGUzMrhh51RdqqdnUU+HEsq0Rs6HrEh
rJEU6IJVpynpBdfW4vE51F5JXnFaTNa4zc7bnuRs+44z2HPA2FU=
=mV72
-----END PGP SIGNATURE-----

--wKVfhtTh68nS4eQWmiWgYb243IAJvQs6u--


From nobody Mon May 25 17:05: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 DA79E3A03F2 for ; Mon, 25 May 2020 17:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 RV7HU9SD5xRV for ; Mon, 25 May 2020 17:05:31 -0700 (PDT)
Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 162C23A03FE for ; Mon, 25 May 2020 17:05:31 -0700 (PDT)
Received: by mail-pg1-x544.google.com with SMTP id t11so9206865pgg.2 for ; Mon, 25 May 2020 17:05:31 -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=3roC/hdLn/9pI2jHQVbjT3woKjoa8nQb+ApWsMmPEoU=; b=lKCTEH0temywuHisw6tW7l/LUISh3S8XMbSwd0H7h3wQdOyqcVMSMjvl9bQvZZlLwk Lj1xFRaLEmQSBSQQiTBa5hZlSs4n/DAxjhT8kF87hTU4/Yqwr9qYMRoBk4Qcj9m9ZPpx RsvQI3PMcopQ2XsPZP39bblpJnOG1j3zVJQY9PDYulIUFuXG3VuA/nq7qYP58SE76i7g HgrCQYWivuXypluQ8DnnhNEguaGmnTRcjHYl51EADJU3/fSBDik8btTde2HCVzqmLX67 U3WIifpubpQYEnakff9iHxfnxDld/1ABSEQPHrbMYAt6agjyQU3eTLOpWarTBpBoSODf Afew==
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=3roC/hdLn/9pI2jHQVbjT3woKjoa8nQb+ApWsMmPEoU=; b=THDlW60sQjuZymeFS1PfTP3OFh0/+GIUNQPawiXBV05gfPtyzfUNlapaF8F6+HFiIP Hdq/qjkMaqZ6x2nYbWKUL4V38s1QLA4HauNVbLGeVQDGQBjdJkgxq8dbyFfki5uHmdCS sHENOsdCuw4100ptztTEuVEMEv8W+8QN8gmP5KiofS33Mm/h1zZSFuaxKo51QHp5u2Sx YXbCKGpQp30W57RXqxVw4ExtTx77GNbDjybS0wGw+LzT7toB4w0QcZNQhQ2+WSoWTD5M vqkaGeVdDukkg32Exk9GvpNOfKLFenJ/QTSytOuPSZV6q3JIOS6a2TjBSnue5Vv0hDIp tS9Q==
X-Gm-Message-State: AOAM531qOOltHn6r3o7+HJ5eWaGXqjyZoHHz0dnE7h3/bFE9DxAqNd5P 2BMTalyjGin+hcYUojLGat3+wHfh
X-Google-Smtp-Source: ABdhPJxO8NBpzNANEL62FnQ2iwIJLY5HJbV48umCFiczi4X6E3ekMoqgvw0bJojCUxc/XUzfER+iew==
X-Received: by 2002:a63:4911:: with SMTP id w17mr28398817pga.13.1590451529321;  Mon, 25 May 2020 17:05:29 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id bu7sm12615145pjb.41.2020.05.25.17.05.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 17:05:28 -0700 (PDT)
To: Michael StJohns , rfced-future@iab.org
References:          <658b6564-9d0b-6c88-238d-9ef04b21678a@nthpermutation.com>
From: Brian E Carpenter 
Message-ID: 
Date: Tue, 26 May 2020 12:05:23 +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: <658b6564-9d0b-6c88-238d-9ef04b21678a@nthpermutation.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 00:05:35 -0000

On 26-May-20 11:04, Michael StJohns wrote:
> On 5/25/2020 6:28 PM, Joel M. Halpern wrote:
>> The efforts it took to produce the old Host Requirements and Router=20
>> Requirements RFCs reflect this.=C2=A0 (I suspect Fred Baker still has =
scars=20
>> from the later.)
>=20
> Me too.

Although not comparable with that, IPv6 Node Requirements has been a
saga too. RFC4294 -> RFC6434 -> RFC8504, all of which were out of date
soon after publication.

Also not comparable, https://www.ietf.org/standards/process/informal/
is the direct result of an attempt back in 2005 to catalogue IETF process=

documents in one place. Also almost instantly out of date after every
update.

I do want to reiterate: this is a known problem that the IETF has
carefully ducked for many years.

   Brian

>=20
> The arguments about whether a device with interfaces on two different=20
> networks was allowed to accept packets for an address tied to interface=
=20
> B but received on interface A were harrowing and painful.=C2=A0 Host=20
> requirements still holds the record as the longest sitting of a working=
=20
> group in one session (approx 9am to 2am with bathroom breaks and sendin=
g=20
> out for pizza).
>=20
>> And the second is that actual packaging is not as trivial as it=20
>> looks.=C2=A0 Should we have a package for BGP, one for OSPF, one of IS=
-IS,=20
>> ..?=C2=A0 Or should we have one for VPNs, one for TE, one for ...?=C2=A0=
 Or=20
>> should we have a good indexing system that lets you ask the question=20
>> either way?
>=20
> This turns out to be very complicated.=C2=A0=C2=A0 Using the example, t=
rying to=20
> keep Host and Router requirements "pure" enough to not be interfering=20
> with each other was almost a sisyphean task.=C2=A0 And to be blunt, you=
're=20
> going to spend a lot more time that you anticipated ensuring consistenc=
y=20
> across the whole document set.
>=20
> Later, Mike
>=20
>=20


From nobody Mon May 25 17:16: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 C9F793A045B for ; Mon, 25 May 2020 17:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY36KgDd5jn4 for ; Mon, 25 May 2020 17:16:42 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 B71083A0437 for ; Mon, 25 May 2020 17:16:41 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id n5so1598579wmd.0 for ; Mon, 25 May 2020 17:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rfP6KJgPl0LWrrh8UC8ePASs30uW4KtSCsGUPCsQWpA=; b=l+dYva8V3G14DOOWB5TqFj43/XqHCW9kON5+2rwrt4aIc21CXEhayoixVCwJcxKcQF XMzFl0wJUjLkbrRSvC3BW75QOtA5tAFdVEWZPMhNc3rDYWqOEXbjssEu726QvLDnTor1 VILEwwo4Kt6kLzcH3uVTNGHQ+j2QtckuG785TaeHNanNGHVhb4UYD86dvrncQufonWXC 3yxdLZ078l8tSDrbzj5opqTGF2Y3FyWF1HQA2bBxLRfpuAPg1qLTaoGPIo/ZWlVX+UV5 Xb/FLdlJQOJnQ1PcGSeJufgJUPjxO60ojOTiJMJcHWd14RJus4+cx+t5DK0tpETpV8M0 BJ3A==
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=rfP6KJgPl0LWrrh8UC8ePASs30uW4KtSCsGUPCsQWpA=; b=MFvHweJMFSQLaI+o+BRa1rdXivaNeAXQifauAEz5Z1tXHO8M/0+lKPL0ZgP9BRjjJX A9fhTLFJW9/cuQmTJ7Rs8uDcTdkQucTeyW9Nn5Ta75I2dpCgZBG7SgJnsIencAgWmNwH tuz3tlzFlMhcyOLDGzNgxTgIjg11CEpg+RAb2p9VIT1Jokw0WaRPBkCNFb7IzfEm9awi U5Jtg3NnYyxGQj2cFOULG1OkUafuVCab77CHH2gnspB8nL+Z4v/EGX2JZkzCKcMZKFps +AQLPz8ucL7wdZ3Ja/1ZEyISjZcx09JZUV02rF1OoO1Mny03nC1IUyrF/KrHifsQfMO9 mgOw==
X-Gm-Message-State: AOAM533wb72mXLxWdKpoo9aFDmCitQ2cayl5lxXc5kncywpuqXPa/roV Xmhe3G8pyBrCVLRlp2R1nb8=
X-Google-Smtp-Source: ABdhPJyVasala1AmOC1Sn4GYqdb7dsrDAtQsN4F4uYvXblGZD1aZREzc9VqO8DTcmeiPMyvmSP//nA==
X-Received: by 2002:a7b:caf2:: with SMTP id t18mr26780884wml.35.1590452199860;  Mon, 25 May 2020 17:16:39 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:9c6b:8767:8b3b:7b48? ([2601:647:5a00:ef0b:9c6b:8767:8b3b:7b48]) by smtp.gmail.com with ESMTPSA id s2sm6150762wmh.11.2020.05.25.17.16.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 17:16:39 -0700 (PDT)
From: Bob Hinden 
Message-Id: <109220B3-C32D-4617-8930-4AF20BB4C6A1@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_1183A177-FE9F-44EE-ABA4-5C2E05480996"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Mon, 25 May 2020 17:16:30 -0700
In-Reply-To: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
Cc: Bob Hinden , rfced-future@iab.org
To: Michael StJohns 
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 00:16:48 -0000

--Apple-Mail=_1183A177-FE9F-44EE-ABA4-5C2E05480996
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mike,

Overall I like your proposal for RFC Series editorial board (RSEB).  It =
would be a nice replacement for the current IAB/RSOC structure.

I am not too troubled by the RSEB approving non-publication as it would =
have to be a very extenuating situation for that to happen and given the =
makeup of the group.

Bob



> On May 24, 2020, at 5:35 PM, Michael StJohns  =
wrote:
>=20
> Hi - Elliot asked me to write my thought on what elements I might want =
from the outcome of this process - ideally as a delta to the current =
system.   It took me a while to go through the existing documents to get =
an idea of the written baseline.  RFC8728 and RFC8729 mainly.  I found =
myself in agreement with quite a large portion of those documents, =
especially with respect to the actual RFC Series Editor and RPC roles.  =
What I found myself less sanguine with were the various sections that =
dealt with "oversight".  To be blunt, I believe that having either the =
IAB or IESG directly manage other resources  or contracts is not =
tenable.  The criteria of "able to manage a contract or employee" is not =
and has never been a criteria for selection of either an IESG or IAB =
member and the delegation of that responsibility to the RSOC does not =
appear to have been successful.
>=20
> 	=E2=80=A2 My general desire is to see an RFC publication system  =
that retains and perhaps expands its global impact and the generally =
wide respect for its quality and reach.
> 	=E2=80=A2 I'd like the people who make up the system to be =
professionals with the ability to continue to help this community =
publish a wide range of documents that help "make the Internet work =
better by ... influenc[ing] the way people design, use, and manage the =
Internet".
> 	=E2=80=A2 I'd like us to treat said professionals at least as =
well as we treat ourselves.
> 	=E2=80=A2 I'd like a system that evolves over time, and that is =
relatively immune to influence from relatively few people over a =
relatively short period of time.
> 	=E2=80=A2 I'd like a system that's responsible and accountable =
to the community directly rather than through the two layers of =
indirection we currently have.
> 	=E2=80=A2 I'd like some large measure of independence to be =
retained by this publication system and that the member's of that system =
voices are heard and honored as full partners and not "just a =
contractor[s]".
> 	=E2=80=A2 I'd like the RFC publication system to be stable in =
the face of unforeseen challenges and be able to gain (or regain) and =
retain institutional memory.
> 	=E2=80=A2 I'd really prefer that we don't have to do this again =
for another 10 years.
> 	=E2=80=A2 I'd also prefer that once we have an RSE, we assume we =
keep them (after a probationary period) until they get tired of us, or =
they really mess up.
> Those are my desires and I could stop there.   But I though I'd =
provide a sketch of how things might be restructured - this is provided =
not as a fleshed out proposal, but as a thought experiment to show that =
I think it's possible to have both independence and accountability:
>=20
>=20
>=20
> ___________________________________
>=20
> The oversight for the RFC Publication System shall vest in an RFC =
Series editorial board (RSEB) consisting of 4 at large members selected =
through the Nomcom process for staggered 4 year terms (with a maximum of =
1 renewal) plus the RSE as the chair, plus the Stream managers (who must =
not be the chair of the particular board that appoints them).  The =
senior at-large member is the deputy chair and acts as chair in any =
matter in which the RSE is recused or not available.  The RSEB shall act =
by voting, but shall try to achieve consensus.
>=20
> The RPC shall appoint a non-voting observer to the RSEB.    The RSEB =
may select an Executive Director or secretary for the RSEB.
>=20
> The RSE may recommend that any document not be published and with a =
majority vote by the RSEB prohibit publication.   This shall generally =
be a last resort after negotiation with the publication stream over =
perceived problems.
>=20
> The RSEB (minus the RSE) is the search committee for new RSEs.  They =
make the hiring recommendation to the LLC board.
>=20
> The at-large members are selected for their experience in the IETF and =
their experience with publication systems with the latter given more =
weight.  They are selected through the normal Nomcom process, and =
approved by the LLC.
>=20
> The at-large members must approve the ISE (who is nominated by the =
IAB).  Tie votes are broken by the RSE.
>=20
> The stream managers for the IAB, IRTF and IESG(Standards) represent =
the groups that they come from, and are expected to consult with them on =
any non-routine matters.  They are reappointed each year as their =
respective bodies reform after the Nomcom process.
>=20
> Each stream manager (including the ISE) shall provide a PUBLIC annual =
assessment of at least a page of how the RSE/RFC publication system is =
meeting or not meeting their needs.
>=20
> The RSE shall provide an annual public report of the numbers and types =
of problems corrected on submitted documents.  This report shall be =
broken down by stream and shall be used to identify remedial actions for =
the production of documents from each stream.
>=20
> The RSEB will consider the public assessments and provide a PUBLIC =
annual response approved by a majority of the board.
>=20
> The RSEB (minus the RSE) will make a private recommendation to the LLC =
not later than 6 months prior to contract renewal (if the RSE is a =
contractor) or not more often than every 2 years (if an employee) on the =
continuance of the RSE.  The recommendation must be approved by the =
majority of the RSEB but may contain additional comments by any member =
for or against the recommendation and identified as originating from =
them.  If the RSEB is unable to approve the report due to a lack of a =
majority, the report shall be forwarded without the recommendation but =
with any individual commentary. If the recommendation is for termination =
or non-renewal, the LLC shall share a redacted summary of the =
recommendation including any vote counts to the RSE, but not the actual =
positions taken by any member of the board.  The RSE is allowed to make =
a public or a private statement to the LLC with respect to the =
recommendation.
>=20
> The LLC is the hiring entity for the RSE and bears all =
responsibilities normally attributed to a hiring entity.  The LLC is =
solely responsible for accepting or rejecting the recommendation of the =
RSEB with respect to the hiring or continuation of the RSE.   The LLC =
must make its own evaluation of the RSE performance rather than rely on =
the RSEB recommendation.
>=20
> The RSEB by a 3/4 vote and with concurrence of the LLC (who must sign =
off on any costs) may add or remove streams.  Streams may be proposed by =
any entity in the form of an Informational RFC on the Independent =
stream.
>=20
> Documents that touch on the RSE or RFC Publication System models shall =
be published after a community wide last call and with the majority =
approval of the RSEB.  Any document that changes the roles or =
responsibilities of the RSE or RPC which would require contract or job =
description changes also requires approval of the LLC.
>=20
> ____________________
>=20
> As you may guess, the above is mostly to fix what I perceive is a =
problem with the IAB and RSOC oversight of the RFC series.   You may =
have other ideas or may hate mine.   Feel free to take exception to the =
broad strokes or propose your own, but for now let's try and avoid =
twiddling the fine points (e.g. "I really think there should be 3 at =
large members" would be twiddling the fine points).
>=20
> Later, Mike
>=20
>=20
>=20
>=20
>=20
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


--Apple-Mail=_1183A177-FE9F-44EE-ABA4-5C2E05480996
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl7MX94ACgkQrut0EXfn
u6jAGgf/dcQOiN0axwMlORl7SJskW7Kz0VAbtPQN+rgdUSKAwb7j+A/4PhC86KSX
8m2Obio6ya1OdPQ9qZTeo2CjE1EGII20uHc03dLB7vbUUo/zEtAS5zqdEL1GPeT+
GvHltBepGY+kjreRQcGp1Ni9d9SIF73Hi4Yk5+ub9LeIhXHGN2j+/9TyiGCVahIE
QvnBg+eAp8j4sF4jtjThAawIceT2IOeCJzm2YBlVjwJFj48G3dlapETB/OaHdKKQ
Z/wrToo4G4uJvHBa+/0ZODJG9jmLab85LChJTB8mYxGrIntS8dN3VPo/w8i7r/yA
OQjFWPgh0km1j1TokvUFlC94IvK+cQ==
=MD47
-----END PGP SIGNATURE-----

--Apple-Mail=_1183A177-FE9F-44EE-ABA4-5C2E05480996--


From nobody Mon May 25 17:22: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 4E3F33A05A4 for ; Mon, 25 May 2020 17:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ZPyDFTcU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zvHaClxc
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBcHqnEUDSrW for ; Mon, 25 May 2020 17:22:38 -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 3854E3A05A0 for ; Mon, 25 May 2020 17:22:38 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5AC705C0048 for ; Mon, 25 May 2020 20:22:37 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 25 May 2020 20:22:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=Plcmm58V+3BKqE1HtVtLqrJg1PD8Xtg M43CaqiPcRaw=; b=ZPyDFTcUcgMgmaHJFuyYXwC9RfT0krBdaXGzzsynAIiTtMd 7TTOhi2Vz3kq+UbAQQJf0sNptUJt2lILhSTE6rIgBl0ou8vsUatxuLb7DDiTMphT 49ert7/hYWdojx4T6FFNYPASLO1mNjXPBFP0L3PM09aB3LZnDmxjUfn/YCP9TgWE Trsvp2ikPRxscNGIrunMjwstVaTWXBj9I2jgZmKFazgey3sW1qmpmbPZC7XzsQ2y 6+Z2iqrA4IjSgfLIElvUnA449svyfOSqhS4Wc/MBYg5ZQoCVeOMPn5ppXPWGTohh a6urCni6cR0u8Z8+fGzVUMnChm0rcSxZEksZ7Fw==
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=fm2; bh=Plcmm5 8V+3BKqE1HtVtLqrJg1PD8XtgM43CaqiPcRaw=; b=zvHaClxc3acA8avh7KGCeL IsQT3xHXlZNydtGsKFqy3UvsaAbFaTfNjEzBA/3wW+APtuldLqY/DC/yu42Y5hmB n9PqgDxdWg9h7GpzSsKMFWsJRWgsP5jKXQ5iMeHMoX6koytAMp2259Uk1KtMuLSv rDpG5i3uW1t6zcdfuKGQNgOOod79cicS1lNRplH18R9oJ5gycsaTGPR/mD8aQN98 hUgTASxvUrecaDCHFPnZaicynL6sECImmxFnCxB5SgGbZlGh/JDuU/eTML+xNzmA LghTJ9HoXSxddmW+kp84Wm9rfw9azXDyCp4Un2RIysbDHQHkkyMEOVdGK3shTqDw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvuddgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D4AABE00B0; Mon, 25 May 2020 20:22:36 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-488-g9249dd4-fm-20200522.001-g9249dd48
Mime-Version: 1.0
Message-Id: <3c04035a-ff04-4669-bea1-6f0eda5b8c46@www.fastmail.com>
In-Reply-To: 
References:        
Date: Tue, 26 May 2020 10:22:17 +1000
From: "Martin Thomson" 
To: rfced-future@iab.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 00:22:42 -0000

On Tue, May 26, 2020, at 08:57, Michael StJohns wrote:
> My take on this is that its probably as RFC 2026 revision that is 
> needed to address your concerns and that's probably not directly tied 
> to how the RFC editor is constituted. That could come from a WG, or 
> from a design team or even an IAB area.

I can see why it is appealing to say that this is a problem for the streams.

But part of evolution of the series means adapting to the needs of its consumers.  Maybe that means a little bit of a concession toward making it easier/better/etc... for the primary source of RFCs to produce RFCs.

To me, it is clear that the structural constraints imposed by the RFC series - such as immutability - has had a material effect on the way that the inputs to the system are produced.  And of course this is intimately tied up with the choices the IETF makes with respect to things like the stages on the standards track and whatnot.

It is also linked to the way that the formality of the IESG process has evolved over time.

The methods of production for documents also are tied into this.  Those too have changed considerably.

My reading of this is that we do agree that there is a problem here.  What seems in contention is whether the RFC series needs to care; and whether the RFC series might need to be part of any solution.  It is maybe true that some of the problem lies outside of the charter of this group, but I don't think we get to ignore that in the hopes that things will improve by doing so.


From nobody Mon May 25 17:23: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 2FDA13A05A4 for ; Mon, 25 May 2020 17:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJdBsVJCbmXL for ; Mon, 25 May 2020 17:23:32 -0700 (PDT)
Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (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 09B753A05A0 for ; Mon, 25 May 2020 17:23:32 -0700 (PDT)
Received: by mail-pj1-x1042.google.com with SMTP id ci23so479893pjb.5 for ; Mon, 25 May 2020 17:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=KD5UDrztOFBSyfjZs/Y6acn3GiEC3XEka3rOHTrpAN0=; b=WL/j66LOVi+REbehp/7l0MkLyWr1fwt3Lgn1GiLuD5Yf/4a6Hs/rovk8mmrgjhx1q2 fG2W7PYWoVRTEMLMie+KNvF/pmDKv0eHn1LbZlp18yxermQ/AHH6VEB76brvLZAQRDCm S8auyZzdK65I9crwkZO95FqEX//dG2Dc9SPDO832DnXquGEOiS9zqiNzIMnsGs7YicZp XsqkWUXqYQzZouSDQApo0ewmywXUkaolkHEHk+r7bOoDuptHJ4t/AqtruiimUzUdON/i bIXHULQz0s7zIOb33s1yzf+mHfq/y7+Ve38miuKB/hsx2rg/GIFbO84ANN+V2fDBk+kL D6FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=KD5UDrztOFBSyfjZs/Y6acn3GiEC3XEka3rOHTrpAN0=; b=NHe+dVghcbW2jqCuAe6CLvEl/1ZoFC0IDNmWYLRPkW+wYNlj+1NdMXEsTbVjGj8lXU xcLVLXFa+qc5HMKokhRctx9/ByRtjvm/EsC3wTp3BfkrTit6whrB56+Kt2w12/X8awL7 snaY/HEZDmUV029NS1F0rzS6RI4uycSlMaqvLffJPYHWURj848GcxG5YofV8bysVnnjk TbRWDrn4r47dacebk2SNPJPzNgHn83H8MsvmwvBG7PGDj0i6snYE4K1ioOJiABVJXZBG fYLgnPDv52qQzHxZWC5+XVgm52eq3nmBfkkfIV8rMmL1Y60WXgPQHZlSeyJ6P0s6mi9H oLwg==
X-Gm-Message-State: AOAM531zxZzqhvdmq/JdwzxjjmRKrfyMCJqJwcVPU8YEConrH9xejwWa OMxNtM44L6FdquPQmy3/uwIrwaYAKm7JmfE=
X-Google-Smtp-Source: ABdhPJzzVdS4McJe9dFw3e3e5cEsPfPHdz3fdHERxcg4FS17mJLlO15IHyl9aC+jChwSJ3pcP0O79A==
X-Received: by 2002:a17:90a:d317:: with SMTP id p23mr23938649pju.107.1590452610822;  Mon, 25 May 2020 17:23:30 -0700 (PDT)
Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id y18sm13862435pfr.100.2020.05.25.17.23.29 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 17:23:30 -0700 (PDT)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: rfced-future@iab.org
References: 
Organization: http://SoftwareAndServices.NET
Message-ID: <2507455b-a835-52fc-76e5-917ab2070288@gmail.com>
Date: Mon, 25 May 2020 18:23:29 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------924636FD3C3B48E4A68E848E"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 00:23:34 -0000

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


YES! Not sure how much of this is in scope for this group... maybe my head is in the cloud...

And I would, as mostly an observer and user of the RFC's, it almost appears to me that many are released as theoretical exercises in possibilities, or to get the paper published. I have also wondered if some that author documents that are part of complex sets to go out of their way to keep the clear path to implementations obscure. Why not copy/paste unchanged text from "updates" RFC's? Many do not look like "updates", they look like "replaces except random paragraphs referred to in the most obscure way possible"

For references that are required and separate from the draft specifics, provide a URL to a persistent reference page. Example, rather than referencing TLS RFC #xyz, it would say say something like, https://ietf.org/protocol/TLS/latest.html that points to the latest accepted RFC. I personally do not want to have to become an expert in what the best or deprecated TLS encryption is in order to say "use it". I would think this would reduce both author and editing check times and errors. (My code just links to the latest released lib-openssl, whatever it has, and I do not compare it to TLS RFC's).

I would also like to see "Standards Track" renamed to "Proposal". Until adopted as a standard. I think the word "standard" confuses many. Especially with the complex sets.

I would like each RFC release to be required to include in the document a URL to a persistent page for errata, updates, and updated.  That page would be updated by the authors of the RFC and WG's and a requirement for publication. And they would be required to update the RFC related page with sufficient information to redirect them to the new document. Then the RFC would be persistent and immutable. And people could track the history and latest, whichever they needed.

It would include interrelationship diagrams or descriptions on how they relate, conflict, complement, or compete with other already released RFC's as a separate living document at the time the RFC was published. And could be updated by a similar RFC/WG/individual process. To be updated by errata or the release of related RFC's. I would like this to be a requirement for publication. I am not talking about extending the references. Provide a persistent link, released inside the document. That when looked at, give the entire list on one external page. It should not be hard for authors that are aware of the interrelationships at the time of release to produce that information.

Eliminate, when possible text and references like "foo: like used in RFC-#old paragraph 16.3" when a copy/paste would work. Reduces the documents that need to be read.

On 5/25/20 2:42 PM, John R Levine wrote:
> The RFC series is two things: it's a stable archival set of documents about the technology and history of the Internet, and it's where you find Internet standards and related specs like BCPs. For the vast majority of people likely to look at RFCs, the latter aspect is what matters. If we were just publishing a series of historical papers, that would be fine but there's no way it would merit the amount we spend editing and publishing RFCs.
>
> The problem is that the RFC series does a lousy job of publishing technical specs. If someone wants to write an SMTP server or a DNS server, there's a long list of RFCs that overlap and rewrite each other, there's a zillion errata not part of the RFCs that you need to know to look for and see if they matter, and there is a great deal of folklore to know which RFCs are important and which you can ignore. (For example, RFC 3865 defines an SMTP extension that we knew nobody would ever use other than to make a political point.)
>
> I believe there were two key reasons our specs have succeeded: one is that they do work if you can figure them out, and the other is that unlike most other SDOs we have always given them away for free.  Open access is now increasingly common, so it would be a good idea to make them easier to use or at the least easier to find the ones you need.
>
> I am not proposing specific changes other than to say that the model of RFCs solely as independent immutable documents no longer makes sense. While I do not suggest we go to WHATWG style living documents, I do think that for our specifications we need to find a more modern way to collect the material into a small number of places with stable names (perhaps using version numbers like everyone else does), and to make discrete low cost updates as we find errors or make partial updates.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>

-- 
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

--------------924636FD3C3B48E4A68E848E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
YES! Not sure how much of this is in
      scope for this group... maybe my head is in the cloud...

    

    


    

    
And I would, as mostly an observer and
      user of the RFC's, it almost appears to me that many are released
      as theoretical exercises in possibilities, or to get the paper
      published. I have also wondered if some that author documents that
      are part of complex sets to go out of their way to keep the clear
      path to implementations obscure. Why not copy/paste unchanged text
      from "updates" RFC's? Many do not look like "updates", they look
      like "replaces except random paragraphs referred to in the most
      obscure way possible"

    


    

    
For references that are required and
      separate from the draft specifics, provide a URL to a persistent
      reference page. Example, rather than referencing TLS RFC #xyz, it
      would say say something like,
      https://ietf.org/protocol/TLS/latest.html that points to the
      latest accepted RFC. I personally do not want to have to become an
      expert in what the best or deprecated TLS encryption is in order
      to say "use it". I would think this would reduce both author and
      editing check times and errors. (My code just links to the latest
      released lib-openssl, whatever it has, and I do not compare it to
      TLS RFC's).

    

    


    

    
I would also like to see "Standards
      Track" renamed to "Proposal". Until adopted as a standard. I think
      the word "standard" confuses many. Especially with the complex
      sets. 

    

    


    

    
I would like each RFC release to be
      required to include in the document a URL to a persistent page for
      errata, updates, and updated.  That page would be updated by the
      authors of the RFC and WG's and a requirement for publication. And
      they would be required to update the RFC related page with
      sufficient information to redirect them to the new document. Then
      the RFC would be persistent and immutable. And people could track
      the history and latest, whichever they needed.

    

    


    

    
It would include interrelationship
      diagrams or descriptions on how they relate, conflict, complement,
      or compete with other already released RFC's as a separate living
      document at the time the RFC was published. And could be updated
      by a similar RFC/WG/individual process. To be updated by errata or
      the release of related RFC's. I would like this to be a
      requirement for publication. I am not talking about extending the
      references. Provide a persistent link, released inside the
      document. That when looked at, give the entire list on one
      external page. It should not be hard for authors that are aware of
      the interrelationships at the time of release to produce that
      information.

    


    

    
Eliminate, when possible text and
      references like "foo: like used in RFC-#old paragraph 16.3" when a
      copy/paste would work. Reduces the documents that need to be read.

    

    

    
On 5/25/20 2:42 PM, John R Levine
      wrote:

    

    
The RFC
      series is two things: it's a stable archival set of documents
      about the technology and history of the Internet, and it's where
      you find Internet standards and related specs like BCPs. For the
      vast majority of people likely to look at RFCs, the latter aspect
      is what matters. If we were just publishing a series of historical
      papers, that would be fine but there's no way it would merit the
      amount we spend editing and publishing RFCs.
      

      

      The problem is that the RFC series does a lousy job of publishing
      technical specs. If someone wants to write an SMTP server or a DNS
      server, there's a long list of RFCs that overlap and rewrite each
      other, there's a zillion errata not part of the RFCs that you need
      to know to look for and see if they matter, and there is a great
      deal of folklore to know which RFCs are important and which you
      can ignore. (For example, RFC 3865 defines an SMTP extension that
      we knew nobody would ever use other than to make a political
      point.)
      

      

      I believe there were two key reasons our specs have succeeded: one
      is that they do work if you can figure them out, and the other is
      that unlike most other SDOs we have always given them away for
      free.  Open access is now increasingly common, so it would be a
      good idea to make them easier to use or at the least easier to
      find the ones you need.
      

      

      I am not proposing specific changes other than to say that the
      model of RFCs solely as independent immutable documents no longer
      makes sense. While I do not suggest we go to WHATWG style living
      documents, I do think that for our specifications we need to find
      a more modern way to collect the material into a small number of
      places with stable names (perhaps using version numbers like
      everyone else does), and to make discrete low cost updates as we
      find errors or make partial updates.
      

      

      Regards,
      

      John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
      

      Please consider the environment before reading this e-mail.
      https://jl.ly
      

      

    

    


    

    
-- 

      Doug Royer - (http://DougRoyer.US)
      Douglas.Royer@gmail.com
      714-989-6135

  


--------------924636FD3C3B48E4A68E848E--


From nobody Mon May 25 17:31:40 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B870E3A0801 for ; Mon, 25 May 2020 17:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfAQ6xr5cden for ; Mon, 25 May 2020 17:30:57 -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 58F683A07C3 for ; Mon, 25 May 2020 17:30:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49WFHj1VMdz6GD9V; Mon, 25 May 2020 17:30:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590453057; bh=rZOmNf550PbutEcgq/g/y3nS4C8E8Rw1QaU2yLCt6G8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=M9C7D6GbsJe2SuiFVw9hOG1iub26fl/Rf0KE9PbLsB4ELIvPrESORZTDosiPQNYEV aQhzCWAmpgcS6jWOufKSuWwJFkoLorNMvyuwkfwmGsEcC1dKU6Nbs78KJMBqw4bDLS S964DgzMBQ4vYjeoUzuXInjwlX0akuvcAg3sRQd4=
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 49WFHh579Jz6G8nj; Mon, 25 May 2020 17:30:56 -0700 (PDT)
To: Martin Thomson , rfced-future@iab.org
References:         <3c04035a-ff04-4669-bea1-6f0eda5b8c46@www.fastmail.com>
From: "Joel M. Halpern" 
Message-ID: <2f7a17c6-f50a-90c6-dfb1-635002a78230@joelhalpern.com>
Date: Mon, 25 May 2020 20:30:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <3c04035a-ff04-4669-bea1-6f0eda5b8c46@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 00:31:01 -0000

I do not think anyone is saying that things will improve (in any regard) 
if we just ignore any specific problem.

However, equally, one of the things that we do know is that if we try to 
solve all problems at once, we get nowhere.  And this group has a 
specific charter.  Which does not include most of the things that you 
listed in the note below.

We all have guesses as to the relationships among causes and effects. 
So?  We could spend a year arguing about that instead of figuring out 
what we want for an RSE and how to get one.  That does not sound like a 
good plan to me.

Yours,
Joel

On 5/25/2020 8:22 PM, Martin Thomson wrote:
> On Tue, May 26, 2020, at 08:57, Michael StJohns wrote:
>> My take on this is that its probably as RFC 2026 revision that is
>> needed to address your concerns and that's probably not directly tied
>> to how the RFC editor is constituted. That could come from a WG, or
>> from a design team or even an IAB area.
> 
> I can see why it is appealing to say that this is a problem for the streams.
> 
> But part of evolution of the series means adapting to the needs of its consumers.  Maybe that means a little bit of a concession toward making it easier/better/etc... for the primary source of RFCs to produce RFCs.
> 
> To me, it is clear that the structural constraints imposed by the RFC series - such as immutability - has had a material effect on the way that the inputs to the system are produced.  And of course this is intimately tied up with the choices the IETF makes with respect to things like the stages on the standards track and whatnot.
> 
> It is also linked to the way that the formality of the IESG process has evolved over time.
> 
> The methods of production for documents also are tied into this.  Those too have changed considerably.
> 
> My reading of this is that we do agree that there is a problem here.  What seems in contention is whether the RFC series needs to care; and whether the RFC series might need to be part of any solution.  It is maybe true that some of the problem lies outside of the charter of this group, but I don't think we get to ignore that in the hopes that things will improve by doing so.
> 


From nobody Mon May 25 17:43: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 E9EA93A0831 for ; Mon, 25 May 2020 17:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level: 
X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BCr1VTesinM for ; Mon, 25 May 2020 17:43:34 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1583A082F for ; Mon, 25 May 2020 17:43:34 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id r7so2025345wro.1 for ; Mon, 25 May 2020 17:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZypC+Q+XtcsqfxMPMPXxIVRH6t9ByLD7eCZbSbWvrnQ=; b=a2OVaAgPHA/f1FVnh4mCKbJaxGTX3HmNQnJpHjq4YxkeelMKZdwsxnQ54Ga2PB+DgQ UVbfiAwhg+q9WgOXRnZ24laWPOTfRdef3vcmZI7TobDBpKvaV8MdU2INWfUiGRfvAMIq QUys9QNpfqzbFvU5IIhTnzZ0r8ANVeHBxC6gnVBkBll/o4VMHKAMq/3bLgPoM4KwnV6t LTMHisjNNrjHaxorPQ8AVwr3LkY0POLDCQsq0YdVFWA81YFQSaQWSVUWUtbrexSmq3Fz run/d4av428CG32YP5jCzVsOYss5QcyQTHpzPugpYND8XilvAjUuuD/9hjwmjJwrUEbK /How==
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=ZypC+Q+XtcsqfxMPMPXxIVRH6t9ByLD7eCZbSbWvrnQ=; b=Fq0afSdV6h+/UKaEw+hRWb7kdo51DoUvwX8cwXNghnfY/vAiVtEuWfdRESLKvnOd27 ZRiuuA/T0KIwNbi3CgJhjxGDKzAch3z/oZoGw8HuPXG6xLe2bUyyElF1ehtWI7Z2sr+j s6Kv7LTqzSnJH0OOphal5l3MA75pVmmtqSTqOWr1yG/xbcbVDr2tcW37ygiU+aiirlOw vmN2r0UGhRfIEgqSXUA1bDmucdy1yFyOCVZetfNdoCxbP3LQqTfVeraqgv3JuTU9lH7+ /405L5yu7lzBYIWn1YxmOLt8M+a+Y9noIItNG0ZLl4GWjR16QI7d4MilO1ynCU9JfP9k tEDA==
X-Gm-Message-State: AOAM531mo6G22od//ZY4xzcBSKKbS3zp7w3xV9/21C8/Bt3f8efi7CdY NQ/hrPayqfBQ3QDZFkTKQI4=
X-Google-Smtp-Source: ABdhPJyjvFoyHa/7cTLdgL/h1tgmJbZkVcoiGbeXJlj7qHUOeZsTxXIWVOlARdT+uzIL9prgDFWLvw==
X-Received: by 2002:a5d:6943:: with SMTP id r3mr17018800wrw.113.1590453812612;  Mon, 25 May 2020 17:43:32 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:9c6b:8767:8b3b:7b48? ([2601:647:5a00:ef0b:9c6b:8767:8b3b:7b48]) by smtp.gmail.com with ESMTPSA id c14sm8828167wme.8.2020.05.25.17.43.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 17:43:31 -0700 (PDT)
From: Bob Hinden 
Message-Id: <084DFF3A-864A-4F4F-B067-D409727F6B81@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A8DB3353-D938-4935-96C6-7DB044C7A709"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Mon, 25 May 2020 17:43:26 -0700
In-Reply-To: 
Cc: Bob Hinden , Eric Rescorla , Tim Wicinski , Rfced-future@iab.org, John Levine 
To: Brian Carpenter 
References:     
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 00:43:36 -0000

--Apple-Mail=_A8DB3353-D938-4935-96C6-7DB044C7A709
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Brian,

> On May 25, 2020, at 2:56 PM, Brian E Carpenter =
 wrote:
>=20
> Let me challenge that with a question.
>=20
> What would really be better if RFC8200 was actually called RFC1883.3?

Having lived through the process of what became RFC8200, doing RFC1883.3 =
might solve the easy part of the problem, but I agree that the hard =
parts are more related to how the IETF standardization process work.    =
There are a lot of related issues, including:

 - The Errata process is broken (it doesn=E2=80=99t separate the problem =
and a solution, easy to abuse).
 - Many bis updating document don=E2=80=99t describe the changes very =
clearly.
 - It=E2=80=99s easier to block something in the IETF than to get it =
approved.
 - We don=E2=80=99t charter w.g.=E2=80=99s to do maintenance of =
protocols (with a few exceptions).

I think most of this is out of scope of the rfced-future.   Improving =
the Errata system would be a good thing for a new RSE to work on.  The =
rest belongs to the IESG.

Bob




> Or if RFC8446 was RFC2246.4?
>=20
> I think the problem is much deeper (see the newtrk archive).
>=20
> Regards
>   Brian Carpenter
>=20
> On 26-May-20 09:19, Eric Rescorla wrote:
>> I think whether this is an IETF problem depends on one's priors.
>>=20
>> At a high level, it seems likely that we need some kind of
>> two-layer system of references:
>>=20
>> - A reference that points to the current state (e.g., "TLS
>>   with all the recommended extensions, etc.").
>>=20
>> - A reference that points to a specific historical state
>>   (in version control, we'd call this a hash or a version
>>   number depending on the system).
>>=20
>> Now, if you assume that RFC #s are the lower layer (i.e., that RFC
>> XXXX always points to the same content), then yes, it seems like the
>> IETF would need to layer something new on top and this becomes an =
IETF
>> problem. However, if one treats RFC #s as the higher layer (perhaps
>> with a version number suffix as the lower layer) then this becomes
>> an RFC series problem.
>>=20
>> -Ekr
>>=20
>>=20
>>=20
>> On Mon, May 25, 2020 at 2:13 PM Tim Wicinski > wrote:
>>=20
>>=20
>>    Brian
>>=20
>>    While it is an IETF problem, I would like to see an RFC Editor =
function
>>    that is empowered to tackle this problem.
>>=20
>>    tim
>>=20
>>=20
>>    On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter =
> =
wrote:
>>=20
>>        On 26-May-20 08:42, John R Levine wrote:
>>        .....
>>> I am not proposing specific changes other than to say that the model =
of
>>> RFCs solely as independent immutable documents no longer makes =
sense.
>>> While I do not suggest we go to WHATWG style living documents, I do =
think
>>> that for our specifications we need to find a more modern way to =
collect
>>> the material into a small number of places with stable names =
(perhaps
>>> using version numbers like everyone else does), and to make discrete =
low
>>> cost updates as we find errors or make partial updates.
>>=20
>>        Writing as one of those who bloodied their noses on this =
problem some
>>        15 years ago, I completely agree, but it is an IETF problem, =
and the IETF
>>        has been remarkably resistant to discussing it, let alone =
fixing it.
>>=20
>>        And I *think* it's orthogonal to our problem here, although if =
the IETF
>>        would get its house in order, our problem might be easier.
>>=20
>>        Regards
>>            Brian
>>=20
>>        --
>>        Rfced-future mailing list
>>        Rfced-future@iab.org 
>>        https://www.iab.org/mailman/listinfo/rfced-future
>>=20
>>    --
>>    Rfced-future mailing list
>>    Rfced-future@iab.org 
>>    https://www.iab.org/mailman/listinfo/rfced-future
>>=20
>=20
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


--Apple-Mail=_A8DB3353-D938-4935-96C6-7DB044C7A709
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl7MZi4ACgkQrut0EXfn
u6i6Fgf9EN9xSTbrXu3Mufm9M6Ab/+v5aDipU2VCQ1KsvDHfXuP4Mp1bMVHzzIce
HSj5+0JIZzUlKffbWFZkmhiNOqKBeiYc3uu5+PxBmhlxTYw3Hm/2dLaEwk7FECD+
ORct/i3jdlKRjMPH3YdMSOQo/jUyzrWdlTqqzCTCP0y0n10E2dfv5bCtYk3SURbT
+AkWpPDhjb9smcZPj3GGr4pA039H3y4hKlGw8wTJa00r2M8F2SlH4Wr+rdhJBLpZ
KNzod5XVms7X7mKCjYQtZSZEVu9oH7kTn6NIdBsJISM88soZpWE6Kj3OqsQJ41NX
O/VSi13YgXrdxOtTgd1wbTkF/R7B7Q==
=27bm
-----END PGP SIGNATURE-----

--Apple-Mail=_A8DB3353-D938-4935-96C6-7DB044C7A709--


From nobody Mon May 25 17:56: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 393523A0968 for ; Mon, 25 May 2020 17:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUgWJCV5lU3Y for ; Mon, 25 May 2020 17:55:19 -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 96E353A089D for ; Mon, 25 May 2020 17:55:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2AF17BE20; Tue, 26 May 2020 01:55:16 +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 tDnK69UM6eRu; Tue, 26 May 2020 01:55:06 +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 82C0CBE2F; Tue, 26 May 2020 01:55:06 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1590454506; bh=NPh8zV18WzfJX8Eu7CpMvEjOoI42jUB0I6oP4oOUIxI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GggIVpBMG7Mkp2X5KZ8TT1v1vvnn2uf4vW6T1guZl/7OfvDKlGCtdoMFao9G1k/rS wbJcTqoqr6hwOpDPwFBfVmkEPcT3UlroDjb9iFhGc0uMlxErhZR2xXbvxTS1Om87AC nReQLbZWOzjzTUHjk54WOFaK7alyBWywM74ZorEI=
To: Bob Hinden , Brian Carpenter 
Cc: Tim Wicinski , Rfced-future@iab.org, Eric Rescorla , John Levine 
References:      <084DFF3A-864A-4F4F-B067-D409727F6B81@gmail.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: Tue, 26 May 2020 01:55:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <084DFF3A-864A-4F4F-B067-D409727F6B81@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Z5qIUHLPwWX1szHSULxNeUBWi3OBZfoJX"
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 00:55:34 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Z5qIUHLPwWX1szHSULxNeUBWi3OBZfoJX
Content-Type: multipart/mixed; boundary="6ME3mp14h7G309jnpcu4dwALp4DZoIpVV";
 protected-headers="v1"
From: Stephen Farrell 
To: Bob Hinden ,
 Brian Carpenter 
Cc: Tim Wicinski , Rfced-future@iab.org,
 Eric Rescorla , John Levine 
Message-ID: 
Subject: Re: [Rfced-future] Why the RFC series is important
References: 
 
 
 
 
 <084DFF3A-864A-4F4F-B067-D409727F6B81@gmail.com>
In-Reply-To: <084DFF3A-864A-4F4F-B067-D409727F6B81@gmail.com>

--6ME3mp14h7G309jnpcu4dwALp4DZoIpVV
Content-Type: multipart/mixed;
 boundary="------------B8EA0738FC91288507D0A580"
Content-Language: en-US

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



On 26/05/2020 01:43, Bob Hinden wrote:
> - The Errata process is broken (it doesn=E2=80=99t separate the problem=
 and a
> solution, easy to abuse). - Many bis updating document don=E2=80=99t de=
scribe
> the changes very clearly. - It=E2=80=99s easier to block something in t=
he
> IETF than to get it approved. - We don=E2=80=99t charter w.g.=E2=80=99s=
 to do
> maintenance of protocols (with a few exceptions).
>=20
> I think most of this is out of scope of the rfced-future.   Improving
> the Errata system would be a good thing for a new RSE to work on.
> The rest belongs to the IESG.

+0.9, (0.1 being an element of uncertainty:-)

S.

--------------B8EA0738FC91288507D0A580
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-----

--------------B8EA0738FC91288507D0A580--

--6ME3mp14h7G309jnpcu4dwALp4DZoIpVV--

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

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

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7MaOkACgkQWrL68XsX
K+rsQxAA05WktqaNGQKF1O7rUypv3YlFoJMf7lGyNoYL22FyWrJHW9JTg8HoM8HY
ON4rxJlQR59oAIrjL50AAg3iNSjgBpSb2xmpfiCHnK+2vulFcbvnoFdpzfRHQGkN
+vi4zwETzd8lFSEJlYoSeqopbA5sFPY4PsrNSe0X0CxkMiqur//yKkQhND2sTItf
ttKA+OwIWpfA11EcbmJnLqS0sD2W9HK/aO09QBWHrNFVFjpax7zmag39/vf4auM1
Tl9JiQZNEulrlL6sn8qB4CUKO3iX1Np/ep3c9GB6coaoJETm4j+yu7/s+aiZoNbd
6gYKTT0o7/oXuFDRPr3Y7yZoFbP7VFhHTmq3bhSGi9gcKv+Tbd+eI2P8GDwYm+kd
RDaSX3SbPu7zpHbodq/4ombMu4mQh/NaEwNcP9VB2WXfh6SL3+KPz41XLzIRVGIS
5NYEOcDWc7B5W+EFIeuAsp7fE8MU3alKkQGLAasdI94fioAdURiOv6ksUmy6fw2x
Q9Kn27lamRmPmHMv4vhLJyBM92fZ1OS1/nofPZrmcj6y4fj335GwRwuup6B3Lia5
XMAUC/qs3dHGYj6zsepEVOQMP7L4Twmfwo5ZZorCVYVx/2lz0XZuhhtbidLpsTeR
xCVhBKfxzZOLY/vnHZ4Q81QKmx5qLcf2DNZJ+4v37ag2JEFrLPE=
=EQc6
-----END PGP SIGNATURE-----

--Z5qIUHLPwWX1szHSULxNeUBWi3OBZfoJX--


From nobody Mon May 25 18:28:51 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CBF3A0A29 for ; Mon, 25 May 2020 18:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 Cspcg55AsGYD for ; Mon, 25 May 2020 18:28:47 -0700 (PDT)
Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 2A19F3A0A27 for ; Mon, 25 May 2020 18:28:47 -0700 (PDT)
Received: by mail-pl1-x644.google.com with SMTP id x18so6899927pll.6 for ; Mon, 25 May 2020 18:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=psNPSRrqAFgTcPpR2sLUbMP2e9CMC74i2ohImVG2Atc=; b=tZYpCamv7iY0y0NVRT4Jehu9oxbBdmG9pNhZVX6d507qgw7XnD6Dk52hoId/lNi8Cy dMcqDSde/H2bcoYxxNIHDJF6DF4Gry+P06vyFW0an45OYpyI8S+P4DyQmW0ogT0IuG96 oH5GV1JYzPn5ynhKEP6lIzVT0li7JdoJNRpbf+WHMwjIwwY/xi8+8gVfdHV9cmPd7rYP peNlNkSkg1tVXKW0ohlM5u/HtKnNsOGRdXg0T5BnGSmDB2Di29+U8PYL/HxtBF3yHYEX meMVCAPnQZeZWNk5hoyg1rZ0H8NPSYOmkeRRTgjqtQuXohDkFpg0peGBHnsOIDLrGONc DShA==
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=psNPSRrqAFgTcPpR2sLUbMP2e9CMC74i2ohImVG2Atc=; b=tUuzbnBisr4t5wW5nkMgYHy5qi7SvWAHkKia/YjK9tPaY+IOESHnK7FKUumO+Yx7dd Ey6qrJ5NCZqYww+1IDeE1ovEzFu/wPapQ5aJKLqxyWAFaAJdmR/uNkOImCgKwLpU5F8N jk/xUcGAHiax1FA5lMRE5/SXB7Tb75Ks0Y+VNvBgMcKK27NVWbyrTjpqxOqgwv0FNM1I wYjKM77gHMk9tGIVcWQ15M/2UoxNfhb0vSgLLofGlPeWxLXpb6CsTDjHiyyVGEn2wv1E Wt4nUmLp9JCF05aQxtuGDDB61sxaqp3prBc5PUiUkivkQfIoNm8qAn//x4ysSm5sW5ZS +e0A==
X-Gm-Message-State: AOAM533exxlwZjgFkTBNMu3CAGVqs5643GqcJdDMoOGGof2dkrazzztz UeapW5Gcw0RZcLnQZCKpbXYKu5tM
X-Google-Smtp-Source: ABdhPJykCCaq9MU1pELKzOhoSSExl8Vz0BJnyBTkUEDv12AoQsr5Vo9UQu5lbPS3jxC6fwqXD1n47A==
X-Received: by 2002:a17:90a:c004:: with SMTP id p4mr24628832pjt.170.1590456525362;  Mon, 25 May 2020 18:28:45 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id x132sm13871603pfd.214.2020.05.25.18.28.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 18:28:44 -0700 (PDT)
To: Doug Royer , rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <18740cff-425c-f1cb-37d3-e3ea80bb343f@gmail.com>
From: Brian E Carpenter 
Message-ID: <8b383696-46b0-3023-b1fb-b42095e26758@gmail.com>
Date: Tue, 26 May 2020 13:28:39 +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: <18740cff-425c-f1cb-37d3-e3ea80bb343f@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 01:28:49 -0000

On 26-May-20 11:32, Doug Royer wrote:
> On 5/24/20 6:35 PM, Michael StJohns wrote:
...
> I have not tracked a specific draft through the process in a long time. I would think that transparency inside the process helps. Including why it is stalled would reduce the desire to change things from frustration or misinformation.

To me, the IETF data tracker and the RFC Editor queue are quite explicit. Yes, you can always ask "Why has my document been in RFC-EDITOR state for 8.9 weeks?" but you can't really expect that level of detail to be exposed in the tracking system.
 
> Influence - as in priorities? I would not think that the format of the documents would be at the whim of hidden people doing hidden communications.

It never has been. The old format was simple and always well described and the new format was openly designed in gory detail.

Regards
   Brian


From nobody Mon May 25 18:35:11 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890693A0A03 for ; Mon, 25 May 2020 18:35:02 -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 BLU4oK2FD1k0 for ; Mon, 25 May 2020 18:34:57 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 969B53A09A6 for ; Mon, 25 May 2020 18:34:57 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id h9so4821150qtj.7 for ; Mon, 25 May 2020 18:34:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=bt2DgjO/+r41e556kkzZQqrDOBvQncewcvmhYyfdYqs=; b=g4SiPBeuMeyzuOLaO0ey8ql5c/iOqty/j39nzVx3zp/kRTJSw9yCWOu94tZ1RK5NiL DwAr3HzIlqF/K/juW235EO5wavlWxTjiLxjWyLGjyxL75wZ51poQ5xB1ZHO07Jqwp5ss dCfBd4OQapo3is/wNUBuhlGENlT03IzTh4uhhrzH1rAazi3a4q8rCX7u2Pj/7qj/OhvM xU6gJRxeQuGAPMJryLNVcr9GvVC4lYT095lDvAWTLuMIVJHVGdnAmkkXfT45KrfFUCZT I8XDSODfrHjr0o3dahrgieT9465JKD7rHHRZ+v1nYCZDzLX7oF8TYiKV3PGmUN2OOCZH EqKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=bt2DgjO/+r41e556kkzZQqrDOBvQncewcvmhYyfdYqs=; b=gWfKZ/2fHa1gOUocYVvCdOMHGt/1LBkSDUnSOUJDe8dEMEfvVlIoEeFYMTv2UVSjSY EDcgqrvBsKsexPlcVRXtel1LFt/UlIKzl+3jZuMbaPrWZEwXEETXvgEAIBBRiHGP+28H b8saAf+KGvcn83jjhT1S8ZWF1+8ooPlTFRYdmxwm+6zFaISNoUSPWcLf40SmGZS4/iCa j4whZj5OFG4dUycTk5ZWSc9dQtNbudsnIRrs7jRwpdC/Y78TVgoyGSg/pwo2JBLaFqH7 Eu2oVDyh7FRE9tnveC5xZaWgqbCbcdztWQ00SYEf2JYvITn1X0UtRuSBXzVEYdpyzYi0 9c3g==
X-Gm-Message-State: AOAM532gl+IHN8gOynkvrKp5298kMbVK+7Rk+lBTrwB9OVEX0Ae7bFBl /67PCNOJjlhOBgcHhxSk7rsalQ==
X-Google-Smtp-Source: ABdhPJxySq5D7qFGY5GUvjh1nkdbcV7b2tGNZI34qO4VDlI1+ND6eNdSG5+LpinFU7Xj9kNIkwVf3Q==
X-Received: by 2002:ac8:7c8e:: with SMTP id y14mr4437596qtv.112.1590456896005;  Mon, 25 May 2020 18:34:56 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id h3sm14792952qkl.28.2020.05.25.18.34.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 18:34:55 -0700 (PDT)
To: Eliot Lear 
Cc: rfced-future@iab.org, Mark Nottingham 
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <28BE2C74-D8A8-470B-A33F-F5A4A37BFBEA@cisco.com>  <4DB5E967-061D-4778-9FFF-EE0F38427B48@cisco.com>
From: Michael StJohns 
Message-ID: <8ab903f3-8ecd-36ab-11e7-d12cac98267a@nthpermutation.com>
Date: Mon, 25 May 2020 21:34:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <4DB5E967-061D-4778-9FFF-EE0F38427B48@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 01:35:04 -0000

On 5/25/2020 3:49 PM, Eliot Lear wrote:
>>
>> Secondly, on the matter of who appoints the ISE, it would be helpful 
>> if you consider the context in which I suggested this.   My 
>> suggestions were meant to devolve the IAB from overall control of the 
>> RFC System and the change in appointment/approval of the ISE was in 
>> that vein. Right now, the IAB appoints the RSE, the ISE and the IAB 
>> stream manager.  They also appoint the IRTF chair who appoints the 
>> IRTF stream manager.  In other words, out of 5 people, the IAB 
>> appoints or indirectly appoints 4.
>>
>
> For one to take this view, one has to be of the opinion that the 
> streams are part of the RFC Editor function.

Hi Eliot -

Kudos on your taking up mind reading as a new educational task, but I'd 
suggest you ask for your money back as I do not have that opinion.

The streams today feed the RFC publication system. They aren't part of 
the editor function (except maybe the ISE as the ISE unlike other stream 
managers well ... edits), but it would foolish in the extreme to not 
consider their needs and how they might influence the publication system 
on a tactical level.

Later, Mike



From nobody Mon May 25 19:05: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 36B6F3A0AA2 for ; Mon, 25 May 2020 19:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNWUwmhlt03O for ; Mon, 25 May 2020 19:05:10 -0700 (PDT)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDDA3A0AA9 for ; Mon, 25 May 2020 19:05:10 -0700 (PDT)
Received: by mail-pj1-x102a.google.com with SMTP id l73so4265339pjb.1 for ; Mon, 25 May 2020 19:05:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=IwhzgVjmR1VOL+4hWwgICwzkMi6VOgVhMJnqlcX86hs=; b=Rm8GB28U/ulFrFl2hN5Kxdmi+Z6jHnhwQoLHdwtfwaYFHWS5NMrw4c9FvE1U0reOZb RPujckQt3mJHmUaXfkmhSOM9RqK7dOg7dUzPyC7JX87kU/AI0OG83AVWdIMn7WHPzwld mD6bHmgYiO58HmCvxZL9lTSjtAkias5glGdeWvDfvvHkYXxhw8HQw/KQGzf126z2ARmO sXp4hguhJaLQ+tyodrxM81RWEdHsuAgrtw1lkVGuWObZ8xCU2wLTTCGkmiHpOPFetU3v wAQ3UCTtsoiFdBjJTb5k8GR6eHJmFV9dQ0LR6zg61imAPBy6vUwjCl4w2RYzymAM3ERW ITYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=IwhzgVjmR1VOL+4hWwgICwzkMi6VOgVhMJnqlcX86hs=; b=tm7hgONwcJMrr0XAh8j4tH/On3Xs/uvmwxSbpa5vZrSjHSbzuKxwiJa9cStxM/3x/o QvHy9vVJZzuo5iifL4Hivcd1Mm20WamAP+0uffwRRsdecjgPSZoOYmE5cZcwIUHu8ymd 9kuwPLV1v6m3ylkNO1vzs69+Bm1bghT/qH6+aCN5ABSUZ3apPh1xJOxtn6UKZawBbIGn Nnno7tnPVDWYoQUbU/vvBnSIHC6sel6wgwlgJx9c/zsDiALhq/kCRa8NbdOrsw98QRHm yEeVUkQ1st9oiM+IuvYfczMnpyjd55TT7Rw16La8gOr2NcRH28LoY8V8mRRt/rB7nROr ICKg==
X-Gm-Message-State: AOAM533hajl3AgMWS2193EM0QV8saYS94Ez+IdWnteBNk4CUzYt6U+Mr 0Xxxu4Wscepv+BvoEhJT6XLvv7Tv9hSfI5Y=
X-Google-Smtp-Source: ABdhPJwo6LOqNRaT4CIwlAOenw6q6/7TJVwZp0CWIvB+33aiALFmvw9IED4wMw+VUXHx1Tdqdh7TyA==
X-Received: by 2002:a17:902:d209:: with SMTP id t9mr16244052ply.298.1590458708307;  Mon, 25 May 2020 19:05:08 -0700 (PDT)
Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id 5sm12229356pgl.4.2020.05.25.19.05.07 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 19:05:07 -0700 (PDT)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <18740cff-425c-f1cb-37d3-e3ea80bb343f@gmail.com> <8b383696-46b0-3023-b1fb-b42095e26758@gmail.com>
Organization: http://SoftwareAndServices.NET
Message-ID: 
Date: Mon, 25 May 2020 20:05:06 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <8b383696-46b0-3023-b1fb-b42095e26758@gmail.com>
Content-Type: multipart/alternative; boundary="------------C76F4572ED0B44F0D254F5F3"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 02:05:13 -0000

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

On 5/25/20 7:28 PM, Brian E Carpenter wrote:
> On 26-May-20 11:32, Doug Royer wrote:
>> On 5/24/20 6:35 PM, Michael StJohns wrote:
> ...
>> I have not tracked a specific draft through the process in a long time. I would think that transparency inside the process helps. Including why it is stalled would reduce the desire to change things from frustration or misinformation.
> To me, the IETF data tracker and the RFC Editor queue are quite explicit. Yes, you can always ask "Why has my document been in RFC-EDITOR state for 8.9 weeks?" but you can't really expect that level of detail to be exposed in the tracking system.

I would expect basic status. "waiting for manpower to start it", "Waiting for answers to questions from ...", "waiting for external zzz to happen...", "being tweaked ..."

As I have no clue how they internalize the process, I would not know what specifically to want. Maybe just a comment saying "if you have waited more that 8.8 weeks, send us an email to find out why"?  Perhaps a live automated graph of average process times? Something other than a black hole. Or maybe I just don't know where to look?

-- 
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

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


  
    
  
  
    
On 5/25/20 7:28 PM, Brian E Carpenter
      wrote:

    

    

      
On 26-May-20 11:32, Doug Royer wrote:


      

        
On 5/24/20 6:35 PM, Michael StJohns wrote:


      

      
...


      

        
I have not tracked a specific draft through the process in a long time. I would think that transparency inside the process helps. Including why it is stalled would reduce the desire to change things from frustration or misinformation.


      

      
To me, the IETF data tracker and the RFC Editor queue are quite explicit. Yes, you can always ask "Why has my document been in RFC-EDITOR state for 8.9 weeks?" but you can't really expect that level of detail to be exposed in the tracking system.


    

    
I would expect basic status. "waiting for manpower to start it",
      "Waiting for answers to questions from ...", "waiting for external
      zzz to happen...", "being tweaked ..."

    

    
As I have no clue how they internalize the process, I would not
      know what specifically to want. Maybe just a comment saying "if
      you have waited more that 8.8 weeks, send us an email to find out
      why"?  Perhaps a live automated graph of average process times?
      Something other than a black hole. Or maybe I just don't know
      where to look?

    

    
-- 

      Doug Royer - (http://DougRoyer.US)
      Douglas.Royer@gmail.com
      714-989-6135

  


--------------C76F4572ED0B44F0D254F5F3--


From nobody Mon May 25 19:20: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 8DEC73A0AFB for ; Mon, 25 May 2020 19:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=XeUcKRWD; dkim=pass (1536-bit key) header.d=taugh.com header.b=DkFCNwbj
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slff9LSH53tB for ; Mon, 25 May 2020 19:20:05 -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 4A7103A0AFD for ; Mon, 25 May 2020 19:20:05 -0700 (PDT)
Received: (qmail 54513 invoked from network); 26 May 2020 02:20:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d4ef.5ecc7cd1.k2005; i=johnl-iecc.com@submit.iecc.com; bh=gaNYKxCmlmWAgm0yY+MkXlvbGef8DTpNvnxLy1+jLUQ=; b=XeUcKRWDOs27psW/ZU2b3AHCv4sZdN7uKUw0GD3XgNZ+f8YZcz619dsipVvZ1QToEM+CeUY2qVwMUisuA3NEY8Odq6YNkUFkG0DiLD2axcsK7yasAfs+AXgyjw9nD3+c91KUn76agnsFYWVskA9r+u7hnqCx0N1zYq4+hdmghVLGPXwvQD+lpqSt74vORNWGVEPyVeYf+redm8gJhKFBMv1BuPwChgJEfyWJweIt0Fze67WNoOahjv6szC3l/A4Z
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:user-agent; s=d4ef.5ecc7cd1.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=gaNYKxCmlmWAgm0yY+MkXlvbGef8DTpNvnxLy1+jLUQ=; b=DkFCNwbjSworapsULj62nBcufBmYJgefVSCE9VGmfr6z/i4vqX/Fjt4rmFCqRI2o8//Hz51tUOma/CKWp0EYtUYY64kl3z5TK9K19xFFtPI5RlBJX3SsyTnJN+qlACHVnGNmDsRkl5x8so/h/35VPzlVif33zgaKA3GsrVVvRW3gwpCK+/xvOPKrEXRN4Wg2NMWDUh2c/AdWdsBC9e2x5rqoTixKcg5jzP77sxQg5BllzgvXAjTfC4EBex5QVF0I
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; 26 May 2020 02:20:01 -0000
Date: 25 May 2020 22:20:00 -0400
Message-ID: 
From: "John R Levine" 
To: "Stephen Farrell" 
Cc: Rfced-future@iab.org
In-Reply-To: 
References:      <084DFF3A-864A-4F4F-B067-D409727F6B81@gmail.com> 
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 02:20:09 -0000

On Tue, 26 May 2020, Stephen Farrell wrote:
>> I think most of this is out of scope of the rfced-future.   Improving
>> the Errata system would be a good thing for a new RSE to work on.
>> The rest belongs to the IESG.
>
> +0.9, (0.1 being an element of uncertainty:-)

If we're considering version numbers or updates by section or applying 
errata, it has to be coordinated by both.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Mon May 25 19:39: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 344023A08F3 for ; Mon, 25 May 2020 19:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSmYK18vX5GR for ; Mon, 25 May 2020 19:39:45 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 ADD163A041E for ; Mon, 25 May 2020 19:39:45 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id bh7so1154139plb.11 for ; Mon, 25 May 2020 19:39: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=ZXa7fxhXeS2acqJdyF2zgD3gF28NSfj/mvYdBK9Z0MM=; b=ZBVAm1v9CcBbAOi5SRFYLvKKYRZ5s4JB1YNPPno4i2gxRdiubuqiCzJRmBGDLBs2P/ xX3BlZRVVKdz3XBnYWuvSXFe+76iSLf6M+7qJQO+Zlp+c+ROxhUG+ZJ5iwHIChd0kLWX ejFUVqM0YgxUEXhCl7+DxQPSKnOmu2LjHL/opQgGCn6SCNWH7X6xRYDXOMbJ2Xbkm20j tKo3daxN5zZT312sT9U9d2ppjChc5ovI2IPcvD1Z2LIChZdF9m8jLoVyXgzPlKN4h8DD gcQqsHFqtIAwE+gMtSRht6ZExaeTnrm/Jxpi9CLoGGGIbDxh+fwZSlROjixGqITV71Pd FmDA==
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=ZXa7fxhXeS2acqJdyF2zgD3gF28NSfj/mvYdBK9Z0MM=; b=CyLsZfLXP5MgkMVrGqdQiVptav+JmbIJzcUjHO4l2eYfkXUpQbQAYIf7KSDcmOZlXt 9lJMX9dWL4gLQmivf/DmmGVF0cAlqoU+0IfSu2CgNZcZvdDlYPrCIBkjnoOMygcEGrCP 0Ya+sW9XewYVAH9ibC9mZYxUvS6JUEpImRKo0Zj2epDA1IYfh8Jm7LFnXPG4jbZxixme +6aBKhWKD8Id7oLImLN7fKoUYLehcLl09Ek2wFyG7923zGRfPQBmoKE7/uXEcZPQiKil nmh0zqg1kjhZfZlB/i5f127pHO6oGm3uoacAB28P605Exsd8ZD3TOBZTggTpOveS14vk PrKA==
X-Gm-Message-State: AOAM531rnJ3ldzMKl58NwLd82oYpbzqc90OrZu9ogjNwALv8cmx/82w/ qDPL6I7LntRC+DrHaG/yomKcLM7s
X-Google-Smtp-Source: ABdhPJxgDga85NtbHhEZ6h2QQYwMql/gIqA29FIAVoOrWzt58hguL9TunFBBwOYndwRf1N/AQ92zjA==
X-Received: by 2002:a17:90a:ce17:: with SMTP id f23mr24916593pju.51.1590460784789;  Mon, 25 May 2020 19:39:44 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id b11sm13807252pjz.54.2020.05.25.19.39.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 19:39:44 -0700 (PDT)
To: Doug Royer , rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <18740cff-425c-f1cb-37d3-e3ea80bb343f@gmail.com> <8b383696-46b0-3023-b1fb-b42095e26758@gmail.com> 
From: Brian E Carpenter 
Message-ID: <421bf636-3c1b-faac-ba09-9dc8af1a0c9d@gmail.com>
Date: Tue, 26 May 2020 14:39:38 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 02:39:49 -0000

On 26-May-20 14:05, Doug Royer wrote:
> On 5/25/20 7:28 PM, Brian E Carpenter wrote:
>> On 26-May-20 11:32, Doug Royer wrote:
>>> On 5/24/20 6:35 PM, Michael StJohns wrote:
>> ...
>>> I have not tracked a specific draft through the process in a long tim=
e. I would think that transparency inside the process helps. Including wh=
y it is stalled would reduce the desire to change things from frustration=
 or misinformation.
>> To me, the IETF data tracker and the RFC Editor queue are quite explic=
it. Yes, you can always ask "Why has my document been in RFC-EDITOR state=
 for 8.9 weeks?" but you can't really expect that level of detail to be e=
xposed in the tracking system.
>=20
> I would expect basic status. "waiting for manpower to start it", "Waiti=
ng for answers to questions from ...", "waiting for external zzz to happe=
n...", "being tweaked ..."
>=20
> As I have no clue how they internalize the process,=20

Well, to focus on this particular state, the /about/queue page says: "RFC=
-EDITOR =3D Undergoing final internal review before AUTH48" and in the qu=
eue there are 48 documents ranging from 0.7 to 11.9 weeks in that state.

There isn't (to my knowledge) a GUI so I used grep, sort and wc. However,=
 those data tell me that whoever does that final review is backlogged.

I don't see any lack of transparency here, although there could certainly=
 (in theory) be a nice GUI that would be easier to use than the raw list.=


(There is a summary table at https://www.rfc-editor.org/reports/CurrQstat=
s.txt
but that confounds RFC-EDITOR and RFC-EDITOR*R which is a different state=
=2E)

> I would not know what specifically to want. Maybe just a comment saying=
 "if you have waited more that 8.8 weeks, send us an email to find out wh=
y"?=C2=A0 Perhaps a live automated graph of average process times? Someth=
ing other than a black hole. Or maybe I just don't know where to look?

Well, I hesitate to send nag emails when the recipient is already backlog=
ged. It can literally only make things worse.

And for our business here: is progress-chasing at the RPC a job for the R=
SE, or for IETF LLC that holds the RPC contract?

Regards,
    Brian


From nobody Mon May 25 22:01: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 258813A09C0 for ; Mon, 25 May 2020 22:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 woN2b3XXsaYV for ; Mon, 25 May 2020 22:01: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 ADD5F3A09B1 for ; Mon, 25 May 2020 22:01:36 -0700 (PDT)
Received: from xse385.mail2web.com ([66.113.197.131] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jdRiW-0003sN-S0 for rfced-future@iab.org; Tue, 26 May 2020 07:01:35 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49WM6P44pkz2w5 for ; Mon, 25 May 2020 21:53:17 -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 1jdRaX-0003Vp-Fa for rfced-future@iab.org; Mon, 25 May 2020 21:53:17 -0700
Received: (qmail 26306 invoked from network); 26 May 2020 04:53:16 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.203]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 May 2020 04:53:16 -0000
To: Brian E Carpenter , Doug Royer , rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <18740cff-425c-f1cb-37d3-e3ea80bb343f@gmail.com> <8b383696-46b0-3023-b1fb-b42095e26758@gmail.com>  <421bf636-3c1b-faac-ba09-9dc8af1a0c9d@gmail.com>
From: Christian Huitema 
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <5935570c-54f7-ae3d-a47d-7b49d9f68690@huitema.net>
Date: Mon, 25 May 2020 21:53:16 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <421bf636-3c1b-faac-ba09-9dc8af1a0c9d@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: 66.113.197.131
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/gcnlw0cz3TYWAMatow42l8TcmTKWpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4i2tLfbSUoiIuqav0zZqCK5QVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuE/oVmIjiUjKW4wTbK4KINs+42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGZNFSBymhtbd6ygEffuU1+3EbilPGcyP4k6t/ikhe7HToJ4sitzQTrzh4X646qRnJnB H1fP3YU+2XWwKzL04bcfwzQZWnqpeh+UbGCVNeqba5Xked+P+aSZU/EB7YnRWs2LBDMrD7q/cJog wbqzsuok04ardUge3wuNDQO738R1NU7JPy9twDyaj6un7qWOkNes1tMqdp5qt7p4N+BRNHSRBC4c DnetTWECMwVZFWAHy+PXdRjeeYOc4D1auWIFhSFseij9XIJGSPSnMXGOy8f7w6nIoDr0sXUZ7YZo 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] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 05:01:39 -0000

On 5/25/2020 7:39 PM, Brian E Carpenter wrote:

> And for our business here: is progress-chasing at the RPC a job for the RSE, or for IETF LLC that holds the RPC contract?

The current structure is a little weird. The RSE is in theory in charge,
but in practice is not managing contracts or budgets. Things would be
clearer if the LLC was clearly in charge of what amounts to executing a
contract according to performance targets, and if the RSE could focus on
issues like formats and errata.

-- Christian Huitema


From nobody Mon May 25 23:16: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 AD5883A0B39 for ; Mon, 25 May 2020 23:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 byfAXOhFBF32 for ; Mon, 25 May 2020 23:16:15 -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 B203F3A0B50 for ; Mon, 25 May 2020 23:16:14 -0700 (PDT)
Received: from [172.16.42.112] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49WNy46VsxzyXf; Tue, 26 May 2020 08:16:12 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: <2507455b-a835-52fc-76e5-917ab2070288@gmail.com>
Date: Tue, 26 May 2020 08:16:12 +0200
X-Mao-Original-Outgoing-Id: 612166572.424724-ec7fd411a7b187734d09a0a462387d34
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <2507455b-a835-52fc-76e5-917ab2070288@gmail.com>
To: rfced-future@iab.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 06:16:21 -0000

>=20
> Eliminate, when possible text and references like "foo: like used in =
RFC-#old paragraph 16.3" when a copy/paste would work. Reduces the =
documents that need to be read.

Beautiful example for why this problem is so hard.

People executing on something like the recommendation above is a big =
source of interoperability problems.  Because the copy/paste didn=E2=80=99=
t contain all the information referenced, was rephrased in the editorial =
process etc., doesn=E2=80=99t get updated together with the original, it =
tends to create a subculture that is different from the original.
(Read up on software clones to know why this is a such a bad idea in =
general.)

No, don=E2=80=99t copy/paste, unless the original really only is an =
inspiration and not a reference.

I note that the discussion here also conflates revisions of documents =
with =E2=80=9Cversions=E2=80=9D of a specification, which in many cases =
really are collections of =E2=80=9Cfeatures=E2=80=9D.  Long story that =
comes up more forcibly when one wants to employ formal description =
techniques.  My summary of that story is well known to be =E2=80=9Cversion=
s are stupid=E2=80=9D.  (Which we partially seem to know: RFC 8200 does =
not create IP version 12.)

Which features are =E2=80=9Ccore=E2=80=9D to a specification ecosystem =
is not always decided at the time the features are defined.  Deployment =
experience, the market, emerging (often unfounded) perceptions etc. also =
play a role here.  I don=E2=80=99t think we (as an organization) have =
even started to understand our role in ecosystem management as different =
from that of a specification writer, even though the successful =
shepherds of ecosystems certainly have.

I don=E2=80=99t think the RFC editor can even remotely be the person =
pushing all this evolution forward.

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


From nobody Tue May 26 00:14: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 8CBFB3A0C4A for ; Tue, 26 May 2020 00:14:03 -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 zx726244fwov for ; Tue, 26 May 2020 00:14:00 -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 DCA973A0C46 for ; Tue, 26 May 2020 00:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4350; q=dns/txt; s=iport; t=1590477240; x=1591686840; h=from:mime-version:subject:message-id:date:to; bh=Xlfv7P/FJyMUFHzomptZOOz2h/QzSJTmA4PYijPsqR8=; b=g29SPnOk/Q/uVeAL2TmqeojeyH43HNlJmWoYcShmQPe6v3c6UmP53cbl +4s8DS3GMAoqtAhAB4xrVJk1FizUtr/z6bQzvoYRI0Y3A/TOYP3xmZ/7n V7KRo5SpWQxTZEvLfSXpaMKy+BjcB8Rxj0YwZg7z/+nFID4y+1n3w5k2W k=;
X-IPAS-Result: =?us-ascii?q?A0BRBgD0wMxe/xbLJq1mHgEBCxIMg36BeAEgEoRRiQGHY?= =?us-ascii?q?ZN7iBALAQEBDAEBLwQBAYcLOBMCAwEBAQMCAwEBAQEFAQEBAgEFBG2FYoYcd?= =?us-ascii?q?Q4wAkuDTYJ9nTqOEHaBMoVRhQaBOIxeggCBOAwQgh+GB4JHM4ItBI5SNKQfg?= =?us-ascii?q?l6CdJVoHYJjjWMnjRWqZ4NJAgQGBQIVgWkigVYzGggbFWUBgj89EhgNnwo/A?= =?us-ascii?q?2cCBgEHAQEDCY1VAQE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.73,436,1583193600"; d="scan'208,217"; a="24182915"
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; 26 May 2020 07:13:55 +0000
Received: from [10.61.225.84] ([10.61.225.84]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 04Q7DsZX030982 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 26 May 2020 07:13:55 GMT
From: Eliot Lear 
Content-Type: multipart/alternative; boundary="Apple-Mail=_8BE2A4FD-210C-42EB-ACB0-A2C4EF8A5B60"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Tue, 26 May 2020 09:13:54 +0200
To: rfced-future@iab.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.225.84, [10.61.225.84]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 07:14:04 -0000

--Apple-Mail=_8BE2A4FD-210C-42EB-ACB0-A2C4EF8A5B60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi everyone,

I am hearing several different points of view on this matter:

The series is difficult to read because one has to traipse through a =
large number of documents, and this is a problem the RSE should take on.
This is a problem for the IETF and the RSE shouldn=E2=80=99t be =
involved.
This is a shared problem between the RSE and the streams
This is so hard a problem we shouldn=E2=80=99t touch it.
What is =E2=80=9Carchival=E2=80=9D?

I wonder if there is consensus around something close to the following =
view:

The RFC Series Editor is responsible for specifying editorial methods =
and the necessary architecture by which RFCs may be amended in a manner =
that is seen as useful to the various stream managers, with an eye =
toward readability and referential integrity (add other stuff here).  It =
is up to the stream owners to set policies around approving such =
amendments.

This isn=E2=80=99t all that far from what we have today with the errata =
process, but is more specific than what is in our documents today.  The =
only question is really how the rendering of changes should take place.

Some jobs may be too big to handle simple edits.  I couldn=E2=80=99t =
imagine, for instance, that TLS 1.3 would be a bunch of edits on top of =
TLS 1.2.  But the streams would largely need to make that call.  =
Interoperability concerns would also largely fall to the streams, =
although the RSE might need to provide mechanisms to warn about =
pitfalls.

Thoughts?

Eliot


--Apple-Mail=_8BE2A4FD-210C-42EB-ACB0-A2C4EF8A5B60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
everyone,

I am =
hearing several different points of view on this matter:

  • The series is difficult to read =
because one has to traipse through a large number of documents, and this =
is a problem the RSE should take on.
  • This is a =
problem for the IETF and the RSE shouldn=E2=80=99t be involved.
  • This is a shared problem between the RSE and the =
streams
  • This is so hard a problem we shouldn=E2=80=99t =
touch it.
  • What is =E2=80=9Carchival=E2=80=9D?
=


I wonder if =
there is consensus around something close to the following =
view:

  • The RFC Series Editor is =
responsible for specifying editorial methods and the necessary =
architecture by which RFCs may be amended in a manner that is seen as =
useful to the various stream managers, with an eye toward readability =
and referential integrity (add other stuff here).  It is up to the =
stream owners to set policies around approving such =
amendments.

This isn=E2=80=99t all that far from what we have today with =
the errata process, but is more specific than what is in our documents =
today.  The only question is really how the rendering of changes =
should take place.

Some jobs may be too big to handle simple edits.  I =
couldn=E2=80=99t imagine, for instance, that TLS 1.3 would be a bunch of =
edits on top of TLS 1.2.  But the streams would largely need to =
make that call.  Interoperability concerns would also largely fall =
to the streams, although the RSE might need to provide mechanisms to =
warn about pitfalls.

Thoughts?

Eliot

=

--Apple-Mail=_8BE2A4FD-210C-42EB-ACB0-A2C4EF8A5B60--


From nobody Tue May 26 00:37: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 CAEBB3A0C66 for ; Tue, 26 May 2020 00:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=kQvEbpJS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=swodW8cD
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuNUsWhkc-W6 for ; Tue, 26 May 2020 00:36:59 -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 D47F93A0C76 for ; Tue, 26 May 2020 00:36:18 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id AC37679A; Tue, 26 May 2020 03:36:17 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 26 May 2020 03:36:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=L 06O3DbgcRLy6OaRwDi4LFqrgwGEZQ4l1S5uHQcxaes=; b=kQvEbpJSga4VQ9xac nyo+q2zxeP2tjCbLMlO38v2386Fe2tOu+JQJDbqLRCfHNnMhaJ+cQFqix5g44WK3 aOIPrESUvYxy5ST82ulE+gs9QvCu+YdZK0PhC6g+SLwfGG+4tspcCBSi54E3HpDv D0S+ZqPXBS4pnVWKMSPaQQozQArtF7tD3OUHu+ICWLUZLKM2kyXtGjxbVaxtG4Z4 2+iJZCiKOgE/baKYtbtOjt2FbXGDVYEEZ22mXlb5hEyc6f6qs3eK2N8xer22Ii6W 8Rbwv1GR6ojhmQYjcf7EAwOB69FpYgHv8oIVM9SXYzX5gK07JRe9VHYZC3hPtTi+ 0u0AQ==
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=fm2; bh=L06O3DbgcRLy6OaRwDi4LFqrgwGEZQ4l1S5uHQcxa es=; b=swodW8cDwNKL8SDvNOM3uCWXGVTxE2B3tf3RhsDWVqw6+saNjucEs/tRz utSr0buKFWDFs8h+YhyGcpiZLZYZvLiOqcmp38a31NsJ6TZlYDro2wKq74kZ/w7E F9U9ORJeIAe+BDXQks2QlUi5oF2QPciuo6t9XqpVTlKDPeHHfnNr0USJtHnEVmxA NbbRf4BN6APnDRBHYv8ND1QEL7mEYxcmUP+vE5Wa2lxJhxQy+oGy9MsT/P+U0Wi/ yyg1h1BSK9LZE6YWJCahL2ChxlaFqHr5T6Cr6O9npME7bfyf4rg+PaZ36iQWsdkx Dm/OlLNIm6a7/sVzaeIfpMiw/jDJg==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvuddguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepteeghfevjeefvdffjeeuieeuvdevvddvudejfedthffhvefhvdfhgfduieel ffevnecuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucfkphepuddule drudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 58736328005D; Tue, 26 May 2020 03:36:15 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 26 May 2020 17:36:11 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FFC3226-679B-4126-9F3D-9FE1DFC89026@mnot.net>
References: 
To: Eliot Lear 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 07:37:06 -0000

To me, the underlying issue here is that the unit of archiving is done =
by RFC number -- i.e., once you know the number, you know the octets =
underneath it don't change.

Perhaps the most extreme example is RFC7159, which only differs from =
RFC7158 in its publication date.=20

That's not in itself bad, but unfortunately that same identifier has =
become by far the most powerful identifier for the work -- to the point =
where efforts to introduce new layers of identification (e.g., STD) fail =
because they don't have the same traction. It's as if a software project =
decided to version its software with commit hashes, and those hashes =
were used not only to represent the version of the software, but its =
very identity (e.g., RFC2616 instead of HTTP; =
b3ec76308b319c7dc660f383ccad803e365de1090c0d2858d85b29e0654f3c00 instead =
of Firefox or even Firefox 76).

In other words, we seem to have built a worldwide brand around a =
low-level revision identifier, and yet failed to introduce a normal way =
to refer to the product of our work at any coarser granularity -- =
partially *because* that brand is so successful.=20

The IETF community absolutely needs to be involved in addressing this, =
but I can't imagine it being done without coordination with (and by?) =
the RSE, if we have such a function.


> On 26 May 2020, at 5:13 pm, Eliot Lear =
 wrote:
>=20
> Hi everyone,
>=20
> I am hearing several different points of view on this matter:
>=20
> 	=E2=80=A2 The series is difficult to read because one has to =
traipse through a large number of documents, and this is a problem the =
RSE should take on.
> 	=E2=80=A2 This is a problem for the IETF and the RSE shouldn=E2=80=
=99t be involved.
> 	=E2=80=A2 This is a shared problem between the RSE and the =
streams
> 	=E2=80=A2 This is so hard a problem we shouldn=E2=80=99t touch =
it.
> 	=E2=80=A2 What is =E2=80=9Carchival=E2=80=9D?
>=20
> I wonder if there is consensus around something close to the following =
view:
>=20
> 	=E2=80=A2 The RFC Series Editor is responsible for specifying =
editorial methods and the necessary architecture by which RFCs may be =
amended in a manner that is seen as useful to the various stream =
managers, with an eye toward readability and referential integrity (add =
other stuff here).  It is up to the stream owners to set policies around =
approving such amendments.
>=20
> This isn=E2=80=99t all that far from what we have today with the =
errata process, but is more specific than what is in our documents =
today.  The only question is really how the rendering of changes should =
take place.
>=20
> Some jobs may be too big to handle simple edits.  I couldn=E2=80=99t =
imagine, for instance, that TLS 1.3 would be a bunch of edits on top of =
TLS 1.2.  But the streams would largely need to make that call.  =
Interoperability concerns would also largely fall to the streams, =
although the RSE might need to provide mechanisms to warn about =
pitfalls.
>=20
> Thoughts?
>=20
> 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 Tue May 26 01:00: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 2AF523A0CA0 for ; Tue, 26 May 2020 01:00: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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 yVxKDpU_S4U8 for ; Tue, 26 May 2020 00:59:59 -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 6B96A3A0C9C for ; Tue, 26 May 2020 00:59:59 -0700 (PDT)
Received: from [172.16.42.112] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49WRFn0TK7zyZ5; Tue, 26 May 2020 09:59:57 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: <5FFC3226-679B-4126-9F3D-9FE1DFC89026@mnot.net>
Date: Tue, 26 May 2020 09:59:56 +0200
Cc: Eliot Lear , rfced-future@iab.org
X-Mao-Original-Outgoing-Id: 612172796.443822-bb49650235522cde7e1604a17d526b5b
Content-Transfer-Encoding: quoted-printable
Message-Id: <6CF52365-BF30-4526-B107-E7873F5BBC5E@tzi.org>
References:  <5FFC3226-679B-4126-9F3D-9FE1DFC89026@mnot.net>
To: Mark Nottingham 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 08:00:08 -0000

On 2020-05-26, at 09:36, Mark Nottingham  wrote:
>=20
> In other words, we seem to have built a worldwide brand around a =
low-level revision identifier, and yet failed to introduce a normal way =
to refer to the product of our work at any coarser granularity -- =
partially *because* that brand is so successful.=20

There is no problem that can=E2=80=99t be solved with another layer of =
indirection.

We already have RFCs that describe mutable information, such as IANA =
registries.

Why don=E2=80=99t we do the same for curated ecosystems?

We can do that experiment within the existing RFC system, and slowly =
migrate any successes into being core elements of the RFC system.  I=E2=80=
=99d rather do that than damage the RFC system by a period of =
instability (inevitably guided by process confabulation).

Again, the actual work is setting up the processes in the IETF stream, =
and getting the energy up to execute them.  I=E2=80=99m a bit more =
optimistic here than I probably should be =E2=80=94 hey, we even managed =
to have a git WG.

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


From nobody Tue May 26 01:12: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 E2FF23A0E9F for ; Tue, 26 May 2020 01:12:50 -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 xNoYZm2A7N0I for ; Tue, 26 May 2020 01:12:50 -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 262F83A0CF5 for ; Tue, 26 May 2020 01:12:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=779; q=dns/txt; s=iport; t=1590480747; x=1591690347; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zf69PHt4OeM5PK84ig98DI/sCuzkPy5qy9ce4z/QEhM=; b=cdSvlYnqiMQbXz6/KAfZ407tmcCYQUfNyUeufT2ED1FLoFGT2/RAs+Uv ZV367X83+vx9gz9Nd90t57PWTOFWyuLtnehdlh6caK2I7QldyCjdGzLrs HfYdWGLzYxQ5FRqlIi0iqfqZJt//jnS3+NUc0LHMMZ7fZhWNJ7kEokwc0 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AQCqzsxe/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBR4NvASASLI0mh2Ilm2YLAQEBDAEBLwQBAYREAoJ?= =?us-ascii?q?FOBMCAwEBCwEBBQEBAQIBBQRthWKFcgEBAQECATo/BQsLDgouVwYTgyaCXSC?= =?us-ascii?q?rWnSBNIVRhRWBOIxeggCBOAwQgh8uPoROg0eCLQSzJYJegnSVaB2QRo08qme?= =?us-ascii?q?DSQIEBgUCFYFpIoFWMxoIGxVlAYI+PhIYDYkulVw/AzA3AgYIAQEDCY1VAQE?=
X-IronPort-AV: E=Sophos;i="5.73,436,1583193600"; d="scan'208";a="26454964"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 May 2020 08:12:23 +0000
Received: from [10.61.225.84] ([10.61.225.84]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04Q8CMa6031015 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 May 2020 08:12:22 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Eliot Lear 
In-Reply-To: <5FFC3226-679B-4126-9F3D-9FE1DFC89026@mnot.net>
Date: Tue, 26 May 2020 10:12:22 +0200
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <11FFE411-FEAA-4325-9860-D9CCE949CB32@cisco.com>
References:  <5FFC3226-679B-4126-9F3D-9FE1DFC89026@mnot.net>
To: Mark Nottingham 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.225.84, [10.61.225.84]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 08:12:53 -0000

Hi Mark,


> On 26 May 2020, at 09:36, Mark Nottingham  wrote:
>=20
> To me, the underlying issue here is that the unit of archiving is done =
by RFC number -- i.e., once you know the number, you know the octets =
underneath it don't change.


Perhaps this goes to what the canonical representation is, and whether =
the meta data can change so that editorial changes can be reflected.  =
What I am wondering is whether we can agree that this is something that =
the RSE should take responsibility for, without actually trying to solve =
the problem here.  It is for sure a meaty problem and goes right to the =
heart of a question that I know is important to you: what sort of skills =
would an RSE need to find a successful path here?

Eliot=


From nobody Tue May 26 02:21: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 616E33A0D62 for ; Tue, 26 May 2020 02:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIQICNRpiYO9 for ; Tue, 26 May 2020 02:21:22 -0700 (PDT)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410125.outbound.protection.outlook.com [40.107.141.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11743A0D50 for ; Tue, 26 May 2020 02:21:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b21EzfqmgvhWr3ETtw1FIRngG8U7zLXRlrKNMsyL6exHoMLYRsKUODM2HYy6w03ngXRGkaUGJQQfkrOHEpZlxnDQ1GG8WI3d+0+dTHQGaL7unCPlYbOamZ8c85v3q3eeBva+BmmeBszShEHTopoQSGvDOt4FG754g8egvfyjJZNH3jgYRSWnl2U+cBSvhQQFQwPRTFWLF+3/S+0u7/Kg1+WocQXjrOZNxvo2bWL8miZru+mOczPDdDW7sRz24+TsiZrcHcT79fyAfCI0LuemCatFE1mGt36W7s0TMcu1ge8xOyDKSfnWRHggIJIAvK0rG9fcgvkWgiLM9NV7kNUHqg==
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=r6HyhA2DdVQPRE2vUEtwMs7hrenAcLmB57qjC28E+d8=; b=mcR6T2B0+Y3egwRKDdlcXXY2A6e/gWtXxMubBLEWM8+2eovPCwFf4bYzqzVuFIjIRU4DPqW8mwOb21C2jnuCM6XVso5ynYWMOvcc+YWSnrmx8RkKkYMuI29rbDmr27r+/27lj6wP/Bz+LdtP9VeLnq005+171y7wUVI38meVXne6WaYBYo8N+ysGLbMvZ2hfoM2TRJSRHPYPE2iVwsJ1z+CihWXupBCu3/NM3ZyLiW0m2heJnvLRz+OBvzqY9SvWNxqIW07xeFzCw9xnhydZHzbkMAd6VNrsdXKgAo5EQWy0362MOFj0p/V3PWTl6hLbgBN1LV2+3ZnltaFSQDvCFA==
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=r6HyhA2DdVQPRE2vUEtwMs7hrenAcLmB57qjC28E+d8=; b=TkWk5wLjd30Nz9eERInc/wLvNfNnbxBH3hgBzfg+XlqzTCKDMFrn7hTe0Ss87RxWSkchCYJ4RwaIwNI97A2rFOCZkDChip/Ex4a7DcMtojUrF1DkaK6itAdD2KTjdcxOmD417uvV17mH8X1kz3b/msi5Tw0iHTC5/j8XBqJ0wO8=
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 OSBPR01MB2453.jpnprd01.prod.outlook.com (2603:1096:604:1d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Tue, 26 May 2020 09:21:11 +0000
Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::80a8:73bf:9ca8:7aae]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::80a8:73bf:9ca8:7aae%5]) with mapi id 15.20.3021.029; Tue, 26 May 2020 09:21:11 +0000
To: Carsten Bormann , John R Levine 
Cc: Rfced-future@iab.org
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>
From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp>
Date: Tue, 26 May 2020 18:21:09 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
In-Reply-To: <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: TYAPR03CA0019.apcprd03.prod.outlook.com (2603:1096:404:14::31) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.6] (125.203.82.4) by TYAPR03CA0019.apcprd03.prod.outlook.com (2603:1096:404:14::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.9 via Frontend Transport; Tue, 26 May 2020 09:21:11 +0000
X-Originating-IP: [125.203.82.4]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b6cb9028-dab5-48c1-c89b-08d801562168
X-MS-TrafficTypeDiagnostic: OSBPR01MB2453:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 041517DFAB
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 8G3kA//QxN5PAZ0dIBz8BQpvN9wx1K9KGE8CyQVBqRWh4lXN3k5FLAPiijE7usKGufwYJFVucD5OmmOYEV8LgCsf3/V5Mtpl8DMpmFPNE0/UR10zAzORN4dIZi23Z9is690V8yhZ2fghpfT+ljwbdGfnGllAjqOfVkaDjB5pjNyYVKJKScmMs8iQLJx1jGVndtg6MWpzc1vVJL4RbyccFHDzf0yESfRr6En/LgCabgCV1DuOwg+sAdAi3qNt2jvLS8t/s0Tvlfqe/Nk4GIyAYPMCs+4bc1JGGMvBOacZ1/mzEAAv5JNpYGMs8ahdLuas73KDijSteWjBbb64S2H0zQvOROslLyF2EqoNqZMKEzyQ1+jNzPWKVn485kLA4ju/
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(396003)(376002)(39840400004)(136003)(346002)(366004)(26005)(6486002)(2616005)(956004)(86362001)(186003)(53546011)(508600001)(16526019)(5660300002)(36916002)(52116002)(66946007)(110136005)(4326008)(31686004)(786003)(16576012)(8936002)(66476007)(8676002)(66556008)(316002)(31696002)(2906002)(43740500002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData: go+UfEyI+upRd3V6doR7RxBBLiHaCK0SeIZEyeQE6k/XjfEwq3czxRrh8U0JbQlRlhw+zt/1moPevapkiw+/j0nKo30ESLCyhqppC8h+etpIx8H2JYE7sxagLU8YtVyDgdRe1ODTFtdFww3vj5T0bMCU2hi6epr5Ndx1dDzZC1nMGzo1a7fsM/hxlJs+GRflkDHSA0hJJhDQcy71GWvOe6rxiI+72oyAgb3VL9KumAFXWzEyk+ASY0ObM5Gcef9k/EebpDFE1rcjIN/6mxHCqc+AWqeHP5QJUryQEABmeIywQzlSyp14xLWeLir3jwGfikJcokFsXnuYxBcqyVK3ZdtEshM3lNMcx6dPzPRQy4i7g+7P/jZB5AabFH/ROCdW+TJVhSozXQrFM881KQoCd56PNsCJQ45SFWRvFsiHC8/0qkaQwHJOXe5QYUWRhD+uz1LCCV55oN+1wIvSqYD2LQYAmEtTwAVwRqm+Bs4HTwE=
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: b6cb9028-dab5-48c1-c89b-08d801562168
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2020 09:21:11.8082 (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: 12Plv27pzJcDWsh7MOIGEZGKrjUtzS58zBJ9fP5I0yKA/0ivuW00YuoVVvo51XpjbA+8NOWLMZn+0IEmH260ag==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2453
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 09:21:29 -0000

On 26/05/2020 06:12, Carsten Bormann wrote:

> So we publish updates to updates to updates, and almost never do consolidated versions like they are being done in lawmaking.

Yes, true, but in order to do what they do in lawmaking, we would have 
to write the original stuff way differently. In law, at least in the 
jurisdictions I'm familiar with (which is an extremely limited set, and 
by the way, IANAL), every article, and for bigger articles, its 
subarticles, is labeled carefully. There is also a system to insert new 
paragraphs between between existing ones (to insert a new article 
between article 22 and article 23, label it e.g. article 22.bis,...).

Laws that update an existing law are written with exact instructions 
(insert the following article as article X,...), not just a general 
"updates RFC XXXX". Editing a law for a new publication requires great 
care, but not really any kind of judgement like "should extension foo be 
recommended for protocol BAR or not?".

And lots of laws are full of completely outdated stuff, not only the 
language but also in terms of content. Most legislatures don't have the 
time and energy to clean out old stuff, because that doesn't get you 
reelected.

So I don't think we will be able to learn too much from lawmaking.

Regards,   Martin.


From nobody Tue May 26 03:56: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 BDE9B3A0A93 for ; Tue, 26 May 2020 03:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpZvCx1Cz4sH for ; Tue, 26 May 2020 03:56:50 -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 4FB2B3A0ABD for ; Tue, 26 May 2020 03:56:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 216BEBE5C; Tue, 26 May 2020 11:56:48 +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 yWjFjCJOeK5z; Tue, 26 May 2020 11:56:46 +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 85F13BE58; Tue, 26 May 2020 11:56:46 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1590490606; bh=0q5UyOB1ocgsT6OJOi8G3mX3xzUfc2m+8eCICd+H10o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ygUTejsbxpgDcQG7zqle1F6QhY+If+FhGRTAw/Ylmkd3ndRO/X2ykdi/2SFH5Blxg cPT8qdzeIkPj7kNvrryOBzTKh2Iv05BhDF3H9kZUjz6tynj3C/pc426z3WqnTAHEHZ 3uMtdMuWHEOgxcUehp0lQqX8VYcd/n/OiUW8v3Ek=
To: Eliot Lear , Mark Nottingham 
Cc: rfced-future@iab.org
References:  <5FFC3226-679B-4126-9F3D-9FE1DFC89026@mnot.net> <11FFE411-FEAA-4325-9860-D9CCE949CB32@cisco.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: Tue, 26 May 2020 11:56:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <11FFE411-FEAA-4325-9860-D9CCE949CB32@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LMtfaBZ5pUXRbYIhcPx8YR5cSt3izTu3V"
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 10:56:53 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--LMtfaBZ5pUXRbYIhcPx8YR5cSt3izTu3V
Content-Type: multipart/mixed; boundary="1Q5e5i8holLVWdC1CkNMTv1ASG3qUjUL0";
 protected-headers="v1"
From: Stephen Farrell 
To: Eliot Lear ,
 Mark Nottingham 
Cc: rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] On the question of a living series
References: 
 <5FFC3226-679B-4126-9F3D-9FE1DFC89026@mnot.net>
 <11FFE411-FEAA-4325-9860-D9CCE949CB32@cisco.com>
In-Reply-To: <11FFE411-FEAA-4325-9860-D9CCE949CB32@cisco.com>

--1Q5e5i8holLVWdC1CkNMTv1ASG3qUjUL0
Content-Type: multipart/mixed;
 boundary="------------2ECA02ADE9397398B4BB617E"
Content-Language: en-US

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



On 26/05/2020 09:12, Eliot Lear wrote:
> what sort of skills would an RSE need to find a successful path here?

That's a good question, definitely in scope here. And the
2020 answer may differ a good bit from what it'd have been
a decade ago.

S.

--------------2ECA02ADE9397398B4BB617E
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-----

--------------2ECA02ADE9397398B4BB617E--

--1Q5e5i8holLVWdC1CkNMTv1ASG3qUjUL0--

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

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

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7M9e0ACgkQWrL68XsX
K+rE8g/9HxBDNDO3Diy4x8o5Qq2PSCbpVEIN6URvGKXkrTWTciPxFh+DXukGvcLx
Juex7qV55U45Zm4QIqmVmM0kTJJM9XCxEe0PJINI2saj2EXrQAichx2mefnBP86p
UEg6Pt7CubgHCmChsuPazex4UDuDt4a2dD40JBvDuMbJghWKqOSUQWiOURp3qaNh
pMH8VxDD6NfJA1DRK563oWooCmfKYirDaB8FoBQa2KI6o50iauDHePJhx/AnoOqF
bm6cozq4ARs89MJIOqLRIMG3ixjkRJCeShWKhh31b3MZcqqaq29MlEftYgfHzb4z
smyGoM+ZlDH2ED1A1e1IyTDN4Z9bVR1+hNsN7BxhGRuian+8exwU8TMAiU8Xz+oV
uk3S2mzsfUizJy5nkYvGtqRgQwavBmfrBhq32wIOse7KfpnMVfqcnvEb+WsUYpJM
+F+8CrWYc3arW2TMoqS1fDYDKBlWscSN3/DTG/lhKTEzYGUY7VrpeS+0lIdqVplr
5iIj5qXGr9WfRVhghZ4S08lfVsMoo4pobJ/HAGYsX1K6imFp0M0JZEvb8ihU7pnl
MzWH7z7yKUMsGTj0wus8kYpZhctU4Cpff/2NMnWg0e+zZLp72eWI5FegmbM+RH9q
HhQONiO6uYKbWCQ0zDDnAJ3303cLoBmYZzAGQdMTeOaGi3Pe2BM=
=iVot
-----END PGP SIGNATURE-----

--LMtfaBZ5pUXRbYIhcPx8YR5cSt3izTu3V--


From nobody Tue May 26 05:18: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 6074E3A0ECB for ; Tue, 26 May 2020 05:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 T9ij2STF9Whr for ; Tue, 26 May 2020 05:18:50 -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 61DD03A0EC0 for ; Tue, 26 May 2020 05:18:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49WY0S4K4Tz6GD5v; Tue, 26 May 2020 05:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590495528; bh=y+mGyWgCkOXI+OSTokfidf9esxGIFaBegTgctGLbEXs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KTShyROf/MeKcywMgGYz/TkX5B/3nUIKtCbS7ObicAZFyUjYUWPL/KI2G/rGIHY/l ILiCUs9Ula7vS9xsLFY/1jsrnQgScupMIvSwsR5I5gmvOFVOcpbZ5GS7l0GoAX7Q1H W1s1tBxZZXdw7yu6eI3LDtK/FEMTHezC5JAt6Ieg=
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 49WY0S0c1Wz6G8mx; Tue, 26 May 2020 05:18:47 -0700 (PDT)
To: Eliot Lear , rfced-future@iab.org
References: 
From: "Joel M. Halpern" 
Message-ID: <347a8c3b-169b-cda9-637e-45e49ccd2805@joelhalpern.com>
Date: Tue, 26 May 2020 08:18:33 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 12:18:54 -0000

I am uncomfortable with the assumption that "RFCs may be amended".  That 
opens the door to much larger changes than eratta, which is not 
something I want, nor something on which I think we have agreement.

Yours,
Joel

On 5/26/2020 3:13 AM, Eliot Lear wrote:
> Hi everyone,
> 
> I am hearing several different points of view on this matter:
> 
>   * The series is difficult to read because one has to traipse through a
>     large number of documents, and this is a problem the RSE should take on.
>   * This is a problem for the IETF and the RSE shouldn’t be involved.
>   * This is a shared problem between the RSE and the streams
>   * This is so hard a problem we shouldn’t touch it.
>   * What is “archival”?
> 
> 
> I wonder if there is consensus around something close to the following view:
> 
>   * The RFC Series Editor is responsible for specifying editorial
>     methods and the necessary architecture by which RFCs may be amended
>     in a manner that is seen as useful to the various stream managers,
>     with an eye toward readability and referential integrity (add other
>     stuff here).  It is up to the stream owners to set policies around
>     approving such amendments.
> 
> 
> This isn’t all that far from what we have today with the errata process, 
> but is more specific than what is in our documents today.  The only 
> question is really how the rendering of changes should take place.
> 
> Some jobs may be too big to handle simple edits.  I couldn’t imagine, 
> for instance, that TLS 1.3 would be a bunch of edits on top of TLS 1.2. 
>   But the streams would largely need to make that call. 
>   Interoperability concerns would also largely fall to the streams, 
> although the RSE might need to provide mechanisms to warn about pitfalls.
> 
> Thoughts?
> 
> Eliot
> 
> 


From nobody Tue May 26 08:11: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 18D7E3A0045 for ; Tue, 26 May 2020 08:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=W1cJ/qNL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mlgQLdOl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSiqMKoZ1oCD for ; Tue, 26 May 2020 08:07:47 -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 9A62D3A03F7 for ; Tue, 26 May 2020 08:06:09 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 148555C00C0; Tue, 26 May 2020 11:06:08 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 26 May 2020 11:06:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=m KEYEGG2OkQP86AEPLXRYWTUyHQgjEUlBfz9WLkXdHI=; b=W1cJ/qNLS5YCuYZQ2 yWfa6u1m+NauUV8xpyxb+wbqG1k8/dwqN8X/EN3m+TolvtyDa9ce9zrz85015+95 55nATgy1uqFcJBQGQGjHdEoD/GDHj9QWXFLKHaX0P3ri16yLZRI8WbZghZn5BA0Q FTeGkHv8paQCaZZT7g4S1/8y46pxeugFrnNyYLWkXNhVxLTM2blaMnvSlT3dRcwL dDKs8yfbK7pI8AwrYospvE9V22tZ3qYH97OS67kwxGgO4BjrMvE1KhC7ZCuL0U2R E6zCZxPh1f92onYKL9Igarqnk6T3ofPrmXov4J6mmKospgprDWL1oFAWTLsT5Fm4 nIMZA==
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=fm2; bh=mKEYEGG2OkQP86AEPLXRYWTUyHQgjEUlBfz9WLkXd HI=; b=mlgQLdOl4rElY9VxtordqF0J2B1oS/VSL0jvB0JUqZn+prwXs7SlBqkvB G/MJPY2qOrC4CFz7NAG6t0Ym/K07wSoNlcJ6VPYtlbfrbwqvcXukHLqNcJ11sZuv MCUEUdFDTNQZmcrmQ0TOC3QSrBVK4TdpenrHYtwRyrCMkV4RbSMy88iYGJJDs0VE 0igVFSlA+GMKNrqUbk41TFar4nyJ+fqbx7IaT55LJMPQn3YHNaiKEqZM1tZ0Xyto Z0VTrdwE7IOvHfFm49VAu/KXgZqosvm2pjJGfh5qWSyd3Tut0rvBNPzuVwmEGkjI VhWE+LWCulkSvhpYQjLXWLTsXjLsA==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvvddgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeeiveeiudejvdejieeuhffhffeiiedtjeegleekueduleejieffteelheeuteff udenucffohhmrghinheplhgvghhishhlrghtihhonhdrghhovhdrrghupdhprhgrtghtih gtrghlthihphhoghhrrghphhihrdgtohhmpdhmnhhothdrnhgvthenucfkphepudduledr udejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id B349330665CF; Tue, 26 May 2020 11:06:04 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp>
Date: Wed, 27 May 2020 01:06:01 +1000
Cc: Carsten Bormann , John R Levine , Rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D974AB5-AF98-4A50-B24D-D5690629019E@mnot.net>
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org> <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp>
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 15:08:21 -0000

> On 26 May 2020, at 7:21 pm, Martin J. D=C3=BCrst =
 wrote:
>=20
> On 26/05/2020 06:12, Carsten Bormann wrote:
>=20
>> So we publish updates to updates to updates, and almost never do =
consolidated versions like they are being done in lawmaking.
>=20
> Yes, true, but in order to do what they do in lawmaking, we would have =
to write the original stuff way differently. In law, at least in the =
jurisdictions I'm familiar with (which is an extremely limited set, and =
by the way, IANAL), every article, and for bigger articles, its =
subarticles, is labeled carefully. There is also a system to insert new =
paragraphs between between existing ones (to insert a new article =
between article 22 and article 23, label it e.g. article 22.bis,...).
>=20
> Laws that update an existing law are written with exact instructions =
(insert the following article as article X,...), not just a general =
"updates RFC XXXX". Editing a law for a new publication requires great =
care, but not really any kind of judgement like "should extension foo be =
recommended for protocol BAR or not?".
>=20
> And lots of laws are full of completely outdated stuff, not only the =
language but also in terms of content. Most legislatures don't have the =
time and energy to clean out old stuff, because that doesn't get you =
reelected.
>=20
> So I don't think we will be able to learn too much from lawmaking.

Oh, I disagree. Statutory drafting is a beautiful thing to see (at least =
in some jurisdictions), and we could learn a lot.

Consolidated legislation is merely that which incorporates amendments =
since it was originally enacted; a Consolidated Act is a piece of =
legislation that does that with the express intent of combining Acts in =
a subject area without updating them. No special notation is required, =
although the legislature does need to do the work (just as we do during =
a bis, etc.).

Even without action by the legislature, you still have reprinted acts, =
which the government printer re-issues each time there's an amendment. =
Their authority varies; in some jurisdictions, they're considered =
authoritative, whereas in others the primary acts have precedence in =
case of disagreement.

So, for example, you can see the Biosecurity Act 2015 (Cth) has been =
amended several times, and each time was reprinted with the appropriate =
updates.[1]

Yes, this requires some editorial discipline, but it also requires =
conventions for the editors to follow -- and that's precisely what one =
should expect the RSE to provide. They need not be pinpoints like =
section numbers (indeed there are several styles in different =
jurisdictions); it could be contextual diffs, or xpaths, etc.

In fact, there's some well-founded criticism of legal norms here; =
Matthew Butterick (both a lawyer and a typographer) urges legal drafters =
to follow best practice from technical writing in identifying =
sections.[2]

Cheers,


1. https://www.legislation.gov.au/Series/C2015A00061
2. https://practicaltypography.com/hierarchical-headings.html

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


From nobody Tue May 26 08:23: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 1D3A33A0765 for ; Tue, 26 May 2020 08:23: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 (1536-bit key) header.d=iecc.com header.b=YEryjrlI; dkim=pass (1536-bit key) header.d=taugh.com header.b=r1XcqS9J
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNpvRhMzDENA for ; Tue, 26 May 2020 08:23: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 008E23A053F for ; Tue, 26 May 2020 08:23:22 -0700 (PDT)
Received: (qmail 62638 invoked from network); 26 May 2020 15:23:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f4ac.5ecd3468.k2005; i=johnl-iecc.com@submit.iecc.com; bh=hUMOB/942iSihW1ehE9kk8JfORnjX5WMpNkotwAPWlw=; b=YEryjrlIVbR5P5E+j5X3+/jTEWdq//kImWuy0a2QlbkG46Vf7f+txlLFpdB9rDCNoxROanJZQs/LscATlOqlfAqX7YMmkz1JgFjAXgD+EaOfhxsaSHx9rs8iu1cYDZYIoZVRsweSq9c5HuCSMrwR72CJEz7KazogTw8Qz/loHs/J57Q+52WU/8d3VtSEMUkWlvcBd/3z89CxLBIjwOLeDRY+5j9cB//9/DY9YTHTPZ7kfotUVwkPeDxYPQfclDi7
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:user-agent; s=f4ac.5ecd3468.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=hUMOB/942iSihW1ehE9kk8JfORnjX5WMpNkotwAPWlw=; b=r1XcqS9J+Ij6zlt37EYl8z3A+oLU/kBF6Rzp1zSn6hYYdyfzfO9PsmRB0us3A4QeRWzPPHGk2R9ywM7830IVFa22InD3DmoCClBkr8YlTLPLPn2ApoS+PFVx8Uze8Ib36cEDWkXuA1S8lkYF3bs1DQM1YP9sJE8Kk9R2jSMo82FA439ijVCY2ldsjEx29f3jGSM0ju1DEakyISmXXedGFp2Fn/8Np0xOEv1F2rLb3tpcaKBNS9emYMJPMwzoNXIv
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; 26 May 2020 15:23:19 -0000
Date: 26 May 2020 11:23:19 -0400
Message-ID: 
From: "John R Levine" 
To: "=?UTF-8?Q?Martin_J=2E_D=C3=BCrst?=" 
Cc: Rfced-future@iab.org
In-Reply-To: <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp>
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org> <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp>
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 15:23:25 -0000

>> So we publish updates to updates to updates, and almost never do 
>> consolidated versions like they are being done in lawmaking.
>
> Yes, true, but in order to do what they do in lawmaking, we would have to 
> write the original stuff way differently. In law, at least in the 
> jurisdictions I'm familiar with (which is an extremely limited set, and by 
> the way, IANAL), every article, and for bigger articles, its subarticles, is 
> labeled carefully. There is also a system to insert new paragraphs between 
> between existing ones (to insert a new article between article 22 and article 
> 23, label it e.g. article 22.bis,...).

Legislatures have an entire staff dedicated to organizing and codifying 
the laws, who have extensive legal experience so they can do so while 
keeping the sense of the laws.

It would be nice if the IETF could do that, but it seems rather unlikely.

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 May 26 08:39: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 DA3093A064C for ; Tue, 26 May 2020 08:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=C5KEil4E; dkim=pass (1536-bit key) header.d=taugh.com header.b=aPc0v/X+
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVJWyOlGw_6p for ; Tue, 26 May 2020 08:39:20 -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 EAD483A0602 for ; Tue, 26 May 2020 08:39:19 -0700 (PDT)
Received: (qmail 64821 invoked from network); 26 May 2020 15:39:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fd33.5ecd3827.k2005; i=johnl-iecc.com@submit.iecc.com; bh=wrzSY0NFDmYnKVoQ9mwUrJry1gwf2JAHOrxYd0kCvPE=; b=C5KEil4EjD3OeovCkDh/6tNR/G4VbOVIvyQ1M2a4MeUXONObleYSPayuQybl/Uts5AnkGDBLlcOYzV/9y/Wz99uCsMyi64erZBLRIGgiVz14L2IcuTHPFkr21NOkNKgzDA3pHZp/dR13XFiz8HrcLvUnTtSgDCOGnbkc2RNTaHZG6rWLFtyMHE1HVf9Wsgg3F3/rhtPSPxDwewHTXr6/aG1NbX7j/2D3nAOE3TTi//DSRMOHPo+8PHUHMm85yf1z
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:user-agent; s=fd33.5ecd3827.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=wrzSY0NFDmYnKVoQ9mwUrJry1gwf2JAHOrxYd0kCvPE=; b=aPc0v/X+/Vk4Vo94YU16Fuezqfpf+iynFtN8H8hOGYEiFYOP2CuwLmC8Xj4PYcXSxD/xVqhQl60wH2uSb1ayKFNuOh68/ZvMnxuZlokA4bfInQQlsLMDAMQZr2LKX7Es10Zp+KhWjPz4CLqhxGRh03YAM9pviHnmNjjgnEcZn4dQWixIHGe2cKZlgnYdBiihD4AfMtRodilmkd8LZS0xeIiZdTUK19wc97FwieoobkmSP0EYoA7iLHRt6+SUXd1x
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; 26 May 2020 15:39:18 -0000
Date: 26 May 2020 11:39:18 -0400
Message-ID: 
From: "John R Levine" 
To: "Mark Nottingham" 
Cc: Rfced-future@iab.org
In-Reply-To: <3D974AB5-AF98-4A50-B24D-D5690629019E@mnot.net>
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org> <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp> <3D974AB5-AF98-4A50-B24D-D5690629019E@mnot.net>
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 15:39:22 -0000

On Wed, 27 May 2020, Mark Nottingham wrote:
> Oh, I disagree. Statutory drafting is a beautiful thing to see (at least in some jurisdictions), and we could learn a lot.

Take a look at the Consitution of the State of Alabama in the southern US. 
It was enacted in 1901, and has been amended 946 times.  It is 310,000 
words long, of which 90% is the amendments.  It centralizes authority in 
the legislature and gives almost no power to counties which might 
otherwise vote for, you know, inappropriate people.  Much of what would be 
state law in other places is written into the constitution so requires the 
tedious amendment process to change.  (Amendment 946 sets the salary of 
the sheriff of one county.)

I wish this reminded me less of the IETF.

http://alisondb.legislature.state.al.us/alison/codeofalabama/constitution/1901/toc.htm

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 May 26 09:36: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 42CDD3A082E for ; Tue, 26 May 2020 09:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae_8zjxs44hI for ; Tue, 26 May 2020 09:36:46 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8A73A07E5 for ; Tue, 26 May 2020 09:36:46 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id b190so10390927pfg.6 for ; Tue, 26 May 2020 09:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=XGn9NaVLUOHbBJyZAPUNBUWLbrlZXIxWvps7rjaYmsY=; b=cUd97MYCZroS1IY73Y1rRThM+WDPlcCn4qITd8o+3Khu2XKWr7xufUCYwejEcxOa26 6JtvvtZJilGkfOmMwq/bzqkDCiRWz9wO+Rirw1QweCbqaHPnjWEjQs0U5St+SOHv2v4Z hjdAPr38zR4acX05ZzOPwUmvyYQ7xl/53BbQ1hrQBhFiqZaznEO9DPvJMraOgGvJG7zN ZAHZRx2QIMctRk+CytHWeQHxDl+2hnR6etF3Eetq2Wh8MKidlGo92Y5VZrGyf/caGOfe jZj9SUWmgDETjhAtlO2MR7RpTRmeUExaYGwyY9mNvSsoryDEIpufj0tCF9a5zWKT6dGJ LDog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=XGn9NaVLUOHbBJyZAPUNBUWLbrlZXIxWvps7rjaYmsY=; b=qqNK7cdgMS4WGa9yo/sVRF246XUUikZ8p3S2i75y24L7YVgxIm/Ho7liZALFb6YSdF sqO5qI5zAzIqh1IMy+EyO8EJ2mFNyb0VMsgL7qXmWDiTi7rVATFa5MgQQ0YAMOSfOsB7 Q+f4pzAxVGplZronntNr71bIEBFrv8NFjMwrsVDQd5c1143UDub5LjdyWdAab4PQAtnY nxsNZ1h6mK5h1cyBF3npL/trhQFlGnm1i8Q0BCtTMhowo7ct2M34U5NXjwNjaY7HMZG5 7qHj9ItlCxzK21w1d7tF7OiJ6b5e4P/I4iJjQwF2S3knIXyNVh8/RFvMDfnp64GVL3OD 28vw==
X-Gm-Message-State: AOAM53183ilqr2GMxCbNEWf44NEUKhGJKVB75DuVGc9oQwj0DSQJrNLp FCYnYFgCCZ9YzyVWquo81CdrV/C56hdpzlo=
X-Google-Smtp-Source: ABdhPJxGaAESfb/LJA0uQIBw1i88e6yUFTcknwAKhFxfoLUbUgfhWz62wfDXGc7eiXkJVPRFXWrGTw==
X-Received: by 2002:a63:8c51:: with SMTP id q17mr1727820pgn.1.1590511004795; Tue, 26 May 2020 09:36:44 -0700 (PDT)
Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id n19sm29614pjo.5.2020.05.26.09.36.43 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 09:36:44 -0700 (PDT)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: rfced-future@iab.org
References:  <2507455b-a835-52fc-76e5-917ab2070288@gmail.com> 
Organization: http://SoftwareAndServices.NET
Message-ID: <560f3131-ea42-bb91-b1ea-730d15211eff@gmail.com>
Date: Tue, 26 May 2020 10:36:43 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------5F28DB6412F79D6633C3FAD2"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 16:36:48 -0000

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

On 5/26/20 12:16 AM, Carsten Bormann wrote:
>> Eliminate, when possible text and references like "foo: like used in RFC-#old paragraph 16.3" when a copy/paste would work. Reduces the documents that need to be read.
> Beautiful example for why this problem is so hard.
>
> People executing on something like the recommendation above is a big source of interoperability problems.  Because the copy/paste didn’t contain all the information referenced, was rephrased in the editorial process etc., doesn’t get updated together with the original, it tends to create a subculture that is different from the original.
> (Read up on software clones to know why this is a such a bad idea in general.)
>
> No, don’t copy/paste, unless the original really only is an inspiration and not a reference.

Yes, Until RFC-#old is updated, then the ambiguities double. Must I link to old library? Or when the library I link to is updated, will it use the RFC-#new definition and will my implementation break?

I am not proposing the editor creates them, I am proposing the editor questions them before publication, especially if they seem to be confusing. If the editor or someone in the publication loop knows knows that RFC-#old is being updated, or has an active WG or draft, or when it really should have been a copy/paste.

And yes - what a mess.

There is *no* DNS specification, and that is critical and core to the Internet. Same with SMTP, IMAP, and VoIP, ...

At some point, this is going to be a big problem. And yep, no one is responsible now. But maybe, deliberate questioning some of this practice in drafts before publication will help the WG that will eventually fix it.

> I note that the discussion here also conflates revisions of documents with “versions” of a specification, which in many cases really are collections of “features”.  Long story that comes up more forcibly when one wants to employ formal description techniques.  My summary of that story is well known to be “versions are stupid”.  (Which we partially seem to know: RFC 8200 does not create IP version 12.)
>
> Which features are “core” to a specification ecosystem is not always decided at the time the features are defined.  Deployment experience, the market, emerging (often unfounded) perceptions etc. also play a role here.  I don’t think we (as an organization) have even started to understand our role in ecosystem management as different from that of a specification writer, even though the successful shepherds of ecosystems certainly have.
>
> I don’t think the RFC editor can even remotely be the person pushing all this evolution forward.

-- 
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

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


  
    
  
  
    
On 5/26/20 12:16 AM, Carsten Bormann
      wrote:

    

    

      

        
Eliminate, when possible text and references like "foo: like used in RFC-#old paragraph 16.3" when a copy/paste would work. Reduces the documents that need to be read.


      

      
Beautiful example for why this problem is so hard.

People executing on something like the recommendation above is a big source of interoperability problems.  Because the copy/paste didn’t contain all the information referenced, was rephrased in the editorial process etc., doesn’t get updated together with the original, it tends to create a subculture that is different from the original.
(Read up on software clones to know why this is a such a bad idea in general.)

No, don’t copy/paste, unless the original really only is an inspiration and not a reference.


    

    
Yes, Until RFC-#old is updated, then the ambiguities double. Must
      I link to old library? Or when the library I link to is updated,
      will it use the RFC-#new definition and will my implementation
      break? 

    

    
I am not proposing the editor creates them, I am proposing the
      editor questions them before publication, especially if they seem
      to be confusing. If the editor or someone in the publication loop
      knows knows that RFC-#old is being updated, or has an active WG or
      draft, or when it really should have been a copy/paste.

    

    
And yes - what a mess.

    
There is *no* DNS specification, and that is critical and core to
      the Internet. Same with SMTP, IMAP, and VoIP, ...

    
At some point, this is going to be a big problem. And yep, no one
      is responsible now. But maybe, deliberate questioning some of this
      practice in drafts before publication will help the WG that will
      eventually fix it.

    

    

      
I note that the discussion here also conflates revisions of documents with “versions” of a specification, which in many cases really are collections of “features”.  Long story that comes up more forcibly when one wants to employ formal description techniques.  My summary of that story is well known to be “versions are stupid”.  (Which we partially seem to know: RFC 8200 does not create IP version 12.)

Which features are “core” to a specification ecosystem is not always decided at the time the features are defined.  Deployment experience, the market, emerging (often unfounded) perceptions etc. also play a role here.  I don’t think we (as an organization) have even started to understand our role in ecosystem management as different from that of a specification writer, even though the successful shepherds of ecosystems certainly have.

I don’t think the RFC editor can even remotely be the person pushing all this evolution forward.


    

    

    
-- 

      Doug Royer - (http://DougRoyer.US)
      Douglas.Royer@gmail.com
      714-989-6135

  


--------------5F28DB6412F79D6633C3FAD2--


From nobody Tue May 26 09:54: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 7909F3A09DC for ; Tue, 26 May 2020 09:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYZ52TYQTKJC for ; Tue, 26 May 2020 09:54:14 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 7BE063A09D7 for ; Tue, 26 May 2020 09:54:14 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id v19so251770wmj.0 for ; Tue, 26 May 2020 09:54:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jBG9N+Wc2myh8jk7uRAW/mupt0O/cBqKmejIf+vdFQs=; b=YjeblE/ovSdUUrF+Xyz1pMKIZuXJE6uKXGbhOf7BRJE7fsS/DhEKFfEqS/SEBaDTtE waU1cc0CTD5oTmZ2iFJMjuvFeZtJROm7Qf3qcEYTnRwdQ5yP4FCMn47iASrUhmTnR65N 4OhBJX2JFCkr8vpArPA3cKdz64woiaZIEF4wxa/emlxKlcmE/B5zMfLRrn+R18/SWFGM TJhX8WMLkpQVWJN1Ojg4RYdFkNVVpQS8Qmy4++a6+ai8WnWMKfNM8mknA2ApzRvDhbiP 1tGR3wJ5zqrbtZt1fVz9/NmA56nt/OXLl2oIA1IQsoPr8K2U8J5zV6PGFz/rvn+Thxfc HqiQ==
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=jBG9N+Wc2myh8jk7uRAW/mupt0O/cBqKmejIf+vdFQs=; b=b2UJ3kXXFqXZMWNIOLol8gZ2BwleEI4811zwwDQwspa1rpwtnUJmknjC27WcyJDjXO AF3tY6b8u9vYwgh3cOItMN3FeC6zS42qe3LhbGEsgTz0bKM48RSzFm71NZs1+oma7Fhp /ThMChNFcsYVedf33PjxM5Bbfmp3HGnX3FhlBcQZO91/fhdXVMpagq15TDpBNVbXYixT cFSPY4LwljpcZWOiaXTeKDvAyKyguG7S/vmjzvqGZf9L1JtvTNB9zfpgG7OtyPweWxf/ i+s5ZlUpHkR+0GU0bMslMWql2pROtcJqVAVHDKt/5IcPHlgc540BwCbgLYfcY3fd0clu HRJQ==
X-Gm-Message-State: AOAM532QHoWftMogdI+ssDW1ANKjNwjoUOppnK9MuLklgrHSTfeilZZh bYU/3A97j3H/qQWV4WmOIWg=
X-Google-Smtp-Source: ABdhPJwur+KFHTcwL75Zo3nnCdprnrV2oVsNLnsWxGTzsThXk4Tc73a33XY1cJPK80smKZPR8dqOXQ==
X-Received: by 2002:a1c:d7:: with SMTP id 206mr135543wma.15.1590512052880; Tue, 26 May 2020 09:54:12 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:6cd2:f69d:7f87:8b5a? ([2601:647:5a00:ef0b:6cd2:f69d:7f87:8b5a]) by smtp.gmail.com with ESMTPSA id i6sm76129wmb.41.2020.05.26.09.54.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 09:54:11 -0700 (PDT)
From: Bob Hinden 
Message-Id: <59D1FF7F-53EF-4FA4-9821-B82A86FBB884@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_7EBC1B20-13E8-48CC-B382-EEF8EA081592"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 26 May 2020 09:54:08 -0700
In-Reply-To: 
Cc: Bob Hinden , Rfced-future@iab.org
To: John Levine 
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org> <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp> 
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 16:54:17 -0000

--Apple-Mail=_7EBC1B20-13E8-48CC-B382-EEF8EA081592
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

John,

> On May 26, 2020, at 8:23 AM, John R Levine  wrote:
>=20
>>> So we publish updates to updates to updates, and almost never do =
consolidated versions like they are being done in lawmaking.
>>=20
>> Yes, true, but in order to do what they do in lawmaking, we would =
have to write the original stuff way differently. In law, at least in =
the jurisdictions I'm familiar with (which is an extremely limited set, =
and by the way, IANAL), every article, and for bigger articles, its =
subarticles, is labeled carefully. There is also a system to insert new =
paragraphs between between existing ones (to insert a new article =
between article 22 and article 23, label it e.g. article 22.bis,...).
>=20
> Legislatures have an entire staff dedicated to organizing and =
codifying the laws, who have extensive legal experience so they can do =
so while keeping the sense of the laws.
>=20
> It would be nice if the IETF could do that, but it seems rather =
unlikely.

Don=E2=80=99t forget that you also get police to enforce the laws, and =
lawyers and courts to interpret them.    Though, I have been in some =
debates lately on IETF lists that look a lot like the latter :-(

Bob



>=20
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. =
https://jl.ly
>=20
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


--Apple-Mail=_7EBC1B20-13E8-48CC-B382-EEF8EA081592
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl7NSbAACgkQrut0EXfn
u6hEpAf/U/4G3HZc2j9kGlTgUr25yNJtCQeH7W/YvhRmj2ECjX47VKwGj1jCXaP+
Jn3ESXMdrQ+rk840otN5Qf+blaQ8TuryDkVd+98iGX0gaDeBgQ3ewMkqEcdRJAas
EKMj+HRgoeMAbwrSUxVTro5MLPOILBsA3dXa8lH5+f4QEPOGsC/R1Q5G2+VBExW9
BMUVNGWOMd5buTvwUMtkjHxg0MB49nTs+DJPbsydu6GkDkGYTlJ10as71/wyBqBV
ETxIJ8mvIRjmAFHtBd9MjfkI+a8bECkGVqnx6bmy2IuDuxTetU4DucGLluFNThXP
/vSPo8HFKYhK8XTrG8vvv6AB9nZdog==
=0REe
-----END PGP SIGNATURE-----

--Apple-Mail=_7EBC1B20-13E8-48CC-B382-EEF8EA081592--


From nobody Tue May 26 10:02: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 311953A0AB0 for ; Tue, 26 May 2020 10:02: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J2q7b_VNfnA for ; Tue, 26 May 2020 10:02:24 -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 2C9253A0AC1 for ; Tue, 26 May 2020 10:02:19 -0700 (PDT)
Received: (qmail 83537 invoked from network); 26 May 2020 17:02:18 -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=1464f.5ecd4b9a.k2005; bh=ot4riT1Zf9VRYuYHOvtAn4frl9wMlk6QgyGxnKvlCnE=; b=Z8MSRtI3zEqlsWx+igVX6tvWvdU1gb3Pf1xq1sb/Vvagj698ZiKs8TnQpptLOQRsTsk43T4xUIlLWFAoYUlAcTOD3bW9peog9X9b2XgUY8VYopCnUxISmdN6hKMsYR3geWhq2rP+xDRCbQ2ED3YDprcb5miY7rRK+Up7SmNUmCKpaUc9ZTDls28ZcopCSQlhU4DItkJpDtwga6U74yImMvLa6osvI1dgaE5a3bn9+/LhPzRqofPkWK2HHUzvtgvT
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 26 May 2020 17:02:18 -0000
Received: by ary.qy (Postfix, from userid 501) id 0F0BB19A1F83; Tue, 26 May 2020 13:02:17 -0400 (EDT)
Date: 26 May 2020 13:02:17 -0400
Message-Id: <20200526170218.0F0BB19A1F83@ary.qy>
From: "John Levine" 
To: rfced-future@iab.org
Cc: jmh@joelhalpern.com
In-Reply-To: <347a8c3b-169b-cda9-637e-45e49ccd2805@joelhalpern.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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 17:02:26 -0000

In article <347a8c3b-169b-cda9-637e-45e49ccd2805@joelhalpern.com> you write:
>I am uncomfortable with the assumption that "RFCs may be amended".  That 
>opens the door to much larger changes than eratta, which is not 
>something I want, nor something on which I think we have agreement.

I was actually thinking of version numbers or number+date, but based
on the discussion so far, we don't seem to have strong agreement
either way.

FYI, as we shake out the changes to the v3 XML vocabulary, it is
likely that we will want to republish the existing XML RFCs with
different coding to match the final vocabulary. The text wouldn't
change, just the codes.  Is that an amendment?

R's.
John


From nobody Tue May 26 10:05: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 BE8AB3A0AFB for ; Tue, 26 May 2020 10:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va4Ewv_-wHVU for ; Tue, 26 May 2020 10:05:41 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A00B3A0AAC for ; Tue, 26 May 2020 10:05:28 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id l11so21209218wru.0 for ; Tue, 26 May 2020 10:05:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PeTJawuGdiOg+qJFaT+ciV1betqcEwE3R/e+MWrWxpI=; b=XWME6Rh+GQwK0xn1Lpoz3TK7c9LR+OG2mMdxZhxVOh/chbp51EIgXNiqh8hQuBRGsi LIPLUoSTzEZ2osCW/RSIUyTR29sbR6Ec5xroIMvGO/vHyzNnANJGK0EpN90xIQRo9IQ8 P6BYOA0VjRrq1BM5uDiyFTVMMY7OaVmdiV2ysP5KVQmtOJ67ZL/gf2/Cfo5eZZCD2+Em yFnBax3mErBUfM/wSxuJjnOMy5MWs2hk257o8sMAoFGTS3oBAzH7xGE9RddbIRJ6cdA9 QTOsA+GbLXw878C8kFbdx/z5TVSx/fBBMqdIvFvu6FLgxlw9iUyQlFTtlhO3T7lVMAAn xUbA==
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=PeTJawuGdiOg+qJFaT+ciV1betqcEwE3R/e+MWrWxpI=; b=F7hniLjcfqcKjN+nGCuPbY1sXw5CExL3WHhROdbvbujz0PN4XZVzVHZLWIfegEcYEP rX/cHr7DuxLM0Outd96dMAxuV7cJfM//4asbN4w9K/HtO/dEsEMk7S0ctGECpIZMeKEX sLdf+HgrB9WALPIoyUMF6Vdhr+99b7f+jZwDnylvlouU6R9bUAzIv8FitdCn3wX+H1CM k5ZvzSD4/RovPUsXtZbAALANL5GG/rvJ5k/+oxoMvrHyHoS6Kt3iIU0mrDPOaosT2Phf YRZPSzBteBV3p5oKBjszSnHS/RwrXnfKDLS9zlxhAuYPlYoAtU/RahN8aggVD2CqEz28 8Q9w==
X-Gm-Message-State: AOAM530FvIOxO4jXK6DuZkF56xhki9KoOfGh277mlWH1+GmI39GByKY2 605IjKdTNGxYrkHkQSDSKTY=
X-Google-Smtp-Source: ABdhPJz7JcceLDfHetOuUXSrVPTWrU+JkKJGfS6Fd/imQAChD3JWz5WB6LnMCbjG/BZwWTxX7WcuOg==
X-Received: by 2002:a5d:690b:: with SMTP id t11mr6359571wru.213.1590512726669;  Tue, 26 May 2020 10:05:26 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:6cd2:f69d:7f87:8b5a? ([2601:647:5a00:ef0b:6cd2:f69d:7f87:8b5a]) by smtp.gmail.com with ESMTPSA id y5sm428384wrs.63.2020.05.26.10.05.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 10:05:25 -0700 (PDT)
From: Bob Hinden 
Message-Id: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_3F8443B6-85B1-4783-8CA6-925F353CC6F9"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 26 May 2020 10:05:19 -0700
In-Reply-To: <5935570c-54f7-ae3d-a47d-7b49d9f68690@huitema.net>
Cc: Bob Hinden , Brian Carpenter , Doug Royer , rfced-future@iab.org
To: Christian Huitema 
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <18740cff-425c-f1cb-37d3-e3ea80bb343f@gmail.com> <8b383696-46b0-3023-b1fb-b42095e26758@gmail.com>  <421bf636-3c1b-faac-ba09-9dc8af1a0c9d@gmail.com> <5935570c-54f7-ae3d-a47d-7b49d9f68690@huitema.net>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 17:05:43 -0000

--Apple-Mail=_3F8443B6-85B1-4783-8CA6-925F353CC6F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Christian,

> On May 25, 2020, at 9:53 PM, Christian Huitema  =
wrote:
>=20
> On 5/25/2020 7:39 PM, Brian E Carpenter wrote:
>=20
>> And for our business here: is progress-chasing at the RPC a job for =
the RSE, or for IETF LLC that holds the RPC contract?
>=20
> The current structure is a little weird. The RSE is in theory in =
charge,
> but in practice is not managing contracts or budgets. Things would be
> clearer if the LLC was clearly in charge of what amounts to executing =
a
> contract according to performance targets, and if the RSE could focus =
on
> issues like formats and errata.

If I remember correctly, the LLC was supposed to be board, so it would =
be the IETF Executive Director who would do this.   Even then, does the =
IETF Executive Director become knowledgable about about the details of =
the operation of the contracts, or does some other group like what Mike =
proposed in the RSEB make recommendations to the LLC.

Bob


--Apple-Mail=_3F8443B6-85B1-4783-8CA6-925F353CC6F9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl7NTE8ACgkQrut0EXfn
u6h7tQf+NLQ0Kt02evu3MUqL4ix+/jyN15zhgsfWQ7L+b9mlnQRdZEADukxOelCB
r6BQftiuRq+fushhDxSRgVEoD7ZgpHPTCRQ5Pwds6jZ6keTBJ2D9hj+SXmtaszJO
IXfAHFO8KrNPtXliEoOdP240CBKS40WJT3+W8FU38fr22KQ0SkazBuWbf313MsyX
vTEaDXvLp1nHrjId+4dRi5PVz+4J9xXRvYKUp1RKp66IbkhRUJWmkwhWD/xPjWfZ
Dun70KoR/fMIQCPE4bALaFmu5NrpxqhoPaU/gDqj0E+UheG3BLGyFaIKvG9LaQJF
/VSnCHeSMh7Soen7TlFLRUNJoo40Qg==
=JfjV
-----END PGP SIGNATURE-----

--Apple-Mail=_3F8443B6-85B1-4783-8CA6-925F353CC6F9--


From nobody Tue May 26 10:45: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 C88AE3A0AB8 for ; Tue, 26 May 2020 10:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 CztFQgGOEvky for ; Tue, 26 May 2020 10:45:45 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52183A0AAC for ; Tue, 26 May 2020 10:45:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49WhFj4bBCz1nsjS; Tue, 26 May 2020 10:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590515145; bh=upn624TlFRP/aAskIz8bZDBBZBBmYWHiQdTayi1wtIE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=plKIkSa51rl0+MihwClXSG1VPTi4Ay+2eky7L+YB0KP6Czq4ZrTVDq7WvnT+vJEZC x9YShLwyQmrbhTpVUQ5Wvjx0lP5oaIgRJ04u7rNviJrNwbaIdsVvECM+QNW+TRMTML Add0sY6qaU4ZS9Eoc3aJlL9yTKS/6JNG5IZKslsc=
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 49WhFh6wY9z1nsTs; Tue, 26 May 2020 10:45:44 -0700 (PDT)
To: John Levine , rfced-future@iab.org
References: <20200526170218.0F0BB19A1F83@ary.qy>
From: "Joel M. Halpern" 
Message-ID: 
Date: Tue, 26 May 2020 13:45:24 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <20200526170218.0F0BB19A1F83@ary.qy>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 17:45:47 -0000

I do not know of any procedure or agreement to change the XML for 
existing RFCs.  The agreements to date do include provisions for 
republishing rendered versions.  But if you claim to need to change the 
XML, as far as I know that would need to be a new RFC.  Could we create 
a simpler review procedure than IETF last call to confirm that you havbe 
not changed the content?  Probably.   But even a full RSE would not have 
the authority to do that unilaterally.

Yours,
Joel

On 5/26/2020 1:02 PM, John Levine wrote:
> In article <347a8c3b-169b-cda9-637e-45e49ccd2805@joelhalpern.com> you write:
>> I am uncomfortable with the assumption that "RFCs may be amended".  That
>> opens the door to much larger changes than eratta, which is not
>> something I want, nor something on which I think we have agreement.
> 
> I was actually thinking of version numbers or number+date, but based
> on the discussion so far, we don't seem to have strong agreement
> either way.
> 
> FYI, as we shake out the changes to the v3 XML vocabulary, it is
> likely that we will want to republish the existing XML RFCs with
> different coding to match the final vocabulary. The text wouldn't
> change, just the codes.  Is that an amendment?
> 
> R's.
> John
> 


From nobody Tue May 26 10:56: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 A7BE53A0829 for ; Tue, 26 May 2020 10:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjRiwWiOnn16 for ; Tue, 26 May 2020 10:56:33 -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 2E30D3A0808 for ; Tue, 26 May 2020 10:56:33 -0700 (PDT)
Received: (qmail 96419 invoked from network); 26 May 2020 17:56:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=178a0.5ecd584d.k2005; i=johnl-iecc.com@submit.iecc.com; bh=BL4Esb+cVniDjwJNhti1NSAeLLjpvOyPh5ub/V04cK0=; b=mj2fdTwOuIhR9u+gDqHenH8ul6FyST6H3jUzGq0vnIM2sRgrk2tH8DhFOo4x4dma9gPpJw36Y1N/3siXHbxrGkiO6eXRj6m9GDndOUz5bkSO238qmwTN6YkOLuKsC2Wt9UszDgKV6loCnK1YARlzF6JJrHvNo9Rg8TOPd0iB/hVoHviL/mkTCZMex6FEbPqCVxbqNR006UZneYAO4WD0NqqB9JGda/+7z+TnqmFUnnUgFHC1mCTLlM9DncHmVwtJ
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; 26 May 2020 17:56:29 -0000
Date: 26 May 2020 13:56:28 -0400
Message-ID: 
From: "John R. Levine" 
To: "Joel M. Halpern" , rfced-future@iab.org
In-Reply-To: 
References: <20200526170218.0F0BB19A1F83@ary.qy> 
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 17:56:35 -0000

> I do not know of any procedure or agreement to change the XML for existing 
> RFCs.  The agreements to date do include provisions for republishing rendered 
> versions.  But if you claim to need to change the XML, as far as I know that 
> would need to be a new RFC.

If that is true, we need to fix it because putting the XML changes through 
anything beyond a lightweight technical review of the XML would be a huge 
waste of everyone's time.

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Tue May 26 11:03: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 27BB23A0B6E for ; Tue, 26 May 2020 11:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CynrwnHfzgn for ; Tue, 26 May 2020 11:03:29 -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 248483A0B70 for ; Tue, 26 May 2020 11:03:27 -0700 (PDT)
Received: from xse358.mail2web.com ([66.113.197.104] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jddv3-0001ih-Fh for rfced-future@iab.org; Tue, 26 May 2020 20:03:25 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49Wh9B0FHpz6MpS for ; Tue, 26 May 2020 10:41:50 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jddaH-0002pn-UQ for rfced-future@iab.org; Tue, 26 May 2020 10:41:49 -0700
Received: (qmail 16018 invoked from network); 26 May 2020 17:41:49 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.46.233]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 May 2020 17:41:49 -0000
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Christian Huitema 
Mime-Version: 1.0 (1.0)
Date: Tue, 26 May 2020 10:41:48 -0700
Message-Id: <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net>
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com>
Cc: Brian Carpenter , Doug Royer , rfced-future@iab.org
In-Reply-To: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com>
To: Bob Hinden 
X-Mailer: iPhone Mail (17E262)
X-Originating-IP: 66.113.197.104
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/gcnlw0cz3TYWAMatow42l8TcmTKWpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4jWV7ZfrBW6iDoYSo6QC2CRQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuE/oVmIjiUjKW4wTbK4KINs+42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGZNFSBymhtbd6ygEffuU1+3EbilPGcyP4k6t/ikhe7HTiGKQkVnE47wpH2uAj8WRV7B H1fP3YU+2XWwKzL04bcfwzQZWnqpeh+UbGCVNeqba5Xked+P+aSZU/EB7YnRWs2LBDMrD7q/cJog wbqzsuokjR9gVRghbRvLCr2HAX7fUE7JPy9twDyaj6un7qWOkNeS+JMIdDO1rs/faRtQvAYc1FyX Gtt/hhK88WnFvYEzfePXdRjeeYOc4D1auWIFhSHecrm2hh9ZmaWcRkVZPPVJw6nIoDr0sXUZ7YZo 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] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 18:03:37 -0000

> On May 26, 2020, at 10:05 AM, Bob Hinden  wrote:
>=20
> =EF=BB=BFChristian,
>=20
>> On May 25, 2020, at 9:53 PM, Christian Huitema  wrot=
e:
>>=20
>>> On 5/25/2020 7:39 PM, Brian E Carpenter wrote:
>>>=20
>>> And for our business here: is progress-chasing at the RPC a job for the R=
SE, or for IETF LLC that holds the RPC contract?
>>=20
>> The current structure is a little weird. The RSE is in theory in charge,
>> but in practice is not managing contracts or budgets. Things would be
>> clearer if the LLC was clearly in charge of what amounts to executing a
>> contract according to performance targets, and if the RSE could focus on
>> issues like formats and errata.
>=20
> If I remember correctly, the LLC was supposed to be board, so it would be t=
he IETF Executive Director who would do this.   Even then, does the IETF Exe=
cutive Director become knowledgable about about the details of the operation=
 of the contracts, or does some other group like what Mike proposed in the R=
SEB make recommendations to the LLC.

Let's set aside the discussion of whether we need a special board and just l=
ook at the RFC function. In the current state, the RSE proposes a set of met=
rics to evaluate the RPC, in terms of delays and load such as number of docu=
ments or pages per month, and the RSE also provides a monthly report showing=
 how the RPC is meeting the negotiated metrics. And then the RSE is supposed=
ly evaluated on how well the RPC performs.

IMHO this setup is fraught with latent conflicts. These conflicts only appea=
r of course during times of tension, such as when RPC productivity is affect=
ed by the arrival of big document clusters, or by spec changes that require r=
etooling and retraining. When that happens everybody gets frustrated. Docume=
nt authors and the IESG resent the long publication delays. The RSE is in th=
eory in charge but cannot easily increase the RPC budget. The RPC is doing i=
ts best but does not control the incoming load or the changes in tools. The t=
ools team gets to deliver on the new spec with the old manpower allocation. E=
tc.

I think we have to address the root causes of these frustrations. I think th=
at means separating clearly the specification functions of the RSE and the p=
roduction functions of the RPC, the latter being controlled by the LLC witho=
ut squeezing the RSE in the middle.

-- Christian Huitema



From nobody Tue May 26 11:12:53 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413AD3A0E02 for ; Tue, 26 May 2020 11:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bn1tvV9MbRHw for ; Tue, 26 May 2020 11:12:51 -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 34D373A0E01 for ; Tue, 26 May 2020 11:12:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49Whrz0hG8z1ntmt; Tue, 26 May 2020 11:12:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590516771; bh=rYAAt6k/IYAVmD6oZKJlwTrA7cX9+GEeIJ+FqJSGKQs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=AzFW0vrxQ2dQe9E76v2dRaSsJp+Z9+HZY+qwgLutkciYke8tWyqaGslwEdH8prHlG 0fq8RlimTkJGUF5WOpXWgbH9cd/d+OM0cH5sNp/rDv2dF1u568JZYum/8SyTynKxqE FOcGr60UyCWXyNNbmPBw8GrfQ6s3e4sOOeMCYVAk=
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 49Whry485zz1nxQP; Tue, 26 May 2020 11:12:50 -0700 (PDT)
To: "John R. Levine" , rfced-future@iab.org
References: <20200526170218.0F0BB19A1F83@ary.qy>  
From: "Joel M. Halpern" 
Message-ID: <1e869abb-5c24-9ea9-00c4-05018cb7486d@joelhalpern.com>
Date: Tue, 26 May 2020 14:12:31 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 18:12:52 -0000

As far as I know, what I stated is the rules.  And while creating a 
solution for the problem you face sounds reasonable, it also is outside 
the scope of this email list.  It seems that you need to talk to the 
stream heads.

Yours,
Joel

On 5/26/2020 1:56 PM, John R. Levine wrote:
>> I do not know of any procedure or agreement to change the XML for 
>> existing RFCs.  The agreements to date do include provisions for 
>> republishing rendered versions.  But if you claim to need to change 
>> the XML, as far as I know that would need to be a new RFC.
> 
> If that is true, we need to fix it because putting the XML changes 
> through anything beyond a lightweight technical review of the XML would 
> be a huge waste of everyone's time.
> 
> Regards,
> John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly


From nobody Tue May 26 11:22: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 82CD93A0A9E for ; Tue, 26 May 2020 11:22:12 -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 Z83vH3KO2YTf for ; Tue, 26 May 2020 11:22:11 -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 099883A0A9C for ; Tue, 26 May 2020 11:22:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=473; q=dns/txt; s=iport; t=1590517331; x=1591726931; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=x7a7BitoPXtjq7D2nOHoQH6ZYHPM/QtyLnNDoyvKAzw=; b=SOXKBVpzAn1eip0tVFnZfrFRunNfWRjGB6JpQmb899xu8NplyRusMT2v 9u8UCCTY8Fdkv/3FRgpjzSb6i10xacjQMdmP49DKDCsuMq4iXzTmC62KE iEXPGZeUV+47SCbua9E5SzoNb+TMY2W1uU6h6Lzld7UweoLpOcylrRui6 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAADiXc1e/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTYEAQELAYNuASASLI0miAqZfoFoCwEBAQwBAS8EAQGERAK?= =?us-ascii?q?CMzcGDgIDAQELAQEFAQEBAgEFBG2FYoVyAQEBAQIBOj8FCwsYLlcGExuDC4J?= =?us-ascii?q?dIK1BdIE0hVGFGoE4AYxdggCBOByCHy4+hBkBEgEhg0eCLQSzJYJegnSVaB2?= =?us-ascii?q?CUgGNc408qmeDSQIEBgUCFYFoI2ZwMxoIGxU7KgGCPj4SGA2fCj8DMDcCBgg?= =?us-ascii?q?BAQMJjVUBAQ?=
X-IronPort-AV: E=Sophos;i="5.73,437,1583193600"; d="scan'208";a="26532023"
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; 26 May 2020 18:22:07 +0000
Received: from [10.61.225.84] ([10.61.225.84]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04QIM6ej021534 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 May 2020 18:22:06 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Eliot Lear 
In-Reply-To: <1e869abb-5c24-9ea9-00c4-05018cb7486d@joelhalpern.com>
Date: Tue, 26 May 2020 20:22:06 +0200
Cc: "John R. Levine" , rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20200526170218.0F0BB19A1F83@ary.qy>   <1e869abb-5c24-9ea9-00c4-05018cb7486d@joelhalpern.com>
To: "Joel M. Halpern" 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.225.84, [10.61.225.84]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 18:22:13 -0000

Joel

> On 26 May 2020, at 20:12, Joel M. Halpern  wrote:
>=20
> As far as I know, what I stated is the rules.  And while creating a =
solution for the problem you face sounds reasonable, it also is outside =
the scope of this email list. =20

Yes.

> It seems that you need to talk to the stream heads.


This group has the ability to decide who decides that in the future.  We =
can decide to leave it as is, or to change it.

Eliot


From nobody Tue May 26 11: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 04F693A0AAD for ; Tue, 26 May 2020 11:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DwN9fJIya5C for ; Tue, 26 May 2020 11:31:03 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 668E43A0AB8 for ; Tue, 26 May 2020 11:31:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590517851; bh=21+ja1RY1kb+oq4KNHq032Uqli6NkQ3A/tW48bgGrcg=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=df3OfgNK7W9xfAjVJEDehS0sLfRpZarTayMCRLufRyPLUTYMrxINg/oblfmaz9WqY Gp/GajwYETGxZ/lVu0w9GqnaJojiwgwbqrhknA+4MVKXsfycW5tPbR1pJVt0GYXdyF 3clw/FsP5MWUcJuig3enRAZGcnJocJV/1FunrZeQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.182] ([84.171.146.2]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0FxV-1iqWOy3HZn-00xLTu; Tue, 26 May 2020 20:30:51 +0200
To: "Joel M. Halpern" , John Levine , rfced-future@iab.org
References: <20200526170218.0F0BB19A1F83@ary.qy> 
From: Julian Reschke 
Message-ID: <1e2313a7-14b9-1aca-9780-2ea3f025574f@gmx.de>
Date: Tue, 26 May 2020 20:30:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:rtMK9QxJ+fSoVYtGYOiIb6jHSW+e7em21dnpxZITNmSVaSvJtsI 5vqaI5JLQCzPCF1uupEuA/zjTZH60FMjXY3sGlPI3eZPYbfj73X7LR8WLefijjGvbkK59fV 9mWUZupCYVfgrA4ImvCdKy8OwOuCG2ddjcXM9NAF6WoGEAXpZ8SK9abWLj23btximrF2tz2 ZR3xGYiXaskzGPSK8z9VQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:k0gvZ99JRhQ=:JBy5f87lvzzSX5/plhz+dF liGAo5EDUYLwwu4klQbVwI+kRnACHOvWi1k4uKUdgIAueOMyuSQJILDt86KUhMPer78qW7qbJ rm8+VekFp2zeawf/yOV/nui8f+i/yPFQeZb+10kpVPryEFqGjeLCrK+Anw8C3ENkG7gGLxeJb eQp5L6oQcwqxoeuvS5NzgjR69W4LN2RPsMvxoLlTTWPpiyzrsO8oARQYO3ctXFIuiFLSTD/dt EnSP8k9OsmXs2rYiKVPUvDdsKnBJW48uVxZ6dKQUH644FXmhVF1VF4aH30Qlaop1j5mH9c/ln qgTJhhPiQIYxFHgizOKlTCfcCRUbOq3hfPnfMf9Zhnrym/OsiM8HBO48ggYrCrIibzaKan4VK fMhWxzw+j/Jk8N9v5nvToMAJJdRLdXjGib7TlE1VDcfUgHnGhpk0Ba1FdCzBk8yyc7Y4t3h6V I1axkKCaaSLh2cl0tMViDMmbN/RA5sKmEwc+L+fct2K083JUGS0T8ULvDqqqMVjEWa7Xo7ZYF 86HHxV6IZfXvXrrBXn1yl7HrQcUg3ZdPSx85DF3ZSsYtCrsaGld+sR2hx7cRrAA6KC883+yw7 jpfAQ9uiedsJ7hVgzAAGhc8yxW8IRdVicLWBw19mGkzsSCnlHNxDAscNv777VkckQ8TPfyTDs xb5SvxKMHwGQFHzk0Q/gvW7EO7JHeInJEj/WvrxScIhPj9CxtaVP5HzA3wkyiT8BNCPyKhZeS 11RH/Gw4rlxD2akJ1laSxYAq48jzyfW8pjipE3g0xcfK/eRmjzG8LJ1hBPMDqbbcit+pytGcQ wLqj5NWcpfEV9gFpdhCNo64oRXc+xuRT4YZx47N6bAsek2Pt1KXOUTfFMlVMt9ujwp8vydqXc 4YRnU1rB9+eaiAA2uOvCXPj9LxK0df1CKZIHD2Ql+Ru/YaMBL0cIGl5aZuzU83Jh5erGs6hde 830d2ToF4KOcDkb4KKhP83cTg3DMW8Hwz66GEBfqxYVOknnJWbRBokEF8DO7rMipBl8TvKN8r FARJbl9pGoM1DyveomBs4rhIQRVKXzIhm1qX9+ub+WosX6YloCtSb0NLQfX7oDaXNRuXoUj1k ZDK16oFbKGROWLwsmusoBuDNNyBhifv6HDIZ6ExCIMd7So9yFoTvhIVn0omv77gSba+bT5uPw QHMzWulJCMXZ8vhoWRI4P7TIi0T+6L6KvHN/UYUvic/v+KKdKnRh7cbQubcu3tb4WPxgeUSBv TR9uiQll8Esk/ALQu
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 18:31:05 -0000

On 26.05.2020 19:45, Joel M. Halpern wrote:
> I do not know of any procedure or agreement to change the XML for
> existing RFCs.=C2=A0 The agreements to date do include provisions for
> republishing rendered versions.=C2=A0 But if you claim to need to change=
 the
> XML, as far as I know that would need to be a new RFC.=C2=A0 Could we cr=
eate
> ...

Disagreed.

There was no claim that RFC 7991 was the final word on v3.

See it this way: we convert to the final V3 vocabulary (7991bis), and
re-render. If the text content of the rendered output changes, something
might be wrong.

Best regards, Julian


From nobody Tue May 26 11:42: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 038D33A0ECA for ; Tue, 26 May 2020 11:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svSCDBB2baoU for ; Tue, 26 May 2020 11:42:26 -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 48B023A0ECC for ; Tue, 26 May 2020 11:42:24 -0700 (PDT)
Received: from xse490.mail2web.com ([66.113.197.236] helo=xse.mail2web.com) by mx128.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jdeWo-000umq-7T for rfced-future@iab.org; Tue, 26 May 2020 20:42:20 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49WhzM4dDMz4pKr for ; Tue, 26 May 2020 11:18:23 -0700 (PDT)
Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jde9f-0002Pf-Hu for rfced-future@iab.org; Tue, 26 May 2020 11:18:23 -0700
Received: (qmail 2501 invoked from network); 26 May 2020 18:18:23 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.46.233]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 May 2020 18:18:23 -0000
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Christian Huitema 
Mime-Version: 1.0 (1.0)
Date: Tue, 26 May 2020 11:18:22 -0700
Message-Id: <2CCB7A6F-F878-4A1A-94F2-F5A75A7081B7@huitema.net>
References: 
Cc: "Joel M. Halpern" , rfced-future@iab.org
In-Reply-To: 
To: "John R. Levine" 
X-Mailer: iPhone Mail (17E262)
X-Originating-IP: 66.113.197.236
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/gcnlw0cz3TYWAMatow42l8TcmTKWpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4hF9HDjq97Ef1qUVXpBbwnnQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEkCyqCRM97FQO8waqZwM6Te42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGbXNqJfz6msVASTB+MD+1/p7GPMfR4JPnPUgCtpcJi9K/uv28QjQ3lQtPZwGXu4k5SS ax8yVT5LNQc0pviCIZ+V87H2ECndxkpBwp1FkQyHa0qTD2ipD9y2znxCv9uYkc8RFZ4oobg8BBg3 Jq+ntzj0b6ewbs3WlbaqYj8aPDhOgQ9mDnaXtu0kZC/OWmUorWjDOo3m5CFQ5K/H5zKMaTH7dPoS zD7+gB/BcOn50df6SnW8TfMUfXZNQGXIjuXCLLpDtV9+Lc8hB356TfEHI+2Zz1caQoi44Wcfj1z/ J5tTt7j1ptfltBQnq8NvNwuG6kuhBG0YWFj/7xYZzwR7/PiKfowXlsolACJrkW/vjDp2NmSdEOMf tBjsWb6BDQzjSsG66974nkMwEqjhfSKHlA2Q3p5onVdn12r9xqR15ROHBesyXD9BkbKX7eGI2jGt /RQxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 18:42:28 -0000

> On May 26, 2020, at 10:56 AM, John R. Levine  wrote:
>=20
> =EF=BB=BF
>>=20
>> I do not know of any procedure or agreement to change the XML for existin=
g RFCs.  The agreements to date do include provisions for republishing rende=
red versions.  But if you claim to need to change the XML, as far as I know t=
hat would need to be a new RFC.
>=20
> If that is true, we need to fix it because putting the XML changes through=
 anything beyond a lightweight technical review of the XML would be a huge w=
aste of everyone's time.

Or we could finesse the rules, leave the old xml alone, and pipe it through a=
 conversion script to the new XML before rendering. That would respect the l=
etter of the requirements. Whether that's a good idea is another question.

-- Christian Huitema=20=


From nobody Tue May 26 11:51: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 876C63A0ED1 for ; Tue, 26 May 2020 11:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6n5g-zzLbpsi for ; Tue, 26 May 2020 11:51:40 -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 1E4A53A0EDF for ; Tue, 26 May 2020 11:51:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49WjjP0Mxnz1nwbk; Tue, 26 May 2020 11:51:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590519081; bh=8IkwNi97uK/KDTU0A1BmZ7293ZaRjnMKpUJa3slPZjg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=TYXf007kiaFimuMD3zr+1I9W6pNmH7qULSQfpirOjvrJS1yDFsMBoP/hA55GmhIJm D6CFXYUqhhckZysBeEiDlOXbboyeXkETqQ5amhTF817I4Y+3DPOiTBL9U7B6kAe1wu rm03j9pps4sginUio29+PQsII/bqVsKV0hOOCKQE=
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 49WjjN24Tjz1nwBv; Tue, 26 May 2020 11:51:20 -0700 (PDT)
To: Julian Reschke , John Levine , rfced-future@iab.org
References: <20200526170218.0F0BB19A1F83@ary.qy>  <1e2313a7-14b9-1aca-9780-2ea3f025574f@gmx.de>
From: "Joel M. Halpern" 
Message-ID: <370eba06-cebd-57c7-8f25-b059a7c965b5@joelhalpern.com>
Date: Tue, 26 May 2020 14:51:00 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <1e2313a7-14b9-1aca-9780-2ea3f025574f@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 18:51:42 -0000

Actually, our statement is that the XXML form of the RFCs is the 
immutable archival form.  that does not give us any room to modify it. 
If we want a new archvial version (and once we have a new v3, I think we 
do want such) then we need to produce it properly.

For Independent Stream RFCs, I think that could be done by the ISE 
picking reviewers to confirm that there is no content change.
For the IRTF stream documents, the IRTF chair can likely figure out a 
lightweight procedure.

For the IETF stream, the IESG will have to get community agreement for 
some sensible lightweight procedure.

If John considers this necessary and important (and it sounds like he 
does) then he needs to make sure that a proposal for such gets discussed 
with the IESG, and then with the community.  Somewhere other than 
rfced-future.

(Sorry to belabor this Eliot.)

Yours,
Joel

On 5/26/2020 2:30 PM, Julian Reschke wrote:
> On 26.05.2020 19:45, Joel M. Halpern wrote:
>> I do not know of any procedure or agreement to change the XML for
>> existing RFCs.  The agreements to date do include provisions for
>> republishing rendered versions.  But if you claim to need to change the
>> XML, as far as I know that would need to be a new RFC.  Could we create
>> ...
> 
> Disagreed.
> 
> There was no claim that RFC 7991 was the final word on v3.
> 
> See it this way: we convert to the final V3 vocabulary (7991bis), and
> re-render. If the text content of the rendered output changes, something
> might be wrong.
> 
> Best regards, Julian
> 


From nobody Tue May 26 12:21: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 4530D3A0F10 for ; Tue, 26 May 2020 12:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1y15ZvRfKgI for ; Tue, 26 May 2020 12:21:31 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1083A0F0F for ; Tue, 26 May 2020 12:21:31 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id a13so9082877pls.8 for ; Tue, 26 May 2020 12:21:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=i8NPHZuMuyEY95VELi9cbwJThNI0W1kwhScpRe0nHBQ=; b=Q4cjEyx+68m2ZVkLyfEyflJgc9iQkklfpB5N72O1dWVi8JpvSC1MYiBligDwBzzKOg 834IrTF1lEnvS8vGhlmXsAJS9qV4o1+JwGjpbrGJdk9RkaTjyJqZ8arbMHKD5VyYrcGM 0DHc6Bs/FYbdMO5D4/WwqIpHRsYso7WNjPSjgA0LRuKNNcGNMSmA7qUP/RlhCxgTILd0 zD7Tt3vOyoyzrkdozkD6lZyP5cy4fQqPajVfGe730tOTznI4W1QcITifFK1eikyo917B 1UBE2Eu8JamthrYInWj2v/7Tv1PObVN4ADpYp+5eAoITb6LOT2xDqKKe4O/dTQq0VYnT +R9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=i8NPHZuMuyEY95VELi9cbwJThNI0W1kwhScpRe0nHBQ=; b=Vhd481y3j4n6fhOJdVUr1AiSD2ljg5VD/UxDCuBVyFZEYt84FxvXzWP8K1qUA7UFHC gfYLYZeQYGWFqQd9uKeSM8xrzkNjkyaRj8SlEyQbRzBqhPcSjZCcuQvjhQrjU6cidlSi rZ80P4EJ1ad5nibw+ntP8w0n86klnnBmuGawo1xVkG/Gi1iuKPnKeDuKR54qJ+J9omc/ w/wcu/jh8lGNUGaThC5cki5/0dsjciaF1cNEGahOEmUwGu2ZAy7gLutx/oULJqbn7N0S /ri/7r41leyGKdkz2xLIQETclHnFGAgD/I8fgZdL9ive8b3Dp63u45fCTbQEIQ5Rwfhj eOHA==
X-Gm-Message-State: AOAM531hZwhMpJd68q6Yk5W7gCyY+l624mf0vpeDQUsicWBpxHuFxFx0 rDmWJT91kXu8ZcgXpdIX37k=
X-Google-Smtp-Source: ABdhPJxtaMJyCFwai5mU6uSUzAWxzAPfKc9aPx2ICk8rsl4CptY1PGH08vVc+W9VewUNpg6SZEYi4g==
X-Received: by 2002:a17:90a:f004:: with SMTP id bt4mr820450pjb.128.1590520889624;  Tue, 26 May 2020 12:21:29 -0700 (PDT)
Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id w19sm276148pfc.95.2020.05.26.12.21.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 12:21:28 -0700 (PDT)
Sender: Larry Masinter 
From: Larry Masinter 
X-Google-Original-From: "Larry Masinter" 
To: "'Carsten Bormann'" , 
References:  <2507455b-a835-52fc-76e5-917ab2070288@gmail.com> 
In-Reply-To: 
Date: Tue, 26 May 2020 12:21:27 -0700
Message-ID: <02f401d63392$db437000$91ca5000$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQHCEuV169MwEzBHXon+HygBHWWOdgKL9+5aAojuO1uoulLQcA==
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 19:21:33 -0000

A little searching turned up:

ISO https://www.iso.org/developing-standards.html
W3C https://www.w3.org/2019/Process-20190301/
IEEE https://standards.ieee.org/develop/index.html
ITU-T https://en.wikipedia.org/wiki/ITU-T
WHATWG https://whatwg.org/workstream-policy

I chose SDOs that I think IETF specs interact with (citations both ways)
I'm sure there are others but these 5 span a range.

None have a role like the RSE in duties and responsibilities.
Each has a notion of what a series and a version is.
They all have some safeguards and document formatting issues and =
restrictions.

I think before changing the RFC series to be different, it might be =
worthwhile=20
to understand what other SDOs do and the rationale for the differences.





From nobody Tue May 26 12:24: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 6722C3A0F17 for ; Tue, 26 May 2020 12:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7r1X_uolUKW for ; Tue, 26 May 2020 12:24:47 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 7FA0D3A0EED for ; Tue, 26 May 2020 12:24:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590521073; bh=5WBe9+zgKums12bVaDV3f2WH0z3Y37rFOV4ekuWVqkE=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Gh6GEWElUgF2sQXGyB2JxXbQXOkguRjwlLrdRuymyC3Mfhpj90plMSAD0yMuBolBf uZg3fLe+7urCkw9/XkE+m2IaeweKUcC+S+Qd9Pnx6csoS8uEtyVk5ZNft54HkFpV4W /sp3cxp4wc30Q67iY0yrBc0dYJqbzq5w3NDtpDv8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.182] ([84.171.146.2]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N33Ed-1is74O0CFR-013Q00; Tue, 26 May 2020 21:24:33 +0200
To: "Joel M. Halpern" , John Levine , rfced-future@iab.org
References: <20200526170218.0F0BB19A1F83@ary.qy>  <1e2313a7-14b9-1aca-9780-2ea3f025574f@gmx.de> <370eba06-cebd-57c7-8f25-b059a7c965b5@joelhalpern.com>
From: Julian Reschke 
Message-ID: <1af58168-f49c-3335-4c9b-97b195d81c91@gmx.de>
Date: Tue, 26 May 2020 21:24:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <370eba06-cebd-57c7-8f25-b059a7c965b5@joelhalpern.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:xGvKfeLzsmxH1XbJHLLxS4dZnIZ/KWcvu1CfxHl5O8jxN/OOG3A CmI33b/kbCm2AwV5b5hCQPViGEFi+W81sihqj7mLue10+heSPwqtxuHqeWzHYLxbc4ZF1zH s8bFRiSbcqKY7AJvr44UpmU2O7JgEf1mcm1k2a/BNCgWE2tJ8IW71dXUp7hxW1LoVdYUrFo nYd4rgWZSN4rmUVCn47Uw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Ym6dQd8k2lY=:/VgX1Tr9fJ+1c2VqIu6Iwy su5EJ5fdC3Ar286E9J3NpBNDRyhqN7fYq2k18Tojn2fPx1TPXSOnCBLeffqh0PCFlsktZ3ijS M+/8GqaKxoWpWsTJrIyiWK8qv4gl2TvmMfsMEm7ShL3rwe1Sjx7jc37dqAb1UiJm2Qp7f5DzZ RlT+lHk1YKUVqgMEE5Ty4okcI3fM2nzZt6wjbT5C4GkT1pB0rdj7CrGOLN/g5XSitgknQ2o4h ItWyBG+ssdh1/ctW3lIsQuf3wau2Q6+zrGoSW+vk0rPa3YaVO9udszHre0dT3bEuAOP8EGVgI irigajlRKVAXCKp1u7UG4nqtY/vu3qajmjwxXHS4N5X47PDpe/LdPYOsh6KfTri23h5ysP7G3 G24NQTzKi/MV7DsKEiiCYq6mgqkaAXrLNzng47x6ZAIdCa8zoSfXILlhHtmte0wxlMoQEBM8X tsxe29ktFUFlimCeHsRzo2aPftCpLez1Zh63zTPzThCvB24jrTdQbDh0Eju39xkdClIfrU9ZY +m9u0ljnCWBWhTjnEjVJzjEufwmtbdXWR74CGpwJIoz4Ofp6w342vMUtLZtvN4YxM5Y3NhIt2 I9bUZ1IvSCekrMqAPX1/khNGGOxBRCXlkMWyGvONqhxOaJsRmWEPvwKpa58C4I1x+s011T0ep 7zFwhz4pMgl67Uc+SvtFSFn0A250Is3Py9ZacGsCVCFk7XLAhSPpoEB418Iy2QlILXrEk8/X5 lLNGBNWey+HYuj9SfhGpzTyUXR37QOnJAq/9f7iIwEr214UIwsNdUUBa9w/6PVpMGYmwkLCUf VmdQ3RaAh1Qj3odyNahyCfx/6iBNBtSmvshC0saqB0NSsb51RJX6E99CGUpbQg0nhBiv78Mvc e1m5Jo8pDU5EKjLDDigwDw9TUFXDK+fHC3j75yQVGnLrglpk2hihqJ1ARRDhulSotZFsv/MGp A5kaK9cn3HrwEtgah2SWmrhqIvWigyMb0JHPdE3+1QfLn3/RpG/wztXekkFoufBgu2kvwyJw8 IaPpYmPbv9XMqt7hjv8vUDJwQnzdSMEismNUONpV0aK4w6WjkYqXlAbQbL4oFkSdG1lfsqme/ dDA5i1bVUb/s4aPzD92nVZSdAsc658Kd+vrIrq98RuXZhB9d1RQFn7Zzzuv/b4okPyC+97pWL z1+CPbq6HnDW/P9xrMXzNGesc0GGwreeg2uqho4jWNYkkE3F7K5zarMem7RCBJA4YqoTrV7Qm LfPgfUt3tNNoyDfpb
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 19:24:48 -0000

On 26.05.2020 20:51, Joel M. Halpern wrote:
> Actually, our statement is that the XXML form of the RFCs is the
> immutable archival form.=C2=A0 that does not give us any room to modify =
it.
> If we want a new archvial version (and once we have a new v3, I think we
> do want such) then we need to produce it properly.

The XML format currently used doesn't have a spec. It adds undocumented
features, and some of what RFC 7991 says isn't implemented as specced.

This *could* be ok for archival, once it's documented.

We're currently trying to reduce the gap between reality and
implementation
(, but it's
hard to do lacking feedback from essentially everybody else.

> ...

Best regards, Julian


From nobody Tue May 26 12:36: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 E097A3A0F72 for ; Tue, 26 May 2020 12:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejeYW2PGW8PM for ; Tue, 26 May 2020 12:36:17 -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 555533A0F66 for ; Tue, 26 May 2020 12:36:17 -0700 (PDT)
Received: (qmail 26442 invoked from network); 26 May 2020 19:36:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6748.5ecd6fae.k2005; i=johnl-iecc.com@submit.iecc.com; bh=QhHosXT9W6iAbEN7pGws9ZJ9cUbD9L4QBJmuLDSlJ4c=; b=M2LJB54xyztdZGfl4kYbOS86zKQ3dDXEkZD/c8r3MsY3YHfhmOQ/5yMHU8zr9jmTOAnSkc7B6Nm/yU/jinicV0SMyEhIwbp5AV4ARoCafHYA0doXC2EYVIrrAn9BAifH1LJ1cg61AbSarfYpxuhJ1V0fAlKj3fOaI9sZxSXYvg6To3EN7+h9aGTpm/F4mCFkL7OHvDY4GPznnV3z+Unp3UEfomY9rV9VliVRXqeM9hlJCtBsxGNGkZWiHu+vhZ7J
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; 26 May 2020 19:36:14 -0000
Date: 26 May 2020 15:36:14 -0400
Message-ID: 
From: "John R. Levine" 
To: "Christian Huitema" 
Cc: rfced-future@iab.org
In-Reply-To: <2CCB7A6F-F878-4A1A-94F2-F5A75A7081B7@huitema.net>
References:  <2CCB7A6F-F878-4A1A-94F2-F5A75A7081B7@huitema.net>
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 19:36:22 -0000

On Tue, 26 May 2020, Christian Huitema wrote:
> Or we could finesse the rules, leave the old xml alone, and pipe it through a conversion script to the new XML before rendering. That would respect the letter of the requirements. Whether that's a good idea is another question.

That seems like a really bad message to send to our successors, that our 
ossified processes forced us to do a needless kludge.

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Tue May 26 12:49:58 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D77B3A0FA3 for ; Tue, 26 May 2020 12:49:57 -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, 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 xcAXgwhhd_89 for ; Tue, 26 May 2020 12:49:55 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B5D3A0FA2 for ; Tue, 26 May 2020 12:49:55 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id n11so16486546qkn.8 for ; Tue, 26 May 2020 12:49:55 -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=HycXQKwcEWlsDeXE32D/RUJol0GMJukyF7UkU7FAUP4=; b=CWnI5/nIqlCeB7KCyPFGrqS0OLvEpAhJvi4qsP9EYFRgBR3eyaOhvcHAfOHho5J52f dQufF2Sxj2bO5CHC2sbT4y3NVLE1qGxu59Y4eL7QuL0S4rHfutx7E/Ld5Rj5Y+oM71Lc qH7G5LokkBWTSruQf6iuq/kvBoJ2pn3Lub/F5pU4zJBgVpjbLRvVbQta6r2i8tx9MBXe qQCPjBv84CWH1FmEhmh7W3QsZ1VQVc1oWQjGqt9DmXGoptCTDWziC8Q+w+pjPTzV8a6P 7VZIRy8l2mp8OaAlOsEArZ8cyO3DGJ12UzaZLbE7So+ba/N17HH7zCVcsX5q8iF9O9AG xxSQ==
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=HycXQKwcEWlsDeXE32D/RUJol0GMJukyF7UkU7FAUP4=; b=llwj8J77tVRrDDDZN/be6JCmgrQc0bdpHKOKnRfTfWZoqfNkRE/Dnn5w5okvpR03Do 4vZXQcj0WWd1PARkmGlI8QlR5edtd67pkOQXqYBZJrUqge80uq9xYsYM87ttkL3rXxNp PialFVSOMU9RLS0LJpnA3ANoFoV/5h42Pe9sqTYB7+qn9UAjctmI1Hvwir3z2hhswyhO UdNMJebZ+Krnl5osZC5GRFv8MuaMvvdGx+BL+PCevSW+jT90+ID6toSqvUr4m5cgCEHb oRx9SLboGISHUZaZc7IEXPiqxE0fNDDQD03G+VZZJSBEaqQhgM2JhbYhvsyHcbhjr2Mg XgDA==
X-Gm-Message-State: AOAM532DHvwiobKCbCyL0rKA6O3UtH+lrHdV0Rh90Jtam2allPpuFBvI xif/Wy1KrNKTZV6q+nVWO+yeAzdTjSA=
X-Google-Smtp-Source: ABdhPJwvJWqPkFXPIX0C+cZc2vuUESfm5/buQyfR0KnK25ggxAd4S2M1BoX3fA1EwH1vjM5h/KMV3g==
X-Received: by 2002:a37:4ed1:: with SMTP id c200mr442336qkb.385.1590522593834;  Tue, 26 May 2020 12:49:53 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id p12sm443496qkp.129.2020.05.26.12.49.53 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 12:49:53 -0700 (PDT)
To: rfced-future@iab.org
References:  <2CCB7A6F-F878-4A1A-94F2-F5A75A7081B7@huitema.net> 
From: Michael StJohns 
Message-ID: <6bf89cd6-7535-5c3f-1994-28c7f5dcbbfb@nthpermutation.com>
Date: Tue, 26 May 2020 15:49:53 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 19:49:58 -0000

On 5/26/2020 3:36 PM, John R. Levine wrote:
> On Tue, 26 May 2020, Christian Huitema wrote:
>> Or we could finesse the rules, leave the old xml alone, and pipe it 
>> through a conversion script to the new XML before rendering. That 
>> would respect the letter of the requirements. Whether that's a good 
>> idea is another question.
>
> That seems like a really bad message to send to our successors, that 
> our ossified processes forced us to do a needless kludge.
>
> 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
>

I've been watching this thread and wasn't involved in any of the current 
issue, but as I understand it:

There was a point in time where the archival format was text. And then 
at a specific date and time we declared that the XML was now the 
archival format (the transition point).  And at a later date and time we 
realized there were flaws in the XML that needed correction.

My question:  Why don't we just erase the transition point, render the 
documents in text as the archival formatbetween that point and a future 
point where we're happy with the XML,  and set a new transition point 
when we're convinced we've worked out the kinks?    No need for 
kludges.  Of course, I don't know how to estimate the work factor of 
this approach so it may be a non-starter.

Mike



From nobody Tue May 26 12:57:02 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4623A0063 for ; Tue, 26 May 2020 12:57:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om0DGUkXj9UO for ; Tue, 26 May 2020 12:56:59 -0700 (PDT)
Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A843A0064 for ; Tue, 26 May 2020 12:56:59 -0700 (PDT)
Received: by mail-wr1-x441.google.com with SMTP id q11so9576950wrp.3 for ; Tue, 26 May 2020 12:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+SOBXwYSjzZopwoKC3c2a4jkpVJ4Z2CuISZa4pIz1Rs=; b=sTgmYF34KoztlocRyWjVP3wsktUFAx2DPdWLOXF/5nk1m1DnTkmPsOUxjvCwlAtoaa Zqwq3zdAaAoAKRtLxffNJcO5EGSsUML3UB7mWsp/6XezFcAGjesTzJrqd9OXI5uiFQxl q18NlxIPWVDSyh2sEUZ65FPntWvTXRI7Nr7kRlvXOxl/RP427XUfm4PUyu+A0xqukpfU WCfbVnLGSi0rJX04yE27SDRHPprVTSZOfSl0a6wOrd/ev/r2RbcLmG53N3H9dA33abZ+ 4XdETe2bOjHnVtQc1lsUFoRclA94gV4R4xeEG36EfImuXgmgzv+Hoj34VTlTQtv+3s0B Oe7g==
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=+SOBXwYSjzZopwoKC3c2a4jkpVJ4Z2CuISZa4pIz1Rs=; b=n96G9RbuYRlq3Bl5BJZ3QSVcRHKZNSTUggbqS5Ug8c7wdBzHsbdb7//WHXFuFFyrNN /MkR96eQ9tHTQ/+UcmVPDclMNNd1m3SmjZkoj5xh0dDkGSf6LwS2oX+bbq/38Xc30OaI tqZYyxKZ6Ai4Lghwfaz+KVT9nq0U38/zdtuMPV7wVBlZbqOHwTNaauNKtMx559SpmcWz SSEwqYrZ+lICxeVuFT8wF+ip6kygtLrx1P+fV6sqvAqAWBWJugUnDiR4YJKep3+NQgh7 Inu3obmlMkD/igaLtahzKJdx8H+JctFSMjv+6NK8e8fA7BLyRL36sCUqKEyICQnZv1ZY kn/w==
X-Gm-Message-State: AOAM530PZ0PStd9gOD3ZFHNqqKzLryCDtUyD6TAc4P1Wj1+mMWlkleBo bfDLEu2S6zIrHi/I5u7p7cg=
X-Google-Smtp-Source: ABdhPJwfAq2vfRh7Tg/LcOqMFXa2rVvnFN5BuXAx0GVkI/PqfaDt1UlZbvlVE4riG9NcampAuRFdQw==
X-Received: by 2002:adf:dfcf:: with SMTP id q15mr1758629wrn.373.1590523017513;  Tue, 26 May 2020 12:56:57 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:6cd2:f69d:7f87:8b5a? ([2601:647:5a00:ef0b:6cd2:f69d:7f87:8b5a]) by smtp.gmail.com with ESMTPSA id m7sm450186wmc.40.2020.05.26.12.56.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 12:56:56 -0700 (PDT)
From: Bob Hinden 
Message-Id: <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CD260ED0-DC9D-4355-96DC-89979A2CCF63"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 26 May 2020 12:56:52 -0700
In-Reply-To: <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net>
Cc: Bob Hinden , Brian Carpenter , Doug Royer , rfced-future@iab.org
To: Christian Huitema 
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com> <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 19:57:01 -0000

--Apple-Mail=_CD260ED0-DC9D-4355-96DC-89979A2CCF63
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Christian,

> On May 26, 2020, at 10:41 AM, Christian Huitema  =
wrote:
>=20
>=20
>> On May 26, 2020, at 10:05 AM, Bob Hinden  =
wrote:
>>=20
>> =EF=BB=BFChristian,
>>=20
>>> On May 25, 2020, at 9:53 PM, Christian Huitema  =
wrote:
>>>=20
>>>> On 5/25/2020 7:39 PM, Brian E Carpenter wrote:
>>>>=20
>>>> And for our business here: is progress-chasing at the RPC a job for =
the RSE, or for IETF LLC that holds the RPC contract?
>>>=20
>>> The current structure is a little weird. The RSE is in theory in =
charge,
>>> but in practice is not managing contracts or budgets. Things would =
be
>>> clearer if the LLC was clearly in charge of what amounts to =
executing a
>>> contract according to performance targets, and if the RSE could =
focus on
>>> issues like formats and errata.
>>=20
>> If I remember correctly, the LLC was supposed to be board, so it =
would be the IETF Executive Director who would do this.   Even then, =
does the IETF Executive Director become knowledgable about about the =
details of the operation of the contracts, or does some other group like =
what Mike proposed in the RSEB make recommendations to the LLC.
>=20
> Let's set aside the discussion of whether we need a special board and =
just look at the RFC function. In the current state, the RSE proposes a =
set of metrics to evaluate the RPC, in terms of delays and load such as =
number of documents or pages per month, and the RSE also provides a =
monthly report showing how the RPC is meeting the negotiated metrics. =
And then the RSE is supposedly evaluated on how well the RPC performs.
>=20
> IMHO this setup is fraught with latent conflicts. These conflicts only =
appear of course during times of tension, such as when RPC productivity =
is affected by the arrival of big document clusters, or by spec changes =
that require retooling and retraining. When that happens everybody gets =
frustrated. Document authors and the IESG resent the long publication =
delays. The RSE is in theory in charge but cannot easily increase the =
RPC budget. The RPC is doing its best but does not control the incoming =
load or the changes in tools. The tools team gets to deliver on the new =
spec with the old manpower allocation. Etc.
>=20
> I think we have to address the root causes of these frustrations. I =
think that means separating clearly the specification functions of the =
RSE and the production functions of the RPC, the latter being controlled =
by the LLC without squeezing the RSE in the middle.

To some degree it like the contract for the Secretariat.   The LLC holds =
the contract, but they are doing work for the IESG.   At a high level if =
the IESG is happy with the secretariat, it=E2=80=99s good.  Might be a =
good model for the RFC Series.

Bob




--Apple-Mail=_CD260ED0-DC9D-4355-96DC-89979A2CCF63
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl7NdIQACgkQrut0EXfn
u6hmxgf9HoBrtoK5lDGuDOxxVe6jExRKIt16nNFRVsZsRBqUNmBBFwZ7+G9AEttU
QHxBkPv3V28qMtV3RriktsiJ3zc9UnR3FNV8RlIsh8HJnpflPhDZ0ZEPlwIdrQon
w784/nMlV6ELse2RntrxbMGzd7rN/ZdQeDtTiIQYbKfb6knQhjBMB1qMpJMpyXjY
R76VYBY6bbLZT5lJC7/CsaP21eDVguBSzlM8HU1A/uKEjTAO0KwSugjbfd05z4hM
850ta7gqELlMN0wvA7EpksrtUYgJzToKQ7YyfxSBaKSN7TnIswMLi/niKY/XBF/Q
s50llx8uQQ/hRWj+32ddCOhMQgNzdQ==
=g4uu
-----END PGP SIGNATURE-----

--Apple-Mail=_CD260ED0-DC9D-4355-96DC-89979A2CCF63--


From nobody Tue May 26 13:47: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 2CAC63A0811 for ; Tue, 26 May 2020 13:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-IrcE2jbIZq for ; Tue, 26 May 2020 13:47:32 -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 A724F3A0841 for ; Tue, 26 May 2020 13:47:32 -0700 (PDT)
Received: (qmail 40936 invoked from network); 26 May 2020 20:47:31 -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=9fe4.5ecd8063.k2005; bh=+pXvnLrbSfzQcBPzQlPjgJFf4vDSiO5yPRhTzMLk02Q=; b=Lj8jn2vkhRGKEs8f4eBQkX3uyvUQxB4Jru+tSFzm+jv/hbReBCqAt1O/vtvgPLktc6iKiNTITPyUN7aXsD7zHSFt2HECEChpggv54sbYRO8OyCFK0lu+kCRNbGo/kAAP4KRiucYLW2nbZbFt8s7i9NMZbtEq9G50A7q2QmZrgLrRIfiCMOBSDHNLm6Lwbf9r9x9vBSOqcT41Up4cMjKpc3cOk9RNMfH08QOLr7lonTVauOZD3gNIBOD1V/b7YPmI
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 26 May 2020 20:47:31 -0000
Received: by ary.qy (Postfix, from userid 501) id E989819A595D; Tue, 26 May 2020 16:47:30 -0400 (EDT)
Date: 26 May 2020 16:47:30 -0400
Message-Id: <20200526204730.E989819A595D@ary.qy>
From: "John Levine" 
To: rfced-future@iab.org
Cc: msj@nthpermutation.com
In-Reply-To: <6bf89cd6-7535-5c3f-1994-28c7f5dcbbfb@nthpermutation.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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 20:47:37 -0000

In article <6bf89cd6-7535-5c3f-1994-28c7f5dcbbfb@nthpermutation.com> you write:
>My question:  Why don't we just erase the transition point, render the 
>documents in text as the archival formatbetween that point and a future 
>point where we're happy with the XML,  and set a new transition point 
>when we're convinced we've worked out the kinks?

There's a great deal of baby in that bathwater. The changes to the XML
we are likely to need are not large, and the semantic info in the XML
is quite useful.

Also, the v3 text output is somewhat different from the old page
images. It is not divided into 60 line pages and it's in UTF-8 with a
BOM at the top. If we're going to change something, making minor
changes in the XML is the smallest useful change.


From nobody Tue May 26 13:49: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 04FF63A0784 for ; Tue, 26 May 2020 13:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWfOSVt9uwxc for ; Tue, 26 May 2020 13:49:49 -0700 (PDT)
Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (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 941343A078A for ; Tue, 26 May 2020 13:49:49 -0700 (PDT)
Received: by mail-pj1-x1044.google.com with SMTP id n15so333661pjt.4 for ; Tue, 26 May 2020 13:49:49 -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=70OKZGbzTocLJ5HWt6A+EkY35ocRSdHpKXhHmg0Z7qo=; b=bKdY/4DS5Awp95yVtVLaeZ2ObAAi00TNZHjeuusLeDxHVsjKgLZllqRose9WMjKIUY A3r0WiYxE1o8OEs6VHkrnNSar6I+ZednRZdKsr4cPUBnZj9UQLVCNDmggeY9Vr7IPac2 qFpZeVP5n6NqyTmNCdEfESFkIofsf54R+phw/QE7+VECmQU/pL6CFEtftsmxOtR984UZ AOuVwvUllz3VFcPVGeLUMG2NYJ3VyvwrVEFeSI53UErPBPfPSZMTWibuEKjalwWJ7ApK nmx0ReOf4Jwz8WcQeCVcKQgkkZs7s5m+PtgZQPPPMKqtay/pOkN9HwGRyWRz9DuH9jxI quZQ==
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=70OKZGbzTocLJ5HWt6A+EkY35ocRSdHpKXhHmg0Z7qo=; b=htEF+QCfVHrdjw8GsfdPswYCDXQatDwAu4zsJ29YIbYY3vyiBG4nzLiCLHF8Pf74B5 ZbknetbOMH8674ENwCFndOH42MviYGDhiMOq5pX+jLYEmDlKJCcE09v17ccPVhGfG6Af hM9CWROAUjfBFy4SMPJG1D7Ixd0pCtuqAM13cE4QWM1g7sCh/QM48LiG/Y3+1iQXLTi4 6xr8REkCnsTAuuZivEyb+bbKwWOtF+FrnFnsBYsba2lWm59Ga1HRfGMpaCUqbif4snKj 7VXlaMFRADqCxFqf6X0OFYNzh9ZZEfOvr99HV22i/0SEsskcOCG2Yv4UaGdOfhZa7pLd oYWA==
X-Gm-Message-State: AOAM531KIkdC+FDRvV/fTrV0enG9G/vFdUUpdhO0DtjesKJ6/snMWW/+ JGEFmWgoTL2orQJetrgio8FtC5Yc
X-Google-Smtp-Source: ABdhPJybOPHRt0IyZxBB07XTtHWPVSVBicymhAe3espt5Psg8mIqkIxy3hSKMUrR4k0PSkCg4jLOMA==
X-Received: by 2002:a17:90a:d497:: with SMTP id s23mr1043621pju.222.1590526188760;  Tue, 26 May 2020 13:49:48 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id i11sm375605pfq.2.2020.05.26.13.49.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 13:49:48 -0700 (PDT)
To: Bob Hinden , Christian Huitema 
Cc: Doug Royer , rfced-future@iab.org
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com> <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net> <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com>
From: Brian E Carpenter 
Message-ID: 
Date: Wed, 27 May 2020 08:49:42 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 20:49:51 -0000

Below...
On 27-May-20 07:56, Bob Hinden wrote:
> Christian,
>=20
>> On May 26, 2020, at 10:41 AM, Christian Huitema  =
wrote:
>>
>>
>>> On May 26, 2020, at 10:05 AM, Bob Hinden  wrote=
:
>>>
>>> =EF=BB=BFChristian,
>>>
>>>> On May 25, 2020, at 9:53 PM, Christian Huitema =
 wrote:
>>>>
>>>>> On 5/25/2020 7:39 PM, Brian E Carpenter wrote:
>>>>>
>>>>> And for our business here: is progress-chasing at the RPC a job for=
 the RSE, or for IETF LLC that holds the RPC contract?
>>>>
>>>> The current structure is a little weird. The RSE is in theory in cha=
rge,
>>>> but in practice is not managing contracts or budgets. Things would b=
e
>>>> clearer if the LLC was clearly in charge of what amounts to executin=
g a
>>>> contract according to performance targets, and if the RSE could focu=
s on
>>>> issues like formats and errata.
>>>
>>> If I remember correctly, the LLC was supposed to be board, so it woul=
d be the IETF Executive Director who would do this.   Even then, does the=
 IETF Executive Director become knowledgable about about the details of t=
he operation of the contracts, or does some other group like what Mike pr=
oposed in the RSEB make recommendations to the LLC.
>>
>> Let's set aside the discussion of whether we need a special board and =
just look at the RFC function. In the current state, the RSE proposes a s=
et of metrics to evaluate the RPC, in terms of delays and load such as nu=
mber of documents or pages per month, and the RSE also provides a monthly=
 report showing how the RPC is meeting the negotiated metrics. And then t=
he RSE is supposedly evaluated on how well the RPC performs.
>>
>> IMHO this setup is fraught with latent conflicts. These conflicts only=
 appear of course during times of tension, such as when RPC productivity =
is affected by the arrival of big document clusters, or by spec changes t=
hat require retooling and retraining. When that happens everybody gets fr=
ustrated. Document authors and the IESG resent the long publication delay=
s. The RSE is in theory in charge but cannot easily increase the RPC budg=
et. The RPC is doing its best but does not control the incoming load or t=
he changes in tools. The tools team gets to deliver on the new spec with =
the old manpower allocation. Etc.
>>
>> I think we have to address the root causes of these frustrations. I th=
ink that means separating clearly the specification functions of the RSE =
and the production functions of the RPC, the latter being controlled by t=
he LLC without squeezing the RSE in the middle.
>=20
> To some degree it like the contract for the Secretariat.   The LLC hold=
s the contract, but they are doing work for the IESG.   At a high level i=
f the IESG is happy with the secretariat, it=E2=80=99s good.  Might be a =
good model for the RFC Series.

If it's working for the IESG/Secretariat relationship, yes. Maybe we shou=
ld check with the IESG?

Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is *not* w=
orking?

     Brian


From nobody Tue May 26 13:50: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 1F6CC3A0784 for ; Tue, 26 May 2020 13:50:48 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl09tkvFq37Q for ; Tue, 26 May 2020 13:50:46 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 C4D443A078A for ; Tue, 26 May 2020 13:50:46 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id c12so7526399qtq.11 for ; Tue, 26 May 2020 13:50:46 -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=wlxk5tnuGlKA2Acm01fkBCouwPh76MpcLLfsZYXlOaU=; b=xwxT6OBpCRm7Ms8gIIVjuBfNlP/R9OQSkFZ+anoq4GvJI+ubY1lYBpDuipM3qCjEO6 +xHthdLGZxPk1lt2sFyTF++BOgOrkrTb+aITGuBMy1u6Fqrpj5yzKxZSv0eTK6ToMAVm SOXyf9C6iBsN/tQvl7LhgyzFijlFJVf6j5TRrGtI6WKo6/Kukx5LTWoWtz1MqBG/dx2I OW+Fan7usmjITOIHPJhtYD8Gr23mMkcP9uw1yxzVnAErQfhUKHTOaIFVjrCPwyc7P2Aa g0bYS44as0ilaODQvjeSh6Rek2OK3GJg3Ez/D7OhT5BQbSKuuuQvqHG6FdRgwKGpuNBt svMQ==
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=wlxk5tnuGlKA2Acm01fkBCouwPh76MpcLLfsZYXlOaU=; b=AfF4eQHiqysVYHFTugHfAnV1n1Whl6/UMEPV+aF8NajzzUGKJOGDzDc29++zBdtFaH /MgcHRMDIlqHfqOpLYK+FFff1uI/xKf7NoWqys1CJZhgHQpT5+n2ts/cP8402FvUmuIO 2NA/+bJmVw8w4KyshK+O38GOm2ZFzVR1Z7HxYCNlT4t9GwoiFcy/kC2GdiBormQi7F7P mA2nZRQpr5WqXzT+HpQOOXwOk+NVQzVOFA2S10+Ye4AEO90Kc92dLNZOFtA/FggWi5Vf g+amoKOCfbPkamcCIkXHbdaUWWzm5/Z29DqLnzaqV3ZDHTJecYnja9drZfWrOWVTsyJE fLkA==
X-Gm-Message-State: AOAM532oq4piKxojdfkEbE4MlaP33AKNNvKG22uI7jJIWncTZCAq3f4/ 5sL3L83ATGBsXwKFm7XUvI0voM+151U=
X-Google-Smtp-Source: ABdhPJw/u/hp3ESALDJklJ8TY4g9LqLPgHR2MtFX1OFwpbToEHnHXUd1aP/4zYOE9kK/wIBQeucYMg==
X-Received: by 2002:aed:308e:: with SMTP id 14mr795269qtf.146.1590526245439; Tue, 26 May 2020 13:50:45 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id a191sm616427qkc.66.2020.05.26.13.50.44 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 13:50:45 -0700 (PDT)
To: rfced-future@iab.org
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com> <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net> <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com> 
From: Michael StJohns 
Message-ID: 
Date: Tue, 26 May 2020 16:50:44 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 20:50:48 -0000

On 5/26/2020 4:49 PM, Brian E Carpenter wrote:
> Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is*not*  working?

Aye.


From nobody Tue May 26 13:58: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 E74B23A07BF for ; Tue, 26 May 2020 13:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aacUA3WGOLMG for ; Tue, 26 May 2020 13:58:45 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0: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 368BE3A07BE for ; Tue, 26 May 2020 13:58:45 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id v128so19887926oia.7 for ; Tue, 26 May 2020 13:58:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IvCUSkHavQc8ORew6j8wanISWs0BsnkurUBuKI5yzVk=; b=X9LSDBK4ZTQdDLqm+Z/gaZB+H3eY8cXefnJjxg401xTdXVMFkPt9TKuNP94gQ5038P 9joU1satmkNt+TqNia4DYN51d4vlQyt1ZEW8HMXf7pTE+DZmaaBbK3B+vZvuepVVh/td yKIgaIqqtMmry7scF8yoJGNMpICb+6FPM0Tk5FojQnnrV2bpXcw5iubW0+DYDgaGnLTy mzlGWLbCSsg9cgBAN+yBBLEr2w9rr+Aqypu8oJ9iVnOCyjLwNS/AOYcpMj4v2jL3BJ2U 8SVoaZa3ITpWoWgRqrh5oSlU0TRrXOaXbs5djG0raFuivsNnEINPa8mx0l4xuqaIZqXt LJCA==
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=IvCUSkHavQc8ORew6j8wanISWs0BsnkurUBuKI5yzVk=; b=BT8zE+UTm3/rh5CetqC23fEVTrrxs8uDLIeDdKCLF+wH7NLwGnDhlXhduJ9v1xlMOn p8bkGoYxS+8bYIudm7A00Ex0IH1xcYpXe/tNfTuK48SurbhQ56IyUxaKJTrouTMzDoQT 6FZlHXt8h8vHxnSyjouv0Los33dHn0ugqdkWD4M0lHoDGmqCTTnU3UCE3dicoQ0b+znq wRw32LQoDfZ4O0UBwfk3vn3DxMBuxOQ1MkCIEi96ozw8ysNg8WR1Sr9cuTw+1cgRcZ00 Uf+FJnYQJqvarIfMculDx9KrbSAcUsJmTcXIet6LPOgnQxPjZU16udGdxOxVNyymORIY H5fA==
X-Gm-Message-State: AOAM532Op9pa+D7+Y0ltzGIQHEvu+187OydcvcQ8+/D0WjHJukp255yF hrQ689xoYaTKmRpfkOkeEFElIoJgw71tlNFazdPeE4Iv
X-Google-Smtp-Source: ABdhPJzwwunpCs9wVI80eWJP+JkAJguZvyHAGvlwRPIBrDFZ9jHOPMJpWfcI/TbFnKy8cGyrOzJHnuwO66IZWCstOCI=
X-Received: by 2002:aca:bd08:: with SMTP id n8mr502524oif.173.1590526723639; Tue, 26 May 2020 13:58:43 -0700 (PDT)
MIME-Version: 1.0
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com> <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net> <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com>  
In-Reply-To: 
From: Tim Wicinski 
Date: Tue, 26 May 2020 16:58:32 -0400
Message-ID: 
To: Michael StJohns 
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000005e4d0105a6935cf1"
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 20:58:47 -0000

--0000000000005e4d0105a6935cf1
Content-Type: text/plain; charset="UTF-8"

Agreed



On Tue, May 26, 2020 at 4:50 PM Michael StJohns 
wrote:

> On 5/26/2020 4:49 PM, Brian E Carpenter wrote:
> > Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is*not*
> working?
>
> Aye.
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

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



A=
greed


On Tue, May 26, 2020 at 4:50 PM Michael StJohns <msj@nthpermutation.com> wrote:
On 5/26/2020 4:49 PM, Brian E C=
arpenter wrote:

> Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is*not*=
=C2=A0 working?



Aye.



-- 

Rfced-future mailing list

Rfced-future@iab.=
org

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




--0000000000005e4d0105a6935cf1--


From nobody Tue May 26 14:03: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 536D83A07BE for ; Tue, 26 May 2020 14:03: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9EyLlgpkEq5 for ; Tue, 26 May 2020 14:03:16 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D793A07BC for ; Tue, 26 May 2020 14:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=nymg1Uj2688TcH2xGm14vmKx/HJjOWacJJFi4s+6Nws=; b=Bdg8eQFTOFnF+u/9fXJwIun8yV L8p5kr+AdGNbwKshgy/67P7jkdZiOSofs09YFiWpwbb2qfF9rjVUBtuzqdAid4uxJVkljKAmPxqzq ybfJhHOGqcr/gSQCe3zq8KHtiWjm+DFXQAKkK58kyhp8YVP/66Poo7EGM3Zm5ek9eMRfKcA/cyvCk v5tGzXSn1MZ20JH31rc3xb/u8UuIp8c16RRrUpFSD4fb+9TtYbZPfzY2aUxK4fEodGcyjJo2KNQ+m ngSdUd0hcfZusmegXKX1UiTq92G3sc4SYlovawDBA5jXtJmMClNVBs+TTge2wmi67wbFfQGAGln/8 OBltcemQ==;
Received: from [81.187.2.149] (port=35580 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jdgj9-00039B-Il; Tue, 26 May 2020 22:03:13 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Colin Perkins 
In-Reply-To: 
Date: Tue, 26 May 2020 22:03:07 +0100
Cc: Rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1BC05659-B4E9-4334-91F2-CB1292943739@csperkins.org>
References: 
To: John R Levine 
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 4
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 21:03:18 -0000

> On 25 May 2020, at 21:42, John R Levine  wrote:
>=20
> The RFC series is two things: it's a stable archival set of documents =
about the technology and history of the Internet, and it's where you =
find Internet standards and related specs like BCPs. For the vast =
majority of people likely to look at RFCs, the latter aspect is what =
matters. If we were just publishing a series of historical papers, that =
would be fine but there's no way it would merit the amount we spend =
editing and publishing RFCs.
>=20
> The problem is that the RFC series does a lousy job of publishing =
technical specs. If someone wants to write an SMTP server or a DNS =
server, there's a long list of RFCs that overlap and rewrite each other, =
there's a zillion errata not part of the RFCs that you need to know to =
look for and see if they matter, and there is a great deal of folklore =
to know which RFCs are important and which you can ignore. (For example, =
RFC 3865 defines an SMTP extension that we knew nobody would ever use =
other than to make a political point.)
>=20
> I believe there were two key reasons our specs have succeeded: one is =
that they do work if you can figure them out, and the other is that =
unlike most other SDOs we have always given them away for free.  Open =
access is now increasingly common, so it would be a good idea to make =
them easier to use or at the least easier to find the ones you need.
>=20
> I am not proposing specific changes other than to say that the model =
of RFCs solely as independent immutable documents no longer makes sense.

I strongly disagree.

> While I do not suggest we go to WHATWG style living documents, I do =
think that for our specifications we need to find a more modern way to =
collect the material into a small number of places with stable names =
(perhaps using version numbers like everyone else does), and to make =
discrete low cost updates as we find errors or make partial updates.


The RFC series provides stable reference documents. The IETF stream does =
a very bad job of using that series to publish new versions of =
specifications with consolidated sets of changes.

That is, I agree there=E2=80=99s a problem, but I think that problem is =
with the way the standards process is managed, not with the RFC series.


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





From nobody Tue May 26 14:05:54 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA453A07DE for ; Tue, 26 May 2020 14:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQDfDjB0A1PM for ; Tue, 26 May 2020 14:05:51 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7CE3A07CE for ; Tue, 26 May 2020 14:05:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=CLKv08a1U5yC+aBQgdW8KSyYERmM1jxX+VlpWzAs9yg=; b=ZLVc8D7/E1yqetN6ooHc2C6Zfn 45INSWI/Io/P72xMM4BQl82ZYZ4hTce1Oe6/m40maHZ6sNwhxkW0Hktu5iLpXRgWg6BTmkkROiR/f cnISlrZcn2dr4qJrnl/gxFlyv8cZ+8kOtYHM3MjXeKa4yvu7mT10WDDd1usgMvrVC8B1BffPVp6s6 jQZyyFz4Vw6nM54v6t8fWw41Txgr3jbC23FRKlsPa/C29ByaZKSY5iZ2ih49TU9SDVhrCCLZbFReC VEOD0mLNDSjVoQ/VR/1PLeLVGkpB8NtDm9Nfx9AmfZP7BcHVL0krfuMmvPINKQUHaUeIq9Bb4VuYG cAX4Jo3w==;
Received: from [81.187.2.149] (port=47418 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jdglf-0003i1-Ka; Tue, 26 May 2020 22:05:48 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Colin Perkins 
In-Reply-To: <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>
Date: Tue, 26 May 2020 22:05:40 +0100
Cc: John R Levine , Rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 4
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 21:05:53 -0000

> On 25 May 2020, at 22:12, Carsten Bormann  wrote:
> On 2020-05-25, at 22:42, John R Levine  wrote:
>>=20
>> I am not proposing specific changes other than to say that the model =
of RFCs solely as independent immutable documents no longer makes sense. =
While I do not suggest we go to WHATWG style living documents, I do =
think that for our specifications we need to find a more modern way to =
collect the material into a small number of places with stable names =
(perhaps using version numbers like everyone else does), and to make =
discrete low cost updates as we find errors or make partial updates.
>=20
> The diagnosis appears to presume a therapy here.
>=20
> However, most of the problems are with the high-energy approval =
process of the IETF stream, which makes it impractical to do actual =
revisions of documents without exposing previous consensus to new =
attacks and subjecting it to current political and technical fashions.

+1

This is the real problem =E2=80=93 not whether the revision to RFC XXXX =
is called RFC YYYY or RFC XXXX.v2.

Colin



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





From nobody Tue May 26 14:09: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 19D943A07DE for ; Tue, 26 May 2020 14:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=RS2tj63Q; dkim=pass (1536-bit key) header.d=taugh.com header.b=GzoVBDgD
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5yCyKRxwVS0 for ; Tue, 26 May 2020 14:09:11 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCB43A07DC for ; Tue, 26 May 2020 14:09:11 -0700 (PDT)
Received: (qmail 45097 invoked from network); 26 May 2020 21:09:10 -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:content-id:user-agent; s=b027.5ecd8576.k2005; i=johnl-iecc.com@submit.iecc.com; bh=06YaqN+vFoCP7CqH7IFCVChO9zrmLiLEq+mN4fso85E=; b=RS2tj63QNvokw+jAoiHTdrzrMHGkCmF3cJcYVrf00I0j73Gpef8VWIkoPcecRc2DdxxxNeHJD95tDB/Yq3m5HWshFiwl4RooiyqjwOFmUy5yk5+upxMhHp+kSF0QsJP6az67qPVnatlY0bofHB/HushS5Va0voN/Xr6wHx7dPG6MMTOM7xx2485aj79oyVWcf3N6E7e9QRSg6yjbcmPC9/t21OpeHe5sY12LzzlRLfU9mUypgvo+0AiyeZMM2pE/
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:content-id:user-agent; s=b027.5ecd8576.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=06YaqN+vFoCP7CqH7IFCVChO9zrmLiLEq+mN4fso85E=; b=GzoVBDgDyXnsE7OYsCbTUsASf0Toh59TZA8VBu5hhz4f15yS3V1YXwXPkoed86rBbdYI+vXv8ibalyCG+lW111porhmU9aw/5SkqNtvo8oykL8xsoMFWbfwSwflZTuGtcCSCFAPrHcMPLQr0mOJHdh6RITyGjls5+YneXyqI2GC13D1d3w5KM+JcCla16SgGlpdaKGERCX2F79OEncNyZ9mokLU2CWNtrTzKdUJxmOyggNC4rGIWJld9dpcOe5d2
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; 26 May 2020 21:09:10 -0000
Date: 26 May 2020 17:09:09 -0400
Message-ID: 
From: "John R Levine" 
To: "Colin Perkins" 
Cc: Rfced-future@iab.org
In-Reply-To: 
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org> 
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1486980901-1590527292=:31277"
Content-ID: 
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 21:09:13 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1486980901-1590527292=:31277
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Tue, 26 May 2020, Colin Perkins wrote:
> This is the real problem – not whether the revision to RFC XXXX is called RFC YYYY or RFC XXXX.v2.

The specs for a mail server or a DNS server are spread across dozens of 
RFCs and errata.

Do you foresee an approval process lightweight enough that we could sweep 
all of the DNS specs into 1034bis or all of the mail specs into 5321bis 
and 5322bis?

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
--0-1486980901-1590527292=:31277--


From nobody Tue May 26 14:15: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 0E0163A0821; Tue, 26 May 2020 14:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGAUbatk12gM; Tue, 26 May 2020 14:14:57 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DCE3A080E; Tue, 26 May 2020 14:14:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=hO6PTCDVjJ9iMkIrownCtl5UV8XOJuhwVgnF0AeErFk=; b=Xkz/9tPaN18CpD+sOZ0X1hZgsA pZ44GkeiLD++IIGWnZsKhTr53h5uL1+o09XIvxU52MyaB9YtCu3HFQ5V2+IGjdwuAq5vdsQLrypCw L5Se9MmoFpa8fwcWavWvvhA6Fn2y+bj18+ld1Sn4OSeioKLTKtD5Mt0S2XQCLDEmp6MO/NYUZ+ICM crmUgbygedDy77ABMLvv/Tx5iI31N+v1UMv/kKrwDRYS38HGht67iEBa+HMKQl2a329g7sOTt5e2B Dsznz6e4Ia3MBp7Ko2A19SKDoBXHxzPRlVuAqjL1W72VyjncJ1VWQ+RhBNir9kGAPXY27bwKbOo6Y IuSibmmw==;
Received: from [81.187.2.149] (port=36270 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jdguU-0005Dk-Up; Tue, 26 May 2020 22:14:55 +0100
From: Colin Perkins 
Message-Id: <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B7B6FAA3-500E-4FD5-8C2D-261DAA1BFBDC"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 26 May 2020 22:14:52 +0100
In-Reply-To: 
Cc: rfced-future@iab.org
To: Eliot Lear 
References: 
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 14
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 21:14:59 -0000

--Apple-Mail=_B7B6FAA3-500E-4FD5-8C2D-261DAA1BFBDC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

[As an individual]

> On 26 May 2020, at 08:13, Eliot Lear =
 wrote:
>=20
> Hi everyone,
>=20
> I am hearing several different points of view on this matter:
>=20
> The series is difficult to read because one has to traipse through a =
large number of documents, and this is a problem the RSE should take on.
> This is a problem for the IETF and the RSE shouldn=E2=80=99t be =
involved.
> This is a shared problem between the RSE and the streams
> This is so hard a problem we shouldn=E2=80=99t touch it.
> What is =E2=80=9Carchival=E2=80=9D?
>=20
> I wonder if there is consensus around something close to the following =
view:
>=20
> The RFC Series Editor is responsible for specifying editorial methods =
and the necessary architecture by which RFCs may be amended in a manner =
that is seen as useful to the various stream managers, with an eye =
toward readability and referential integrity (add other stuff here).  It =
is up to the stream owners to set policies around approving such =
amendments.
>=20
> This isn=E2=80=99t all that far from what we have today with the =
errata process, but is more specific than what is in our documents =
today.  The only question is really how the rendering of changes should =
take place.

I do not believe allowing amendments to published RFCs is desirable =
(with the possible exception: to fix bugs in the XML schema, provided =
there=E2=80=99s no content change).

Having the RFC Editor develop better processes for collecting, =
verifying, surfacing, and displaying errata seems useful.=20

Having the community develop lighter-weight processes for producing -bis =
RFCs seems useful.=20

But I do not believe amending published RFCs is desirable.

Colin



> Some jobs may be too big to handle simple edits.  I couldn=E2=80=99t =
imagine, for instance, that TLS 1.3 would be a bunch of edits on top of =
TLS 1.2.  But the streams would largely need to make that call.  =
Interoperability concerns would also largely fall to the streams, =
although the RSE might need to provide mechanisms to warn about =
pitfalls.
>=20
> Thoughts?
>=20
> Eliot
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future



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





--Apple-Mail=_B7B6FAA3-500E-4FD5-8C2D-261DAA1BFBDC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


[As an individual]

On 26 May 2020, at 08:13, Eliot =
Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

Hi everyone,

I am hearing several =
different points of view on this matter:

  • The series is difficult to read because one has to traipse =
through a large number of documents, and this is a problem the RSE =
should take on.
  • This is a problem for the IETF and =
the RSE shouldn=E2=80=99t be involved.
  • This is a =
shared problem between the RSE and the streams
  • This =
is so hard a problem we shouldn=E2=80=99t touch it.
  • What is =E2=80=9Carchival=E2=80=9D?

I wonder if there =
is consensus around something close to the following view:

  • The RFC Series Editor is =
responsible for specifying editorial methods and the necessary =
architecture by which RFCs may be amended in a manner that is seen as =
useful to the various stream managers, with an eye toward readability =
and referential integrity (add other stuff here).  It is up to the =
stream owners to set policies around approving such =
amendments.

This isn=E2=80=99t all that far from what we have today with =
the errata process, but is more specific than what is in our documents =
today.  The only question is really how the rendering of changes =
should take place.

I do not believe allowing amendments to published =
RFCs is desirable (with the possible exception: to fix bugs in the XML =
schema, provided there=E2=80=99s no content change).

Having the RFC Editor develop better processes for =
collecting, verifying, surfacing, and displaying errata seems =
useful. 

Having the community =
develop lighter-weight processes for producing -bis RFCs seems =
useful. 

But I do not believe =
amending published RFCs is desirable.

Colin



Some =
jobs may be too big to handle simple edits.  I couldn=E2=80=99t =
imagine, for instance, that TLS 1.3 would be a bunch of edits on top of =
TLS 1.2.  But the streams would largely need to make that call. =
 Interoperability concerns would also largely fall to the streams, =
although the RSE might need to provide mechanisms to warn about =
pitfalls.

Thoughts?

Eliot

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




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








=

--Apple-Mail=_B7B6FAA3-500E-4FD5-8C2D-261DAA1BFBDC--


From nobody Tue May 26 14:24: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 295F83A082F for ; Tue, 26 May 2020 14:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDUs7iqounee for ; Tue, 26 May 2020 14:24:20 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CFA3A085D for ; Tue, 26 May 2020 14:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=Mdfkh/PQNcuw/NP4aFJPndYWJ52oZJWSmIr0ThXKIYM=; b=oA/jo653KM5m0zT3BVmydUhEVW DH2ufUt/C4YFW3MEseBD0Ucb60xhhSovEh3MippOpovz5R2yDkBktVgEwePlCLI2zOjOZ2FzYoUEq IW1BQ8Gls75aPBxzFjal8oS6zTqDmN6hy/9FmKGvE9HMf760x4WP+E85JIaBKamMB2mXGFj+CjlnT hSjzX6apnofi0LEGNgl9QfhaDr0tJgKzHHY+Y0+iJy8NBOjvCOiy4HPG31NFzZAGIaw7hzbk6xmfo KtKqnzI2xzyz9r+PeBo04XPUVpvrzeeoY0IQESlx/vjOM10ObxAKqEFeK0Gi8sKSVt8lvhlPGNcpW P8egXV3Q==;
Received: from [81.187.2.149] (port=33710 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jdh3W-0006mF-Fi; Tue, 26 May 2020 22:24:14 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Colin Perkins 
In-Reply-To: 
Date: Tue, 26 May 2020 22:24:12 +0100
Cc: Rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C031669-FA86-4ACE-930C-6322180A32AA@csperkins.org>
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>  
To: John R Levine 
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 4
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 21:24:22 -0000

> On 26 May 2020, at 22:09, John R Levine  wrote:
> On Tue, 26 May 2020, Colin Perkins wrote:
>> This is the real problem =E2=80=93 not whether the revision to RFC =
XXXX is called RFC YYYY or RFC XXXX.v2.
>=20
> The specs for a mail server or a DNS server are spread across dozens =
of RFCs and errata.
>=20
> Do you foresee an approval process lightweight enough that we could =
sweep all of the DNS specs into 1034bis or all of the mail specs into =
5321bis and 5322bis?

Can we magically solve all the problems with existing documents? No, of =
course not. To do that would involve a significant effort to either =
rewrite and consolidate the text into a new document, or to publish a =
roadmap document (e.g., as was done with RFCs 4614 and 7414). I don=E2=80=99=
t see how allowing RFCs to be versioned changes that effort in any way.

I believe the IETF could develop a process that would allow us to evolve =
new specifications in a way that avoids these problems in future, by =
making it easier to publish -bis RFCs.=20

Again: I agree that there is a problem that needs to be solved. I do not =
agree that mutable RFCs are the right solution.


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





From nobody Tue May 26 14:25:51 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC70F3A082F for ; Tue, 26 May 2020 14:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.403
X-Spam-Level: 
X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, 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 CMHuiXm4vcdQ for ; Tue, 26 May 2020 14:25:44 -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 D86C23A082E for ; Tue, 26 May 2020 14:25:44 -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.15.2/8.15.2) with ESMTPSA id 04QLPS7W096911 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 May 2020 16:25:29 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1590528330; bh=07waWuaR3jJyq+lO6BgCCpHfZM+6dqpnbgpjCE9bHLc=; h=Subject:To:References:From:Date:In-Reply-To; b=Fkugcp+4hQ2lK0ACFw2vaq2lBNDJhTRLCwNfvu4IHfoOOxKHaQCFGPI2rTOh3JeRY /Ui89dSxj2EAPJoK8kqoRSdnMzCF5fbyPBhvkc3hUW4mX1jt3PoADg5hQgfBZ4yXb3 dUefYBG+OClA1K8rKJzcG0eq5fu/LVKaq9qPqUDA=
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: Larry Masinter , "'Carsten Bormann'" , rfced-future@iab.org
References:  <2507455b-a835-52fc-76e5-917ab2070288@gmail.com>  <02f401d63392$db437000$91ca5000$@acm.org>
From: Adam Roach 
Message-ID: <4f1715c8-584f-8400-161e-4af706ccf6bb@nostrum.com>
Date: Tue, 26 May 2020 16:25:22 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <02f401d63392$db437000$91ca5000$@acm.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 21:25:50 -0000

On 5/26/2020 2:21 PM, Larry Masinter wrote:
> A little searching turned up:
>
> ISO https://www.iso.org/developing-standards.html
> W3C https://www.w3.org/2019/Process-20190301/
> IEEE https://standards.ieee.org/develop/index.html
> ITU-T https://en.wikipedia.org/wiki/ITU-T
> WHATWG https://whatwg.org/workstream-policy
>
> I chose SDOs that I think IETF specs interact with (citations both ways)
> I'm sure there are others but these 5 span a range.
>
> None have a role like the RSE in duties and responsibilities.


That's a really interesting observation. I agree that it's worth teasing 
out what we gain (and what those SDOs miss out on) by having such a 
role. Given that we've seen some proposals for relatively large changes 
(e.g., splitting the RSE's "editorial" role from its "managerial" role), 
I think we're likely to have a hard time preserving those benefits 
unless we have some common understanding of what they are.

/a


From nobody Tue May 26 14:31:55 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957D93A082B for ; Tue, 26 May 2020 14:31:54 -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, 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 vKoTlIo0ZU-O for ; Tue, 26 May 2020 14:31:53 -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 8E0703A0825 for ; Tue, 26 May 2020 14:31:53 -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.15.2/8.15.2) with ESMTPSA id 04QLVgVR098038 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 May 2020 16:31:43 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1590528704; bh=sbC1CDN9k0UlXWp55zU7bVnohGnKOk4M9/BeUZeIec0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=rwhpyWxgAdzY8vQfF5j3mhMFPtCjWi7+qEDJi/nbXALQRvymnjnryIfrpjyMzAaYk 9su4MTp9ieVOQQmC7jJfTXHc964Lc4qYvwf/MU1uqm/L3AxJNtbfZgAftFK3jnkNqj 1b6HXtyjVfhtL4A6GprbF1QVGnrKNVahzrNbP+5Q=
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: Colin Perkins , John R Levine 
Cc: Rfced-future@iab.org
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>   <0C031669-FA86-4ACE-930C-6322180A32AA@csperkins.org>
From: Adam Roach 
Message-ID: <9c560363-7225-62ae-0c25-0af54077958b@nostrum.com>
Date: Tue, 26 May 2020 16:31:37 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <0C031669-FA86-4ACE-930C-6322180A32AA@csperkins.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 21:31:55 -0000

On 5/26/2020 4:24 PM, Colin Perkins wrote:
> I believe the IETF could develop a process that would allow us to evolve new specifications in a way that avoids these problems in future, by making it easier to publish -bis RFCs.


As a short-term solution, I agree this is something the IETF could do 
unilaterally by producing and approving -bis documents with fewer 
barriers -- this is why I've proposed such a process. I'm not sure this 
is an ideal end-state, though. My proposal is offered as an improvement, 
and one that I would hope would eventually evolve to something more 
sustainable. There's a good chance that any better longer-term solution 
has implications for the RFC series.

/a


From nobody Tue May 26 14:59: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 698733A09D2 for ; Tue, 26 May 2020 14:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 igCqDFKx0hmo for ; Tue, 26 May 2020 14:58:56 -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 8912D3A09A9 for ; Tue, 26 May 2020 14:58:56 -0700 (PDT)
Received: from [172.16.42.112] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49Wnsj3QKkzyWD; Tue, 26 May 2020 23:58:49 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: <20200526204730.E989819A595D@ary.qy>
Date: Tue, 26 May 2020 23:58:48 +0200
Cc: rfced-future@iab.org
X-Mao-Original-Outgoing-Id: 612223128.4363641-a3a5bde1349701ff0a30e02d8dc4ead4
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20200526204730.E989819A595D@ary.qy>
To: John Levine 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 21:58:59 -0000

On 2020-05-26, at 22:47, John Levine  wrote:
>=20
> it's in UTF-8 with a
> BOM at the top.

Fortunately, that doesn=E2=80=99t appear to be true (or we would have =
larger problems).

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


From nobody Tue May 26 15:01:36 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAE73A09CA for ; Tue, 26 May 2020 15:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 hrebxmzVkZbS for ; Tue, 26 May 2020 15:01: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 394433A09C0 for ; Tue, 26 May 2020 15:01:33 -0700 (PDT)
Received: from [172.16.42.112] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49Wnwq1vyfzyWD; Wed, 27 May 2020 00:01:31 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 27 May 2020 00:01:30 +0200
Cc: rfced-future@iab.org
X-Mao-Original-Outgoing-Id: 612223290.72948-8e338fff63eb1bdbee431bd00707e83f
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20200526204730.E989819A595D@ary.qy> 
To: John Levine 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 22:01:36 -0000

On 2020-05-26, at 23:58, Carsten Bormann  wrote:
>=20
> On 2020-05-26, at 22:47, John Levine  wrote:
>>=20
>> it's in UTF-8 with a
>> BOM at the top.
>=20
> Fortunately, that doesn=E2=80=99t appear to be true (or we would have =
larger problems).

(Sorry, misread =E2=80=9Cit=E2=80=9D as the XML files, which of course =
are in UTF-8 and not BOMmed.)

I think it would useful to have UTF-8 files of the text version as well, =
preferably with page breaks.

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


From nobody Tue May 26 15:04: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 6F6953A0A74 for ; Tue, 26 May 2020 15:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhB2Yor7OOZf for ; Tue, 26 May 2020 15:04:45 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F903A0A6E for ; Tue, 26 May 2020 15:04:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=GieyuBW47KT+O0RYIgMSHui294CPgTQSiIwp0US32As=; b=VEJSusyThUZ5Y+9fwBTUzVZfz+ tFcDep5zz5Yp6xbqFe1oQNBawMnroMnf00KfbeLdVBHNVhaJzGamAhwcZ3S/yhTJJcDOuFGc/zK1v qExQSSbwp+CPNzTUhUg4p/zeCfL/wcE3arnRiuqNUKAMy9LxQTGUcP4KFsGvGbeVDvBLJ4qmTbYth Nx+md+36t51ohSVoq9bUUIiUsgGLJv7KMjQFbkPwwB/xJfM5nUMviTfvK3s1OeC7kddwgd/XXO0HO J2T0SORueh++VnI5uh2GjNZq2ljSJbhqXFhrJg8VztvmbqE7MQ/oyU+T45hTgcj+mtIwOeztW+auz kwn2s9eQ==;
Received: from [81.187.2.149] (port=35892 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jdhgg-0005V5-Ot; Tue, 26 May 2020 23:04:43 +0100
From: Colin Perkins 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_BB9BC48F-654C-46C6-A6FC-C8B12C437F80"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 26 May 2020 23:04:40 +0100
In-Reply-To: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
Cc: rfced-future@iab.org
To: Michael StJohns 
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 14
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 22:04:47 -0000

--Apple-Mail=_BB9BC48F-654C-46C6-A6FC-C8B12C437F80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

[As an individual]

> On 25 May 2020, at 01:35, Michael StJohns  =
wrote:
> Hi - Elliot asked me to write my thought on what elements I might want =
from the outcome of this process - ideally as a delta to the current =
system.   It took me a while to go through the existing documents to get =
an idea of the written baseline.  RFC8728 and RFC8729 mainly.  I found =
myself in agreement with quite a large portion of those documents, =
especially with respect to the actual RFC Series Editor and RPC roles.  =
What I found myself less sanguine with were the various sections that =
dealt with "oversight".  To be blunt, I believe that having either the =
IAB or IESG directly manage other resources  or contracts is not =
tenable.  The criteria of "able to manage a contract or employee" is not =
and has never been a criteria for selection of either an IESG or IAB =
member
>=20

That specific wording is not included, but both the IAB and IESG job =
descriptions ask for leadership and management skills. =46rom the list =
of current and past members, I would be surprised if there was a time =
when they did not include several members with significant experience in =
managing contracts and employees.

> and the delegation of that responsibility to the RSOC does not appear =
to have been successful. =20
>=20
> My general desire is to see an RFC publication system  that retains =
and perhaps expands its global impact and the generally wide respect for =
its quality and reach. =20
> I'd like the people who make up the system to be professionals with =
the ability to continue to help this community publish a wide range of =
documents that help "make the Internet work better by ... influenc[ing] =
the way people design, use, and manage the Internet".=20
> I'd like us to treat said professionals at least as well as we treat =
ourselves.  =20
> I'd like a system that evolves over time, and that is relatively =
immune to influence from relatively few people over a relatively short =
period of time. =20
> I'd like a system that's responsible and accountable to the community =
directly rather than through the two layers of indirection we currently =
have. =20
> I'd like some large measure of independence to be retained by this =
publication system and that the member's of that system voices are heard =
and honored as full partners and not "just a contractor[s]=E2=80=9D. =20
Given the importance of the RFC series to the standards process, the =
limits of such independence would need to be very clearly specified.
> I'd like the RFC publication system to be stable in the face of =
unforeseen challenges and be able to gain (or regain) and retain =
institutional memory. =20
> I'd really prefer that we don't have to do this again for another 10 =
years. =20
> I'd also prefer that once we have an RSE, we assume we keep them =
(after a probationary period) until they get tired of us, or they really =
mess up.
That sounds suspiciously like a job for life. We have rolling contracts =
for other services the IETF community requires. It=E2=80=99s not clear =
why the RFC Series Editor should be different.
> Those are my desires and I could stop there.   But I though I'd =
provide a sketch of how things might be restructured - this is provided =
not as a fleshed out proposal, but as a thought experiment to show that =
I think it's possible to have both independence and accountability:
>=20

Since it=E2=80=99s not clear we have agreement on the problem, specific =
proposals to solve it seem premature.=20

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





--Apple-Mail=_BB9BC48F-654C-46C6-A6FC-C8B12C437F80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


[As an individual]

On 25 May 2020, at 01:35, =
Michael StJohns <msj@nthpermutation.com> wrote:

 =20

    
 =20
  
Hi - Elliot asked me to write my thought =
on what elements I might
      want from the outcome of this process - ideally as a delta to the
      current system.   It took me a while to go through the =
existing
      documents to get an idea of the written baseline.  RFC8728 =
and
      RFC8729 mainly.  I found myself in agreement with quite a =
large
      portion of those documents, especially with respect to the actual
      RFC Series Editor and RPC roles.  What I found myself less
      sanguine with were the various sections that dealt with
      "oversight".  To be blunt, I believe that having either the =
IAB or
      IESG directly manage other resources  or contracts is not
      tenable.  The criteria of "able to manage a contract or =
employee"
      is not and has never been a criteria for selection of either an
      IESG or IAB member

That specific wording is not included, but both =
the IAB and IESG job descriptions ask for leadership and management =
skills. =46rom the list of current and past members, I would be =
surprised if there was a time when they did not include several members =
with significant experience in managing contracts and =
employees.

 and the delegation of that =
responsibility to
      the RSOC does not appear to have been successful.  

    

    
    
      
  • My general desire is to see an RFC publication =
system  that
        retains and perhaps expands its global impact and the generally
        wide respect for its quality and reach.  
    
      
    • 
      
  • I'd like the people who make up the system to be =
professionals
        with the ability to continue to help this community publish a
        wide range of documents that help "make the Internet work better by ...
            influenc[ing] the way people design, use, and manage the
            Internet". 
    
          
    • 
      
  • I'd =
like us to treat
            said professionals at least as well as we treat =
ourselves.  
            
    
          
    • 
      
  • I'd =
like a system
            that evolves over time, and that is relatively immune to
            influence from relatively few people over a relatively short
            period of time.  
    
          
    • 
      
  • I'd =
like a system
            that's responsible and accountable to the community directly
            rather than through the two layers of indirection we
            currently have.  
    
          
    • 
      
  • I'd =
like some large
            measure of independence to be retained by this publication
            system and that the member's of that system voices are heard
            and honored as full partners and not "just a
            contractor[s]=E2=80=9D.  
Given the =
importance of the RFC series to the standards process, the limits of =
such independence would need to be very clearly specified.
  • I'd like the RFC
            publication system to be stable in the face of unforeseen
            challenges and be able to gain (or regain) and retain
            institutional memory.  
    
          
    • 
      
  • I'd =
really prefer
            that we don't have to do this again for another 10 =
years.  
    
          
    • 
      
  • I'd =
also prefer that
            once we have an RSE, we assume we keep them (after a
            probationary period) until they get tired of us, or they
            really mess up.
That sounds =
suspiciously like a job for life. We have rolling contracts for other =
services the IETF community requires. It=E2=80=99s not clear why the RFC =
Series Editor should be different.
  • 
          
    • 
    
Those=
 are my desires
          and I could stop there.   But I though I'd provide a =
sketch of
          how things might be restructured - this is provided not as a
          fleshed out proposal, but as a thought experiment to show that
          I think it's possible to have both independence and
          =
accountability:
Since it=E2=80=99s not clear we have agreement on the =
problem, specific proposals to solve it seem premature. 

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








=

--Apple-Mail=_BB9BC48F-654C-46C6-A6FC-C8B12C437F80--


From nobody Tue May 26 15:09: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 B68193A0A92 for ; Tue, 26 May 2020 15:09:25 -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 JnWNhl59dbFW for ; Tue, 26 May 2020 15:09:24 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B0B3A0A8E for ; Tue, 26 May 2020 15:09:24 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id w20so5714180pga.6 for ; Tue, 26 May 2020 15:09: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=SxPz4Ms4QWdK6axa3lY5Ul5pqTYe6nDOjUjXE32SKxM=; b=frjC0J1jKX1Gn/SYOEkVtKI5zgnO43qNz9x+jM76fhpjgSXPXTXYSUcFyriPsZid4Z qiTVZ5S+XxkwV0PJnoF9vliA1YjUNp7O2PIhYi50oXKeDclD4bEWbMfZ2PVwYEiAShFN B2giB53K/eOQrhjVYU+/7spU0kdIeYzzqxlsEehzoRO/HyuCFNelN04fZ15oYeNusFGe kMfR/podYe4H58zdpAoWnK1/2sFmLZFzijW+VTxJKyKcCCGoCS+T5hTVlWl8XX8rcN9f xRXWbhYuPttXZwxUwGRXspw3qXVYNPZeU/cG6h1yf66ZXChRlqx1LfVzXMfR5ZNlR+xi iV/Q==
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=SxPz4Ms4QWdK6axa3lY5Ul5pqTYe6nDOjUjXE32SKxM=; b=nbDBX+6A+GcOSIQilNZgftenOA/Qd7r1OULadwcmB6MVqFH3MPONyq0dF/NKw69EvR eP/X1CoW8+cD3c0d6iu2Axzjwl6J6yJ5uFqnDNJDK5TpBElZEhsZIxRgbSiTvxUI2mwH d5PLlC2EugwbVj94g+j9Oi9pXHISd9YrUc3/g7urIVbZaEsmq0/mIGpX+WYjOEUHXJK6 UEwvV7l73qtCt+zvQc4fHNbklwM9FLXrYoj8cKDtzUXn1MZ4/BBpXp9+LNYXAgBoCxid YcvveFsdbWfUYl/vFx7L8Qu18ZWoCFizTN8i40UmtV5Pd4TXv5QtdsInMr6YRFwIyDGz 0kjg==
X-Gm-Message-State: AOAM532v4+0Ka3CnYvs3tnpQGBcx8mo2duF6ZfOmlrk9sK0KpjwOuBu/ VuPChGYjKrrMifH7IRe9XNrZz5dT
X-Google-Smtp-Source: ABdhPJxkJ7CoZTOraxTxPOoNLvO6E7YJRYR9JScJxmaCmND6W5eR88HUhi3QrMtU7JzryaPW+VmVzQ==
X-Received: by 2002:a65:66d5:: with SMTP id c21mr894478pgw.155.1590530962676;  Tue, 26 May 2020 15:09:22 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id p7sm417721pfq.184.2020.05.26.15.09.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 15:09:21 -0700 (PDT)
To: Julian Reschke , "Joel M. Halpern" , John Levine , rfced-future@iab.org
References: <20200526170218.0F0BB19A1F83@ary.qy>  <1e2313a7-14b9-1aca-9780-2ea3f025574f@gmx.de> <370eba06-cebd-57c7-8f25-b059a7c965b5@joelhalpern.com> <1af58168-f49c-3335-4c9b-97b195d81c91@gmx.de>
From: Brian E Carpenter 
Message-ID: 
Date: Wed, 27 May 2020 10:09: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: <1af58168-f49c-3335-4c9b-97b195d81c91@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 22:09:26 -0000

On 27-May-20 07:24, Julian Reschke wrote:
> On 26.05.2020 20:51, Joel M. Halpern wrote:
>> Actually, our statement is that the XXML form of the RFCs is the
>> immutable archival form.=C2=A0 that does not give us any room to modif=
y it.
>> If we want a new archvial version (and once we have a new v3, I think =
we
>> do want such) then we need to produce it properly.
>=20
> The XML format currently used doesn't have a spec. It adds undocumented=

> features, and some of what RFC 7991 says isn't implemented as specced.
>=20
> This *could* be ok for archival, once it's documented.
>=20
> We're currently trying to reduce the gap between reality and
> implementation
> (, but it's
> hard to do lacking feedback from essentially everybody else.

If there is a decision to formally update the v3 spec (that would be
Updates: 7991) then we could decide to retroactively update the older
XML files if we wanted to. It's our choice, because the entire dogma
that RFCs are immutable is *our* dogma and we can change it if we
want to. Or we could declare a new version. But that would be a bit
weird, since as Julian points out, we aren't actually using the RFC7991
spec anyway. So all the recent RFCs have been issued in a formally
undocumented format.

(As far as I'm concerned, the current spec is always whatever the current=

conversion tool accepts.)

  Brian, certified pragmatist.


From nobody Tue May 26 15:09: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 5D2603A0A92 for ; Tue, 26 May 2020 15:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEo0METc6-OO for ; Tue, 26 May 2020 15:09:45 -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 8B4C33A09F6 for ; Tue, 26 May 2020 15:09:45 -0700 (PDT)
Received: (qmail 55482 invoked from network); 26 May 2020 22:09:43 -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:content-id:user-agent; s=d8b8.5ecd93a7.k2005; i=johnl-iecc.com@submit.iecc.com; bh=QVvosTgtGtzq7d1PIJd9ohOYnokxU/80iFyveOrbYb4=; b=UzFkKWMgz265RqZsaasjAT6ompFVMCkyMFV9HoE/m4R5nA4wGEkGMZAWen4VBekp+24uXd/LIyqk6MFbbS7MIp804CQS3xoj9Bcz1lZvmz7JS87gKeMHNFxB+86nk6q+ZY/2+gmGV2p5hIkKDCAljLU7tsJ82m4Pu0jUSnrNO1D3SWHxRXStheiAEGYiFxjZVsxqNOX5Arm7VV+sCYo7MyZEJmZzFnxp7wXzOrkfY4YTPMLQ8DRk8Z2dF5puSC7g
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; 26 May 2020 22:09:43 -0000
Date: 26 May 2020 18:09:43 -0400
Message-ID: 
From: "John R. Levine" 
To: "Carsten Bormann" 
Cc: rfced-future@iab.org
In-Reply-To: 
References: <20200526204730.E989819A595D@ary.qy> 
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-984499086-1590530910=:31577"
Content-ID: 
Archived-At: 
Subject: Re: [Rfced-future] existing RFCs, On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 22:09:47 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-984499086-1590530910=:31577
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: 

>> it's in UTF-8 with a BOM at the top.
>
> Fortunately, that doesn’t appear to be true (or we would have larger problems).

I can assure you that the published copies of rfc8650.txt through 
rfc8781.txt are in UTF-8 with BOMs at the top.  That's what the the spec 
in RFC 7990 says, that's what they are.

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
--0-984499086-1590530910=:31577--


From nobody Tue May 26 15:16: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 883793A0A8E for ; Tue, 26 May 2020 15:16: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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 W3ex7jGW638k for ; Tue, 26 May 2020 15:16: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 5E2FE3A09F6 for ; Tue, 26 May 2020 15:16:33 -0700 (PDT)
Received: from [172.16.42.112] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49WpG75pgJzytX; Wed, 27 May 2020 00:16:31 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: <421bf636-3c1b-faac-ba09-9dc8af1a0c9d@gmail.com>
Date: Wed, 27 May 2020 00:16:30 +0200
Cc: rfced-future@iab.org
X-Mao-Original-Outgoing-Id: 612224190.886732-a22abc3e7304e93149783942895346d4
Content-Transfer-Encoding: quoted-printable
Message-Id: <6DD5F169-3A9F-4AA5-80AE-671295C82612@tzi.org>
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <18740cff-425c-f1cb-37d3-e3ea80bb343f@gmail.com> <8b383696-46b0-3023-b1fb-b42095e26758@gmail.com>  <421bf636-3c1b-faac-ba09-9dc8af1a0c9d@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 22:16:37 -0000

On 2020-05-26, at 04:39, Brian E Carpenter  =
wrote:
>=20
> that confounds RFC-EDITOR and RFC-EDITOR*R which is a different state

(One of the little projects that the next RSE could do as part of a =
continual improvement process is clean up that state system, or, more =
generally speaking, the way the progress is communicated.
After some little surprises, I=E2=80=99m no longer sure even the RPC =
personnel understands it fully.)

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


From nobody Tue May 26 15:19: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 0C36F3A0AA8 for ; Tue, 26 May 2020 15:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDMvVNsoYWQd for ; Tue, 26 May 2020 15:19:45 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C5B3A0A9D for ; Tue, 26 May 2020 15:19:44 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id x11so8294602plv.9 for ; Tue, 26 May 2020 15:19:44 -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=b2ja+XHKAgZeBMPxj+3WiUdmnSlwn19Yx071gpe9CQo=; b=pnEdezRQa14qSHODRJhNBIHAPvcNd9hjOpSuvyxrlNykN28JxhQbKe7GfLnjJ5Awr/ q+QBdTgaiPcjUpS/SBfVbEuoVEdUAP6Mocz28NTf3HHetHtJge0DN0b8Ujs8RPx2pXbw S6A4BLZ6dGieZ2t3c1qDDhB7uvRFo3gUDmSfXIFUzbwW5gYgkC41L7x7d45rlYumyIQb UAxNW1P56zAjUFzcV+M44X/4Pbcv7tg6tVPhLbiMPk/oVZQQCHs5WURgiZ7J877xQ/7f xUZzpOb/DzrRkZSNeUm0fG2WEkc31PuxzOzRYX8F7sSyZ2CUttgO+MvGPeyOR1Fod4H8 Ov3Q==
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=b2ja+XHKAgZeBMPxj+3WiUdmnSlwn19Yx071gpe9CQo=; b=YxhBy7Od7WsTQpJzZV/22amxbWo0fF/WD2nwbCZpJQ1hhhe1EGbKIAmDtLM+Co3zP4 hU926P1jZqVTkDT99Iha8Qm/ESdKEa3XCujdMEgyt2pM8iTsuVt1JBD3DtmbfIw4kaox OZg4UwaDvZN/AJmFzxvYl32bwdquA/1cDDiH4LEpmaW7cb+r/2KmXuqblEvlHC8zvIKr fYDSaAnZ5YywWDK70eZ2c5VhRv2NWzLqPg34WEIka/bKFJyld+bzUsvQzzrZEBbjtuLW o17uU8PBdpdwTUfxzWI2/EEC3xpJc+wOJBor9eOVgIbSFNsvJTG3O/f7Ei9OID6eakwI oA1Q==
X-Gm-Message-State: AOAM532gmfLE5Pa9xBG2jeHLn5Qb+wvZh0BBgMVcsFNacvpN3Abskj67 1Tn1Tmfl190mnqB1ux3yzUxNEEyw
X-Google-Smtp-Source: ABdhPJzmnmORu8wptIQZrNUgOOb+FwT65aUMnuNQHyYhZ2OnAA03J5ZdRgMZbrwMS0tm2vkooOql6Q==
X-Received: by 2002:a17:90b:503:: with SMTP id r3mr1419785pjz.69.1590531584266;  Tue, 26 May 2020 15:19:44 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id z20sm443697pjn.53.2020.05.26.15.19.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 15:19:43 -0700 (PDT)
To: Carsten Bormann , John Levine 
Cc: rfced-future@iab.org
References: <20200526204730.E989819A595D@ary.qy>  
From: Brian E Carpenter 
Message-ID: <06909c7a-5bc1-d384-5061-ef62de5e8e33@gmail.com>
Date: Wed, 27 May 2020 10:19:37 +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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 22:19:46 -0000

On 27-May-20 10:01, Carsten Bormann wrote:
> On 2020-05-26, at 23:58, Carsten Bormann  wrote:
>>
>> On 2020-05-26, at 22:47, John Levine  wrote:
>>>
>>> it's in UTF-8 with a
>>> BOM at the top.
>>
>> Fortunately, that doesn=E2=80=99t appear to be true (or we would have =
larger problems).
>=20
> (Sorry, misread =E2=80=9Cit=E2=80=9D as the XML files, which of course =
are in UTF-8 and not BOMmed.)
>=20
> I think it would useful to have UTF-8 files of the text version as well=
, preferably with page breaks.

My experimental result is that the "v3-plaintext" format is UTF-8, has no=
 BOM and does have pagination.

   Brian


From nobody Tue May 26 15:23: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 3526D3A0B68 for ; Tue, 26 May 2020 15:23:42 -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 cjn9iavCgLoR for ; Tue, 26 May 2020 15:23:40 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30ED93A0B62 for ; Tue, 26 May 2020 15:23:40 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id t16so9279797plo.7 for ; Tue, 26 May 2020 15:23:40 -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=Uw3goCmzQx8g5hiFzLtE+pkVcLUPw05NIujLMiW+rQk=; b=jGTzl3KgHMh/iQ4L4FFir23xoarKKP+TaDS+wY87ecsAFL5nmocnMLZ7oW9qivBsNg OhWUHtjuioebtjX+f1TUQDvKSS9pxehuBwRKq9dylYLkQnIPPrJDzE/1Y/Nl7TpqLyFZ 8Xgz8I3FBb9QF7aZDzdtdPGC8ycJupIzIcGctdhnY3kmG412kVVP4uXC6Q3uMPvIb/ET Kkit3u428ddId0NaJBSZOck143VUYWUEP30jUcZamoW3p+hUp5ROt4/2beSspydh3AIA bTuJTIegyFC/JOuStwHxWCCkJ5pAdwlq5VV8dIh+z8HXwIr46JqWayq25SH2+bDP6I1x qLOw==
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=Uw3goCmzQx8g5hiFzLtE+pkVcLUPw05NIujLMiW+rQk=; b=LhIKwfrk10TmReUmwvvueVXrVOk8+hDbErdCW7vN8IO33X76yWwxXeff0N3RzIG7JS zhTqdFwr9qU6RiOAnkMh4/1gpxGm4EdVv6F1Yxz7pYzilNGOLFD3obhap051/WVbc0e8 hT6B9/08X7523BNPb8EAHw5US53oHV6e81Q16ea4roRRSmxTd0pHLdO8pSBs0NBgUE+v 7mcNakGjSccY0oklmK+3lTGObLi22iSwTKdjEuLOyjH6rxHLYVvLgdWWXgENRbtkx4jy YfBBISjtaaqCxa6byXsyjniHHiuLvCW3FHuskkCeVjutJDJejGlZULY2q9861/Fh7fEX y5Rw==
X-Gm-Message-State: AOAM533+UrocNRf/bJtt5bGhXcNObbrYKBHLFBOZinvdhTzTbOWMthf1 gKp7/Dg51XuCt5T3g9VCf1wRepP4
X-Google-Smtp-Source: ABdhPJzq/H60Cnvkt2VDlq5nRXBRKwOd3wWpVI2OF6xLhEjXqyeId0pmO7F5Zge2UVWLsVku/PA9iA==
X-Received: by 2002:a17:90a:2a4a:: with SMTP id d10mr1483407pjg.32.1590531819503;  Tue, 26 May 2020 15:23:39 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id f29sm533395pgf.63.2020.05.26.15.23.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 15:23:38 -0700 (PDT)
To: "John R. Levine" , Carsten Bormann 
Cc: rfced-future@iab.org
References: <20200526204730.E989819A595D@ary.qy>  
From: Brian E Carpenter 
Message-ID: <2e24d5ae-db12-4ece-2988-31f07c911476@gmail.com>
Date: Wed, 27 May 2020 10:23:33 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] existing RFCs, On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 22:23:49 -0000

On 27-May-20 10:09, John R. Levine wrote:
>>> it's in UTF-8 with a BOM at the top.
>>
>> Fortunately, that doesn=E2=80=99t appear to be true (or we would have =
larger problems).
>=20
> I can assure you that the published copies of rfc8650.txt through=20
> rfc8781.txt are in UTF-8 with BOMs at the top.  That's what the the spe=
c=20
> in RFC 7990 says, that's what they are.

import time
print("BOM remover")
fn=3Dinput('File name: ')
try:
    file1 =3D open(fn+".txt", "rb")
except:
    try:
        file1 =3D open(fn, "rb")
    except:
        print("File name error")
        time.sleep(5)
        exit()

chunk=3Dfile1.read(1024)
if chunk[0:3] =3D=3D b'\xef\xbb\xbf':
    chunk=3Dchunk[3:]
    file2=3Dopen(fn+".nob", "wb")
    while chunk:
        file2.write(chunk)
        chunk=3Dfile1.read(1024)
    file2.close()
    print("Rewritten without BOM as",fn+".nob")
else:
    print("No BOM found")   =20
file1.close()
time.sleep(5)


From nobody Tue May 26 15:40: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 3CFAD3A0B0F for ; Tue, 26 May 2020 15:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61iCiLU7GRhy for ; Tue, 26 May 2020 15:40:38 -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 D4CC13A0AF7 for ; Tue, 26 May 2020 15:40:38 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id m7so9316361plt.5 for ; Tue, 26 May 2020 15:40:38 -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=5X4MN43eh+Hp/AM425SGunMtMypvgbGcYDMYp82Jlh4=; b=T4+uR/LB9wKi8QfPwpo+6CQkKfvX7ZbhM9BGzSf9+zuOT4RG2y0/PmxidmlDiHKahh 93neiI8uLRFVpE9V1JtS9GcihKT7EeVOKCbXknlaZPpW9HJghE/vIR4avBkvp6dM9bP8 hzkHD8isKYIo7Yqm4wC7rOqK/yIG/hiaW8aIH6e6Vlt9JNm3OL1Nc+kFv+Di6uU1Ifx8 ZqT5UP5jMkTMBx0z/b6YjMUeKV2qjEgLFQrbNfbBxdjTaa/IKYL0kiPb6uNyenXrcpD0 J3VZxlRorDbbwKHgsV6Kb2LMk42jbKXQueiWAVFsf6O6EcsszW32X1D/0saBM0RHhD5e qQmQ==
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=5X4MN43eh+Hp/AM425SGunMtMypvgbGcYDMYp82Jlh4=; b=kPBH4z2p0o8JzJgbKILR50BdYqIJcMAOzu06LocJNHdhXx95ub/mU6Pw7r6c9tQd06 avGc3jdryBDX/y1qfRCHrmacrnLzNux0/Nez5pIQjar/uM1+NS44/+/FJ0gxJPDTT1sf oeh5um3V0iFGYahXUW68oTypFvUY2xe3XNtTR3hDsWTL1LtAS1nrf2C5N7TBStNWVUfi 1UYDZ9VmCbJNDBBk4XRzKjAMbU5JFCQmOrqES7agEcsPI8SWBdrkSpKyvRaGeCTqG0L9 5qMmjKxdRTGfmHPF9S0po4HiJDcBQ93sx5lVCoirXnUMdFcooQSKdMMIoeQUxGuW+K0G Yn2w==
X-Gm-Message-State: AOAM530Rp5seTqlq3EPY4KbgwnnXR+k68HOd6q9PsRxSugux7ZzAOdkW HTWTNXiFOvmdCkDbDJaVrkIDIObu
X-Google-Smtp-Source: ABdhPJzrCY4jTpuWPSFyGqrjNtgJ6D6NDa+/AVKyUQ1AcYc3aed2DJ3F6jTyfMhitvX+UlWiekwMrg==
X-Received: by 2002:a17:90b:4c0f:: with SMTP id na15mr1523287pjb.112.1590532837280;  Tue, 26 May 2020 15:40:37 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id 136sm454397pfa.152.2020.05.26.15.40.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 15:40:36 -0700 (PDT)
To: John R Levine , Colin Perkins 
Cc: Rfced-future@iab.org
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>  
From: Brian E Carpenter 
Message-ID: <97a12212-c935-00b1-305d-a1e7d83c04b6@gmail.com>
Date: Wed, 27 May 2020 10:40: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: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 26 May 2020 22:40:40 -0000

On 27-May-20 09:09, John R Levine wrote:
> On Tue, 26 May 2020, Colin Perkins wrote:
>> This is the real problem =E2=80=93 not whether the revision to RFC XXX=
X is called RFC YYYY or RFC XXXX.v2.
>=20
> The specs for a mail server or a DNS server are spread across dozens of=
=20
> RFCs and errata.
>=20
> Do you foresee an approval process lightweight enough that we could swe=
ep=20
> all of the DNS specs into 1034bis or all of the mail specs into 5321bis=
=20
> and 5322bis?

This really was addressed in depth quite some years ago:
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04

The short answer is no, the process would not be lightweight, and no, the=
 IETF would not sweep all the specs for a complex system into a couple of=
 RFCs. But the IETF would attempt to document the complexity.

And there are examples, which happen to cover part of the mail system:
https://tools.ietf.org/html/draft-ietf-newtrk-sample-isd-00

For our present purposes, IMHO the RFC Series should be willing to suppor=
t such a mechanism, if and only if the IETF is willing to make the effort=
=2E

    Brian




From nobody Tue May 26 17:00: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 CC1863A0BEB for ; Tue, 26 May 2020 17:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=o8WRpjjp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DcLm7Jx4
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j06-Hw2rQd4B for ; Tue, 26 May 2020 17:00:00 -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 0ABA03A0BDA for ; Tue, 26 May 2020 17:00:00 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 38444FE3; Tue, 26 May 2020 19:59:59 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 26 May 2020 19:59:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=W Mppu2V3Il3cLuMTT1nNW9Rl/tCEJsqqzh94NXUZ15Q=; b=o8WRpjjpBiLbia4VA eEhJb9h9BT26dSqOsVIutjWvk3MyWQxdeba20XA2RdrnkNVMZ9eZSB1k2qj8NSb4 XALYq0PY9iWmDZPBMBidklGrPbixLIwvbjpko+N4J81tj5RJboJCFl0vLAG3r8qg ozjKNbYGofM78+ugf3XakqOhSuaN3otEygRst1a+cK9xMigeT6ZSzSV3BETCjhHG SVIU4jMCzHRTmyT5UuVSLNDtSjoYPESliFthSoqMFu/O8ay6nfzh1m6R+M8ZzG1z x5jUHl+NdWnhpJtjDvCVQKqt4spjxcjth6bIqRqbncQlrbAu0PpBFb46GJe/f1mK QyCdw==
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=fm2; bh=WMppu2V3Il3cLuMTT1nNW9Rl/tCEJsqqzh94NXUZ1 5Q=; b=DcLm7Jx4A0EsDwOtxOx+ruWsLH5clJB4FK67pndKD35MZ6P7w5iSK0zxk GD6wXweBT5MhKBisziXLtUGjcFNZ1P0M/tvbMVII1uRpTd5WkO4rfO+w69cUdlUp ftdPS3mze21r/GTV0u7F2KkJGL0IEKNkpgIbckB9NOmHK1MEmOqOEH4wWrowf4Y7 6V8y95uT1g8iJjQEA6YT+1jpu2ZHJ+zJ1wFCRiofOCFNmF5wwgD5fJR9NwXqEC3c qVnkgw9qZqfGdtxgL30fGD4Z4LnG5YciMPUrrtevn/n7djOJ5cZfM3bYPyGGFDJD gGwhZV8KmSkbPS3oZJqmXkPuJUtRQ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvfedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeetfeelffejfffhheehfeefgedulefgueejudekieegvdeghefffedvheffieel keenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C642328005A; Tue, 26 May 2020 19:59:57 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 27 May 2020 09:59:54 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com> <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net> <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com> 
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 00:00:02 -0000

On 27 May 2020, at 6:49 am, Brian E Carpenter =
 wrote:
>=20
>> To some degree it like the contract for the Secretariat.   The LLC =
holds the contract, but they are doing work for the IESG.   At a high =
level if the IESG is happy with the secretariat, it=E2=80=99s good.  =
Might be a good model for the RFC Series.
>=20
> If it's working for the IESG/Secretariat relationship, yes. Maybe we =
should check with the IESG?
>=20
> Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is =
*not* working?

I agree that it's not working, but I don't think swapping out the IAB =
for another, similar body is going to help in any significant way. The =
problems are structural -- they're caused by the (lack of) description =
of the roles, and their relationships. If we constitute Mike's model, =
it'll happen again.

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


From nobody Tue May 26 17:06: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 0F5EF3A0BF7 for ; Tue, 26 May 2020 17:06:53 -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, 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 i87xbHb7QdqM for ; Tue, 26 May 2020 17:06:51 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 F338D3A0BF4 for ; Tue, 26 May 2020 17:06:50 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id n141so10285454qke.2 for ; Tue, 26 May 2020 17:06:50 -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=vmquXG6r2y3wEqsStyFHGzVSO6eLQhdQPIBpqofwwFY=; b=RN0I4y1Di6P8045au7RJs84UYmSpE9jXaVG5gqxn3Rl58TylgkA233KznEH89B5zY4 VbfV+n5/e8r3Kz3KaU9OVCjoVtPl8TH6b7BBKvbxuhsraW52ACVCZs4fm5mW8pb0mq1k D38mmK+TtrNMIkhkJIMdCPjdS3oXoUI6xbCnMsUtdUdj2pg+j+iRbHcTati681UCHlXq aMxJs7sUA2iaTdsIgAwub48e6Z2YfKCO5SvwJiIhoKH7xxhOVzAMtkuLL8OhP30hXccM GLVKJ4UKJUj9pQQBDc3/n+Ylma4ppygXAgSmTZ1mMhgRPGTq7nCNaC9FmVBqpWsrcWln wBaA==
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=vmquXG6r2y3wEqsStyFHGzVSO6eLQhdQPIBpqofwwFY=; b=MOW3x+is3zBy9j/huwg1JPG4xvs+HSwwQhhW/sMTgzJMz8hhV3HG9q45VRwwuzcJEs GvPTfna8XpBJImxjWZY/h76E6kQhtov76aztCvN/FE/jHSPlyNHraRFTPtebibrIE5vM 9dAiO2pGXVYgYSXm4lIu8zpo8Cn2XtzFDCmZ1GL1ymh22G7/TJk6488Cu+C1Cm/aulh0 sIJAgaWRd2W3XBuTa2B0HreeCI98Qrmtvd7Jq3+VNP/KzBfUjTHBmsR8iHAPVxHqWbTi 9dYx51chPmSdZ5CsVNf5uljLj8LOG/56+ow4xbSvLrJYxaQaOr7BA3N1kltOYu1LXZ+9 +v+g==
X-Gm-Message-State: AOAM531Ws/rVIMM6hQORVjGVqMWIZKWA5OZVpuTIiWbLYm5MjFJAmH+O lMw4S4Y2AeMADI6IYI0bviX4ojB+JAw=
X-Google-Smtp-Source: ABdhPJxBN192IS580n8NHKwpC4Qvqbmp4nAbEqKWQyFvBdv514jNooqSKsv2/E++95J0Y6Vr0Wziug==
X-Received: by 2002:a37:7984:: with SMTP id u126mr1457168qkc.73.1590538008569;  Tue, 26 May 2020 17:06:48 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id w68sm1048734qkc.68.2020.05.26.17.06.48 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 17:06:48 -0700 (PDT)
To: rfced-future@iab.org
References: <20200525165200.D76EC199A58B@ary.qy>
From: Michael StJohns 
Message-ID: <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>
Date: Tue, 26 May 2020 20:06:47 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <20200525165200.D76EC199A58B@ary.qy>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 00:06:53 -0000

On 5/25/2020 12:52 PM, John Levine wrote:
> In article <53f690a7-9477-47a7-a256-75139aae269f@dogfood.fastmail.com> you write:
>> At this point, the remedy for the RSE is to resign rather than publish under their watch. They must have this option open
>> to them, but that is the ultimate remedy available to the RSE.
> Agreed.  The point of a having a nuclear option is to force people on each side to think really
> carefully before pushing the button.

I submit that this pretty much what happened with Heather and it's 
really not IMHO what we want to have happen ever again.

On one hand, you have a group of people with little or no skin in the 
game - they might not get their document published, but it's not going 
to adversely affect their career and livelihood.  On the other you have 
someone who basically has to either give up a job that they hopefully 
enjoy and take pride in or bow to pressure and stay silent and perhaps 
have their name on something they find problematic.  E.g. for one side 
its like stepping in a puddle, for the other it's like drowning.

The funny thing about this is that we all agree that the RSE may 
prohibit publication of a document - we're just arguing about what 
conditions apply (e.g. small editorial, large editorial, content, 
technical, violations of physics).   I'd rather - in the words of 
someone who was eloquent on that point -

>   don't appoint an RSE who is a jerk,
> rather than to try to invent meta-meta-rules for bad faith situations
> unlikely to arise in practice.

In 40 some odd years there's one apocryphal story about Jon refusing to 
publish a document.  Up until 10 years ago with the transition from ISI, 
there really was no question that the RFC Editor had the final call.  I 
don't expect there to be cases where this happens in the future, but 
that's because I lack imagination, not because I think it can't possibly 
happen.   I suggested a way forward by allowing the RSEB to be the final 
shot caller and placing a pretty high bar on that.

Later, Mike


>
>> P.S. There also needs to be a way to deal with RSE filibustering, and/or tarpitting - either undue delay in publishing a
>> document they don't like, or running out the clock and then sending it back with minor edits over and and over.
> I think the solution to that is don't appoint an RSE who is a jerk,
> rather than to try to invent meta-meta-rules for bad faith situations
> unlikely to arise in practice. We have had RSEs for decades and as far
> as I know filibustering has never been a problem.
>
> R's,
> John
>


From nobody Tue May 26 17:18: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 C72AD3A0C0A for ; Tue, 26 May 2020 17:18:18 -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 ljjYikkZNCKk for ; Tue, 26 May 2020 17:18:17 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 7AADD3A0C06 for ; Tue, 26 May 2020 17:18:17 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id b6so22688904qkh.11 for ; Tue, 26 May 2020 17:18:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=8yYl6OioI1L1RziYKY0q21+iZyoysHq0QO4IEMtu1JY=; b=0Qh8T0n3iOE42jhQO5KsopEQa9lvVgg/vggMhgJCkw5pwFdEB/5aeu1+RCDXrLPdIB mmXq3oOeDKh5AmhV9wp0KgHHYG+TViFhclR65yB9UIEY21LEKS1X/g5b6LAKQ0JJU7rc aiJfSqEeGHvHphJFAesko5fLtZhIyqKG0ngrOqfmkrlTi0YnS57l0A2qHyXU/Ur/gkL4 XMsFoOj2cZRe2vjE1kQu8hH9bpJW14sfXx6L8+N7z7BvHsC40SOqtIVYk1jb/vmOR0Oa tIV3UvwtDbhJnyjSd7V1fIgu8rbjUI9u7l4siRi4iavtwxZFn/rNvz4S3/xoMWcOiaGF ZSzA==
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=8yYl6OioI1L1RziYKY0q21+iZyoysHq0QO4IEMtu1JY=; b=JHRjyJZNqbPxRp4xZTBfq4Ok2qw+nGsGUALJprKgl/VzAKYG3AJnjkPMpQXVYVNO4E X53C2ovDX4eSr9j50riuU2aDdMmz3//K4zy+dQvC66shM9Lsn1u2ws0MLnK5h0ccuha1 R+IoEr7RqDr37PbotCAaDADCtWubdQbt4EL0QXFZwnNlC7gcvZUHARjavH0Vab01yU1U M0+M/jL8OqIeDMCiqdXGJrhnfeaI9g0Mh3w0igpBoRB3c3UBXBN/XKSdc6nw0GnGv9g8 DXLw4E5/aiwrj4RFt5dMbBj5r/ALwxehB/yEbzzO3JEZTnUBAdRkx7YadE3Bg8JrH16s k01w==
X-Gm-Message-State: AOAM533XE0tdRBw+gyye4MSBFgTPjK/hSs4J+tVRGzEqad9HTO9w80xp gnDNLFh8WAPxU6pWhyLD0BbfkxPm2rU=
X-Google-Smtp-Source: ABdhPJwaLeynEjxfmf+h9W5MXy8/KKPjdbV96Z8Gz0Q5JcnLs2GrCs7a0cJzWrWHVFLttnHWQyKVzw==
X-Received: by 2002:a37:9c84:: with SMTP id f126mr1600372qke.140.1590538696048;  Tue, 26 May 2020 17:18:16 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id v14sm1168395qtj.31.2020.05.26.17.18.15 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 17:18:15 -0700 (PDT)
To: rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> <18740cff-425c-f1cb-37d3-e3ea80bb343f@gmail.com> <8b383696-46b0-3023-b1fb-b42095e26758@gmail.com>  <421bf636-3c1b-faac-ba09-9dc8af1a0c9d@gmail.com>
From: Michael StJohns 
Message-ID: 
Date: Tue, 26 May 2020 20:18:15 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <421bf636-3c1b-faac-ba09-9dc8af1a0c9d@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 00:18:19 -0000

On 5/25/2020 10:39 PM, Brian E Carpenter wrote:
> And for our business here: is progress-chasing at the RPC a job for the RSE, or for IETF LLC that holds the RPC contract?

The general rule in the US at least is that you can tell a contractor 
what to do, but not how to do it.  I don't have a problem with the RSE 
being the contract monitor and technical advisor (both to the LLC and to 
the RPC) on the RPC functions.  I believe it would be unfair to tag the 
RSE with responsibility of nagging the RPC and judging their performance 
on the RPC's performance.   The main role here I think is to identify 
current and pending problems related to the RPC to the LLC and suggest 
ways to mitigate or resources (and perhaps budget) to be added. 
Alternately, we outsource everything into one contract (including the 
RSE function) and only have one place to kick when we're unhappy.  (I 
*do not* recommend this approach).

Later, Mike




From nobody Tue May 26 17:20: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 ACEF93A0C0C for ; Tue, 26 May 2020 17:20:17 -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 77g1DICDXN7G for ; Tue, 26 May 2020 17:20:16 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 D5EBB3A0C0B for ; Tue, 26 May 2020 17:20:15 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id a25so15137795ljp.3 for ; Tue, 26 May 2020 17:20:15 -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=2dSuOICjpkow8NtZzWzQOZrwpJ26nM9Fw/6sYl44b88=; b=YQ89vq7+oEblgKyunQKbQXRmz0Pc6G3AR1XV1Ekm8wYuFGOynpXA9CDiikvlpjynFQ RA0CfqIDb05VtTTrMdX86/0wOOGQ7iBih5Yq/EvL6Lr5BIrWBT+OdFnXHXPSANvrast9 4AedUozdD4690O2SJ86jY5UFkvpe8lMQJbpdH5yb0QUK1t4QkrifAw+Sy40CDJnJ6Yi0 57pP9BATC/Ur0g821dklplUyq1D13j1sGLARGUSvvdPI+/SZgPdq+cpKQDiL6e7NqEkC 8K7WRNK0uVXXUY8Ry6wsQSp3R2SAdGpD8Cy3zZPdL70vDMNuO/F4DSg01U8z0kXYVdcl TwNg==
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=2dSuOICjpkow8NtZzWzQOZrwpJ26nM9Fw/6sYl44b88=; b=exU6z9cIwXAFek20kd9LaT4OnnKYnZ+FlZ4kc85PDGVs52taq49Mo0pTfWi2drWW5v pYuAZtWfBIFdPKXYrR5A7eKQ6YcxAMTypsFBzAb1nVyqz4jaHsLEaguyXOaINYtrnm0+ xkJrfkBGnGQlMmyENwIRfOJe066ez3T5cW2h80wJliQUOwrUAJYTGU2RqZZWMNrFCvqN DqCUx+HyVkPz1cEh3c26j1zwQvQ+/1kDu6pqn0+idRLDZLi6Z4CP883q5vikfMYgblSW tO3ArvgqtahRRmvO7EjrGE36RYoqy+FJ7kR0+qezhQxw0TL6a44IKziMJkolYd77Z3Dd PtOA==
X-Gm-Message-State: AOAM532x80+PhQNjypY020eGv2UVjXvO4YQQaD5jtMEwq3OoL25X0M4y MOOmXTqpuPHiSWNHXuUQslF8R7gL63L97QKLAnpEFg==
X-Google-Smtp-Source: ABdhPJwiQQyMnxBW2XdH1O1vQW3aRVtMqfhVb0RytNMAhk8UoFvGhwubNGP4NcNS0SVyimDDV9sxN+9pW9AYDocx0xA=
X-Received: by 2002:a2e:b4e2:: with SMTP id s2mr1538490ljm.17.1590538814078; Tue, 26 May 2020 17:20:14 -0700 (PDT)
MIME-Version: 1.0
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com> <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net> <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com>  
In-Reply-To: 
From: Eric Rescorla 
Date: Tue, 26 May 2020 17:19:37 -0700
Message-ID: 
To: Mark Nottingham 
Cc: Brian E Carpenter , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="00000000000003d0a605a6962d60"
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 00:20:18 -0000

--00000000000003d0a605a6962d60
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 26, 2020 at 5:00 PM Mark Nottingham  wrote:

> On 27 May 2020, at 6:49 am, Brian E Carpenter 
> wrote:
> >
> >> To some degree it like the contract for the Secretariat.   The LLC
> holds the contract, but they are doing work for the IESG.   At a high lev=
el
> if the IESG is happy with the secretariat, it=E2=80=99s good.  Might be a=
 good
> model for the RFC Series.
> >
> > If it's working for the IESG/Secretariat relationship, yes. Maybe we
> should check with the IESG?
> >
> > Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is *not*
> working?
>
> I agree that it's not working, but I don't think swapping out the IAB for
> another, similar body is going to help in any significant way. The proble=
ms
> are structural -- they're caused by the (lack of) description of the role=
s,
> and their relationships. If we constitute Mike's model, it'll happen agai=
n.
>

I agree with Mark here. We need to first figure out what it is we are
trying to achieve before we start designing mechanism.

-Ekr


> --
> Mark Nottingham   https://www.mnot.net/
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

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




=

On Tue, May 26, 2020 at 5:00 PM Mark =
Nottingham <mnot@mnot.net> wrote=
:
On 27 May 2020=
, at 6:49 am, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> 

>> To some degree it like the contract for the Secretariat.=C2=A0 =C2=
=A0The LLC holds the contract, but they are doing work for the IESG.=C2=A0 =
=C2=A0At a high level if the IESG is happy with the secretariat, it=E2=80=
=99s good.=C2=A0 Might be a good model for the RFC Series.

> 

> If it's working for the IESG/Secretariat relationship, yes. Maybe =
we should check with the IESG?

> 

> Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is *not=
* working?



I agree that it's not working, but I don't think swapping out the I=
AB for another, similar body is going to help in any significant way. The p=
roblems are structural -- they're caused by the (lack of) description o=
f the roles, and their relationships. If we constitute Mike's model, it=
'll happen again.

I agree with Mark=
 here. We need to first figure out what it is we are trying to achieve befo=
re we start designing mechanism.

-Ekr




--

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



-- 

Rfced-future mailing list

Rfced-future@iab.=
org

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




--00000000000003d0a605a6962d60--


From nobody Tue May 26 17:22: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 680963A0C0D for ; Tue, 26 May 2020 17:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWZ1rql2iB5f for ; Tue, 26 May 2020 17:22:41 -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 4CBA83A0C0B for ; Tue, 26 May 2020 17:22:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 62115BE24; Wed, 27 May 2020 01:22:38 +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 BV9iIlKmQhkJ; Wed, 27 May 2020 01:22:36 +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 89085BE20; Wed, 27 May 2020 01:22:36 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1590538956; bh=qkDRGtF1QNxJ0OGWaPfrGj39BAxfhIZp4/bxkSaEu4s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=N+RJpVKcgtn9+Xj7PbrPe03X7c9XiYfHRWMqUTFaoZGS0gXxwo699JzJe6yJe8cow RgDJ4/NEq4oPSkVECxqgQEgdZhVYpvG7oNOQXC94aOO8NDoVp/pu1ON6qh3Vajk8/W ygpmAW5Vx5itjYa/ayImS0GTPxutUgDG+j7rJhaM=
To: Michael StJohns , rfced-future@iab.org
References: <20200525165200.D76EC199A58B@ary.qy> <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.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: <319ebd6d-e6e6-93fa-d94e-a9fb7e60f3ea@cs.tcd.ie>
Date: Wed, 27 May 2020 01:22:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mNdQqScbUAVwHuGE4Chv0PWalH6jbckd4"
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 00:22:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mNdQqScbUAVwHuGE4Chv0PWalH6jbckd4
Content-Type: multipart/mixed; boundary="lv6hnkhFwxevBENm1m4OaGyfjb1YImxye";
 protected-headers="v1"
From: Stephen Farrell 
To: Michael StJohns , rfced-future@iab.org
Message-ID: <319ebd6d-e6e6-93fa-d94e-a9fb7e60f3ea@cs.tcd.ie>
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
References: <20200525165200.D76EC199A58B@ary.qy>
 <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>
In-Reply-To: <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>

--lv6hnkhFwxevBENm1m4OaGyfjb1YImxye
Content-Type: multipart/mixed;
 boundary="------------B479DCB74C7A5942B701457B"
Content-Language: en-US

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


Hiya,

On 27/05/2020 01:06, Michael StJohns wrote:
>=20
> The funny thing about this is that we all agree that the RSE may
> prohibit publication of a document

I don't agree with that statement myself.

I think the earlier discussion seemed to indicate that
the RSE would need to go nuclear (i.e. resign) in that
situation and was not expected to have "prohibition" as
a weapon of choice. The RSE ought have a bunch of ways
of pushing back if one of the set of streams starts asking
for gibberish to be published, but no, I don't buy a veto,
which is how I read your mail.

Cheers,
S.

PS: I do think the IAB screwed up in the events that lead
to Heather's resignation. I hope we don't conflate things
too much but extending the RSE's powers in that way solely
based on that IAB screw-up doesn't seem like a considered
plan to me.


--------------B479DCB74C7A5942B701457B
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-----

--------------B479DCB74C7A5942B701457B--

--lv6hnkhFwxevBENm1m4OaGyfjb1YImxye--

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

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

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7NsssACgkQWrL68XsX
K+qg6w/+PeacQQYjmoBTo+zoPtrEoviihuRY2F/EhWhWFil+mkfYUZw5F+/anim5
8ZbBMX/I9OodAAYtCBlhSc5HARpWgM+Dir6p9iGOC7Y3cKfK9UhVzGGGeadUHmEI
y7eNPjTXN/khaHchYgvauEmOOy+gqJNtlVdE0+P6nSLlAD8+YfOZpa8gTCuAq96f
yynC46BYxpchHJc1sXa+j8NSORo49H+wyoyKpWKjTZtGILCYzb66dc0Z0G+u+Y9v
cmhmCSE2AWCmfa9Dnp/gLzOdmM3VdqzEXAT7myger6jOMlwcEM0vmx1sQ/wV1RPQ
PSQ28EOFE7mBtTQNxXVhOCeSS2WPFMmtzTGxIVJILvttKC+JyJZVg6ikqolfmPeC
It/xTsyWGiaTgvdMjNG6RMLcpgVf+vUFTK9usX3crrYbYoKHiu8cCZaZVJNUYF3B
ejHnuqGSswjNOrBTDQEaurKSEthw396olDDXUbqP9ZdzcBfi8IsXe/MKGX/Ri7ON
vIpIKnfEwE9pp8/xXRMBk0R/7tlsa27mKxVn6oWaB0JsRiBAY9VPBTIuIzorAySp
a8qfXNGIVUIZveKmePIQSgoHmfWzfI1Ka7AdfhXdfFViCEH3eraVGIctlm9mQt6f
v0/q54omOLUW4Zn08Xfcjki3FQILiESuZQ8xbdYNwp6sflDYSvU=
=3xXa
-----END PGP SIGNATURE-----

--mNdQqScbUAVwHuGE4Chv0PWalH6jbckd4--


From nobody Tue May 26 17:41:55 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEB63A0C5D for ; Tue, 26 May 2020 17:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEhkJfoZH1uM for ; Tue, 26 May 2020 17:41:52 -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 BC29B3A0C5E for ; Tue, 26 May 2020 17:41:51 -0700 (PDT)
Received: (qmail 82808 invoked from network); 27 May 2020 00:41:49 -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=14374.5ecdb74d.k2005; bh=jwSsDmibK+oJGWUMuf7pJSmzE7sChbRNI7SlMwgk9jg=; b=FOAayB6YCykw26+gFtmchc6ZCFe09WdGjhkicNyMmkzHIaupbf8Q56xDiuNHntPfZtOXoYDHO3vSug1NFKKkUxTDVkusYKKdUvBmvB220UkKrj9CJsBENdPeLWap1NiKW+lRGUgEszj9Dsvsi/d4VwCon5oKgMC2neObexRbZ6MbilMsEDjcj7N9HGdZL3227v0NqwRPLC2uoUKyOmbA181UivaC/2vYTBaJudAB0I2xsiCIlSPw5ffUeYl19392
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 27 May 2020 00:41:48 -0000
Received: by ary.qy (Postfix, from userid 501) id A335E19A7319; Tue, 26 May 2020 20:41:48 -0400 (EDT)
Date: 26 May 2020 20:41:48 -0400
Message-Id: <20200527004148.A335E19A7319@ary.qy>
From: "John Levine" 
To: rfced-future@iab.org
In-Reply-To: <06909c7a-5bc1-d384-5061-ef62de5e8e33@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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 00:41:53 -0000

In article <06909c7a-5bc1-d384-5061-ef62de5e8e33@gmail.com> you write:
>> I think it would useful to have UTF-8 files of the text version as well, preferably with page breaks.
>
>My experimental result is that the "v3-plaintext" format is UTF-8, has no BOM and does have pagination.

For I-D's, yes, not for RFCs.

R's,
John


From nobody Tue May 26 17:50: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 8906C3A0C67 for ; Tue, 26 May 2020 17:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 fL12RAiuQszv for ; Tue, 26 May 2020 17:50:10 -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 808423A0C41 for ; Tue, 26 May 2020 17:50:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49WsgQ1v3xz1nyD9; Tue, 26 May 2020 17:50:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590540610; bh=6oTHoDdkWNH7WPMFzY4++fiB7EEwHXrllwCf3PXdZjk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=g511DzC66PSGcM6aIyb+xMFwvgyYHRpG5ki1YaBkSBmrT31acEKJRq5luRDIx06Pk S6ojopmhhWW01pBPxXEz/nMbnNzGbdegk5tjk9bKHwSAnTzTtq2RuuOoa2S/zV+LIF Sr5gxecjVI0vTuim9hTSbf9UEFM42+jNNd3I2kg8=
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 49WsgP4TG7z1nsjS; Tue, 26 May 2020 17:50:09 -0700 (PDT)
To: Eric Rescorla , Mark Nottingham 
Cc: rfced-future@iab.org
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com> <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net> <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com>   
From: "Joel M. Halpern" 
Message-ID: 
Date: Tue, 26 May 2020 20:50:08 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
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] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 00:50:12 -0000

I do not know whether I agree or disagree.
Until the mess that led to Heather's resignation, I thought the 
structure was working pretty well.

So I strongly suspect that the forms of "not working" that various 
people want to solve are quite different.  Without specifying what was 
not working, I do not know if I agree or disagree with the claim it is 
or is not working.

Yours,
Joel

On 5/26/2020 8:19 PM, Eric Rescorla wrote:
> 
> 
> On Tue, May 26, 2020 at 5:00 PM Mark Nottingham  > wrote:
> 
>     On 27 May 2020, at 6:49 am, Brian E Carpenter
>     >
>     wrote:
>      >
>      >> To some degree it like the contract for the Secretariat.   The
>     LLC holds the contract, but they are doing work for the IESG.   At a
>     high level if the IESG is happy with the secretariat, it’s good. 
>     Might be a good model for the RFC Series.
>      >
>      > If it's working for the IESG/Secretariat relationship, yes. Maybe
>     we should check with the IESG?
>      >
>      > Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is
>     *not* working?
> 
>     I agree that it's not working, but I don't think swapping out the
>     IAB for another, similar body is going to help in any significant
>     way. The problems are structural -- they're caused by the (lack of)
>     description of the roles, and their relationships. If we constitute
>     Mike's model, it'll happen again.
> 
> 
> I agree with Mark here. We need to first figure out what it is we are 
> trying to achieve before we start designing mechanism.
> 
> -Ekr
> 
> 
>     --
>     Mark Nottingham https://www.mnot.net/
> 
>     -- 
>     Rfced-future mailing list
>     Rfced-future@iab.org 
>     https://www.iab.org/mailman/listinfo/rfced-future
> 
> 


From nobody Tue May 26 18:33: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 367673A0CF0 for ; Tue, 26 May 2020 18:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siWlA3-2VFho for ; Tue, 26 May 2020 18:33:21 -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 BD5E43A0CEE for ; Tue, 26 May 2020 18:33:21 -0700 (PDT)
Received: by mail-pl1-x641.google.com with SMTP id i17so947084pli.13 for ; Tue, 26 May 2020 18:33:21 -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=cacFoItkbDGWpiej2yL7h4pF823LLxr6AcMJ4MsD7GI=; b=P+EbDOYXXDH32XDgdeULeNVe8M+Nahht1qT1EKIES1asmqvKhHln8g0uJMkBzl3sjc UjbXZ69bkz7+fDwfJCLBJSm8bATJ5G1YaTfqv4iUiAQOaeFQKQdgtG8FNiLRg5/buZ7r wCrLxPXpNtryZVRlsCq1OjiV1k2pjs67H+K4QHcle5qtnfateEmRctQALiTBLiBQOz7g 4yaUpAgv751fUelh+VuMwgWPkQ9AREVJFMsGW/ziuaUNUG4M8x/+ZL743cVUulXHsS6O sJjFsuFyz30mSpKsBXXaISUFkpmrOQKYNtG1eksl4rLxQ2IZwLgACzVjy0D5GgepBRHv AmVw==
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=cacFoItkbDGWpiej2yL7h4pF823LLxr6AcMJ4MsD7GI=; b=RtqsDxacrxKQ9daubY0j8NXbUVVdGcoUMhlYpsNLKFpifMe38L2BIKo4y4jv9rMoYl gmq4wQJnR3caD8hk7YGZFEtE9P9HC7bMyN1lSaeVQZu+K9QdqqejMNu4My2lYDJzxjCt RbyQspy/wuI83sI8xNueXkUUapa0FhJ/oqIl+LaWm0yp2znl0iLol0CTHKZwMKBJcMzF mehrazRMUJNpUHmDgZ6efbDi8cwfo4XIPKhwZNw4oXWUSU8xboNrqkStngv3O/mKYAVD NHI3NSpw8A5deyM5EjAtrZ4kw1ldAG5kyjOUenKd/01lloMOJPBVPm7Dw/uxqMLHgtYN xyaQ==
X-Gm-Message-State: AOAM532Ix9AnhLW0duKJiC+D5ZrykijEHVM6bUJoD8q4Qaobo9vQ6G5X g95fa6PQzOZ233NpyeRFhICj1AQV
X-Google-Smtp-Source: ABdhPJxVjKXih8X1IX08TZyvMIQOOhBud7yzw4OMXHCroYJg6E/QfZWwGSq9CzAKy7yQleCA1oNtEQ==
X-Received: by 2002:a17:90a:890b:: with SMTP id u11mr2087646pjn.233.1590543200914;  Tue, 26 May 2020 18:33:20 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id gz19sm600780pjb.33.2020.05.26.18.33.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 18:33:19 -0700 (PDT)
To: "Joel M. Halpern" , Eric Rescorla , Mark Nottingham 
Cc: rfced-future@iab.org
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com> <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net> <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com>    
From: Brian E Carpenter 
Message-ID: <3b66e9a6-fb39-4266-2f7d-9ce88b40195a@gmail.com>
Date: Wed, 27 May 2020 13:33:13 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 01:33:23 -0000

On 27-May-20 12:50, Joel M. Halpern wrote:
> I do not know whether I agree or disagree.
> Until the mess that led to Heather's resignation, I thought the=20
> structure was working pretty well.
>=20
> So I strongly suspect that the forms of "not working" that various=20
> people want to solve are quite different.  Without specifying what was =

> not working, I do not know if I agree or disagree with the claim it is =

> or is not working.

I would guess that we've all suffered matrix management at some point
in our lives. If so, we also know that it works as long as people are
reasonable, and stops working when they're not. So I suggest that our
goal should be to carefully minimise the matrix component of the structur=
e;
it seems impossible to reduce it to zero.

    Brian

>=20
> Yours,
> Joel
>=20
> On 5/26/2020 8:19 PM, Eric Rescorla wrote:
>>
>>
>> On Tue, May 26, 2020 at 5:00 PM Mark Nottingham > > wrote:
>>
>>     On 27 May 2020, at 6:49 am, Brian E Carpenter
>>     >=

>>     wrote:
>>      >
>>      >> To some degree it like the contract for the Secretariat.=C2=A0=
 =C2=A0The
>>     LLC holds the contract, but they are doing work for the IESG.=C2=A0=
 =C2=A0At a
>>     high level if the IESG is happy with the secretariat, it=E2=80=99s=
 good.=20
>>     Might be a good model for the RFC Series.
>>      >
>>      > If it's working for the IESG/Secretariat relationship, yes. May=
be
>>     we should check with the IESG?
>>      >
>>      > Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship =
is
>>     *not* working?
>>
>>     I agree that it's not working, but I don't think swapping out the
>>     IAB for another, similar body is going to help in any significant
>>     way. The problems are structural -- they're caused by the (lack of=
)
>>     description of the roles, and their relationships. If we constitut=
e
>>     Mike's model, it'll happen again.
>>
>>
>> I agree with Mark here. We need to first figure out what it is we are =

>> trying to achieve before we start designing mechanism.
>>
>> -Ekr
>>
>>
>>     --
>>     Mark Nottingham https://www.mnot.net/
>>
>>     --=20
>>     Rfced-future mailing list
>>     Rfced-future@iab.org 
>>     https://www.iab.org/mailman/listinfo/rfced-future
>>
>>
>=20


From nobody Tue May 26 18:35:11 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330E83A0CF0 for ; Tue, 26 May 2020 18:35:10 -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 FmUEmCBK6c7V for ; Tue, 26 May 2020 18:35:08 -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 6E4A53A0CAE for ; Tue, 26 May 2020 18:35:08 -0700 (PDT)
Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 04R1Z4ZC039759 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 May 2020 20:35:06 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1590543307; bh=Va+HMPtnnQTXLee6T9rb4kQX4JZsYljaSXFuCpBYZDM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Wg7Vms7SGq0u6b5YxUR2BnW/2IrNhtfi9ytJeQ1KJPjCpx32/tHCH+LPCWX7H5mTx vZEsWwLpkdM6wlLRS09a4VpGMH7O5jbtZkzoISMjRgnvvxLViFK9TS4EMKcgu4jU9o xCNAKU+6zAU9QnP0m8dW5kGAu/2D5CjQPIvSByTA=
X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239]
From: Ben Campbell 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D01934FE-31CA-4266-B6A1-E2BE42DC9D34"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 26 May 2020 20:34:58 -0500
In-Reply-To: <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>
Cc: rfced-future@iab.org
To: Michael StJohns 
References: <20200525165200.D76EC199A58B@ary.qy> <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 01:35:10 -0000

--Apple-Mail=_D01934FE-31CA-4266-B6A1-E2BE42DC9D34
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On May 26, 2020, at 7:06 PM, Michael StJohns  =
wrote:
>=20
[=E2=80=A6]

> The funny thing about this is that we all agree that the RSE may =
prohibit publication of a document - we're just arguing about what =
conditions apply (e.g. small editorial, large editorial, content, =
technical, violations of physics).   I'd rather - in the words of =
someone who was eloquent on that point -

In retrospect, I do not agree that the RSE should be able to veto =
publication of an IETF stream document, period.  I previously thought it =
might be reasonable for the RSE to do so for editorial issues, but I no =
longer think that. I think the IESG should be able to insist on =
publishing anything on the IETF stream. The recourse for that should be =
the same as the recourse for any other IESG action.

So, no, I don=E2=80=99t think we all agree on that point.

[=E2=80=A6]


--Apple-Mail=_D01934FE-31CA-4266-B6A1-E2BE42DC9D34
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On May 26, 2020, at 7:06 PM, Michael StJohns <msj@nthpermutation.com> wrote:

[=E2=80=A6]
The funny thing about this is =
that we all agree that the RSE may prohibit publication of a document - =
we're just arguing about what conditions apply (e.g. small editorial, =
large editorial, content, technical, violations of physics).   =
I'd rather - in the words of someone who was eloquent on that point =
-

In =
retrospect, I do not agree that the RSE should be able to veto =
publication of an IETF stream document, period.  I previously =
thought it might be reasonable for the RSE to do so for editorial =
issues, but I no longer think that. I think the IESG should be able to =
insist on publishing anything on the IETF stream. The recourse for that =
should be the same as the recourse for any other IESG =
action.

So, no, I don=E2=80=99t =
think we all agree on that point.

[=E2=80=A6]

=

--Apple-Mail=_D01934FE-31CA-4266-B6A1-E2BE42DC9D34--


From nobody Tue May 26 18:47: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 51B0C3A0CF7 for ; Tue, 26 May 2020 18:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWMC5_baX-tr for ; Tue, 26 May 2020 18:47:21 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 70BEF3A0CF4 for ; Tue, 26 May 2020 18:47:21 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id b6so22878618qkh.11 for ; Tue, 26 May 2020 18:47:21 -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=OaYUPk2yjxmg24NJTxFPbyeoHBdHq8WcJjER6I/jzK0=; b=R0KCk7GsjNWSCmJq7wMtR/2iuWOjrUXc7h52KeTVS3iTb1B/7bW6QKCzvkYa6GaldO jKQpl1lC7ETJpDHh0JFdOQaQDDfQsv5btbFw9TPvkJfSRnzMPVYkZrwdZV9qswzwjff/ huPpXoSueS+LYrhhjqedjiWATO2UWxx3P+QLmqbuUwbKR5oWQzTKEmUunbuhzeazQTtX ljEp3HTeG7u3MVpNN+BX24XpA67Kn0UGGIWxSszg+JTL7EqzeWFahJfl9h60ixFztfNW ekOvz0x5hugTtplXvd5R/CS+21Q6ECtkWpFyXiZzZNHS5xYR/iq/Q5A6Vfrt4kbBL65R QyEA==
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=OaYUPk2yjxmg24NJTxFPbyeoHBdHq8WcJjER6I/jzK0=; b=o5JZN2Q6VCraeDXTOYyos3w0y0SQS11vcR1ej7C7V4KYZ7bZp0uN16T0Q2sGVBe4uQ P5pa8zTqj0zHwQkN3TZCOH7NEZ2GTegb8v8Z8vtuqRBkM+8gmR5381iGtnuc/JxzQWRo +JQS/0fdQFLsGtl7ALGqMxtt/exXIJFQbaHh4C8HBvxTalewLDL4U6/xXHzt0GYCtSHw YKAu+xFGhYqG16mYu27cSiIGhskX4gR3xV3D5IhVJr6oWUwD+HPmO5gaKRtrWM+e1L8N pP/mOH8Vi1KpY3J9o9gwBeQct4GaO8aZ/s9e/KUkJ6m9yF4g23+QWknEWhrXDiNjhTiN Ku1Q==
X-Gm-Message-State: AOAM530WoQx02pT5wrULDytT09iosmDjwudwd1ZG+CJnfNGk/5JrVqlc 93CGd9biNRQ8X0dXQYC76TMkyyVtwcQ=
X-Google-Smtp-Source: ABdhPJx+HOS9MNjfoCrTtruKTDk06jvyhndy9Op8QfB+d+zXzH83gv8IrkAkxFW8tQyULwYSypm8yg==
X-Received: by 2002:a37:4e81:: with SMTP id c123mr1753517qkb.467.1590544039937;  Tue, 26 May 2020 18:47:19 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id x24sm1325055qth.57.2020.05.26.18.47.19 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 18:47:19 -0700 (PDT)
To: rfced-future@iab.org
References: <147BBC4D-76DE-4084-9045-EB9670B84CB2@gmail.com> <931ED56C-0F8B-4649-B650-5478F5DC466F@huitema.net> <02B06576-3B8E-431A-803C-797F50E59AC6@gmail.com>   
From: Michael StJohns 
Message-ID: <2fe9e96f-3126-bebb-39a5-aa7fd148018d@nthpermutation.com>
Date: Tue, 26 May 2020 21:47:19 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------7E3B229A3809E27C48B1530A"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 01:47:23 -0000

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

On 5/26/2020 8:19 PM, Eric Rescorla wrote:
>
>
> On Tue, May 26, 2020 at 5:00 PM Mark Nottingham  > wrote:
>
>     On 27 May 2020, at 6:49 am, Brian E Carpenter
>     >
>     wrote:
>     >
>     >> To some degree it like the contract for the Secretariat.   The
>     LLC holds the contract, but they are doing work for the IESG.   At
>     a high level if the IESG is happy with the secretariat, it’s
>     good.  Might be a good model for the RFC Series.
>     >
>     > If it's working for the IESG/Secretariat relationship, yes.
>     Maybe we should check with the IESG?
>     >
>     > Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship
>     is *not* working?
>
>     I agree that it's not working, but I don't think swapping out the
>     IAB for another, similar body is going to help in any significant
>     way. The problems are structural -- they're caused by the (lack
>     of) description of the roles, and their relationships. If we
>     constitute Mike's model, it'll happen again.
>
>
> I agree with Mark here. We need to first figure out what it is we are 
> trying to achieve before we start designing mechanism.
>
> -Ekr


The problems aren't actually publicly structural, they appear to be 
deeply embedded in how the IAB managed this task.  Given that the 
general response for details on why things were done is "its a personnel 
matter" and the lack of a transparent explanation for how things went 
wrong from their point of view, we need to give the current structure up 
as lost and figure out something else.

Here's where I found active problems with the IAB:    The scheduling of 
the RFC++ BOF without reference or involvement of the RSE at the time; 
the wholesale replacement of RSOC members who had served well and 
consisted of substantially more than 60% of the institutional knowledge 
of the "new" RFC model again without reference to the RSE; the 
constructive termination of the RSE by the RSOC with the explanation 
that "we're going to re-run the selection process early because we want 
to make sure we have options" - an explanation that still makes no 
sense; and the failure of the IAB exercise its oversight of the RSOC or  
to take any action to try and mitigate the actions of the RSOC - I note 
the RSOC is still intact.   The problem we have here is that the 
community has no sway over the RSOC, and that it would require wholesale 
recalls of the IAB to reach through to address RSOC issues.  That needs 
to change.

I do understand the IAB has a bit of paralysis due to the hue and cry 
we've raised and is attempting to keep in the background and hopefully 
let the community come to a better solution and I do appreciate that.  
That still doesn't argue for the IAB retaining the oversight function in 
any manner.  In case I haven't been clear, this is primary to what I 
believe we need to achieve.

With respect to the mechanism I proposed - as I said - it's a thought 
experiment to show there are workable alternatives to what we're 
currently doing.    I don't expect that the RSEB would be a "similar 
body" to the IAB as Mark suggests, but one focused ONLY on the RFC 
publication system and responsible to the community directly.

Later, Mike


--------------7E3B229A3809E27C48B1530A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 5/26/2020 8:19 PM, Eric Rescorla
      wrote:

    

    

      
      

        


        

        

        

          
On Tue, May 26, 2020 at 5:00
            PM Mark Nottingham <mnot@mnot.net> wrote:

          

          
On 27 May 2020, at 6:49
            am, Brian E Carpenter <brian.e.carpenter@gmail.com>
            wrote:

            > 

            >> To some degree it like the contract for the
            Secretariat.   The LLC holds the contract, but they are
            doing work for the IESG.   At a high level if the IESG is
            happy with the secretariat, it’s good.  Might be a good
            model for the RFC Series.

            > 

            > If it's working for the IESG/Secretariat relationship,
            yes. Maybe we should check with the IESG?

            > 

            > Do we agree that the current IAB/RSOC/LLC/RSE/RPC
            relationship is *not* working?

            

            I agree that it's not working, but I don't think swapping
            out the IAB for another, similar body is going to help in
            any significant way. The problems are structural -- they're
            caused by the (lack of) description of the roles, and their
            relationships. If we constitute Mike's model, it'll happen
            again.

          

          


          

          
I agree with Mark here. We need to first figure out what
            it is we are trying to achieve before we start designing
            mechanism.

          

          


          

          
-Ekr

        

      

    

    


    

    
The problems aren't actually publicly structural, they appear to
      be deeply embedded in how the IAB managed this task.  Given that
      the general response for details on why things were done is "its a
      personnel matter" and the lack of a transparent explanation for
      how things went wrong from their point of view, we need to give
      the current structure up as lost and figure out something else.

    
Here's where I found active problems with the IAB:    The
      scheduling of the RFC++ BOF without reference or involvement of
      the RSE at the time; the wholesale replacement of RSOC members who
      had served well and consisted of substantially more than 60% of
      the institutional knowledge of the "new" RFC model again without
      reference to the RSE; the constructive termination of the RSE by
      the RSOC with the explanation that "we're going to re-run the
      selection process early because we want to make sure we have
      options" - an explanation that still makes no sense; and the
      failure of the IAB exercise its oversight of the RSOC or  to take
      any action to try and mitigate the actions of the RSOC - I note
      the RSOC is still intact.   The problem we have here is that the
      community has no sway over the RSOC, and that it would require
      wholesale recalls of the IAB to reach through to address RSOC
      issues.  That needs to change.  

    

    
I do understand the IAB has a bit of paralysis due to the hue and
      cry we've raised and is attempting to keep in the background and
      hopefully let the community come to a better solution and I do
      appreciate that.  That still doesn't argue for the IAB retaining
      the oversight function in any manner.  In case I haven't been
      clear, this is primary to what I believe we need to achieve.

    
With respect to the mechanism I proposed - as I said - it's a
      thought experiment to show there are workable alternatives to what
      we're currently doing.    I don't expect that the RSEB would be a
      "similar body" to the IAB as Mark suggests, but one focused ONLY
      on the RFC publication system and responsible to the community
      directly. 

    

    
Later, Mike

    

  


--------------7E3B229A3809E27C48B1530A--


From nobody Tue May 26 18:56: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 CB3643A0D07 for ; Tue, 26 May 2020 18:56:44 -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 X4GneILgbY5F for ; Tue, 26 May 2020 18:56:43 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E833A0D05 for ; Tue, 26 May 2020 18:56:43 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id 205so9818405qkg.3 for ; Tue, 26 May 2020 18:56:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=50PV2Pqy3HHwI0BU4N26bPyjXvMWaKLbGbLlO3y77NQ=; b=QZWP5gjM5r8jd0VfuFj5VTLolYYjkJht2GYgePjyNdZUXbspxrcWDCarOZol622uvr 4ta12EJLqnvDFD4YDB/apmy8Lstq8XU6P/H+AADmWScMrnji0AUtLpvnXjoiyM1MoNAD dOcV66eOjLccyx3hpdS9VzF2Tn72X3mn4I8vBmrTkp0IxRyGICK83jbfYs5/SC61O6nX 4oPeTfBQlH5O+ME4DeVSjVBUPmSv+M1UsrmR066zpSvdHdxCLyQGECAoPdJwM5BIeqO/ KbGG0WprkHPumebfy7mFPAR49BPnUa20mS7XkZp+tnWMT6do7q+6TTYajCiTvUAB8FRh hstw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=50PV2Pqy3HHwI0BU4N26bPyjXvMWaKLbGbLlO3y77NQ=; b=Cso1bMXGyL3PnbsgTvOLJIZZdT+gGnH9vCcPvTEIRWKiB4cE40jqUPKjztGie6qtD7 nWbxl0doBdjyGuK5psNURtTh8hPfVln6JzXJgUQHaIynZL89fD780wmLrRiXiJDnwVZw YUlTp05AB0nHnjPJVAHDEWV0l5+a9HAOulx22+Xz9VnokWFHmKeHroxbSkDXlQNDrJ59 o7Ez/1H0vTr2CvIOLV6AN+yd8xBnpZ1h+omGUx9AGXPAkYoPATp5GZxIuXz/rf+UFD9c bJpId0Z3ns1bGdkiLldr+j6io/xWG+l4JxWnEyZMbfEBEWPE/4HWnIIETnqZtwVInRgl yINA==
X-Gm-Message-State: AOAM530f1kRcSIpnNXEjpGn7BcSQcP4iqXZ5s5JKb2Cb2Q0M96byQ4Dk PB7J5sZceocxEA6JbtfPobVhNx6UvhA=
X-Google-Smtp-Source: ABdhPJy2A179OR1+b4hrtHAwJg2jW8CNHMB3K/wAujz2l746Oi/IxW1ZPh7loJ7e17x3I5lEDug1Zg==
X-Received: by 2002:a37:9cc7:: with SMTP id f190mr1863501qke.236.1590544602391;  Tue, 26 May 2020 18:56:42 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id y28sm1316759qtc.62.2020.05.26.18.56.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 18:56:41 -0700 (PDT)
To: Ben Campbell 
Cc: rfced-future@iab.org
References: <20200525165200.D76EC199A58B@ary.qy> <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com> 
From: Michael StJohns 
Message-ID: <8af15191-b651-b46d-bf44-00b7be23c2de@nthpermutation.com>
Date: Tue, 26 May 2020 21:56:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 01:56:45 -0000

On 5/26/2020 9:34 PM, Ben Campbell wrote:
> I think the IESG should be able to insist on publishing anything on 
> the IETF stream. The recourse for that should be the same as the 
> recourse for any other IESG action.

I did not see that coming.  You really don't need an RPC or an RSE then 
- just run your final document through an ID to RFC filter and you're 
done.   Or hire someone to do that?

Later, Mike





From nobody Tue May 26 19:05: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 ADDB63A0D10 for ; Tue, 26 May 2020 19:05:23 -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, 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 5jZa8KuXi_D2 for ; Tue, 26 May 2020 19:05: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 F18453A0D0E for ; Tue, 26 May 2020 19:05: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.15.2/8.15.2) with ESMTPSA id 04R25HvQ045023 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 May 2020 21:05:19 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1590545119; bh=NQv2bFXvuMQFwU9zAh39oVaDp1LAyRHu62ff1V0MTUk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Gxr6/Gce4Aua9mTS0ycuLNNtTK4uw03781jl/ydclSh2jmmeLhRhwf/gqtzpjQUW3 p2iGYGosGf2XCcqH06tHzqsVB8OzvzIuPmFRGLMdyBXV3N1L2znf15SHgSIXOWl6lX n3Olie/Xzjf2HY94CyYoHX/oyXxa6qP6j2+Tc0uE=
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 , Ben Campbell 
Cc: rfced-future@iab.org
References: <20200525165200.D76EC199A58B@ary.qy> <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>  <8af15191-b651-b46d-bf44-00b7be23c2de@nthpermutation.com>
From: Adam Roach 
Message-ID: <5748aacd-cbf3-fdbb-eb6a-672a2a3262f8@nostrum.com>
Date: Tue, 26 May 2020 21:05:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <8af15191-b651-b46d-bf44-00b7be23c2de@nthpermutation.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 02:05:24 -0000

On 5/26/2020 8:56 PM, Michael StJohns wrote:
> I did not see that coming.  You really don't need an RPC or an RSE 
> then - just run your final document through an ID to RFC filter and 
> you're done.   Or hire someone to do that? 


While I expect that the model Ben has in mind here is "the RPC does its 
best to edit a document, but the go/no-go decision ultimately lies with 
the stream manager," there's also a much bigger question of what the 
purpose of the RSE role *is*. This really gets to the core of the issue 
that Larry raised earlier today.

/a


From nobody Tue May 26 19:09: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 BB2923A0D19 for ; Tue, 26 May 2020 19:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CjKsfHPqobn for ; Tue, 26 May 2020 19:09: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 69F8D3A0D18 for ; Tue, 26 May 2020 19:09:17 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id f21so7982394pgg.12 for ; Tue, 26 May 2020 19:09:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=E8QAzrkmvqB0fa/O6TIZT/v7h3VomG1b2Bwc4XfQlRg=; b=XfOVCMrJMUqqKo3qSV0RV70wLJ7sdeIic18WQlnYxUbGB2q+CH8Jc7hwnicr/2xqvS MlQRWnVXYb+ToHJ+aR0LLCuUuPQtnAt1GIQQXTsZ5RAeXN5dwoD/gdiUtaBoH+GrpNLH GtMbOIk44ZRDiSQcF17VFcT6WJ0p6qqVu/RDZsWzeyH6zcP3oZbcTQtlxgeMyt1D6wHU SVnvG33e8Jc4nm4yFOJyPp5+14hVLnn3B4jnEnfkBsQO+agStwp8ewDkEZ+uGlVJ0gTf zV3TZiOMifIIicR2D7OstJJreaaboCNVKwsfg9M2RJ4F7TfAs98NGpulD3EFSs2TOiI1 OPJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=E8QAzrkmvqB0fa/O6TIZT/v7h3VomG1b2Bwc4XfQlRg=; b=e9tt62NDfGjGwBgA2lsJkMCJp1AdxlqojG72XYsnRuQ1NDwaanCTKva/U6q26aEPXt yOl/duwqZkUTc/Tu0JZk7VwHqg0Gf7eK51jPHV8/JQqDhnHUaeQraTjj/056R7j7H4pZ awIFu8MzL+AuYiiMZ8qw9tEPkG8VXV9rFWtRwl42BSngSRrtpbS4cAhCaw4s9YbONGCJ Gp9Jwa/399O/NZLOWiqBjGSvDTPTCwwql3ayhXrRjde8mHMG5GGwoqZW+bmz9btn08TB OFQnE23WXm/FthrKW/7Lr5mNUwQY+u0MmaiRD0NLqXnNAevftfdpdMiArcQycqGSUmsT Mavg==
X-Gm-Message-State: AOAM533pXDTw0mmYm9kfA4jVwScCc6zge3nahZ01j6cjzyUKNL7Ot1d2 3NeR/pwJBoaKN01eBoE0RgQ9RNfVbLWzXes=
X-Google-Smtp-Source: ABdhPJx90wSmQWFnBInLUSX6iHXKu4BiQbpT/dBuXcncnBVldANjVlQU6HgKv3HbwgC007raoSHPxA==
X-Received: by 2002:a63:de18:: with SMTP id f24mr1627666pgg.415.1590545355610;  Tue, 26 May 2020 19:09:15 -0700 (PDT)
Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id u5sm641535pjv.54.2020.05.26.19.09.14 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 19:09:14 -0700 (PDT)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: rfced-future@iab.org
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>  
Organization: http://SoftwareAndServices.NET
Message-ID: <386b0ecd-05ba-aaa1-401d-2ddb161d97bd@gmail.com>
Date: Tue, 26 May 2020 20:09:13 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8538B877E362E35CBA18CEB3"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 27 May 2020 02:09:19 -0000

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

On 5/26/20 3:09 PM, John R Levine wrote:
> On Tue, 26 May 2020, Colin Perkins wrote:
>> This is the real problem – not whether the revision to RFC XXXX is called RFC YYYY or RFC XXXX.v2.
>
> The specs for a mail server or a DNS server are spread across dozens of RFCs and errata.
>
> Do you foresee an approval process lightweight enough that we could sweep all of the DNS specs into 1034bis or all of the mail specs into 5321bis and 5322bis? 

As they are spread out across dozens of RFCs, it is not possible to give an accurate answer.


-- 
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

--------------8538B877E362E35CBA18CEB3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 5/26/20 3:09 PM, John R Levine
      wrote:

    

    
On Tue,
      26 May 2020, Colin Perkins wrote:
      

      
This is the real problem – not whether the
        revision to RFC XXXX is called RFC YYYY or RFC XXXX.v2.
        

      

      

      The specs for a mail server or a DNS server are spread across
      dozens of RFCs and errata.
      

      

      Do you foresee an approval process lightweight enough that we
      could sweep all of the DNS specs into 1034bis or all of the mail
      specs into 5321bis and 5322bis?
    

    
As they are spread out across dozens of RFCs, it is not possible
      to give an accurate answer.

    


    

    
-- 

      Doug Royer - (http://DougRoyer.US)
      Douglas.Royer@gmail.com
      714-989-6135

  


--------------8538B877E362E35CBA18CEB3--


From nobody Tue May 26 19:22: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 B23893A0D3E for ; Tue, 26 May 2020 19:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level: 
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, MAY_BE_FORGED=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 OuNRKQ2KkRIz for ; Tue, 26 May 2020 19:22: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 A2CA93A0D3D for ; Tue, 26 May 2020 19:22:23 -0700 (PDT)
Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 04R2MKX3047832 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 May 2020 21:22:21 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1590546142; bh=OS5YnMVj2PI8Y6698PEcUFsFc+Ikj1ZTQsLwj5VzW/I=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=B9mn1IJHj9/toB2rtOH22X7dsesDpV98l1O1G4fFDz2aFi7LzDjybq6wzDj/ljmX4 gHx2fO4jQUtxwz5HBlOrMgeA9y1mdaeGSs5YGOcVFb8DjTs82niS5x24ISFy9x4xPZ HIyoLyX8nF4USgGm2TxeOHBsoy7kRhD9z+uZig7Y=
X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Ben Campbell 
In-Reply-To: <5748aacd-cbf3-fdbb-eb6a-672a2a3262f8@nostrum.com>
Date: Tue, 26 May 2020 21:22:13 -0500
Cc: Michael StJohns , rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <699B1990-9DAD-4F72-BD40-A0B3607467E9@nostrum.com>
References: <20200525165200.D76EC199A58B@ary.qy> <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>  <8af15191-b651-b46d-bf44-00b7be23c2de@nthpermutation.com> <5748aacd-cbf3-fdbb-eb6a-672a2a3262f8@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 02:22:25 -0000

> On May 26, 2020, at 9:05 PM, Adam Roach  wrote:
>=20
> On 5/26/2020 8:56 PM, Michael StJohns wrote:
>> I did not see that coming.  You really don't need an RPC or an RSE =
then - just run your final document through an ID to RFC filter and =
you're done.   Or hire someone to do that?=20
>=20
>=20
> While I expect that the model Ben has in mind here is "the RPC does =
its best to edit a document, but the go/no-go decision ultimately lies =
with the stream manager,=E2=80=9D

Yes, exactly. I expect that, if an RPC has issues with an IETF stream =
document, they would do everything in their power to correct the issues. =
But =E2=80=9Cunilaterally refuse to publish=E2=80=9D should not part of =
that toolbox.

> there's also a much bigger question of what the purpose of the RSE =
role *is*. This really gets to the core of the issue that Larry raised =
earlier today.
>=20

I agree that is a bigger question :-)=20

Ben.


From nobody Tue May 26 19:23: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 C67023A0D43 for ; Tue, 26 May 2020 19:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVQYsmKLpxGj for ; Tue, 26 May 2020 19:23:42 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCAC33A0D42 for ; Tue, 26 May 2020 19:23:42 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id p21so10981493pgm.13 for ; Tue, 26 May 2020 19:23:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Pet6/fO84QoXS11fB7W2RLiyQ7yvWvUn26yGE/MdR1I=; b=NNiCYL2aXmv6D9R0f5PYXq1SS5+7QUWEBghyh8D9aYqF6mSE89UvZjS6mEcHFZaWWY VLyVDdLfrJqLwNuvPySD210EtyvMr2MQN0N59IS4BL6lVQYbdPSkJ+no5ztOx2P5m78c cUyIcpH3rzUvdITq7cxqILqtfW/3TjmqpkH6REonXYOMeQxt0O3WzzmHECYxizNxOYFg 0QVUYrBHuY9YpJH2FBhD390I9ZiwsPI/POhLeNulpS2v4Gl8u0/J9eUP6/1s+BgdCUzG mMZZQIAMZLTX2u5pFD+8aY49lJ+k6uRB9P4Y0yfd/6tmPhDOlxnZF78/lSJI/JEg918s zG1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=Pet6/fO84QoXS11fB7W2RLiyQ7yvWvUn26yGE/MdR1I=; b=ayBg8scsbSivS1nME48W0AcPZnJl2RU9RP3pZT3F3AYTKP2f05egdjftA95ooiGdqu DScyKBeN2CR93LR6ABJed58kzDXsuuqBdPM1XcatrtExFDSs7cAYVFA95Pi1swmXyLID 9+qZCmRuTjdVcOJBBNW8rOSKPLFR4a3D51JlUFvAKwIGhLUo9pyeNtxCssmFLZ+1W1FH rOrIvSt84C74lkqma1oS2wZAmJXug0VTy3qwRbTntzXeYVNE1S6YnwhdlKxfpfSzP+hF yMZHpCaRS7ljbHr0xhz/vEc6su2z5P+rmuuLMK/7Or9H1PS0D8shJWYBS3Fom7umnmYQ 01vQ==
X-Gm-Message-State: AOAM530MLgHpGIw4+YatM6c1Bq7tw/NkiWoij8HEQttq3QtuAYucEpAW 5ffHgzZcv6x/j1TMTuSdcGUfJeVQt51r0fY=
X-Google-Smtp-Source: ABdhPJzwZoUU2D04qiaBwsfTz43BNwvr8wBvFlAGy5VyBclGODoiHPrsZC4OCw6zrCTFNKfBicVCkg==
X-Received: by 2002:a63:a51b:: with SMTP id n27mr1839634pgf.40.1590546221644;  Tue, 26 May 2020 19:23:41 -0700 (PDT)
Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id u4sm1104453pjf.3.2020.05.26.19.23.40 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 19:23:40 -0700 (PDT)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com> 
Organization: http://SoftwareAndServices.NET
Message-ID: <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com>
Date: Tue, 26 May 2020 20:23:40 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1E4628324782D2A62E581EAC"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 02:23:44 -0000

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

On 5/26/20 4:04 PM, Colin Perkins wrote:
>
>>   * I'd like the RFC publication system to be stable in the face of unforeseen challenges and be able to gain (or regain) and retain institutional memory.
>>   * I'd really prefer that we don't have to do this again for another 10 years.
>>   * I'd also prefer that once we have an RSE, we assume we keep them (after a probationary period) until they get tired of us, or they really mess up.
>>
> That sounds suspiciously like a job for life. We have rolling contracts for other services the IETF community requires. It’s not clear why the RFC Series Editor should be different.

As they are not Microsoft Word editors that can be replaced by someone just bubbling out of school, I would think that it would be in everyone's best interest if they could last for a long time. The learning curve has to be very large.

--
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

--------------1E4628324782D2A62E581EAC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 5/26/20 4:04 PM, Colin Perkins
      wrote:

    

    

      
      

      

        

          

            

              
    
                
  • I'd
                      like the RFC publication system to be stable in
                      the face of unforeseen challenges and be able to
                      gain (or regain) and retain institutional memory. 
                      
    
                    
    • 
                
  • I'd
                      really prefer that we don't have to do this again
                      for another 10 years.  
    
                    
    • 
                
  • I'd
                      also prefer that once we have an RSE, we assume we
                      keep them (after a probationary period) until they
                      get tired of us, or they really mess up.
    
                    
    • 
              

            

          

        

        That sounds suspiciously like a job for life. We have rolling
        contracts for other services the IETF community requires. It’s
        not clear why the RFC Series Editor should be different.

      

    

    
As they are not Microsoft Word editors that can be replaced by
      someone just bubbling out of school, I would think that it would
      be in everyone's best interest if they could last for a long time.
      The learning curve has to be very large.

    --

    
Doug Royer - (http://DougRoyer.US)
      Douglas.Royer@gmail.com
      714-989-6135

  


--------------1E4628324782D2A62E581EAC--


From nobody Tue May 26 19:28: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 0BD8F3A0AFD for ; Tue, 26 May 2020 19:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOjzeZ28z5M1 for ; Tue, 26 May 2020 19:28:42 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 4B8653A0AFA for ; Tue, 26 May 2020 19:28:42 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id z18so26980228lji.12 for ; Tue, 26 May 2020 19:28:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RUwngMm+SISg1m9JuUx0BwN829mqnPIMX8jmeRfkmJc=; b=p6wYjq9zxWa0LTGmXX1scGOGBJAZO9ciz/sUqBaNxXi5QbZSaM9Pc/8CX1czIrq0is ucVKkjsu7mEGXBO6mZHLsOhuKl6VYLnzHQo4k9QEgjCdTwceMTW98Uo7524bU5uKnWbL fXqYzVITulmJDGOAZgxWGWL23XOL89p7p1saTXYbQ2d5X7BCDp4ZeEIP4wmgHyeoUgcU lOJnVm5Abjnft6qdPih/WnnwuLr/cPfu8nW87WV9fiXIIhfaG9evlkMqfrXT7IVoQ5fF opxSanZCNrAZ+/7C9RwmP+m1DMLrcnf9916r5nUzQQbU84BaaOXj/1/Y6swUSjPWe8Fm fYVw==
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=RUwngMm+SISg1m9JuUx0BwN829mqnPIMX8jmeRfkmJc=; b=K1fK2p+ubBzE2E8dJILeTHB4zv4e6wamkkmPFvnBjwWE2hHlhiLw9ttUNrWXFhktTv 4c/rRk6mdyYHefVtuYgqX/gnrYF1WMwfCFMqirMZNpr0AettdrL3sZ1ZT2/sobiuZX/l XC/bwdPyt0PHryfX95BXcCGr7XsMhXnK3eI3EuGBJSk3vVqcdKezz4YT+8t6VDN6itVO KRZcgRq9xUM17lo8oGKX1XfVFIJxfCb735D3Y4pUU9eZnJ+dPZlCkRrWyMbcTeJZaGnG 03WGWmaVotIM50nOak2AmITnViaLCZ89oXgjTAGVYfXWR0A1HDxOinJvJVAl3RUXLlft YsdQ==
X-Gm-Message-State: AOAM533de8agTO7AWdbG4E+ic437/TVfN/fD6JnLyaO/MEY2M/VSuAH8 KvkVujqA2/jE7YIOkhli3Lvb8Mzo2oL7zFHRBOZxlg==
X-Google-Smtp-Source: ABdhPJw4ysm5z67/mmTzgL5VDl9M7l7mALVQK+dR0U8LFJo6oJbnr1ybQhPoRNddPA2zW5HqoyAzBSdqcjiZNZBiyXM=
X-Received: by 2002:a2e:3201:: with SMTP id y1mr2013379ljy.13.1590546520414; Tue, 26 May 2020 19:28:40 -0700 (PDT)
MIME-Version: 1.0
References: <20200525165200.D76EC199A58B@ary.qy> <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>  <8af15191-b651-b46d-bf44-00b7be23c2de@nthpermutation.com>
In-Reply-To: <8af15191-b651-b46d-bf44-00b7be23c2de@nthpermutation.com>
From: Eric Rescorla 
Date: Tue, 26 May 2020 19:28:04 -0700
Message-ID: 
To: Michael StJohns 
Cc: Ben Campbell , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="00000000000059397b05a697f8e6"
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 02:28:44 -0000

--00000000000059397b05a697f8e6
Content-Type: text/plain; charset="UTF-8"

On Tue, May 26, 2020 at 6:56 PM Michael StJohns 
wrote:

> On 5/26/2020 9:34 PM, Ben Campbell wrote:
> > I think the IESG should be able to insist on publishing anything on
> > the IETF stream. The recourse for that should be the same as the
> > recourse for any other IESG action.
>
> I did not see that coming.  You really don't need an RPC or an RSE then
> - just run your final document through an ID to RFC filter and you're
> done.   Or hire someone to do that?
>

Well, as has been noted, some other SDOs (for instance WHATWG) more or less
do this, but I don't think that that really follows.

While not a direct comparison, if I self-publish a book, I might hire a
copy editor or a technical editor, but the ultimate decision about the
contents of the book would be mine. That doesn't mean I didn't need the
copy editor.

-Ekr

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




=

On Tue, May 26, 2020 at 6:56 PM Micha=
el StJohns <msj@nthpermutation=
.com> wrote:
On 5/26/2020 9:34 PM, Ben Campbell wrote:

> I think the IESG should be able to insist on publishing anything on 
> the IETF stream. The recourse for that should be the same as the 

> recourse for any other IESG action.



I did not see that coming.=C2=A0 You really don't need an RPC or an RSE=
 then 

- just run your final document through an ID to RFC filter and you're <=
br>
done.=C2=A0=C2=A0 Or hire someone to do that?

Well, as has been noted, some other SDOs (for instance WHATWG) more =
or less do this, but I don't think that that really follows.
=

While not a direct comparison, if I self-publish a book, I m=
ight hire a copy editor or a technical editor, but the ultimate decision ab=
out the contents of the book would be mine. That doesn't mean I didn=
9;t need the copy editor.

-Ekr


--00000000000059397b05a697f8e6--


From nobody Tue May 26 19: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 438D23A0AC5 for ; Tue, 26 May 2020 19:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=SrejVdmy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IK+PoScj
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsf5RmVPdE80 for ; Tue, 26 May 2020 19:40:37 -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 1F0243A0AFC for ; Tue, 26 May 2020 19:40:37 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 258DB10F5; Tue, 26 May 2020 22:40:36 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 26 May 2020 22:40:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=v pjPg/0Ht+ynXkmo7fFrB+ErjZUddBOnRFKl5bRYEpU=; b=SrejVdmyjoS1TotBW Va1W8Kmgm5aEKqvCUz8aAjV2N5qWXVyD1SJrPndTrTe/D7MC6IAuXDy/8eJXrbc9 MzMmYRqdRPjDf0G0fXMVX0gI40zZyVyMsdBvOiZmwjoKFXmXtSlVKMAJ4EQ3iz1D v9NrU27da/treIUT/erKpbTdwTC0iAcEYvC/Dwx7SmEadrvqJFkmH4jpNQ1vG1Bn q/SGgfv9PKABg5MaZSRXQm6UNmmI2oO47onqswwr8dpxeb+kruskT9yWQeoirQjG hnAoXp3PEnXlSmSiIJHo2sxjyckLKoCO52nUgOhJpcn47xSpWrKeFL9Gqxwhlq/D gZOOA==
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=fm2; bh=vpjPg/0Ht+ynXkmo7fFrB+ErjZUddBOnRFKl5bRYE pU=; b=IK+PoScjHC5exHWdopB7FZceFuFrp5tEp2iLpiLWtInWWYnweLKP0MYO2 VFpNy/MrP3e8CVs5H7JuHuZHOlxCO/jCxe5PDmrWJtgzCuNJcHJKfrTAk8FLd7Mf CWbyO/N5+JOFdArG/rqFWNl5bQA2z/66dvoEFxFngUzgFMGGrJClcweKXSzYzFpa 0a/Ch1iyqDF5Leb9YLCs+uqB4VNvz2IutHASXax+utoGQAgXijGWky6miOhU60LE +Tu4wwnARoacZ+oDdXmgy1R1tnmcrBIQh90WDvuLIbJyOVZjt1d0KEhqlWCDB23J OrO0Loti48YZtw7LQwrZCXuYQsvfw==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvfedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpefgheeltdehveelgeekhfethfevfffgieffhfetvdegffeffeekheejtefgtdeu ieenucffohhmrghinhepohhptgdrghhovhdrrghupdgsuhgughgvthdrghhovhdrrghupd hivghtfhdrohhrghdprhhftgdqvgguihhtohhrrdhorhhgpdhmnhhothdrnhgvthenucfk phepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 9AE25328005E; Tue, 26 May 2020 22:40:33 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 27 May 2020 12:40:29 +1000
Cc: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A821289-6D63-40B9-BCD5-B31AE90DD39B@mnot.net>
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org> <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp> 
To: John R Levine 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 27 May 2020 02:40:39 -0000

On 27 May 2020, at 1:23 am, John R Levine  wrote:
>=20
> Legislatures have an entire staff dedicated to organizing and =
codifying the laws, who have extensive legal experience so they can do =
so while keeping the sense of the laws.
>=20
> It would be nice if the IETF could do that, but it seems rather =
unlikely.

Let's dig a bit to get a better idea.

In Australia, that function is performed by the Office of Parliamentary =
Counsel.[1] They currently have a staff of 118,[2] and a budget of =
AU$17,298,000 (currently just under US$11,500,000; I don't include =
external revenue because AFAICT that's for services to those other than =
the legislature).[3] OPC drafted 5,218 pages last year.[4]

However, we have to keep in mind that OPC does much more than edit and =
publish the legislation; they actually _draft_ it, based upon =
instructions from lawmakers and in consultation with the relevant =
government departments. The rough equivalent would be the RFC Editor =
paying staff to act as editors for WGs.

The relevant part of the OPC for this discussion is their Publications =
group. They are responsible for:

"""
* publishing policy, including preparation of sunsetting and bulk repeal =
lists and managing the Legislation Register Helpdesk;

* preparing compilations, operating the Legislation Register, and =
publishing and making arrangements for the printing of Commonwealth =
legislation Gazettes;

* proofreading and editorial checking of all draft legislation drafted =
in OPC; and

* the development and operation of the Legislation Register website.
"""[7]

This sounds very analogous to what the RFC Editor does, with some =
additions like providing compilations.=20

The Publications group published 30,756 pages of legislative instruments =
and 287,116 pages of Act compilations last year, along with =
approximately 70,000 pages of other document types.[8]

Apparently, this group has about 40 staff.[9] While that's 34% of the =
staff in OPC, they're not legally trained drafters (50 staff), so at a =
rough guess they account for 20% of the budget -- say, US$2,300,000.

In comparison, we currently spend over US$1,350,000[10] to edit and =
publish just under 7,000 pages last year[11], although it previous years =
it was closer to 5,000 pages.

So their budget for that role is about 75% greater than ours, and they =
publish more than 50x the number of pages.

This is all back-of-an-envelope, of course, and you have to account for =
things like the level of effort required to edit a document from a =
professional drafter vs. one of our WG participants. That said, =
considering that they also provide consolidated legislation, have a =
helpdesk and, well, it's a _country_, I think that's pretty good value.

Based upon that very rough estimate, I don't think it's outside the =
realm of possibility that this sort of service could be provided. The =
question is defining what we want and how much resource we're willing to =
devote to it; as has been said before, other SDOs get by without any RFC =
Editor-like function, and don't have any dedicated budget for it. If we =
can find US$1,300,000 for the services we currently consume, maybe =
spending a bit more to get truely "full" service is the right thing to =
do. Or maybe refocusing to get what we want from it is the right thing.=20=


These are the kinds of conversations I'd expect an RSE to be leading the =
community through.

Cheers,

P.S. If you look at nothing else, I'd encourage folks to look at the OPC =
annual report;[12] I'd love to see this level of detail from future RFC =
Editors.


1. 
2. =
 =
pg 170
3. pg =
46
4.  pg 2
7.  pg =
10
8.  pg =
35
9. 
10. 
11. 
12. 

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


From nobody Tue May 26 22:36: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 92A5E3A05A0 for ; Tue, 26 May 2020 22:36: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 nWg0OQo_l2gQ for ; Tue, 26 May 2020 22:36:22 -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 D15FD3A0542 for ; Tue, 26 May 2020 22:36:21 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jdojk-000C32-4w; Wed, 27 May 2020 01:36:20 -0400
Date: Wed, 27 May 2020 01:36:14 -0400
From: John C Klensin 
To: John R Levine , Rfced-future@iab.org
Message-ID: <4D5E61FBBF95FCB6F8E86BD6@PSB>
In-Reply-To: 
References: 
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] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 27 May 2020 05:36:26 -0000

--On Monday, May 25, 2020 16:42 -0400 John R Levine
 wrote:

>...
> The problem is that the RFC series does a lousy job of
> publishing technical specs. If someone wants to write an SMTP
> server or a DNS server, there's a long list of RFCs that
> overlap and rewrite each other, there's a zillion errata not
> part of the RFCs that you need to know to look for and see if
> they matter, and there is a great deal of folklore to know
> which RFCs are important and which you can ignore. (For
> example, RFC 3865 defines an SMTP extension that we knew
> nobody would ever use other than to make a political point.)
> 
> I believe there were two key reasons our specs have succeeded:
> one is that they do work if you can figure them out, and the
> other is that unlike most other SDOs we have always given them
> away for free.  Open access is now increasingly common, so it
> would be a good idea to make them easier to use or at the
> least easier to find the ones you need.
> 
> I am not proposing specific changes other than to say that the
> model of RFCs solely as independent immutable documents no
> longer makes sense. While I do not suggest we go to WHATWG
> style living documents, I do think that for our specifications
> we need to find a more modern way to collect the material into
> a small number of places with stable names (perhaps using
> version numbers like everyone else does), and to make discrete
> low cost updates as we find errors or make partial updates.

Disclaimer: I have not been able to read this list between the
beginning of the weekend and the last hour or so, have not read
all of every thread (and doing so and still getting on the call
is hopeless).  However because I have a slightly different
perspective than others who have posted, even those I agree
with, some comments that may be helpful.

First, what I recall from conversations with Jon Postel a _very_
long time ago, is that when the IETF started thinking of itself
as a standards body in addition to (or rather than) an
engineering one (it is not accidental that we are not the
"Internet Standards Task Force" or even the "Internet Standards
Organization")  it was not completely obvious that standards
should be published in the RFC Series.  The obvious choice,
perhaps, but not the only possible one.  If I correctly recall
what Jon said during those conversations, at least one of the
issues was whether an archival document series that had evolved
to document the evolutionary history of the Internet and its
protocols was the right place to publish standards.  That does
not prove much today but it identifies several things that may
be worth keeping mind in addition to this being a very old
topic, not a new one: One is that even if the decision to
publish IETF standards-track products in the RFC Series was the
right one then, it may not be the right decision today.  A
second was that it was an IETF decision, not an RFC Editor one.
In principle, the IETF could reverse that decision at any time
or, for example, decide that only exceptionally stable
specifications, perhaps at Internet Standard level, should be
published as RFCs and everything else should live as an I-D,
perhaps with some I-Ds being officially designed as "IETF
endorsed" or "WG endorsed" rather than documents that can be
posted by anyone with no requirement for community review.
While I would hope the RSE would be given the opportunity to
voice an opinion, it is clear to me that the IETF could make any
decision of that type on its own (modulo a consultation with the
IETF Trust if that were needed), whether the RSE liked it or not.

Finally, we've been down this path before.  Once upon a time,
the RFC Editor had authority to group documents by assignment of
BCP and STD (and FYI) numbers.  The IESG took that away (IMO for
good reason).  In chartering NEWTRK, the IESG and the IETF
community concluded (and it seemed obvious at the time) that
building roadmaps among related standards, making Applicability
Statements in the tradition of RFC 1122 and 1123, or grouping
documents, especially standards track documents, in other ways
were an IETF responsibility.  For whatever it is worth, there
were discussions at the time as to whether roadmap documents
that would explain relationship and tell people what they needed
to read and how things fit together belonged in the RFC Series.
Given comments others have made about how much work it takes to
build and reach consensus on such documents, it is perhaps also
worth noting that, IIR, one of the reasons the IESG at the time
gave for refusing to consider the primary NEWTRK outputs was
that developing and, especially maintaining, such documents
would just be too much work (other NEWTRK efforts, including the
successful activity described as getting rid of the cruft (see
RFC 4450), further reinforce the sense that this is a discussion
about IETF issues, not RFC Editor ones -- the days in which the
RFC Editor could, on their own, reclassify a document as
Historic are decades in the past.

So, while I would love to see the IETF start an effort along the
lines of NEWTRK (or restart that one with the work that was
abandoned), and, ideally, expand its charter to make finer
distinctions about what IETF materials should, or should not, be
in the RFC Series, there is only one, very narrow, sense in
which I can imagine its being an appropriate topic for this
group.  That sense is that, if all or some IETF standards track
documents were pulled out of the Series, the workload and scope
of the RFC Editor Function would go down considerably.  Even
then, that would be more of an issue for the staffing required
in the Production Center than something that would change the
RSE's job description or the RFC Editor model significantly.

best,
  john

p.s. I'm not going to go into it because it would make this note
much longer and I think this is the wrong forum.  However there
is lots of experience with the advantages and disadvantages of
standards documents that are altered or updated rapidly and as
issues are discovered.  If that is a discussion the community
wants to have, it would be good to study the experiences enough
that we don't need to replicate the mistakes and learning
experiences of others.  As one example, without some special
adaptations they work very well when the "standards" are really
evolving memoranda of understanding among all of the
implementers (or all of the implementers who are deemed to
count) but less well when the target is interoperability between
independently-developed implementations.



From nobody Tue May 26 23:00: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 E32903A07FC for ; Tue, 26 May 2020 23:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHTZcLLe5hN3 for ; Tue, 26 May 2020 23:00:45 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F663A060A for ; Tue, 26 May 2020 23:00:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=sRVoT4tZLrPFEP/c+j1hKX47vN8DjtYbaVE+Kt5iMCw=; b=V6fAxcLZO3Z4zJQpq2DYvy2wga uedzFPmHe5LiDmLpT1SSkfPuRDZ11JvpRija+b/xvFHV4FXC1PSs3TwJdSOUkloiByLCsViCpAInY XxJeXsa3QQDQhJ7v7Zpf9OqPMGo3SZp+7fTqxktihlf6XF3rQbLi/EYe7tTDYoRRibRIP2NfLK8Fm 6hJSDY1n7JJaZqhnzfEOm+P3m+7/Kx1jM8yhR4jVScKfJcXv5oRZuEyZNtJ2SAUunqOJCmJ9dXIXy 1lZW+jKa8+XxYyuIBxOy8NlGQRTITH7vx/WJ0wXTs06/AjAwZuodZ/JdKuoFmm03gjG41DrLymYPe UBUqejRQ==;
Received: from [81.187.2.149] (port=33377 helo=[192.168.0.80]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jdp71-0001kM-KP; Wed, 27 May 2020 07:00:43 +0100
From: Colin Perkins 
Message-Id: <49634773-BC10-405A-9983-FDD124DDB02B@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CD73A761-D589-42C8-8EEF-5C0B65A551DE"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Wed, 27 May 2020 07:00:12 +0100
In-Reply-To: 
Cc: rfced-future@iab.org
To: Ben Campbell 
References: <20200525165200.D76EC199A58B@ary.qy> <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com> 
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 14
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 06:00:49 -0000

--Apple-Mail=_CD73A761-D589-42C8-8EEF-5C0B65A551DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 27 May 2020, at 02:34, Ben Campbell  wrote:
>=20
>=20
>=20
>> On May 26, 2020, at 7:06 PM, Michael StJohns > wrote:
>>=20
> [=E2=80=A6]
>=20
>> The funny thing about this is that we all agree that the RSE may =
prohibit publication of a document - we're just arguing about what =
conditions apply (e.g. small editorial, large editorial, content, =
technical, violations of physics).   I'd rather - in the words of =
someone who was eloquent on that point -
>=20
> In retrospect, I do not agree that the RSE should be able to veto =
publication of an IETF stream document, period.  I previously thought it =
might be reasonable for the RSE to do so for editorial issues, but I no =
longer think that. I think the IESG should be able to insist on =
publishing anything on the IETF stream. The recourse for that should be =
the same as the recourse for any other IESG action.
>=20
> So, no, I don=E2=80=99t think we all agree on that point.

+1

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





--Apple-Mail=_CD73A761-D589-42C8-8EEF-5C0B65A551DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 27 May 2020, at 02:34, Ben Campbell <ben@nostrum.com> =
wrote:



On May 26, 2020, at 7:06 PM, Michael StJohns <msj@nthpermutation.com> wrote:

[=E2=80=A6]

The funny thing about this is that we all agree that the RSE =
may prohibit publication of a document - we're just arguing about what =
conditions apply (e.g. small editorial, large editorial, content, =
technical, violations of physics).   I'd rather - in the words =
of someone who was eloquent on that point -

In =
retrospect, I do not agree that the RSE should be able to veto =
publication of an IETF stream document, period.  I previously =
thought it might be reasonable for the RSE to do so for editorial =
issues, but I no longer think that. I think the IESG should be able to =
insist on publishing anything on the IETF stream. The recourse for that =
should be the same as the recourse for any other IESG action.

So, no, I don=E2=80=99t =
think we all agree on that point.

+1

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








=

--Apple-Mail=_CD73A761-D589-42C8-8EEF-5C0B65A551DE--


From nobody Tue May 26 23:27: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 B93283A0440 for ; Tue, 26 May 2020 23:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=fKrG0eK8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=u7sEWVas
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9fqnQpr9y90 for ; Tue, 26 May 2020 23:27:32 -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 A41B43A0420 for ; Tue, 26 May 2020 23:27:32 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id EFA5A5C0111 for ; Wed, 27 May 2020 02:27:31 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 27 May 2020 02:27:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=jJxBchsCe4qmncWWcuJ5O7F+lwcFAVpPbItV2KAsdiE=; b=fKrG0eK8 yNhteNejA1mvOdIp5N8SL78O++apG/DmzOYa61Rfg+BUGMdmFmDdq6Sbz4HtyWGb wYvtRUY/lDBKroUl25uHE6VhmmSYLHW4OxpGkyAwSVqqiudlj3Y0++9HPmA91cny OvRswDODNFbnp6aUY325W6Yx606zz+9qCOpXGqoFbuApN53vznRHiUhYTaz/eN5u ukvOLILt1/RYTkQK31NXSkrb05ZMyXjkB/uiSqIXGthEp7aFiuDSZn8rVBUX7kaf 5wSl5+0Vl0hDud/2d9xP8l1QIljZT19UifZD6cKjozrKLrob9kUxoKa18OzE1GfQ 9AvrQl04nGh21Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=jJxBchsCe4qmncWWcuJ5O7F+lwcFA VpPbItV2KAsdiE=; b=u7sEWVasR2tqHs2ZuHftGW1AAIFZ3lxh49MbV05DLu5Iq +Rnqsk30rm8epvuEevk7lr/VbbUIOXvE/4E+trq5YLD5/yMssZde0KpyWPxbJZNo Hdi8OurSJ9ZreNzluIsgfLZX/wmqEorSaaFmkLv5Dn4JuZpVfRAmuJHgGuCS2bfU bkrQwiS9qd5WZc05QV7geuIj/HMARY59ogIukelpKtmwv5AUwf7p4tu4x/MBeNN4 W1ZdNterbgcvxrmhK3wTp8dvMio9uJw+230ZgMT2lkaJE57dFlRUnCgYWEDspquM vcYPpJA6pwg8PMT7fxkihI0iTZULnbXm81r67gL9w==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvfedguddtfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepvefguddtgfejfeduueehke ehkeduueegheefgeevkeekgeelveevffeuudffheehnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 42F03E011C; Wed, 27 May 2020 02:27:31 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-488-g9249dd4-fm-20200522.001-g9249dd48
Mime-Version: 1.0
Message-Id: <191b0c0f-7941-4fed-a8f3-230f20430d57@www.fastmail.com>
Date: Wed, 27 May 2020 16:27:11 +1000
From: "Martin Thomson" 
To: rfced-future@iab.org
Content-Type: text/plain
Archived-At: 
Subject: [Rfced-future] What are the roles?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 27 May 2020 06:27:34 -0000

Eliot's formulation of questions on the slides made me ask a question that I don't think I had really contemplated before.

The question Eliot asked was: What roles are defined and what is their relationship to one another?

I think that's an excellent question.  I had been thinking that we might not consider a single human being involved in filling the hole we seem to be discussing.  But this particular formulation leads me to ask:

Do we agree that we need a RFC Series Editor?  If this function exists, do we agree that needs to be a single person?

I keep coming back to the presumption of heroism attributed to the role.  The list of potential functions attributed to this potential role are vast, varied, and while exceptional individuals have been present in the past, we cannot expect that the line of heroes will continue to show up.


From nobody Tue May 26 23: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 0318E3A0946 for ; Tue, 26 May 2020 23:57:59 -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 dbd7o_Y2izjf for ; Tue, 26 May 2020 23:57:57 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFCC3A0945 for ; Tue, 26 May 2020 23:57:57 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id v79so13328957qkb.10 for ; Tue, 26 May 2020 23:57: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-transfer-encoding:content-language; bh=gBU8V+27t6DHVDeMRgHp1y/270/PDXTJKMLuOjB380k=; b=buUMD78AsMVekW7LI2fQ5/f00aAd6EVnNbZgdyPRbAJ1z7jc0pwLqc9WJs7M67VXmI yFlDYh3sqNpScV8CgEsYG6GwmTypUrwPszUD/Hi6UzG9aFQQJpvAYsG33J+kCSKjJGCR kRUd5UlZxW/Gnmq36VCKpVtyHyPnngDp9g5z2t5zd+J75UtYsOnfwmjKXYNSyxUPXX7i lijcLXOdMkQHT3FXODT+l37kmNNitY65zdj+sMfR4LEbFKxQJb+Dq5IHQ5CTLeYVku9a H1vCdJC8YbZICNU8gWGtuu+AyQdRqn0ZOC+fNmzUcZd6nsy8nKfA+C5QmX3OdfincDwW KMSA==
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=gBU8V+27t6DHVDeMRgHp1y/270/PDXTJKMLuOjB380k=; b=LDPxFk2ZnwrlOlm11M1OGnqQeOYAuPtRBML4nZzZge54ztoCZ9dAEe9V99zVSpqtVj XTQQhAu7s+mefVBcBp1HwO4H+HMXn0wTT6fhHt7CRZrSye8jwn9U0R3saY4xpVhXFCZO exI7ShzsfNNj4TlypH8Op6LK5lmzGIMXOugJp6VDTw/s3bcLBLrt0LK4TYVqYQyx/Ey/ woE1yAXYlQJo0UMiJBz8ijl6xR+Owr4wzO87tM1NCm+rmkzETFy8q68ufABPPlsQJ32J 89HxORivIFmh+Qfcg2dGt47RJF8XK4OU0MUHi0JX7UyM2YQ6HpXPEdn/gukKjJBgpDEj YlHw==
X-Gm-Message-State: AOAM530bA6k66wUX5muey2Cj22dQky13C5LcuTdhJ24ch5Vfwz8VX5/s D6m+Xvqti8XKuHTb3KnBwLzcXqnvTLI=
X-Google-Smtp-Source: ABdhPJwwCsbQm6mEf8nRI18TIUAI4m2xPsPbYFssXQGSrhAnQa8bd9YKFfHaAYVxGLMsCaLv3a+Ejg==
X-Received: by 2002:a37:a111:: with SMTP id k17mr2588164qke.376.1590562675421;  Tue, 26 May 2020 23:57:55 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id j90sm1755343qte.33.2020.05.26.23.57.54 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 23:57:54 -0700 (PDT)
To: rfced-future@iab.org
References: <191b0c0f-7941-4fed-a8f3-230f20430d57@www.fastmail.com>
From: Michael StJohns 
Message-ID: <42329a64-8688-fdc3-e58d-978eb9fdc07a@nthpermutation.com>
Date: Wed, 27 May 2020 02:57:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <191b0c0f-7941-4fed-a8f3-230f20430d57@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] What are the roles?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 27 May 2020 06:57:59 -0000

On 5/27/2020 2:27 AM, Martin Thomson wrote:
> If this function exists, do we agree that needs to be a single person?

Just going to tag this one.   We had Joyce/Bob as co-RFC Editor for some 
number of years and  it worked well, but they were all under the 
umbrella of a single organization.  I agree its a question to think 
about though.

Mike



From nobody Wed May 27 00:18: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 94FFD3A0A68 for ; Wed, 27 May 2020 00:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=h3M9P3HN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hbyFz59V
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKVVTQO7ZH0l for ; Wed, 27 May 2020 00:18:48 -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 415353A0A67 for ; Wed, 27 May 2020 00:18:48 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8BA025C0181; Wed, 27 May 2020 03:18:47 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 27 May 2020 03:18:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=z HBu0RZeJQpFa2fB4mT37nWscJ5BoYkbM9XR1aQl4OM=; b=h3M9P3HNn6S/VHzjM RHns6d8jXNPkRKLsbJuU7HTmg01BmmhNvximfNCRI0cLaJDWNiQwege+2QU5yknx bMug4YMq4up/GvAdtYrG3nhrj2DtgfKIDo1ZmOP4wRZszqgmdimlcZKvDHXKujuo FGz8w/oi/QQETQf8zPO18XyPJtifPCdfWcrxnoa8l0SHYuDRIQ3Zk9eAl1l7JIOg bqWmSXn9fecTRikNee0UWpIwZTYDSqnbI6XaiGWYm82nxVSEonHYgibsOx9Vy88Y UaZ+yIlKDrwPByp3AkHF/XtVpyQaSJDofWePAnaBGLvowGuCcIGGK89uQp7Sxj4U S87fg==
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=fm2; bh=zHBu0RZeJQpFa2fB4mT37nWscJ5BoYkbM9XR1aQl4 OM=; b=hbyFz59VgIUEVNTX1fSQmASa8Lw0I2JuviBfpqPENzBCsXYr4xdW2y3KP FmvR2znFdHbGDtGPrl+rg+7jFvyUXZiuSHAZUuEfWxZzViZiWN+CrVZ14bfi4bwq DnmIWzv0fXcGVvhUPhIQJSFBWwJEP1piH3CevG3XGvoaj1dU8D6NVxG77oVv120g nyLCDa0JfnI/rxTAmUvs2yUL6bggcPzhL/k1HTHhC9wbVUHGss6UO5VaVll0zTLp rOIli6MVN4bBBaJTQ0byhkMY0mgnIWhTSMG4oRsA1BghSi3G7sG66TgzqPqPMQjc Quhfp2jRR4L6lFRgcnHSh5BQkjiwQ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvfedgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepuedtkefhtdfggfejjeegkeevheefhffguefgheefgfegkefhiedtgeduvedu feeinecuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucfkphepuddule drudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id B285C3280064; Wed, 27 May 2020 03:18:44 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: <191b0c0f-7941-4fed-a8f3-230f20430d57@www.fastmail.com>
Date: Wed, 27 May 2020 17:18:41 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D1898F0-1565-4730-9E97-6D0F6E6075F0@mnot.net>
References: <191b0c0f-7941-4fed-a8f3-230f20430d57@www.fastmail.com>
To: Martin Thomson 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] What are the roles?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 27 May 2020 07:18:51 -0000

+1; this came up before.

To me, there are at least three major roles with different skill sets:

- Defining the strategy of the series, in consultation with the =
community -- heavy consensus-building / community interaction, as well =
as publication strategy
- Executing the strategy -- e.g., defining tools, document schema, =
keeping the Web site modern --  Technical skills with a publishing bent
- Interacting with / overseeing / training the RPC -- management, =
editorial skills

Cheers,


> On 27 May 2020, at 4:27 pm, Martin Thomson  wrote:
>=20
> Eliot's formulation of questions on the slides made me ask a question =
that I don't think I had really contemplated before.
>=20
> The question Eliot asked was: What roles are defined and what is their =
relationship to one another?
>=20
> I think that's an excellent question.  I had been thinking that we =
might not consider a single human being involved in filling the hole we =
seem to be discussing.  But this particular formulation leads me to ask:
>=20
> Do we agree that we need a RFC Series Editor?  If this function =
exists, do we agree that needs to be a single person?
>=20
> I keep coming back to the presumption of heroism attributed to the =
role.  The list of potential functions attributed to this potential role =
are vast, varied, and while exceptional individuals have been present in =
the past, we cannot expect that the line of heroes will continue to show =
up.
>=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 Wed May 27 00:49: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 0C7943A0AFA for ; Wed, 27 May 2020 00:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 KkkOjPZEKLZs for ; Wed, 27 May 2020 00:49:49 -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 B7BFB3A0AF5 for ; Wed, 27 May 2020 00:49:49 -0700 (PDT)
Received: from [172.16.42.112] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (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 49X2zZ4lBrzyRm; Wed, 27 May 2020 09:49:46 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: <20200527004148.A335E19A7319@ary.qy>
Date: Wed, 27 May 2020 09:49:45 +0200
Cc: rfced-future@iab.org
X-Mao-Original-Outgoing-Id: 612258585.015206-9c7733c62658800c289dc3c75bbbc1fc
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E19B390-9451-41D0-AB66-799E5FDCEA41@tzi.org>
References: <20200527004148.A335E19A7319@ary.qy>
To: John Levine 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 07:49:53 -0000

On 2020-05-27, at 02:41, John Levine  wrote:
>=20
>> My experimental result is that the "v3-plaintext" format is UTF-8, =
has no BOM and does have pagination.
>=20
> For I-D's, yes, not for RFCs.

(I=E2=80=99ll follow along as long we are on this tangent, which I seem =
to have split off accidentally:)

This is one of the interesting symptoms of the confusion of RFCXML as an =
authoring format and RFCXML as the archival format.  Obviously, the tool =
is giving the authors what they (OK, many of them) want during =
authoring.  For the archival RFC version, the tool then switches to a =
(text file) format that is less concerned about the wishes of the =
authors.  This might be a nice example to discuss =E2=80=9Cindependence=E2=
=80=9D =E2=80=94 except I have no idea where that deviation actually =
originated, and who might have browbeat whom here.

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


From nobody Wed May 27 00:54: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 CA5F53A0B05 for ; Wed, 27 May 2020 00:54:36 -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 rH47GHN-mnPJ for ; Wed, 27 May 2020 00:54:35 -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 D0C333A0B0B for ; Wed, 27 May 2020 00:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5482; q=dns/txt; s=iport; t=1590566075; x=1591775675; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=rHFoHFzxysJqr9iP1u/VGrTUnCaDv+CfQ4Y2mtheSPM=; b=EfjGuki2VVjKuUui1i8fTTVHCk3K05TKhIu89ZsUDgsFVmnTmVjnfCPa UDsoiJ7eYtggPwH6/T/HvaSohSJokmdRFg1Y8cC39TO7hcuFz6c6Zq9cG 0blwrxjzU7RCkbMlqJENp83ox2ggSFIkN3laFpErkPtEGN/kV+b6zRDaC Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAAApHM5e/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBeAUBAQsBgxdUASASLIQliQGICpNbhhWBfAsBAQEMAQEYAQo?= =?us-ascii?q?MBAEBhEQCghIlNgcOAgMBAQsBAQUBAQECAQYEbYVWDIVyAQEBAQIBAQEhSws?= =?us-ascii?q?FCwsEFCoCAicwBhODJgGCXCAPrHt2gTKFUYURBoE4AYxdggCBOByCHy4+gmc?= =?us-ascii?q?BgUQBAQiDLDOCLQSOTYpkgVeYJ4JegnWFNZA2HYJkiQOEY40+ki+XXGeDSQI?= =?us-ascii?q?EBgUCFYFaDCaBVjMaCBsVOwcjAYFiXD4SGA2YI4EjhUQ/AzA3AgYBBwEBAwm?= =?us-ascii?q?NQAEB?=
X-IronPort-AV: E=Sophos; i="5.73,440,1583193600"; d="scan'208,217"; a="26548507"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2020 07:54:30 +0000
Received: from [10.61.225.84] ([10.61.225.84]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04R7sT4K024825 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 May 2020 07:54:30 GMT
From: Eliot Lear 
Message-Id: <47A44FB7-36A4-4CBD-BB14-7B998145C554@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_669A2B9E-845A-43FB-A41B-6DC13C2BF4CC"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 27 May 2020 09:54:29 +0200
In-Reply-To: 
Cc: Colin Perkins , Rfced-future@iab.org
To: John R Levine 
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.225.84, [10.61.225.84]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 27 May 2020 07:54:37 -0000

--Apple-Mail=_669A2B9E-845A-43FB-A41B-6DC13C2BF4CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It seems to me that in this conversation there are two groups we want to =
optimize for:

The people who are attempting to update the document
The readers

Thus far, the conversation has focused on the first group.  Earlier, it =
was pointed out that to implement a standard like DNS or TCP requires =
reading quite a lot of RFCs.  This was indeed what NEWTRK set out to =
address.  If we recreate NEWTRK without understanding why it failed, we =
are very likely to get the same results.  This raises several other =
questions:

Is this just a stream problem?  I don=E2=80=99t see how the answer to =
this question could be =E2=80=9Cyes=E2=80=9D.  How we group information =
has to be in some way reflected in how the information is presented to =
the user- its editorial form.
If is not just a stream problem, then who initiates change?  Who =
approves change?  This idea of a working group is an interesting one, =
but there must be a caution: our typical working group structure could =
allow filibustering.  Is that desirable?  Stability says yes, ability to =
evolve says no (when viewed from extremes).

Eliot

> On 26 May 2020, at 23:09, John R Levine  wrote:
>=20
> On Tue, 26 May 2020, Colin Perkins wrote:
>> This is the real problem =E2=80=93 not whether the revision to RFC =
XXXX is called RFC YYYY or RFC XXXX.v2.
>=20
> The specs for a mail server or a DNS server are spread across dozens =
of RFCs and errata.
>=20
> Do you foresee an approval process lightweight enough that we could =
sweep all of the DNS specs into 1034bis or all of the mail specs into =
5321bis and 5322bis?
>=20
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. =
https://jl.ly--=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


--Apple-Mail=_669A2B9E-845A-43FB-A41B-6DC13C2BF4CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

It =
seems to me that in this conversation there are two groups we want to =
optimize for:

  • The people who are attempting to =
update the document
  • The readers

Thus far, the =
conversation has focused on the first group.  Earlier, it was =
pointed out that to implement a standard like DNS or TCP requires =
reading quite a lot of RFCs.  This was indeed what NEWTRK set out =
to address.  If we recreate NEWTRK without understanding why it =
failed, we are very likely to get the same results.  This raises =
several other questions:

  • Is this just a =
stream problem?  I don=E2=80=99t see how the answer to this =
question could be =E2=80=9Cyes=E2=80=9D.  How we group information =
has to be in some way reflected in how the information is presented to =
the user- its editorial form.
  • If is not just a stream =
problem, then who initiates change?  Who approves change? =
 This idea of a working group is an interesting one, but there must =
be a caution: our typical working group structure could allow =
filibustering.  Is that desirable?  Stability says yes, =
ability to evolve says no (when viewed from extremes).

Eliot

On 26 =
May 2020, at 23:09, John R Levine <johnl@taugh.com> wrote:

On =
Tue, 26 May 2020, Colin Perkins wrote:
This is the real problem =E2=80=93 not whether =
the revision to RFC XXXX is called RFC YYYY or RFC XXXX.v2.

The specs for a mail server or a =
DNS server are spread across dozens of RFCs and errata.

Do you foresee an approval process lightweight enough that we =
could sweep all of the DNS specs into 1034bis or all of the mail specs =
into 5321bis and 5322bis?

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. =
https://jl.ly-- 
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

=

--Apple-Mail=_669A2B9E-845A-43FB-A41B-6DC13C2BF4CC--


From nobody Wed May 27 00:58: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 B803E3A0B24 for ; Wed, 27 May 2020 00:58:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyKnLD5mjNyp for ; Wed, 27 May 2020 00:58:16 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 041AC3A0B1C for ; Wed, 27 May 2020 00:58:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590566281; bh=/r5l73E6dUZevqS/xGKZI8TWusnnlXxm6YEkcirtSOE=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=cRXTwxfThGIL2TMeUiWVomU5bkkmat9NKol7N3ZHgQ1FwQN2hz1QqAEPiKRAkXtyF wGakAkG+i+iaz79FTkU+opd8tJwwpdOxK6J+LUxGbA86n8+8KLsn9M5481q2HDsah3 rsdDAkWmo/sADi1+dZuRj1Squu4YEiHZ3aAK9X0A=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.182] ([84.171.146.196]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCsU6-1jmgeW3uM4-008pxX; Wed, 27 May 2020 09:58:00 +0200
To: Carsten Bormann , John Levine 
Cc: rfced-future@iab.org
References: <20200527004148.A335E19A7319@ary.qy> <2E19B390-9451-41D0-AB66-799E5FDCEA41@tzi.org>
From: Julian Reschke 
Message-ID: 
Date: Wed, 27 May 2020 09:57:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <2E19B390-9451-41D0-AB66-799E5FDCEA41@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Qdezv39oXH0nkMSZSoAjYHfSZh/UNhd9K7JOT5CUqv7YYrhbL1Z MnpacnqGBWu89xd3mAybPHhgaiKcAJdAIZSponVIEoJ85SCK8rGyF5mpi5W0YK3WGOV2T1W B3kgGFLWzWDVwVAXPepZlgFQ8Tilc/J3EvSPruB19/YNVAyw1V4YCCFTkhj5zVfuENwBfDc 88+WaImCL7U1fTNiZNqcA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:zBT+ZfHEAsI=:LWnvTq4ZOKCGRC+FQuEpgX 6X/qJ9EcDxLRM9Zj5j/cMG2iDwcVaIHi1iZps79JI8AZqRjG9FlWHXljMij59ryuH/kvE17CV ONROgVYBdX+ei1sx1pfey1csHTXi2H0pyOOzu1afqlsbPqgMy6d+J0tB5JQcIW9GMMMWnrM1u 3htJCM3lv3zkRwLdPRfk84fYFXfx/U5IF1kemVl/7qO5yJUZI7EtqJVBS94B9249giwNeVAJw 1E6dgX8kOYAJ0RuhbtFW0P3BXKTniSam1lPyXFGCywX+hfe4tntFwUBGSm2YcPDXx6oHbRKVD ZdFHHyQ782OJuyJjdqAy5GlI+XkO25gqgZfw3kDMiDaDHZ0lPfO6Vd56xZ4GsOCbrkoCkHBdi gWXmZrA73tBushipipKhx7FrOKFNtjZ15H0fUSfisc+eQ6r+bGCS6wNIpSTc6VWN/80aN5ydk ufUhLax+1QbZIYUCDSqWam0HjFZNN8GGzUmna2uvyfdHbzkH3sV47HPyrs0q52/ILgqGG1zJ3 6iuhwt5vTSNwdIBw7pjPHd8ukuel1EHxgDrSgxS5pBOWEtZUlnV53+BKTsDEY4eTdjjZ9RhQ4 w0AyWArpF0Z6k9LL3YjC3n0dYeRCXM2Z5tN7ZHKXEPiZD16qmSsg/STxSRKyw0+m4b6NdJv+H 2B6Qj71kP3Do/B7M9CAZVedDWUbUkCB/sqpwRpi4BDx+tIr14t7duZAHGLc0hOAgrR8IJNJ/e yeXAcuN5eFEtht9jFWRj1N+1fZbWhWvs0+AbfEEdDDo52vz/z4ZfsueuIp8G61TWK0PonCRTB E44jUQPGFih0EHn6auOw8DXAZheyM34iZeNWyw3UHZr3FjfxfhH569iGHDsQc+SJjo5BmtqS2 jG3ccdXizMpowxbeLjHE4YybVxmI8ns5+XIM1R5WDPWpfH4NWfwrI4FhtOOCLHUiOGSI61hxn zXhCO7DI0rZkNbLqBFLW73JcTD0L8rFYP2ywnt7pfXlrTAfNfeKvq2z3KofxaxXAL6mnb2yye /Suxe77Yo26XwGp0YGY3TTHY998T/ZeNZUk+faEVVEguBpp0VX/ryywZyaR8n/jHv4AkEVzVr 1JQJe+9JbbyrSUfRDf6zRhjsu7p4hX0VXWMcfsub2L4slPjMM+gTes7tiBWwcYWSjxlIJrTEr 84oF2xqAomEQNRf9xEOh8T8beNgKcuXoCMuJOaPuCQqY8eWGMFptaSDgHxddUrVqTjG0CEsyV 95vOOHdm1COrgwgRR
Archived-At: 
Subject: [Rfced-future] BOMs, was:  On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 07:58:18 -0000

On 27.05.2020 09:49, Carsten Bormann wrote:
> On 2020-05-27, at 02:41, John Levine  wrote:
>>
>>> My experimental result is that the "v3-plaintext" format is UTF-8, has=
 no BOM and does have pagination.
>>
>> For I-D's, yes, not for RFCs.
>
> (I=E2=80=99ll follow along as long we are on this tangent, which I seem =
to have split off accidentally:)
>
> This is one of the interesting symptoms of the confusion of RFCXML as an=
 authoring format and RFCXML as the archival format.  Obviously, the tool =
is giving the authors what they (OK, many of them) want during authoring. =
 For the archival RFC version, the tool then switches to a (text file) for=
mat that is less concerned about the wishes of the authors.  This might be=
 a nice example to discuss =E2=80=9Cindependence=E2=80=9D =E2=80=94 except=
 I have no idea where that deviation actually originated, and who might ha=
ve browbeat whom here.
> ...

xml2rfc, when producing TXT RFCs, just implements what RFC 7994
("Requirements for Plain-Text RFCs") says...

Best regards, Julian


From nobody Wed May 27 01:06: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 105423A0AF6 for ; Wed, 27 May 2020 01:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsQDvQE69ePq for ; Wed, 27 May 2020 01:06:27 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178B23A0B4A for ; Wed, 27 May 2020 01:06:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=ypkyBjxcPs290y28H8ZFwcp5WJ+OPuLWbJWw2xOEmlk=; b=auJBvhrIcnjFXiDTxkeSl7vF3/ hkxoQUP1xWdtZs0a0i2wQoLSCaLLjRVAEWqR1exiovatV5uQx1BWeMBfHVZa1E/GtNa4nEjMyxtUQ 0c6ExhVdycn9uDuU9EImjtNvLVsVK8jXwWshg8jVKDpIXzxfub4+RKsIbUREnI7wzcrlm/77D4EvI aI2wY1z5Qms8SLEwJahN+QQeKmqOq1CkJRbp+vtkAcV2oUgMY5uSqvmqFU8xAI3ZQPfDb/qFy+tjU ZSbzT+hPNyjO15BbNw0r/p4aIuk2dfhRNZtUloz7nYRadFO2fjSfu0B9pre3uPiwVzum5BNrmWggr uyf8AnJg==;
Received: from [81.187.2.149] (port=45661 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jdr4y-0005OF-5P for rfced-future@iab.org; Wed, 27 May 2020 09:06:24 +0100
From: Colin Perkins 
Content-Type: multipart/alternative; boundary="Apple-Mail=_90B1BECE-B9A8-4A23-ABD3-8B75D56D4A12"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Wed, 27 May 2020 09:06:23 +0100
References: <20200525165200.D76EC199A58B@ary.qy> <45c45d92-3df2-ba6b-6eba-c44f627b1bfa@nthpermutation.com>  <49634773-BC10-405A-9983-FDD124DDB02B@csperkins.org>
To: rfced-future@iab.org
In-Reply-To: <49634773-BC10-405A-9983-FDD124DDB02B@csperkins.org>
Message-Id: <28D6241D-B626-43E0-996C-F32820CAFF9D@csperkins.org>
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 4
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 08:06:29 -0000

--Apple-Mail=_90B1BECE-B9A8-4A23-ABD3-8B75D56D4A12
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

[As an individual]

> On 27 May 2020, at 07:00, Colin Perkins  wrote:
>> On 27 May 2020, at 02:34, Ben Campbell > wrote:
>>> On May 26, 2020, at 7:06 PM, Michael StJohns > wrote:
>> [=E2=80=A6]
>>> The funny thing about this is that we all agree that the RSE may =
prohibit publication of a document - we're just arguing about what =
conditions apply (e.g. small editorial, large editorial, content, =
technical, violations of physics).   I'd rather - in the words of =
someone who was eloquent on that point -
>>=20
>> In retrospect, I do not agree that the RSE should be able to veto =
publication of an IETF stream document, period.  I previously thought it =
might be reasonable for the RSE to do so for editorial issues, but I no =
longer think that. I think the IESG should be able to insist on =
publishing anything on the IETF stream. The recourse for that should be =
the same as the recourse for any other IESG action.
>>=20
>> So, no, I don=E2=80=99t think we all agree on that point.
>=20
> +1

To elaborate: I=E2=80=99d agree that the RFC Editor ought to be able to =
push back, perhaps quite strongly, to say =E2=80=9Cthis is too poorly =
written to publish=E2=80=9D, but ultimately an editorial veto should not =
be possible.

Similarly, I do not believe the RFC Editor has the right to veto =
publication on technical grounds. If they object on such grounds they =
can comment, and appeal against publication, in the same way as any =
other member of the community, but have no special right as RFC Editor.

I=E2=80=99d argue that there should be a policy defining what is =
inappropriate content for the RFC series (hate speech, obscenity, =
indecency, etc.), how it should be handled, and when/if the RFC Editor =
can refuse publication on such grounds.=20

There will certainly be legal restrictions on what the RFC Editor can =
publish, and the community needs to understand those.=20

Colin=

--Apple-Mail=_90B1BECE-B9A8-4A23-ABD3-8B75D56D4A12
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


[As an individual]

On 27 May 2020, at 07:00, Colin =
Perkins <csp@csperkins.org> wrote:
On 27 May 2020, at 02:34, Ben Campbell <ben@nostrum.com> =
wrote:
On May =
26, 2020, at 7:06 PM, Michael StJohns <msj@nthpermutation.com> wrote:
[=E2=80=A6]
The funny =
thing about this is that we all agree that the RSE may prohibit =
publication of a document - we're just arguing about what conditions =
apply (e.g. small editorial, large editorial, content, technical, =
violations of physics).   I'd rather - in the words of someone =
who was eloquent on that point -

In retrospect, I do not agree that the =
RSE should be able to veto publication of an IETF stream document, =
period.  I previously thought it might be reasonable for the RSE to =
do so for editorial issues, but I no longer think that. I think the IESG =
should be able to insist on publishing anything on the IETF stream. The =
recourse for that should be the same as the recourse for any other IESG =
action.

So, =
no, I don=E2=80=99t think we all agree on that =
point.

+1

To =
elaborate: I=E2=80=99d agree that the RFC Editor ought to be able to =
push back, perhaps quite strongly, to say =E2=80=9Cthis is too poorly =
written to publish=E2=80=9D, but ultimately an editorial veto should not =
be possible.

Similarly, I do not =
believe the RFC Editor has the right to veto publication on technical =
grounds. If they object on such grounds they can comment, and appeal =
against publication, in the same way as any other member of the =
community, but have no special right as RFC Editor.

I=E2=80=99d argue that there should be a policy =
defining what is inappropriate content for the RFC series (hate speech, =
obscenity, indecency, etc.), how it should be handled, and when/if the =
RFC Editor can refuse publication on such grounds. 

There will certainly be legal restrictions on what =
the RFC Editor can publish, and the community needs to understand =
those. 

Colin
=

--Apple-Mail=_90B1BECE-B9A8-4A23-ABD3-8B75D56D4A12--


From nobody Wed May 27 07:53: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 5EA9E3A0E6F for ; Wed, 27 May 2020 07:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=OQf7zAjF; dkim=pass (1536-bit key) header.d=taugh.com header.b=CSl2ox3R
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr2eOqnuTqhg for ; Wed, 27 May 2020 07:53:09 -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 967BA3A0C19 for ; Wed, 27 May 2020 07:53:09 -0700 (PDT)
Received: (qmail 42112 invoked from network); 27 May 2020 14:53:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a46c.5ece7ed3.k2005; i=johnl-iecc.com@submit.iecc.com; bh=YzdAtvAXlS6cKEiUzMet/lX58Oag09MrfwAbCvYvhYY=; b=OQf7zAjFVLKjDfEE1ZlIPq3fYutOMTrJUbustmSykj/mVocpPitfADkDd0NJyl2HJ1TiNyUc5LutIqFFh+LvMxAIsphmF2nVo7yfXgnlCDOPuqgaqBoKU/2qrqJHNxT/CPpsysBwQdfeE+5zlmSiE1d6Tyb3LJtgXtsxqvis1y7fSVVgLPiShDxqGlR2SqWT3reMDOGhNyMoAT6+O6A8ZBRZmu2PkMVQvJN2c0jdg+t15YffYih59L5on5VoS4v/
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:user-agent; s=a46c.5ece7ed3.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=YzdAtvAXlS6cKEiUzMet/lX58Oag09MrfwAbCvYvhYY=; b=CSl2ox3RdaXJ8b7jvqNvjcyNdBMytPUryTObP+uDMx9yc9RqY8XvPpSiXbPNHNugkD66wrLOQTR+1p6IhdrS7il+zbHFaXVIohtC+z4P/tRKLRERoG56bHGWYdRu7zw/slklq9QV8QhcQ6b/QsP4G09u07HnIuNVn+uuQqGPpTBEbS/RJlleT2R63d/bM5bu9ck8fgK6+uNrZTeQ1ka8+Ji/Ick2oeCLakIsAcnyk36xl9FAIb4QPYrDz2eSU8sI
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; 27 May 2020 14:53:07 -0000
Date: 27 May 2020 10:53:07 -0400
Message-ID: 
From: "John R Levine" 
To: "Mark Nottingham" 
Cc: Rfced-future@iab.org
In-Reply-To: <2A821289-6D63-40B9-BCD5-B31AE90DD39B@mnot.net>
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org> <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp>  <2A821289-6D63-40B9-BCD5-B31AE90DD39B@mnot.net>
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 27 May 2020 14:53:11 -0000

On Wed, 27 May 2020, Mark Nottingham wrote:
>> Legislatures have an entire staff dedicated to organizing and codifying the laws, who have extensive legal experience so they can do so while keeping the sense of the laws.
>> It would be nice if the IETF could do that, but it seems rather unlikely.
>
> Let's dig a bit to get a better idea.
>
> In Australia, that function is performed by the Office of Parliamentary Counsel. ...

In the US it's the Office of the Law Revision Counsel in the House of 
Representatives, with a budget of $3.4 million.  Each state has a similar 
office.

The idea of paying someone to codify RFC standards is intriguing.  I see 
two main challenges: one is to find someone with the combination of 
technical and editing skills to do the work, the other is whether the IESG 
and WGs would accept it.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Wed May 27 15:07: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 CC2373A0CF8 for ; Wed, 27 May 2020 15:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjjvKMLuQ0_1 for ; Wed, 27 May 2020 15:07:39 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 C915F3A0CF6 for ; Wed, 27 May 2020 15:07:39 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id q8so12490325pfu.5 for ; Wed, 27 May 2020 15:07:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Fl3Fj4RV0aoN+tkh3SD9XdUe2u8MV0CNq9NVa0Sq8NE=; b=hkvVsG04wV2/8qpZCskzePqbZ+vT/L/z0KYOGCRKzF8ymB8HmglG5h0+reg20AjoIu tPJ7XDcvGqAMZ2bEJpumOs3NGd6A007e1sLV+KQ6mib4e6gwR9Jfp9bCSTCCOw8BeRDN EQWWIO2Dw6DgDmGOxe2UCl+Plzt9h0BPrRD9mD0raTjsolpJLPrRJx9FUfCXVNQ7jCjY w18dpJeb4IjLlEiFRs9HPoIuAw10fTBo5rkTlicsv978gMsFekFrw/V7PTD5su31KZYV IvLat08Z/GD7588HQaPGv62CKeDIxOBXFgg/TXtmz/2x4gXHxsDK2l8sJMsYzlR4cns/ nGkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=Fl3Fj4RV0aoN+tkh3SD9XdUe2u8MV0CNq9NVa0Sq8NE=; b=dhGNqpYIPM9X32Yg8vA0PcpqMv9Y+aKShQHLve6zoFx3SxGydnf+XOM+bk7XcnTazq bWvQMTxaZTpZV1vc0aXBG9MjQnJNnSX0cf6R9XomjuUTH3p8B3j+eQVM++UiQap/RcUW k3AHoLei8LCvk8J6qtGvsN3K3luPKsi1QY1t5i2McHFkxc8D4uCp9QJlViTKMjszYcKR ddyNnG9clwP7sur2ls7Be/f0qIGa1yWUG1y6Jxr8LLBtTSIGP+wc0nz37/vO08FsTchj S8Iy/8JuCFAlfv508QSpjJuf4wXQJnTlyNanwyu1AZvW83weC1IonE4rFUqzSnzHWTwF htag==
X-Gm-Message-State: AOAM533TZkXiS6EpRRBtJ0vbFcj5mMgfxczMOqjkWPg4PybWsPJfEYQR dvPkIOaYlRXDTCEtGsD19tyMNmRJ6HAFCfo=
X-Google-Smtp-Source: ABdhPJwhHzS7umjv4cIEml3SHlciCBAqYF31j3KXmy/ISwpzrZn5cu4yJt7icxywmQ+Fyawq4F58Vg==
X-Received: by 2002:a63:5f11:: with SMTP id t17mr5843597pgb.177.1590617258487;  Wed, 27 May 2020 15:07:38 -0700 (PDT)
Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id 131sm2916257pfv.139.2020.05.27.15.07.37 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 15:07:37 -0700 (PDT)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: rfced-future@iab.org
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>   <47A44FB7-36A4-4CBD-BB14-7B998145C554@cisco.com>
Organization: http://SoftwareAndServices.NET
Message-ID: 
Date: Wed, 27 May 2020 16:07:36 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <47A44FB7-36A4-4CBD-BB14-7B998145C554@cisco.com>
Content-Type: multipart/alternative; boundary="------------69C478A879FF97972424BCE1"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 27 May 2020 22:07:41 -0000

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

On 5/27/20 1:54 AM, Eliot Lear wrote:
> It seems to me that in this conversation there are two groups we want to optimize for:
>
>   * The people who are attempting to update the document
>   * The readers
>
The standard is becoming the existing implementations, not the documents, as almost no one can read the DNS (and some others) documents in any succinct way. You find open source code and then look for any RFC that describes each feature.

Some discussion on this list has been about paying for it. Perhaps for just complex sets, it could be time to consolidate them into one (or few) documents. Unless you can get some volunteers.

Not really an editor function. And no WG tasked with this kind of thing.

-- 
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

--------------69C478A879FF97972424BCE1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 5/27/20 1:54 AM, Eliot Lear wrote:

    

    

      
      It seems to me that in this conversation there are two groups we
      want to optimize for:
      


      

      

        
    
          
  • The people who are attempting to update the
            document
    • 
          
  • The readers
    • 
        

      

    

    
The standard is becoming the existing implementations, not the
      documents, as almost no one can read the DNS (and some others)
      documents in any succinct way. You find open source code and then
      look for any RFC that describes each feature.

    
Some discussion on this list has been about paying for it.
      Perhaps for just complex sets, it could be time to consolidate
      them into one (or few) documents. Unless you can get some
      volunteers.

    
Not really an editor function. And no WG
      tasked with this kind of thing.

    

    
-- 

      Doug Royer - (http://DougRoyer.US)
      Douglas.Royer@gmail.com
      714-989-6135

  


--------------69C478A879FF97972424BCE1--


From nobody Wed May 27 15:19: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 C39193A0D18 for ; Wed, 27 May 2020 15:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level: 
X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PP_MIME_FAKE_ASCII_TEXT=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=fJTED2se; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=kuq8upfl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3m-_TKAlUAN for ; Wed, 27 May 2020 15:19:53 -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 CFFDB3A0D13 for ; Wed, 27 May 2020 15:19:52 -0700 (PDT)
Received: (qmail 55926 invoked by uid 100); 27 May 2020 22:19:50 -0000
Date: 27 May 2020 22:19:50 -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=da6f.5ecee786.k2005; i=news@user.iecc.com; bh=M21z2ETBM/UxX5IZP6DeRBzRbNO2drp3LVBcfcb1KYE=; b=fJTED2seda5q7YkHOG4WUFSl4vG/H/TemQfvd8nMyw52xzsArUiPELaBZm045TvLfVeUJ2RDZHA7np6jNJ4+PDXnS2P0z7kpytq2izpFOn6SN0DiurJk7okD2UnZQyB3BKpOROB+KAD8YscZMKBYMH+ZeHc8Vl+87gncgaFYu+uv91LqYG5DftK20ByC7iYgCVWNq/IpmoqoqqB9YFThxz5EB0snOunBLihePVKunm28jF5G1GvWgxvl3rMYq4IR
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=da6f.5ecee786.k2005; olt=news@user.iecc.com; bh=M21z2ETBM/UxX5IZP6DeRBzRbNO2drp3LVBcfcb1KYE=; b=kuq8upfl9zux2qknavTynvt9Dlr3s9n92EauNMKMrDwjUs9/LWhBCB1ZTAMmUfOSFcjQduBKX/xwBCyQOE4Y7+G1O0FYIsJXNNoy4I+HBgIxaJGORxiMAaAaqquoj3pVejuE1iDrlMdR32uE1t9tsf7/E7cdEtOUJVZ8jrrG03uZiKZ3J1YPi/841BOKEA/0FFHHlh7aKWPV8QpTz+b0hutPorw1zWV1WCcg9xVeD9KxDAchR9Hgye3b+b1F45SO
Organization: Taughannock Networks
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>  <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com>
In-Reply-To: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>  <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
Archived-At: 
Subject: Re: [Rfced-future] What I hope for with respect to the RFC/RSE.
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2020 22:19:55 -0000

In article <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com>,
Doug Royer   wrote:
>> That sounds suspiciously like a job for life. We have rolling contracts for other services the IETF
>community requires. It’s not clear why the RFC Series Editor should be different.
>
>As they are not Microsoft Word editors that can be replaced by someone just bubbling out of school, I would
>think that it would be in everyone's best interest if they could last for a long time. The learning curve has
>to be very large.

Although the RFC production center contract is up for renewal every
few years, in practice the same group of people have been doing it for
decades. It would be very difficult to replace or recreate their
skills and experience.

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 Wed May 27 17:35: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 B891D3A0029 for ; Wed, 27 May 2020 17:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=RGLFUgYM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Sp/J7/eS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmnc2GlsuNcC for ; Wed, 27 May 2020 17:35:48 -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 809FF3A0028 for ; Wed, 27 May 2020 17:35:48 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 393B95C0058; Wed, 27 May 2020 20:35:47 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 27 May 2020 20:35:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=i RyuexDjKHhImbytkayvOGuLD479p40t9MeS+QM5eNs=; b=RGLFUgYMIdvpAauX1 jnh9HapKb9oXYB+61gmLLNIFguYY10ZuHttjarTeMaVGl3d7+CTz4IBZaVbqmyoe D0CnbOlbBZr/VfGz4jlDsB6FPIwamUciFUJpdKgY0Zm2MAaZWBhJPtGrYJ7sS0Na lPn0pd519A/+/njsrnSQJzULKL7JEzPsyil5CdDpayCSrJjmUz4vZ1jG7TVBx0/3 5kqJ31eUiVSjYp8BCk/xMQ9UfGsHR5rGaJKKjKAxmDmxOM+mg1LUvMDr+3YD61xC j9RaXFskFeoDalPrfSVmNYcgGdZtIP49QHuGN6dNeF4TjizgJENY5OWflcMTR1li xl5DA==
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=fm2; bh=iRyuexDjKHhImbytkayvOGuLD479p40t9MeS+QM5e Ns=; b=Sp/J7/eSA5heOJWZwxA6RAVHp7XkUQ4mHaLyGObTyuZ2C1TgGCtzfs/ec WlbfPre02Zjb4GU8/YQzQgLJ3KEU1p+6OlLjip6/Fy7pO/0FDXiT980jeJjMezgT SWE/YSaXVjeN1A18OP8ceM2LcZYRD7hTu631XaZWShvKSnfyxKBfUeRPOv4tL6/v k04uVK4jJ+Z85S7mOq26k16yfB0/PU33l0ZkdPSNgucYAfVD4E72xnxMJBk1QKAl 47BAqW1DrGGdc4h0TcVzbDcwiCMpqF3VDcaKTB11XCaAXPmuI+CRBBjRHLUHdWYd /g7UEzZ5pv4NC4BR3U435y5cGs1tg==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvhedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 03D013061CB6; Wed, 27 May 2020 20:35:44 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: 
Date: Thu, 28 May 2020 10:35:41 +1000
Cc: Rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <03DAC71C-4FCE-4FA9-9B3A-519DF79F0CA6@mnot.net>
References:  <821BC38D-97E3-4976-8571-1427CF747627@tzi.org> <1ce25e32-4f44-1a07-bc79-a94760295f60@it.aoyama.ac.jp>  <2A821289-6D63-40B9-BCD5-B31AE90DD39B@mnot.net> 
To: John R Levine 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 00:35:51 -0000

> On 28 May 2020, at 12:53 am, John R Levine  wrote:
>=20
> The idea of paying someone to codify RFC standards is intriguing.  I =
see two main challenges: one is to find someone with the combination of =
technical and editing skills to do the work, the other is whether the =
IESG and WGs would accept it.

I think at least at first, it'd need to be opt-in. And the RFC Editor =
would need to provide guidelines, along the lines of "if you want your =
RFC to be consolidated, do it like _this_..." We'd also need to figure =
out how they'd be presented / identified, and what takes precedence in =
case of disagreements. Provided that it's well-thought-out, I'd think =
that the RPC could do this to a large degree (predicated mostly upon =
reasonable inputs).

My main point, though, was that if we have an RSE role, this is the sort =
of thing they should be looking at, talking to the community about, and =
potentially doing.

Cheers,

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


From nobody Wed May 27 17:51: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 31A1A3A00D4 for ; Wed, 27 May 2020 17:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=PuqV0TIq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RPl2Bbmm
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CyZh_WEueb8 for ; Wed, 27 May 2020 17:51:35 -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 AAEE53A00D3 for ; Wed, 27 May 2020 17:51:35 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D0E325C01A3; Wed, 27 May 2020 20:51:34 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 27 May 2020 20:51:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=U Y3Z26xkbdos4MQNY8DuJjIvFfXp0pR+i2yiI5IIYos=; b=PuqV0TIqv5dZK/Ea3 Yxyau9PVXOA2qNUQ0U+k2CjJ8ill7yXYIf1c9eeOp70nXnCxrnb0IrT2wulIzQKR /MagyHewCW5yV8zTYL6yMQRn+Vghc/8R7IHGz88eCoo2N+AtaQpcrNf+bo+wsonX u3EfSZaoz6HKmk8NIf55DUqS9lUXB7E2BkgZwHNr/vFnfoZgxwJq3yW2r1D4tz9I x2+j9pnoQvEHkpXODLsCMaEyceWUvmdJBuMSftBCMplg6m1SQLVY1pzZoyi1xmvM ePzEEfZPFZ3iSmCCf9DOLs5/n3e/FHpI0FTtSMqGzRPl27kc2wR73lh+rnSIY2d6 XER4A==
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=fm2; bh=UY3Z26xkbdos4MQNY8DuJjIvFfXp0pR+i2yiI5IIY os=; b=RPl2BbmmATJaU2mwwvIKHOXyBhR716C8KxCMMyJHCuzDMy2XtoTBPFqsl kX/MqcpkyuNVytlYGEw28ztSUHl5tkXpQ6fskIINk39krRKk5dtjMlhnIxhWLhfz x/BPcGs7Tu5SX0JFqWQpLvxdwOHBvhtEGjUeP7Jet5Bkuv6zykIe4ynNmO2AsXMx cwwyxPs4cEVVdkj/bR9G2n5ebWHwKpfjqjTGfGndfx+YwcicZ5j2yHWChRDjlwGF XHwJ9mLFtm6bYlZjRzA6tIUKxN6nx6nJQWkD1fhwLT+ONNEvelQz3t5jDf8bOl+8 nrU1+97ayWn8kee3kSAmAvnFaB22w==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvhedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeetfeelffejfffhheehfeefgedulefgueejudekieegvdeghefffedvheffieel keenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 29E463060FE7; Wed, 27 May 2020 20:51:32 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: 
Date: Thu, 28 May 2020 10:51:30 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <51805BD9-2091-45EC-9854-DEC35E476A1F@mnot.net>
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>  <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com> 
To: John Levine 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: [Rfced-future] Independence and Authority
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 00:51:37 -0000

On 28 May 2020, at 8:19 am, John Levine  wrote:
>=20
>>> That sounds suspiciously like a job for life. We have rolling =
contracts for other services the IETF
>> community requires. It=E2=80=99s not clear why the RFC Series Editor =
should be different.
>>=20
>> As they are not Microsoft Word editors that can be replaced by =
someone just bubbling out of school, I would
>> think that it would be in everyone's best interest if they could last =
for a long time. The learning curve has
>> to be very large.
>=20
> Although the RFC production center contract is up for renewal every
> few years, in practice the same group of people have been doing it for
> decades. It would be very difficult to replace or recreate their
> skills and experience.

Agreed. They are 'contractors' in the sense that they are on contract, =
but they have considerable context about our needs that's hard to =
replace.

So, this is another interesting comparison. I've never heard of anyone =
from our community treating the RPC badly in their interactions, and =
would be appalled if that happened; I think it's safe to say that =
there's an expectation in our community that the RPC are treated as =
professionals, and there would be at least social sanctions against =
someone who violated that. We respect the RPC both as people and =
professionals; they do hard work cleaning up our editorial messes.

That respect, however, doesn't translate to giving them authority over =
the documents; they make editorial suggestions, and authors, WG chairs =
and ADs make decisions about the final content of the document (at least =
in the IETF stream). As was mentioned yesterday, there are clear roles =
and expectations for all parties, and so things work smoothly. =
Describing the RPC as 'independent' doesn't really make sense, except in =
one or two narrow technical senses (e.g., they are an independent legal =
entity contracted to us).

With this in mind, can someone who believes that the RSE should be =
independent and/or have some form of authority explain what motivates =
the difference to the relationship with the RPC? That might help move =
the discussion along.

Cheers,

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


From nobody Wed May 27 19:11:53 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5723A0A6C for ; Wed, 27 May 2020 19:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PzMnmE0Fh_L for ; Wed, 27 May 2020 19:11:46 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508403A0A69 for ; Wed, 27 May 2020 19:11:46 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id 23so12711079pfy.8 for ; Wed, 27 May 2020 19:11:46 -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=oUHVn4LV7OFbpA1xQqlTg8GUk3OuYtK8PIfBDKZ70hY=; b=bXyUQl7oHtDLA7HrcOsoeXAn9GRXUu+Ap1UjPr9YjW0KzOSZNDqiJTV2KYg1KntFy9 xER6yABbiFcR4lFd/EqGOiggzNmS9Wa1JYY1lKoCkxHkPCHpZto5bAXdXM8Nim1Fsu2K x8D6nW4GW+/ZY4F7RydYffGe+ZzZl+vJpiykUIaXWvLfUc+WWHGKHiXG3fs7VlsKnu// s16TiDIR8avAZdHXu8ZLwQyzkkJVPYviYoExujusiQtKPZW9tpFQciYuI5PM2aAlswHi 38AnCqnzwTs9SCzGO09ZoPJjCozfj6n6xzHbi94zv2bBnH0aisFo4L+xO0xzSvQsC8fS amQQ==
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=oUHVn4LV7OFbpA1xQqlTg8GUk3OuYtK8PIfBDKZ70hY=; b=axnTB1sj0jy8/yTxMAhyO2w5BSr1mtI/BYzAxwdX0od3JwtKlc1bIPdImEuwS6lrrs T3kdBYaZAF/8H/0P+oe9eK+0qLoSwwm1BTv8ueuNcRZTDS/hN6yykeAYBs+AOp1tt2uu wyCAQTC49vSTJIspIV3AFNxFGyklW/oTJ3naU/6RRGPWTv8Ev2K0vz0x0CmnGem3QZHu /916Vl+BxbtZmZr7kFEOmKTE4K58a7K88uOzwYjrDZvX1BNqm9r7sseC0BAyYZPa3KbM 48cuJTsA3sCs1oCCGabZ3eH8uNBGwFh5T8cFrjbLn+lcTFsVKNGOU+AGnyog77DXEsbp kyNQ==
X-Gm-Message-State: AOAM5304peTG6YpJoxAccICwgfgCbapLNEPGspC0mvEfCf6ajwJC9aH1 JA7khvZTlKab/Nd+MbeWQgie+3gqeKk=
X-Google-Smtp-Source: ABdhPJyGy7Jz8IN+Ca57P5aUgmwkOxeZLmoaarXcjkN/aAn5Ek4dc8R/2/PPOlK2/0IP5bYTaOm7OA==
X-Received: by 2002:a62:e219:: with SMTP id a25mr683095pfi.303.1590631905201;  Wed, 27 May 2020 19:11:45 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id b11sm3183639pfd.178.2020.05.27.19.11.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2020 19:11:44 -0700 (PDT)
To: Mark Nottingham , John Levine 
Cc: rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>  <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com>  <51805BD9-2091-45EC-9854-DEC35E476A1F@mnot.net>
From: Brian E Carpenter 
Message-ID: 
Date: Thu, 28 May 2020 14:11:39 +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: <51805BD9-2091-45EC-9854-DEC35E476A1F@mnot.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Independence and Authority
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 02:11:52 -0000

On 28-May-20 12:51, Mark Nottingham wrote:
> On 28 May 2020, at 8:19 am, John Levine  wrote:
>>
>>>> That sounds suspiciously like a job for life. We have rolling contra=
cts for other services the IETF
>>> community requires. It=E2=80=99s not clear why the RFC Series Editor =
should be different.
>>>
>>> As they are not Microsoft Word editors that can be replaced by someon=
e just bubbling out of school, I would
>>> think that it would be in everyone's best interest if they could last=
 for a long time. The learning curve has
>>> to be very large.
>>
>> Although the RFC production center contract is up for renewal every
>> few years, in practice the same group of people have been doing it for=

>> decades. It would be very difficult to replace or recreate their
>> skills and experience.
>=20
> Agreed. They are 'contractors' in the sense that they are on contract, =
but they have considerable context about our needs that's hard to replace=
=2E
>=20
> So, this is another interesting comparison. I've never heard of anyone =
from our community treating the RPC badly in their interactions, and woul=
d be appalled if that happened; I think it's safe to say that there's an =
expectation in our community that the RPC are treated as professionals, a=
nd there would be at least social sanctions against someone who violated =
that. We respect the RPC both as people and professionals; they do hard w=
ork cleaning up our editorial messes.
>=20
> That respect, however, doesn't translate to giving them authority over =
the documents; they make editorial suggestions, and authors, WG chairs an=
d ADs make decisions about the final content of the document (at least in=
 the IETF stream). As was mentioned yesterday, there are clear roles and =
expectations for all parties, and so things work smoothly. Describing the=
 RPC as 'independent' doesn't really make sense, except in one or two nar=
row technical senses (e.g., they are an independent legal entity contract=
ed to us).
>=20
> With this in mind, can someone who believes that the RSE should be inde=
pendent and/or have some form of authority explain what motivates the dif=
ference to the relationship with the RPC? That might help move the discus=
sion along.

It's hard to answer that without erecting a strawman, so here we go, trea=
ting the style guide as a benchmark for authority:

The RPC announces that instead of using the Chicago Manual of Style, they=
 are switching to using Lynne Truss's "Eats, Shoots & Leaves", and all Am=
erican spellings will be replaced by British spellings, and all occurrenc=
es of "ize" will be replaced by "ise".

(The current spelling policy is at https://www.rfc-editor.org/rfc/rfc7322=
=2Ehtml#section-3.1 )

Who has authority to tell them whether that's OK or not? It really can't =
be IETF LLC, and the IETF bodies like the IAB are not subject matter expe=
rts. Bikeshedding such issues on ietf@ietf.org doesn't seem like a good i=
dea. An RSE who is explicitly responsible to the community and who has re=
levant expertise seems like the right answer. There are certainly less tr=
ivial issues of course (like what "archival" means in the library world) =
that lead to the same answer IMHO.

    Brian


From nobody Wed May 27 19:21:55 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9D3A0AC6 for ; Wed, 27 May 2020 19:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 y7MggYeAHNug for ; Wed, 27 May 2020 19:21:52 -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 A4A993A0C66 for ; Wed, 27 May 2020 19:21:15 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id a25so19800592ljp.3 for ; Wed, 27 May 2020 19:21:15 -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=JvhBisyGGcbZAqwliGsmFPy8cFcnVkad5I3AeD2SgVo=; b=WU9UqGBSw5H6bQfKgQoYG/gRiQ1moJIskE7ilwI+4dVSPIf+MTwOJiTYM+m//sXdVz EUkXFnaPJhpCwCog+gxCRowBNFeHvLGW84ygFSgyfr4H4bcXl/wKNSY27pBd/hE0irep Z4BpKonqqmCpgvh8zdnmsfbJyhwJ/3xf51VH2QSOI80AYF1AxqQ/UMk+BESflISvEZap v+Z7byTiJNpSkx3Lh9kgjaAMCzRrpAGLKWdl3NPhGdOPXjC9Jn5wo/ZBy7FvrJPTbzFM Xt86yb1T3vdXbR8aRqeSaLnAhknTX02BgosAtM0MVnWG6f58a5nuTqRjAJeDuXb/VOUS gsVw==
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=JvhBisyGGcbZAqwliGsmFPy8cFcnVkad5I3AeD2SgVo=; b=eAGvdXNNMy0rVHSoLU2itXa5efcVPXNuprsfD/j+LtjM1eRqbFXDyZJCzCBWfiCypB 5ySSwQ1QPklaXxr7yzxGA3f/27rBITDvqvKnKEFXS4xHgmV++PEsasmC93FhYxarHHNf k1xruPXMix29h4ntifPR5n6konT46t5aTO3vF9sNM4geim6XoP1GCMl8FQc5uYU/+V1X dKaL5Q2zizy/Lo6Li7HoUKDw5TNXCHaGflsb1a2Hy2S8sOW9Em9zjDHQKLifjATBzXrg Mus4gYy0STyWICJaKKqki3iNVkA/jYf+RgOOQGfeGRuHekggYLBmgLcKh4JmRY/R2/LE TDcw==
X-Gm-Message-State: AOAM531JUxTWBvchrVJqSeKIncYvkn0I/AM6ts3WHIr0o6WXfMYLScms E5g4NdF43LHH+mZ5w60o0y9VS9lj9rNF5z5yiFI/HQ==
X-Google-Smtp-Source: ABdhPJzXbnDG/BArLqE7m4bVD2hxy5BYSCB9ps8OaK2Fmrj8ZY3GR4ysohS32UIC9Vg/9nIOW/D2NCtla9h6jegepGc=
X-Received: by 2002:a2e:b4e2:: with SMTP id s2mr259825ljm.17.1590632473754; Wed, 27 May 2020 19:21:13 -0700 (PDT)
MIME-Version: 1.0
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>  <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com>  <51805BD9-2091-45EC-9854-DEC35E476A1F@mnot.net> 
In-Reply-To: 
From: Eric Rescorla 
Date: Wed, 27 May 2020 19:20:37 -0700
Message-ID: 
To: Brian E Carpenter 
Cc: Mark Nottingham , John Levine , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="00000000000091132b05a6abfb96"
Archived-At: 
Subject: Re: [Rfced-future] Independence and Authority
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 02:21:54 -0000

--00000000000091132b05a6abfb96
Content-Type: text/plain; charset="UTF-8"

On Wed, May 27, 2020 at 7:11 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> It's hard to answer that without erecting a strawman, so here we go,
> treating the style guide as a benchmark for authority:
>
> The RPC announces that instead of using the Chicago Manual of Style, they
> are switching to using Lynne Truss's "Eats, Shoots & Leaves", and all
> American spellings will be replaced by British spellings, and all
> occurrences of "ize" will be replaced by "ise".
>
> (The current spelling policy is at
> https://www.rfc-editor.org/rfc/rfc7322.html#section-3.1 )
>
> Who has authority to tell them whether that's OK or not? It really can't
> be IETF LLC, and the IETF bodies like the IAB are not subject matter
> experts.


Actually, it's not at all clear to me that the IAB can't decide this.

Yes, this is a topic that involves technical issues, but it's not at all
uncommon to have someone make decisions on topics that involve technical
issues in which they are not subject matter experts (indeed, this is
arguably the norm in companies, governments, etc.)  The way that this
usually works is that the decision maker gets briefed on the issue by
subject matter experts and makes a decision based on that briefing.

I don't want to overindex on your example, but I'd note that spelling
conventions are actually not really the kind of question on which subject
matter expertise is particularly helpful: after all, both the American and
British spellings are legitimate and it's a judgement call, not a matter of
technical right or wrong which to choose. This is in fact the case with
many questions which involve technical issues.

-Ekr

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




=

On Wed, May 27, 2020 at 7:11 PM Brian=
 E Carpenter <brian.e.car=
penter@gmail.com> wrote:

It's hard to answer that without erecting a strawman, so here we go, tr=
eating the style guide as a benchmark for authority:



The RPC announces that instead of using the Chicago Manual of Style, they a=
re switching to using Lynne Truss's "Eats, Shoots & Leaves&quo=
t;, and all American spellings will be replaced by British spellings, and a=
ll occurrences of "ize" will be replaced by "ise".



(The current spelling policy is at https://ww=
w.rfc-editor.org/rfc/rfc7322.html#section-3.1 )



Who has authority to tell them whether that's OK or not? It really can&=
#39;t be IETF LLC, and the IETF bodies like the IAB are not subject matter =
experts.

Actually, it's not at all clea=
r to me that the IAB can't decide this.

 Yes, =
this is a topic that involves technical issues, but it's not at all unc=
ommon to have someone make decisions on topics that involve technical issue=
s in which they are not subject matter experts (indeed, this is arguably th=
e norm in companies, governments, etc.)=C2=A0 The way that this usually wor=
ks is that the decision maker gets briefed on the issue by subject matter e=
xperts and makes a decision based on that briefing.

I don't want to overindex on your example, but I'd note that spel=
ling conventions are actually not really the kind of question on which subj=
ect matter expertise is particularly helpful: after all, both the American =
and British spellings are legitimate and it's a judgement call, not a m=
atter of technical right or wrong which to choose. This is in fact the case=
 with many questions which involve technical issues.

-Ekr




--00000000000091132b05a6abfb96--


From nobody Thu May 28 01:25: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 8EB243A0AF9 for ; Thu, 28 May 2020 01:25:45 -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 32-0RiJoOfvp for ; Thu, 28 May 2020 01:25:44 -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 2FAA63A0AEB for ; Thu, 28 May 2020 01:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=342; q=dns/txt; s=iport; t=1590654344; x=1591863944; h=from:content-transfer-encoding:mime-version:subject: message-id:date:to; bh=AAqY5EZvuCHEjsJgN4dACIQ6UiNuSGwEpahAl/xyCDI=; b=U+5Vjk5D+m4zGlloO9VP3W1Fk+Htl2KtUSke7r3kkmFYh8jxuYvFdYKg lnryQ4ktAKnVzhsXfNkExWt2r0jtNy3Q8xhnMPR48CJ5fZiuy8rsQqggf OVSmJcGKccGH+lrNZCJskWXpE7R/VtOleRYAYyh1oeNzAyMCx6Ueg+yGo E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAwA5dc9e/xbLJq1mHgEBCxIMQIE?= =?us-ascii?q?/C4NsASASjVKhd4F8CwEBAQwBAS8EAQGGYSU0CQ4CAwEBCwEBBQEBAQIBBgR?= =?us-ascii?q?thWOGM4U2gn2gIo4QdIE0hVGFIoE4jF6CAIE4HIIfhgeCeoItBI8FpCqCXgS?= =?us-ascii?q?CcZVrHYJTAZs0qnKDSQIEBgUCFYFTOYFWMxoIGxVlAYI/PRIYDZ8KPwNnAgY?= =?us-ascii?q?IAQEDCY00AQE?=
X-IronPort-AV: E=Sophos;i="5.73,444,1583193600"; d="scan'208";a="26525609"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2020 08:25:40 +0000
Received: from ams3-vpn-dhcp2844.cisco.com (ams3-vpn-dhcp2844.cisco.com [10.61.75.28]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04S8PdC1030337 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 May 2020 08:25:40 GMT
From: Eliot Lear 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Thu, 28 May 2020 10:25:39 +0200
To: rfced-future@iab.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.75.28, ams3-vpn-dhcp2844.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: [Rfced-future] Minutes and blue sheets uploaded from yesterday's call
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 08:25:46 -0000

You can find them here.  Corrections to me.  Webex recordings usually =
take a day or two to show up.  Thanks to all that attended, and a =
special thank you to Tim for having taken notes, to Cindy as always for =
having made the arrangements, and to the tooling team for having made =
data tracker accessible to IAB programs.

Eliot=


From nobody Thu May 28 01:28: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 662BA3A0C06 for ; Thu, 28 May 2020 01:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level: 
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 zEiCoD76P3L7 for ; Thu, 28 May 2020 01:28:18 -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 941383A0C02 for ; Thu, 28 May 2020 01:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2690; q=dns/txt; s=iport; t=1590654497; x=1591864097; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=zDDC5zCOYwiZ1Q4YcUL2/2XV/L6ZW1Ze27Pcdb1YqLM=; b=Uz5jShXFW+2e21rG0+75urWRa2ihQGtR/9yPgQOv9kp5c40uFIngGVaU 5GlIw2tF5h35azrPKG9hfd34VsolpldRuhBPZUNY9YZUTVw2pplWx8cZR 0wPysdB4xOlF/OIQb9Ngz7RTVd1qilbMexdXWs+woMRLJRBM/YXCulpXk k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAAA5dc9e/xbLJq1mARkBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAUCBSoMYVAEgEiyNJogHk1uIEQsBAQEMAQE?= =?us-ascii?q?YAQwKBAEBhEQCghslOBMCAwEBCwEBBQEBAQIBBgRthVcMhXIBAQEBAgEBAWw?= =?us-ascii?q?LBQsLBAETLicwBhODJgGCXCAPriN0gTSEPgKBEYUcBoE4jF6CAIE4HIIfLj6?= =?us-ascii?q?CZwEBAgGFKYItBI8FpCqCXoJ1hTWQNh2eCJpCkDCDSQIEBgUCFYFqIoFWMxo?= =?us-ascii?q?IGxU7KgGCPj4SGA2ZRoVEPwMwAjUCBggBAQMJjTQBAQ?=
X-IronPort-AV: E=Sophos; i="5.73,444,1583193600"; d="scan'208,217"; a="26525654"
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; 28 May 2020 08:28:13 +0000
Received: from ams3-vpn-dhcp2844.cisco.com (ams3-vpn-dhcp2844.cisco.com [10.61.75.28]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04S8Ro4h021995 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 May 2020 08:28:13 GMT
From: Eliot Lear 
Message-Id: <503DB90C-B7E7-42EB-B6E0-F4F82D2D0016@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8C536FB7-9238-4E53-9BF0-F9423CFE31D4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 28 May 2020 10:28:13 +0200
In-Reply-To: 
Cc: rfced-future@iab.org
To: Eliot Lear 
References: 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.75.28, ams3-vpn-dhcp2844.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] Minutes and blue sheets uploaded from yesterday's call
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 08:28:19 -0000

--Apple-Mail=_8C536FB7-9238-4E53-9BF0-F9423CFE31D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Oops.  I meant here:

=
https://datatracker.ietf.org/meeting/interim-2020-rfcefdp-02/session/rfcef=
dp =


Eliot

> On 28 May 2020, at 10:25, Eliot Lear =
 wrote:
>=20
> You can find them here.  Corrections to me.  Webex recordings usually =
take a day or two to show up.  Thanks to all that attended, and a =
special thank you to Tim for having taken notes, to Cindy as always for =
having made the arrangements, and to the tooling team for having made =
data tracker accessible to IAB programs.
>=20
> Eliot
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


--Apple-Mail=_8C536FB7-9238-4E53-9BF0-F9423CFE31D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Oops.=
  I meant here:

https://datatracker.ietf.org/meeting/interim-2020-rfcefdp-02/se=
ssion/rfcefdp

Eliot

On 28 May 2020, at 10:25, Eliot =
Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

You =
can find them here.  Corrections to me.  Webex recordings =
usually take a day or two to show up.  Thanks to all that attended, =
and a special thank you to Tim for having taken notes, to Cindy as =
always for having made the arrangements, and to the tooling team for =
having made data tracker accessible to IAB programs.

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

=

--Apple-Mail=_8C536FB7-9238-4E53-9BF0-F9423CFE31D4--


From nobody Thu May 28 03:31:02 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E933A0D2A for ; Thu, 28 May 2020 03:30: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 8MlsR_8dR8ey for ; Thu, 28 May 2020 03:30:58 -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 EE6A33A0D29 for ; Thu, 28 May 2020 03:30:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10134; q=dns/txt; s=iport; t=1590661858; x=1591871458; h=from:mime-version:subject:message-id:date:to; bh=lVaJ9l6Qb19eUxeNxIreeyd+/9UmIJgM6yYx+vk3ddI=; b=FLD6uCVhlSsHzomPh3j2M64Wj6KPFjcszpsKRYfC/QzsO2Ly+guS7aiB CeoWpSzXl+MxBk7QXUUMNfflYsF92UueNNcvKZSte17NIgwJ1m5k6kgSz uTite6dbfe1Eip7zEZS/98UiUPYcYZkW0p2OGiaiJqCjaVFg0jcX1qmdW Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwBwCbks9e/xbLJq1mhj8BIBKEUYk?= =?us-ascii?q?Bh2GUBoYpgWgLAQEBDAEBLwQBAYZiJTgTAgMBAQsBAQUBAQECAQYEbYVjhhx?= =?us-ascii?q?IB2QCgQYBBoMLgn2gKo4QdoEyhVGFIIE4jF6CAIERJwwQhyQBEgGDNTOCLQS?= =?us-ascii?q?OOBFFpCyCXgSCcop2incegmSJBJIlhQelcYNJAgQGBQIVgWoiZnAzGggbFTs?= =?us-ascii?q?qAYI/PRIYDZBMF44nPwNnAgYBBwEBAwmNWwEB?=
X-IronPort-AV: E=Sophos; i="5.73,444,1583193600"; d="scan'208,217"; a="26529910"
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; 28 May 2020 10:30:45 +0000
Received: from ams3-vpn-dhcp2844.cisco.com (ams3-vpn-dhcp2844.cisco.com [10.61.75.28]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04SAUhOX026712 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 May 2020 10:30:44 GMT
From: Eliot Lear 
Content-Type: multipart/alternative; boundary="Apple-Mail=_CD2426AF-76FA-4C31-B442-AC3EB477CC17"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <53470428-7F4A-4187-B4A2-C758BF88EDE8@cisco.com>
Date: Thu, 28 May 2020 12:30:43 +0200
To: rfced-future@iab.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.75.28, ams3-vpn-dhcp2844.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: [Rfced-future] Going forward - some issues
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 10:31:00 -0000

--Apple-Mail=_CD2426AF-76FA-4C31-B442-AC3EB477CC17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi everyone,

We=E2=80=99ve had a very free ranging discussion over the last few =
weeks.  I thought yesterday=E2=80=99s call was very helpful.  A few =
points that I would like to address going forward:

Bike shedding

We have a tendency to get into a lot of details about how the series is =
formatted, and I have received several complaints.  Formatting is not =
something that this group should discuss.  The only issue for this group =
is who gets to decide that question.  Nothing more.  Lower than that I =
now propose to rule out of scope.  In general, when you post, please =
relate the note to governance or definition of one or more of the roles =
in the system, and avoid doing that person=E2=80=99s job in this WG.

Relationship between series evolution and governance

Mike made a key observation yesterday in support of independence that I =
want to highlight, because I think it goes to the heart of governance:  =
he said that our rough consensus processes can paralyze decision making. =
 I think we have all seen that happen at the IETF in particular.  There =
is value in moving slowly in evolutionary terms, but there is also value =
in recognizing that filibustering can entirely stop evolution.  As we =
consider governance approaches for the RSE, we should also consider =
whether rough consensus is an appropriate model for change.

Engagement Model

There was a lot of discussion yesterday about the customer/vendor model, =
and what it means to interact with professionals who are well outside =
our scope of expertise.  EKR gave the example of a lawyer he might =
employ, for instance, where as Colin pointed out that the respect and =
attachment to people who are labeled =E2=80=9Ccontractors=E2=80=9D might =
have some cultural differences.  Mark pointed out on list that he =
hasn=E2=80=99t seen people show disrespect toward the RPC.  Indeed, I =
would go further and say that on the whole we do not show disrespect to =
those who we clearly see in a supporting role to the organization.

RFC 8728 does not use the word =E2=80=9Ccustomer=E2=80=9D.  This is a =
new word in the RSE vocabulary.  Adrian made the point early on that if =
we are to use this term, we need to define the role.  That is smack in =
the middle of our charter.  As I reads things, we have two definitions =
proposed within the group, and I will add a third and a fourth for =
discussion purposes:

A working group along the lines that Nevil mentioned in his draft
A committee that Mike mentioned in his proposal
The stream managers
The RSOC (status quo)

I do not endorse any of these.  I would ask for conversation about any =
of the four of these, or any other group you would like to formulate =
(you needn=E2=80=99t stick to those four).  For discussion purposes, I =
propose that we accept the rebuttable presumption that these groups are =
responsible for setting qualifications on the role of RSE, that they may =
range those qualifications from pencil pusher to anointed Grand Poobah =
of the Series.

In considering these groups, it is important for people answer these =
questions:

Who is accountable to the community for the series and how?  If =
something goes wrong again, how does the community express its =
displeasure?  To put a fine point on this: if you define customer as =
coders, you should be able to define an accountability mechanism to =
them.  Otherwise you might think in terms of proxies.

What is the relationship between each entity in the system?  =
Specifically, the RSE, these committees, the other governing boards (the =
IAB, IESG, LLC), the Executive Director, and the RPC?

Format of proposals

As we move forward, email messages or drafts for proposals are fine.  I =
will capture the key points on Github.  As I mentioned yesterday, I =
propose to seek a neutral editor for a consensus draft at least on the =
problem space, and then aiming toward solutions.

Comments?

Eliot=

--Apple-Mail=_CD2426AF-76FA-4C31-B442-AC3EB477CC17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
everyone,

We=E2=80=99v=
e had a very free ranging discussion over the last few weeks.  I =
thought yesterday=E2=80=99s call was very helpful.  A few points =
that I would like to address going forward:

  • Bike shedding

We have a tendency to get into a =
lot of details about how the series is formatted, and I have received =
several complaints.  Formatting is not something that this group should discuss. =
 The only issue for this group is who gets to decide that question. =
 Nothing more.  Lower than that I =
now propose to rule out of scope.  In general, when you =
post, please relate the note to governance or definition of one or more =
of the roles in the system, and avoid doing that person=E2=80=99s job in =
this WG.

  • Relationship between series =
evolution and governance

Mike made a key observation =
yesterday in support of independence that I want to highlight, because I =
think it goes to the heart of governance:  he said that our rough =
consensus processes can paralyze decision making.  I think we have =
all seen that happen at the IETF in particular.  There is value in =
moving slowly in evolutionary terms, but there is also value in =
recognizing that filibustering can entirely stop evolution.  As we =
consider governance approaches for the RSE, we should also consider =
whether rough consensus is an appropriate model for change.

  • Engagement Model

There was a lot of =
discussion yesterday about the customer/vendor model, and what it means =
to interact with professionals who are well outside our scope of =
expertise.  EKR gave the example of a lawyer he might employ, for =
instance, where as Colin pointed out that the respect and attachment to =
people who are labeled =E2=80=9Ccontractors=E2=80=9D might have some =
cultural differences.  Mark pointed out on list that he hasn=E2=80=99=
t seen people show disrespect toward the RPC.  Indeed, I would go =
further and say that on the whole we do not show disrespect to those who =
we clearly see in a supporting role to the organization.

RFC 8728 does not use =
the word =E2=80=9Ccustomer=E2=80=9D.  This is a new word in the RSE =
vocabulary.  Adrian made the point early on that if we are to use =
this term, we need to define the role.  That is smack in the middle =
of our charter.  As I reads things, we have two definitions =
proposed within the group, and I will add a third and a fourth for =
discussion purposes:

  • A working group =
along the lines that Nevil mentioned in his draft
  • A =
committee that Mike mentioned in his proposal
  • The =
stream managers
  • The RSOC (status quo)

I do not endorse any of these.  I would ask for conversation =
about any of the four of these, or any other group you would like to =
formulate (you needn=E2=80=99t stick to those four).  For =
discussion purposes, I propose that we accept the rebuttable presumption =
that these groups are responsible for setting qualifications on the role =
of RSE, that they may range those qualifications from pencil pusher to =
anointed Grand Poobah of the Series.

In considering these groups, it =
is important for people answer these questions:

Who is accountable to the community for =
the series and how?  If something goes wrong again, how does the =
community express its displeasure?  To put a fine point on this: if =
you define customer as coders, you should be able to define an =
accountability mechanism to them.  Otherwise you might think in =
terms of proxies.

What is the relationship between each entity in the system? =
 Specifically, the RSE, these committees, the other governing =
boards (the IAB, IESG, LLC), the Executive Director, and the =
RPC?

  • Format of proposals

As we move =
forward, email messages or drafts for proposals are fine.  I will =
capture the key points on Github.  As I mentioned yesterday, I =
propose to seek a neutral editor for a consensus draft at least on the =
problem space, and then aiming toward solutions.

Comments?

Eliot
=

--Apple-Mail=_CD2426AF-76FA-4C31-B442-AC3EB477CC17--


From nobody Thu May 28 13:47:51 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA17E3A0DB2 for ; Thu, 28 May 2020 13:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbHNahzI6_0D for ; Thu, 28 May 2020 13:47:48 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126203A0DAF for ; Thu, 28 May 2020 13:47:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DF999300B4F for ; Thu, 28 May 2020 16:47:44 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OgilkBZGhk15 for ; Thu, 28 May 2020 16:47:43 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id E5996300A51; Thu, 28 May 2020 16:47:42 -0400 (EDT)
From: Russ Housley 
Message-Id: <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB4332FB-CFEF-416F-A9DC-206DF346CB5D"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Thu, 28 May 2020 16:47:44 -0400
In-Reply-To: <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org>
Cc: rfced-future@iab.org
To: Colin Perkins 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 May 2020 20:47:50 -0000

--Apple-Mail=_AB4332FB-CFEF-416F-A9DC-206DF346CB5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On May 26, 2020, at 5:14 PM, Colin Perkins  wrote:
>=20
> [As an individual]
>=20
>> On 26 May 2020, at 08:13, Eliot Lear > wrote:
>>=20
>> Hi everyone,
>>=20
>> I am hearing several different points of view on this matter:
>>=20
>> The series is difficult to read because one has to traipse through a =
large number of documents, and this is a problem the RSE should take on.
>> This is a problem for the IETF and the RSE shouldn=E2=80=99t be =
involved.
>> This is a shared problem between the RSE and the streams
>> This is so hard a problem we shouldn=E2=80=99t touch it.
>> What is =E2=80=9Carchival=E2=80=9D?
>>=20
>> I wonder if there is consensus around something close to the =
following view:
>>=20
>> The RFC Series Editor is responsible for specifying editorial methods =
and the necessary architecture by which RFCs may be amended in a manner =
that is seen as useful to the various stream managers, with an eye =
toward readability and referential integrity (add other stuff here).  It =
is up to the stream owners to set policies around approving such =
amendments.
>>=20
>> This isn=E2=80=99t all that far from what we have today with the =
errata process, but is more specific than what is in our documents =
today.  The only question is really how the rendering of changes should =
take place.
>=20
> I do not believe allowing amendments to published RFCs is desirable =
(with the possible exception: to fix bugs in the XML schema, provided =
there=E2=80=99s no content change).

+1

> Having the RFC Editor develop better processes for collecting, =
verifying, surfacing, and displaying errata seems useful.=20
>=20
> Having the community develop lighter-weight processes for producing =
-bis RFCs seems useful.=20
>=20
> But I do not believe amending published RFCs is desirable.

Right.  The inline errata are an improvement, and it would be =
interesting to do even better.

Russ


--Apple-Mail=_AB4332FB-CFEF-416F-A9DC-206DF346CB5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On May 26, 2020, at 5:14 PM, Colin Perkins <csp@csperkins.org> =
wrote:

[As an =
individual]

On 26 May 2020, at 08:13, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

Hi everyone,

I am hearing several =
different points of view on this matter:

  • The series is difficult to read because one has to traipse =
through a large number of documents, and this is a problem the RSE =
should take on.
  • This is a problem for the IETF and =
the RSE shouldn=E2=80=99t be involved.
  • This is a =
shared problem between the RSE and the streams
  • This =
is so hard a problem we shouldn=E2=80=99t touch it.
  • What is =E2=80=9Carchival=E2=80=9D?

I wonder if there =
is consensus around something close to the following view:

  • The RFC Series Editor is =
responsible for specifying editorial methods and the necessary =
architecture by which RFCs may be amended in a manner that is seen as =
useful to the various stream managers, with an eye toward readability =
and referential integrity (add other stuff here).  It is up to the =
stream owners to set policies around approving such =
amendments.

This isn=E2=80=99t all that far from what we have today with =
the errata process, but is more specific than what is in our documents =
today.  The only question is really how the rendering of changes =
should take place.

I do not believe allowing amendments to =
published RFCs is desirable (with the possible exception: to fix bugs in =
the XML schema, provided there=E2=80=99s no content =
change).

+1

Having the RFC Editor develop better =
processes for collecting, verifying, surfacing, and displaying errata =
seems useful. 

Having the community develop lighter-weight processes for =
producing -bis RFCs seems useful. 

But I do not believe amending published =
RFCs is desirable.

Right.  The inline errata are an improvement, and =
it would be interesting to do even better.

Russ

=

--Apple-Mail=_AB4332FB-CFEF-416F-A9DC-206DF346CB5D--


From nobody Thu May 28 13:48: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 E2F8B3A0E07 for ; Thu, 28 May 2020 13:48:04 -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, 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 jqFPKttWDxyi for ; Thu, 28 May 2020 13:48:03 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 0865B3A0DCF for ; Thu, 28 May 2020 13:48:02 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id z1so209511qtn.2 for ; Thu, 28 May 2020 13:48:02 -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=RutR1fVHRZ1YiybcsFRZaC9+FmMsvY+rHMxIBg+c3Dk=; b=Lx6L9L2SioaX/OEXndjnUW8o38zmC2qCJEORPdirge9cd+KcBVGGc7VeTH62NQHKZB Dtva4nhwnrhOcLLxdgJeLyZy+Vsane8rtLoz3P38gR/mdIgDLxq6b7mEqDcel1ZVqqbJ fJqbOmCySCy/bnYBqBu7ZT8LAb2VYjBEHQ3C/EhjNl2SCjlCxi0Lf2kHFA1siHuxcfgu vlpLoORuDKH+sB98H0ICzKF6Z06PlLgSObNZ1EjiinvzmBwPY5vF7PlSkFwVslcJ4J/6 3uX7/MYs8QBM4YZnZggNLonjLJJNoBk1dgp9tL0jjopxyTOoiJzpHO9kfVtfeWrQBVH0 uL8g==
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=RutR1fVHRZ1YiybcsFRZaC9+FmMsvY+rHMxIBg+c3Dk=; b=QwpZMsHxlTt8a88q7GeUF6gSaujeKe/zwV4qLUfF5yohEZc91CFELq8V6BbytcEsZz tIO4P8Q4mNivZhApithmgVhqoChc4rMtzjFeV+/NdOlK3/UB7kkUJ8fB5cZWDDw4FNxG WSNzsmjiIMOVVXgdADQPFs7nYmIBj5ShrfHWAxCeRghcLCAIE7EjNUdbw6cN/GMxkxOK gSu8r5oZd7ReO0civp0xCHqGsWj1V09lBGMZIC4i61tNmZgQxujTrsCRjOApPM0DbxaR +O9jPobHRQZr85MXOuwCfIlg0KRkOHe8HVwcSJJspR05niH1Gazo7xazBmoPuCd7YChK DxdQ==
X-Gm-Message-State: AOAM530q16no3c7efjhdVd7RbmJDcYqVP5q6X4KjUNj506itCLRLz8y+ n2uGxpvq/iyH1b+vD+ihk36+/mNcu58=
X-Google-Smtp-Source: ABdhPJxtIkcftd10wAb7RleLy86igGKX1HQ5Rxvcj5y6on3A/QLjU7Um5YlZz7f7Etpx7/hCnW1RwA==
X-Received: by 2002:aed:3beb:: with SMTP id s40mr4787948qte.322.1590698880591;  Thu, 28 May 2020 13:48:00 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id 17sm4910712qka.27.2020.05.28.13.47.59 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2020 13:48:00 -0700 (PDT)
To: rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>  <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com>  <51805BD9-2091-45EC-9854-DEC35E476A1F@mnot.net>
From: Michael StJohns 
Message-ID: 
Date: Thu, 28 May 2020 16:47:59 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <51805BD9-2091-45EC-9854-DEC35E476A1F@mnot.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Independence and Authority
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 20:48:12 -0000

On 5/27/2020 8:51 PM, Mark Nottingham wrote:
> On 28 May 2020, at 8:19 am, John Levine  wrote:
>>>> That sounds suspiciously like a job for life. We have rolling contracts for other services the IETF
>>> community requires. It’s not clear why the RFC Series Editor should be different.
>>>
>>> As they are not Microsoft Word editors that can be replaced by someone just bubbling out of school, I would
>>> think that it would be in everyone's best interest if they could last for a long time. The learning curve has
>>> to be very large.
>> Although the RFC production center contract is up for renewal every
>> few years, in practice the same group of people have been doing it for
>> decades. It would be very difficult to replace or recreate their
>> skills and experience.
> Agreed. They are 'contractors' in the sense that they are on contract, but they have considerable context about our needs that's hard to replace.

Actually, no.  They are employees of a contractor - this is an important 
difference.  In models like this, what happens is the contractors 
change, and the employees are generally hired away by the new 
contractor.   The employees are insulated from adverse actions on the 
part of the contracting entity (e.g. us collectively) by their 
relationship with the contracted entity (e.g the RPC).

>
> So, this is another interesting comparison. I've never heard of anyone from our community treating the RPC badly in their interactions, and would be appalled if that happened; I think it's safe to say that there's an expectation in our community that the RPC are treated as professionals, and there would be at least social sanctions against someone who violated that. We respect the RPC both as people and professionals; they do hard work cleaning up our editorial messes.

As employees of a contract managed by the ED and the LLC no individuals 
within the IETF or even the IETF leadership have any ability to twiddle 
directly with an RPC employee.   The recourse is for the ED or LLC to 
talk to the RPC manager who is responsible for executing the contract.  
If the ED or LLC are unable to get satisfaction that way, then they may 
take legal action  - if and only if there's a contract violation.

In practice, it's in the best interest of the IETF that the ED/LLC and 
RPC act together as collaborators rather than in a 
me-boss-you-contractor relationship and the "never heard of anyone...." 
comment is indicative of that model.  Sadly, that's seems to be anathema 
as a model for the IETF dealing with the RSE.

>
> That respect, however, doesn't translate to giving them authority over the documents; they make editorial suggestions, and authors, WG chairs and ADs make decisions about the final content of the document (at least in the IETF stream). As was mentioned yesterday, there are clear roles and expectations for all parties, and so things work smoothly.
The RPC has a contract which spells out the boundaries.  And even the, 
the IETF has no direct control over *how* things are done.  I'd actually 
have to look at the wording of the RPC contract to see if the lines are 
drawn as clearly as you think they are.
>   Describing the RPC as 'independent' doesn't really make sense, except in one or two narrow technical senses (e.g., they are an independent legal entity contracted to us).

*sigh*   Independent:  "Free from outside control; not depending on 
another's authority".  I'd argue strongly that - within the boundaries 
of the contract - the RPC members are independent of IETF control.   
They may not be independent from their managers, but they certainly 
don't have to worry about day to day interference from the IETF with 
their core responsibilities.  The way the relationship is structured 
provides some measure of protection.

>
> With this in mind, can someone who believes that the RSE should be independent and/or have some form of authority explain what motivates the difference to the relationship with the RPC? That might help move the discussion along.

Unfortunately, the structure that the IAB set up to deal with the RSE 
had few if any of these restraints and in a few instances stepped over 
the line into the space that the community had agreed belonged to the RSE.

The US IRS says this about independent contractors: "The general rule is 
that an individual is an independent contractor if the payer has the 
right to control or direct only the result of the work and not what will 
be done and how it will be done."   So maybe what I should be asking you 
is "what is the result of the work and how should the community direct it?"

Jay - in the chat transcript of the last call - argued that he didn't 
have independence, he had defined lines of authority.  I would argue 
that these are the same unless the lines of authority may be changed at 
any time by fiat.  It may be that he doesn't have independence to do his 
job - but that would actually be a sad commentary on the relationship.

Later, Mike



>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>


From nobody Thu May 28 13:59: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 661E63A0E7C for ; Thu, 28 May 2020 13:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taO4gQ2YppU3 for ; Thu, 28 May 2020 13:59:23 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 BE16C3A0E7A for ; Thu, 28 May 2020 13:59:23 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id p21so151640pgm.13 for ; Thu, 28 May 2020 13:59: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=9/ahqB9r0aTN6PEXKBBp6uYnpZlDavFnwciBnOmp/OY=; b=IS+3bPGZNoFe2eyZ1JA7Jqrdu0slQWkB8R3KMrL+OZpcx1JeLhtZW/TBYseQs8BSv/ fSXj8layaIy41bVh/sCsQyqnoSYlZ0PBa5vB4CVhqAgFG3M7FlhiOD4VIQG2oVRp9e3Z 29xnkLgYG9O+0vRQhLDGG9a+4okpLVeZko6X4uZeV4EveA4Ar1G4k496iucsB3M2XkYp YQxA87Qjt3zl3ce+nY8hU9ZoYhRBpqVMIx1A82SxQGUbZDIaI73Iiry7kpO0GBraaXz6 Vt7+5G1szcSRyXQSXfmzjo0v48jgZNGC5zU1j9OdFQsRaTVabGFfcS77bjBd1sShzDjt DWWA==
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=9/ahqB9r0aTN6PEXKBBp6uYnpZlDavFnwciBnOmp/OY=; b=uMnDryyQYyc9Pa9FgoQv031D1pUT2jnhkltHuDKKxQDN70k4+eDh9UMuSZq0HegYgo OFp9x6nKTW4+Jk7/QZUelnpZIk3VT1m2QQ+wmClZaaNpaF0vVJKDfZ2ii09s5aZQNeS1 QW6N1wetY+kVLLwFLG/Y74BslAG0/qyogpCHNlIax72qyEaq4GbuEw5QIIltgAj5DfoU ISzXl2XqaR1JfUpMiBA9ICJ3INvJWmYCLyzzBwddK+dGYRVZOAc/bi2nFIFOmCjYemB5 n02Fsh0Vhq3ZCz5W49STpMdvzcu0dXEAWfY54v1YkT3PlQYiS0CZqeTGaLEphukfs6B5 sO7w==
X-Gm-Message-State: AOAM531JYQj4wI71V1iuR/Xt0r+7O5vnC0WMwCaTq9nii48D6COzxIV6 OOhd6sIS5zXgrr6bu+cRRGIncaFroQo=
X-Google-Smtp-Source: ABdhPJwgJhkDlLTxF9t4btznI/MKCyfSsnT7Jbw4byReOg1MFv9W0rtUO4EsXKegXBIQ+j3Exp2uCg==
X-Received: by 2002:a63:7b51:: with SMTP id k17mr4880635pgn.422.1590699562914;  Thu, 28 May 2020 13:59:22 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id m22sm5655938pjv.30.2020.05.28.13.59.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2020 13:59:22 -0700 (PDT)
To: Michael StJohns , rfced-future@iab.org
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>  <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com>  <51805BD9-2091-45EC-9854-DEC35E476A1F@mnot.net> 
From: Brian E Carpenter 
Message-ID: 
Date: Fri, 29 May 2020 08:59: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] Independence and Authority
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 20:59:25 -0000

> In models like this, what happens is the contractors=20
> change, and the employees are generally hired away by the new=20
> contractor.
And, importantly, hiring nominated key staff can be a *requirement* of th=
e RFP. I've done RFPs for services where we did that.

Regards
   Brian Carpenter

On 29-May-20 08:47, Michael StJohns wrote:
> On 5/27/2020 8:51 PM, Mark Nottingham wrote:
>> On 28 May 2020, at 8:19 am, John Levine  wrote:
>>>>> That sounds suspiciously like a job for life. We have rolling contr=
acts for other services the IETF
>>>> community requires. It=E2=80=99s not clear why the RFC Series Editor=
 should be different.
>>>>
>>>> As they are not Microsoft Word editors that can be replaced by someo=
ne just bubbling out of school, I would
>>>> think that it would be in everyone's best interest if they could las=
t for a long time. The learning curve has
>>>> to be very large.
>>> Although the RFC production center contract is up for renewal every
>>> few years, in practice the same group of people have been doing it fo=
r
>>> decades. It would be very difficult to replace or recreate their
>>> skills and experience.
>> Agreed. They are 'contractors' in the sense that they are on contract,=
 but they have considerable context about our needs that's hard to replac=
e.
>=20
> Actually, no.=C2=A0 They are employees of a contractor - this is an imp=
ortant=20
> difference.=C2=A0 In models like this, what happens is the contractors =

> change, and the employees are generally hired away by the new=20
> contractor.=C2=A0=C2=A0 The employees are insulated from adverse action=
s on the=20
> part of the contracting entity (e.g. us collectively) by their=20
> relationship with the contracted entity (e.g the RPC).
>=20
>>
>> So, this is another interesting comparison. I've never heard of anyone=
 from our community treating the RPC badly in their interactions, and wou=
ld be appalled if that happened; I think it's safe to say that there's an=
 expectation in our community that the RPC are treated as professionals, =
and there would be at least social sanctions against someone who violated=
 that. We respect the RPC both as people and professionals; they do hard =
work cleaning up our editorial messes.
>=20
> As employees of a contract managed by the ED and the LLC no individuals=
=20
> within the IETF or even the IETF leadership have any ability to twiddle=
=20
> directly with an RPC employee.=C2=A0=C2=A0 The recourse is for the ED o=
r LLC to=20
> talk to the RPC manager who is responsible for executing the contract.=C2=
=A0=20
> If the ED or LLC are unable to get satisfaction that way, then they may=
=20
> take legal action=C2=A0 - if and only if there's a contract violation.
>=20
> In practice, it's in the best interest of the IETF that the ED/LLC and =

> RPC act together as collaborators rather than in a=20
> me-boss-you-contractor relationship and the "never heard of anyone...."=
=20
> comment is indicative of that model.=C2=A0 Sadly, that's seems to be an=
athema=20
> as a model for the IETF dealing with the RSE.
>=20
>>
>> That respect, however, doesn't translate to giving them authority over=
 the documents; they make editorial suggestions, and authors, WG chairs a=
nd ADs make decisions about the final content of the document (at least i=
n the IETF stream). As was mentioned yesterday, there are clear roles and=
 expectations for all parties, and so things work smoothly.
> The RPC has a contract which spells out the boundaries.=C2=A0 And even =
the,=20
> the IETF has no direct control over *how* things are done.=C2=A0 I'd ac=
tually=20
> have to look at the wording of the RPC contract to see if the lines are=
=20
> drawn as clearly as you think they are.
>>   Describing the RPC as 'independent' doesn't really make sense, excep=
t in one or two narrow technical senses (e.g., they are an independent le=
gal entity contracted to us).
>=20
> *sigh*=C2=A0=C2=A0 Independent:=C2=A0 "Free from outside control; not d=
epending on=20
> another's authority".=C2=A0 I'd argue strongly that - within the bounda=
ries=20
> of the contract - the RPC members are independent of IETF control.=C2=A0=
=C2=A0=20
> They may not be independent from their managers, but they certainly=20
> don't have to worry about day to day interference from the IETF with=20
> their core responsibilities.=C2=A0 The way the relationship is structur=
ed=20
> provides some measure of protection.
>=20
>>
>> With this in mind, can someone who believes that the RSE should be ind=
ependent and/or have some form of authority explain what motivates the di=
fference to the relationship with the RPC? That might help move the discu=
ssion along.
>=20
> Unfortunately, the structure that the IAB set up to deal with the RSE=20
> had few if any of these restraints and in a few instances stepped over =

> the line into the space that the community had agreed belonged to the R=
SE.
>=20
> The US IRS says this about independent contractors: "The general rule i=
s=20
> that an individual is an independent contractor if the payer has the=20
> right to control or direct only the result of the work and not what wil=
l=20
> be done and how it will be done."=C2=A0=C2=A0 So maybe what I should be=
 asking you=20
> is "what is the result of the work and how should the community direct =
it?"
>=20
> Jay - in the chat transcript of the last call - argued that he didn't=20
> have independence, he had defined lines of authority.=C2=A0 I would arg=
ue=20
> that these are the same unless the lines of authority may be changed at=
=20
> any time by fiat.=C2=A0 It may be that he doesn't have independence to =
do his=20
> job - but that would actually be a sad commentary on the relationship.
>=20
> Later, Mike
>=20
>=20
>=20
>>
>> Cheers,
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>=20


From nobody Thu May 28 14:02: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 E79673A0F7F for ; Thu, 28 May 2020 14:02:20 -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 gleRxGxjrDXW; Thu, 28 May 2020 14:02:19 -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 13A2A3A0E9C; Thu, 28 May 2020 14:02:03 -0700 (PDT)
From: Jay Daley 
Message-Id: <532D2A10-F3AB-4646-B58B-F2FAEC7189CB@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EF44D801-F516-49DC-9518-E88BB232AF27"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 29 May 2020 09:02:01 +1200
In-Reply-To: 
Cc: rfced-future@iab.org
To: Michael StJohns 
References: <18575358-600e-fa65-a03e-fc5d85790b00@nthpermutation.com>  <389555ca-3ee0-88a4-6406-c82e0ce752be@gmail.com>  <51805BD9-2091-45EC-9854-DEC35E476A1F@mnot.net> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] Independence and Authority
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 28 May 2020 21:02:28 -0000

--Apple-Mail=_EF44D801-F516-49DC-9518-E88BB232AF27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 29/05/2020, at 8:47 AM, Michael StJohns  =
wrote:
>=20
> Jay - in the chat transcript of the last call - argued that he didn't =
have independence, he had defined lines of authority.  I would argue =
that these are the same unless the lines of authority may be changed at =
any time by fiat.  It may be that he doesn't have independence to do his =
job - but that would actually be a sad commentary on the relationship.

I didn=E2=80=99t argue that I don=E2=80=99t have independence, what I =
said was that framing this as 'independence' is the wrong way to look at =
it as a) it masks the details of the issues; and b) takes us into =
various ratholes about the meaning of independence.

A far better way to look at it, which applies to me, is that when the =
following chain is in place, things work

1.  clear governance (both for goal setting and performance management)
2.  clear goals
3.  clear delegated authorities
4.  clear values (how things should be done)

Jay

>=20
> Later, Mike
>=20
>=20
>=20
>>=20
>> Cheers,
>>=20
>> --
>> Mark Nottingham   https://www.mnot.net/
>>=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=_EF44D801-F516-49DC-9518-E88BB232AF27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 29/05/2020, at 8:47 AM, Michael StJohns <msj@nthpermutation.com> wrote:

Jay =
- in the chat transcript of the last call - argued that he didn't have =
independence, he had defined lines of authority.  I would argue =
that these are the same unless the lines of authority may be changed at =
any time by fiat.  It may be that he doesn't have independence to =
do his job - but that would actually be a sad commentary on the =
relationship.

I didn=E2=80=99t argue that I don=E2=80=99t have =
independence, what I said was that framing this as 'independence' is the =
wrong way to look at it as a) it masks the details of the issues; and b) =
takes us into various ratholes about the meaning of =
independence.

A far better way to =
look at it, which applies to me, is that when the following chain is in =
place, things work

1.  clear =
governance (both for goal setting and performance =
management)
2.  clear goals
3.  clear =
delegated authorities
4.  clear values (how things should =
be done)

Jay


Later, Mike




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=_EF44D801-F516-49DC-9518-E88BB232AF27--


From nobody Thu May 28 16:58: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 9AED93A0FD0 for ; Thu, 28 May 2020 16:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=eNy2A1oj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VHFrjXTF
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-8Gm1QaTRaf for ; Thu, 28 May 2020 16:58:34 -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 2049C3A0FCF for ; Thu, 28 May 2020 16:58:34 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 240A85C00DA; Thu, 28 May 2020 19:58:33 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 28 May 2020 19:58:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=/ GOdexgpbghUf/8OpNgbOIdLnrURpwV7OaLp/J1JRuo=; b=eNy2A1oj38JKc4uFe SNCb60zT2L/y/jsriyQV98AJWETA59thIMpfUKb4+Ao4kCgx9QmM1rIcM+DzM3RG j8tswpHR/opVHXAa9SN6zeqCmuSbW5DD0uvc2n+TNw6MJEwBJdPZixe86fVS6Zcw ZQLtYcspc2k7xQNBx6Ux+4ldC41vDP91rcU6c3MKudXYI+tmwZY52kmgYiN9U91v twUeNVgy6RlbmLLrNR5qJLlSx+mT1zryGlIvVvaAQwE09ozsbJuqHNYlesIAcDT4 7tpzpNoZL+4jsqGJiqL3Kddr/usfV4AdHsKitLAvKwpho+DWRMMY2sx2ijnYpVCq sYehw==
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=fm2; bh=/GOdexgpbghUf/8OpNgbOIdLnrURpwV7OaLp/J1JR uo=; b=VHFrjXTFCcCGXVletq1viLKr4ATqHsxOSMuCSVmsTl0x/ZWtX7sqH+18k CI91B4ups6t42lmELjUCG6tAUYdr0Z1kHVls7wycnBmFkS0HDX2rA9hm2aPmE4oH G1ZBfipJo9qrZr8mhJ+N93Pphxg45ebbJ/WPiOtgXAGnrfHRPYE50U3a5G7k39+K j2Q3xRmxzcibUUAbL15DOJ4KHRcrG9WqyMcgMN3/Uffl1FXGXGjlbX7QXHWRWf6g buaklLb2sEabWMzXtZ3eCYavZvxJvPXu1zpSaC0nNvg4mXZe5H8RpsoFsudKCG0D eahfyIg+XqGTj0ja+3nUfMao6GAvw==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvjedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeetfeelffejfffhheehfeefgedulefgueejudekieegvdeghefffedvheffieel keenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 68523328005D; Thu, 28 May 2020 19:58:31 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com>
Date: Fri, 29 May 2020 09:58:29 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <065D5755-1C98-458B-993A-700228EE2259@mnot.net>
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com>
To: Russ Housley , Colin Perkins 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 May 2020 23:58:36 -0000

> On 29 May 2020, at 6:47 am, Russ Housley  wrote:
>=20
>> I do not believe allowing amendments to published RFCs is desirable =
(with the possible exception: to fix bugs in the XML schema, provided =
there=E2=80=99s no content change).
>=20
> +1

Could you give us some indication as to why you feel this way -- e.g., =
what would be impacted? I fear we're falling into the habit of just =
stating our preferences and expecting Eliot to tally the votes...

Cheers,

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


From nobody Thu May 28 18:13: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 6A7E33A107C for ; Thu, 28 May 2020 18:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVzcCP4JfsV0 for ; Thu, 28 May 2020 18:13:38 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B236A3A107A for ; Thu, 28 May 2020 18:13:38 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id 64so148394pfg.8 for ; Thu, 28 May 2020 18:13:38 -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=NLrolFMai6eWb2eJ+iFDRM29B9ytwjYY7wplqmBjHp8=; b=CuwECxIXxUBBTrkXTKm9IGDXAQx1egaucHE950StQ0QLrJebTMmsZp10ZWf3A8KqhX BpG+TF7pqBTTABCGtNJ7L9UaRPowtNRsO69Bd5aIB2regkPAaAe67Ir4WavWf47trVmq pntTBVg6+w576lqSwy2hqiO0aA35BRRsUbaJIIKdfi7WbG2lNxOnILzQI3Kt6KPn3Lvt A3ywH/AEr6oosAaW+lzw/D19QlkaWUHK0ZIPQj1UkyUYwrV1fbuvoHZl0q5dl+/9KfHH 2SiaVC1SRB+vOJRtnBzaByE4wJJzanqYcOSuCHLhJmYEBlFh5TPZiu2/9rWyZ3pEUJkP gNQw==
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=NLrolFMai6eWb2eJ+iFDRM29B9ytwjYY7wplqmBjHp8=; b=PGdLdSgUVBI47QrMmdeC0w+8ThswZmCXof1vQQORW5xdTN7VF8mplM1ExrALreXI0B Cla4YICnSk7I/EM6frYb5KNpwcJJfhsxTIB/K2NuzBxGUXwZja/yKpv20RSO0bAPeNxF J3s50HrrGY2zon4nFkqfXqVu5u18KKojrgO3yuQpOH3OtlDdjcwH/X6KRp5ANBA50gzT fTGh1WTRbkKz0cZg7uLxqVrSxlAtNvcbtCXlEuzzgjxU6xWh65wC7aPLx4fay4htYBIi rHDUDPPbbA3EnG8YvpM59GmhjPNWYa2I0+6d9oDGuavBYftaHtApjg8J7904pKrvzEDU +7aw==
X-Gm-Message-State: AOAM530CpXul38ZPwlTC8dy17TgOqS+3+Ol3rZwtdlLrTSubNkhvnezg /dXQ0opWkTCkZH7W1OUOzV0QKgD4Z0E=
X-Google-Smtp-Source: ABdhPJw8IWTC4ZVn1+JTk6YjjeCFyU3bUgIiDrNH9hwBhxG44DIBYYxqDVt0DSM1yGuIS2ZbTD3VLQ==
X-Received: by 2002:a63:63c6:: with SMTP id x189mr5784339pgb.36.1590714817855;  Thu, 28 May 2020 18:13:37 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id c21sm5533851pfo.131.2020.05.28.18.13.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2020 18:13:37 -0700 (PDT)
To: Mark Nottingham , Russ Housley , Colin Perkins 
Cc: rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net>
From: Brian E Carpenter 
Message-ID: <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com>
Date: Fri, 29 May 2020 13:13:33 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <065D5755-1C98-458B-993A-700228EE2259@mnot.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 01:13:40 -0000

On 29-May-20 11:58, Mark Nottingham wrote:
>=20
>> On 29 May 2020, at 6:47 am, Russ Housley  wrote:=

>>
>>> I do not believe allowing amendments to published RFCs is desirable (=
with the possible exception: to fix bugs in the XML schema, provided ther=
e=E2=80=99s no content change).
>>
>> +1
>=20
> Could you give us some indication as to why you feel this way -- e.g., =
what would be impacted? I fear we're falling into the habit of just stati=
ng our preferences and expecting Eliot to tally the votes...

I'd add a specific question to that: does the objection extend to a simpl=
e versioning mechanism, such as RFC8200.1 for RFC8200 plus accumulated er=
rata? (Assuming that RFC8200 is also kept around, of course.)

     Brian
=20



From nobody Thu May 28 19:15: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 D00C43A0062 for ; Thu, 28 May 2020 19:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNPpWPoWcJIv for ; Thu, 28 May 2020 19:15:16 -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 A3C913A0061 for ; Thu, 28 May 2020 19:15:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1F662BE2C; Fri, 29 May 2020 03:15:11 +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 qmJlHRaZ-Rde; Fri, 29 May 2020 03:15:09 +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 2FD02BE24; Fri, 29 May 2020 03:15:09 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1590718509; bh=KcjUNUz/6h5Kak5MGpCDGa9TsjKk79+TWdNoSUR+KYc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=D37oeue2U0ybVMoGEJ/gfl/YB/3JSHzksuVVFeqC4f7Wwon2egJYEl9D5hpu3TEjB oJlnbzNlv+K1ckc+1wABssjn8J7SiAt5B65W02TMUJgWU978i+uQ8U3vJlZNiUJEM1 7trDolQi7fMJonDqTpcqvUmcDxrJFbKF5+2i7YM8=
To: Brian E Carpenter , Mark Nottingham , Russ Housley , Colin Perkins 
Cc: rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.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: <66a79d61-bfff-e825-f2f1-a7f3f44fefd9@cs.tcd.ie>
Date: Fri, 29 May 2020 03:15:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dM8THygyMSMvhzmKf0Y3oNbHHCMsVB40p"
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 02:15:19 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--dM8THygyMSMvhzmKf0Y3oNbHHCMsVB40p
Content-Type: multipart/mixed; boundary="Hc5F2ril48KcVTB8OLtXrqAvOVQ42Umgr";
 protected-headers="v1"
From: Stephen Farrell 
To: Brian E Carpenter ,
 Mark Nottingham , Russ Housley ,
 Colin Perkins 
Cc: rfced-future@iab.org
Message-ID: <66a79d61-bfff-e825-f2f1-a7f3f44fefd9@cs.tcd.ie>
Subject: Re: [Rfced-future] On the question of a living series
References: 
 <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org>
 <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com>
 <065D5755-1C98-458B-993A-700228EE2259@mnot.net>
 <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com>
In-Reply-To: <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com>

--Hc5F2ril48KcVTB8OLtXrqAvOVQ42Umgr
Content-Type: multipart/mixed;
 boundary="------------093FAD5C7B5F398F73C9C1A2"
Content-Language: en-US

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


Hiya,

Colin will answer himself when he does, but it strikes me
that maybe the question exposes a bit of a gap in what we
each are considering...

On 29/05/2020 02:13, Brian E Carpenter wrote:
> On 29-May-20 11:58, Mark Nottingham wrote:
>>=20
>>> On 29 May 2020, at 6:47 am, Russ Housley 
>>> wrote:
>>>=20
>>>> I do not believe allowing amendments to published RFCs is
>>>> desirable (with the possible exception: to fix bugs in the XML
>>>> schema, provided there=E2=80=99s no content change).
>>>=20
>>> +1
>>=20
>> Could you give us some indication as to why you feel this way --
>> e.g., what would be impacted? I fear we're falling into the habit
>> of just stating our preferences and expecting Eliot to tally the
>> votes...
>=20
> I'd add a specific question to that: does the objection extend to a
> simple versioning mechanism, such as RFC8200.1 for RFC8200 plus
> accumulated errata? (Assuming that RFC8200 is also kept around, of
> course.)

My personal impression is that the vast majority of
correctly approved errata are pedantic and no more.
Given that's what I think, I've not been motivated to
check it out in detail;-)

So I don't think analysis of the living-document-RFC
vs. immutable-text-RFC via facts-about-errata is that
useful. I reckon the "where's the DNS spec" question
is more likely to lead us in a useful direction (should
one exist, and I'm not yet convinced one does).

Cheers,
S.


--------------093FAD5C7B5F398F73C9C1A2
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-----

--------------093FAD5C7B5F398F73C9C1A2--

--Hc5F2ril48KcVTB8OLtXrqAvOVQ42Umgr--

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

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

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7QcCwACgkQWrL68XsX
K+p3/RAAtntLrNHjRubwI/YbTfufbyXrc2jxJQSTlUFS1LEDYLko72pSbCg3S8ny
Ch+zlDe935RV5Zdi8GdwyXxSplxLQYSyyGuTW3iqUcS1L+RtlkFxwD3Q1MKMkhz6
AqfctDvt/PHJn7sEH7ZMUDo+MzyeOB0KxdLBt1k7hojhHgvIryZsdZGN+GSR6q9d
VTZfUQilTkL5kHc0vAHjhNh/SN0cpSDPMxevyxXb/n38vuR3x9Sm71d2hCg0JIQP
dttWSQQVV6VjwJEnIqv90EXGEnaq8oJDSEAAfH4AWcJb/UahagkIKvnLY8RiS04x
H+D7/KQy8mzM8DdvKNEaiTMBcAvXosudeBY1m8BFfzfVaisfQrVxHder/2+q76wB
4c7LWouljf7nGcC9PkUzasrSj4BM7XBnwcomOx1BlQJORredIK+xiDN/beTs4k7G
XYS8LQMZOX7nmKTQ8FunF+SzMhgqa2I/z/SmgwXqq1BsDl5rKRQF+j5z6iYm1gkm
W+Wwuru9OMJtSsNmDeUlihNvPlXwq1dSSKEDCdxge+KtpX7BRq21uuIGDsT9d64O
2PBRpQsgqbbOe29NYErL5h58yHUQ/n+PybJB5aYU/7nag+NPRzRBU8Ltqt64Yy1/
6/oxU1RMdgY+nUIABnvdm5LU5jMPjwsH7lUXCfRvrtT0XFBpUl8=
=0VGy
-----END PGP SIGNATURE-----

--dM8THygyMSMvhzmKf0Y3oNbHHCMsVB40p--


From nobody Thu May 28 19:31: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 08A653A040F for ; Thu, 28 May 2020 19:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=RMqZGAfw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ldWIGenT
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQk1ISujxssY for ; Thu, 28 May 2020 19:31:31 -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 1D77C3A03F2 for ; Thu, 28 May 2020 19:31:31 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 26E21390; Thu, 28 May 2020 22:31:30 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 28 May 2020 22:31:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=i tKCnUo0uSbazUjYjtM8odA8d08idvVnO4RjWRTN6bA=; b=RMqZGAfw1zc8C8yqK f0+55D1FfW+8OaeS0CA2uHQ00gXmrp8YO4RICOMP/Uy+z5QqAIG9o6HYF1p3kTUT xHedouC/YVNGGRzIYi/stwNbHKr4JtsWsz8ECpH1Vm1ENXYBl4LoVhGnseyh2M3Q Ka+k6lKbXbGRPcKJnNiUptuN58s0kbIxPMCaWFxPo0LoQ/5Q7UOX9DZyVdhqSEbi Fb5N5sXaVWDUPA1TCBIzaYnwf8IOXvwtDbEs7lJby0IkcZQLzq0gdrss1P/rX4/s 7NUFxURe0m2QzZTBty5JdkUxLNAp89ftuiIWWBp4iCt5M24LlGIwpHJd31g1cz8h NUFOQ==
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=fm2; bh=itKCnUo0uSbazUjYjtM8odA8d08idvVnO4RjWRTN6 bA=; b=ldWIGenTo3iShGKicbPXtofhE49A/ZFRrf6kKcXzH7EolFZhC/6Kk+bxL Xhyg184tTvt4Ckv65bymicT39ria3xk2QhUWzcfo52EPSXBPnb9DyFLpmL/+0C7c 2Vs4K9Wzfk4cTEwrzzmWlxiDOTZktj7Ep3mWDTmqB+f7LO/qHmj9KD+1mYzBKCve AghZyO2WXohHeBPnS6SiiNWL2zj6Zi0q0hTS65M2ketlcbBZ+73rXOZNCAMpl5mL sfwO4iOUubeGxMKaxDMftiDPzT18A/zhOcTokIOfoX+qCzVP97xB5zKXSXJA//pq Jk77SvXoWPSLk53Ad8/5SMTsZ4YrA==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvjedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpedttddutdevudefveefudeuvedvheetueeigeevvedvjeefvdejgfejudffkeff geenucffohhmrghinhephhhtthhpfihgrdhorhhgpdhmnhhothdrnhgvthenucfkphepud duledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 984C0328005D; Thu, 28 May 2020 22:31:26 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham 
In-Reply-To: <66a79d61-bfff-e825-f2f1-a7f3f44fefd9@cs.tcd.ie>
Date: Fri, 29 May 2020 12:31:24 +1000
Cc: Brian E Carpenter , Russ Housley , Colin Perkins , rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com> <66a79d61-bfff-e825-f2f1-a7f3f44fefd9@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 02:31:33 -0000

Hi Stephen,

> On 29 May 2020, at 12:15 pm, Stephen Farrell =
 wrote:
>=20
> So I don't think analysis of the living-document-RFC
> vs. immutable-text-RFC via facts-about-errata is that
> useful. I reckon the "where's the DNS spec" question
> is more likely to lead us in a useful direction (should
> one exist, and I'm not yet convinced one does).

Personally, that's my interest as well (s/DNS/HTTP/ of course).

E.g., people still widely refer to RFC2616 as the authoritative =
reference for HTTP, even though we obsoleted it in 2014, and have been =
working on something to obsolete that more recently.

The best we can do is to summarise the currently in-effect specs, like =
this:
  https://httpwg.org/specs/
... but that doesn't have anything close to the mindshare of an RFC =
number.

This is why I suggested expanding the idea of an RFC number to include =
tokens to identify specifications at this level -- i.e., not revisions, =
but conceptual documents. So we could have an RFC-HTTP that identified =
the core spec, and an RFC-HTTP11 to identify the in-force document for =
that version of the wire protocol. Currently, people conflate document =
versioning with protocol versioning, and that's problematic. The hope =
here would be that the RFC prefix would be familiar enough to let these =
identifiers catch on (unlike STD and the like), and moving away from a =
linear, numeric identifier series would help people find the right =
documents.

That's just an idea, and I'm not fixated on that particular solution; =
the problem is what deserves our attention.

Cheers,

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


From nobody Thu May 28 19:48: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 DA4A73A0747 for ; Thu, 28 May 2020 19:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlCxgNKXeX4R for ; Thu, 28 May 2020 19:48:25 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA433A0743 for ; Thu, 28 May 2020 19:48:24 -0700 (PDT)
Received: (qmail 25902 invoked from network); 29 May 2020 02:48: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:mime-version:content-type:content-transfer-encoding; s=6528.5ed077f6.k2005; bh=IvVnuBtP0l2QwPwj9BA1LSpj49ZbHg2NEIcWInc9v/c=; b=L1Z31uIhaB+hq+I6EyhXzRU4dlqBjAymmADsKsXX6IBBcU5bK/hU0/rOFc4iNpXxdQiTadcMIy5d+rtUeVXcgPECzWr+FNXKYtnsOh/2nCu5ern+tzMJJsesVG1XFP9HtC0IWDt/kA+eYd7tZpZ69PVTmLaTmhfL+tGJFGQEzW6XQ9ZUdhMQc0cresJvObAMU9I13cHUdkkvXt48XxGgdI2pudfeV7pEOcTWkINTQUBUpfda50Caj2o8x9hnrcoz
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 29 May 2020 02:48:21 -0000
Received: by ary.qy (Postfix, from userid 501) id 9E00D19D0AF0; Thu, 28 May 2020 22:48:20 -0400 (EDT)
Date: 28 May 2020 22:48:20 -0400
Message-Id: <20200529024821.9E00D19D0AF0@ary.qy>
From: "John Levine" 
To: rfced-future@iab.org
Cc: stephen.farrell@cs.tcd.ie
In-Reply-To: <66a79d61-bfff-e825-f2f1-a7f3f44fefd9@cs.tcd.ie>
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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 02:48:28 -0000

In article <66a79d61-bfff-e825-f2f1-a7f3f44fefd9@cs.tcd.ie> you write:
>> I'd add a specific question to that: does the objection extend to a
>> simple versioning mechanism, such as RFC8200.1 for RFC8200 plus
>> accumulated errata? (Assuming that RFC8200 is also kept around, of
>> course.)
>
>My personal impression is that the vast majority of
>correctly approved errata are pedantic and no more.
>Given that's what I think, I've not been motivated to
>check it out in detail;-)

Having watched the reports go by for the past four months I agree that
most of them are nits but there are some that correct significant
technical or editorial errors in the document, to the extent that if
you do what the RFC says without also consulting the errata, you'll
get it wrong.

R's,
JOhn


From nobody Thu May 28 20:15: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 D61213A09FD for ; Thu, 28 May 2020 20:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.077
X-Spam-Level: 
X-Spam-Status: No, score=-1.077 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, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 oAlpFHNiJDYU for ; Thu, 28 May 2020 20:15: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 333D63A0A6E for ; Thu, 28 May 2020 20:15:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49Y8nt06nzz1p4TC for ; Thu, 28 May 2020 20:15:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590722114; bh=FwYU1iofc3z8RMbbmT375Q9uIcNQ1r5X4ZdPea0zc30=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=M/GHQuUrt2LqdXS4UOFLIkiurTH55WTgqFOl6nZtXxzcUF/GjB2MaNsFDLnQyEQYe 1WU1ToLHLPmBPz8jLtpWUwBaLSWK61+fk6HU+t9tD5Rs9/4/bqwjRq1DAmuOn1IKA6 6160pZf+rqMkGSLiSARsTNk1/FaDWxrdpUHMeFG0=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [IPv6:2600:380:4012:c3a0:7d38:8b1:18f6:fb54] (unknown [IPv6:2600:380:4012:c3a0:7d38:8b1:18f6:fb54]) (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 49Y8ns3dvjz1p0RD for ; Thu, 28 May 2020 20:15:13 -0700 (PDT)
Cc: rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com>
From: "Joel M. Halpern" 
Message-ID: 
Date: Thu, 28 May 2020 23:15:12 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 03:15:20 -0000

I am uncomfortable with any process where the content of the document 
with a given explicit and agreed name can change.
I don't care whether the new name is a new RFC number, or the same 
number with some modieirs, or some other new name.
I can even live with the IEEE approach where there is a base number and 
a date.  And then insistence that any formal reference has to actually 
use the date.

What I do not want is a situation where people expect "BGP" to be a 
well-defined standard which you can name that way.  (Yes, people will do 
so in conversation.  And in marketing materials.)  But as a vendor, I 
expect to ahve to be clear about exactly what I implement.  And I expect 
my customers to ahve to be clear about what they want me to support. 
Saying "supprot MPLS", or even "support SR-MPLS" does not work.

As a lesser but important matter, I do not want revision of a 
specification conflated with the problem of determining what all the 
related specs are.  Sorry, no, we can not produce a standard for 
Internet EMAIL.  I would like to see us tackle as a separate matter how 
the heck give folks that information.  But it is NOT the same problem.

And I would suggest that at least in the portions of the IETF I live in 
(primarily internet and routing) changing the way we number revisions is 
not likely to change the pace of them.  8200 took a long time because 
there were a lot of hard debates as to what it should say, not because 
it had to be a new RFC.

And the only part of this that is relevant to rfced-future is the 
question of who should be driving this.  In my personal reading, these 
topics are IETF topics.  One would hope that the RSE (or whatever we 
call the directional leadership of the RFC series) would be involved. 
But until there is IEtF rough consensus and IESG support for changes, it 
is not going to happen.

Apologies for the length of this note.  I am apparently too tired to 
write it more concisely.

Yours,
Joel

On 5/28/2020 9:13 PM, Brian E Carpenter wrote:
> On 29-May-20 11:58, Mark Nottingham wrote:
>>
>>> On 29 May 2020, at 6:47 am, Russ Housley  wrote:
>>>
>>>> I do not believe allowing amendments to published RFCs is desirable (with the possible exception: to fix bugs in the XML schema, provided there’s no content change).
>>>
>>> +1
>>
>> Could you give us some indication as to why you feel this way -- e.g., what would be impacted? I fear we're falling into the habit of just stating our preferences and expecting Eliot to tally the votes...
> 
> I'd add a specific question to that: does the objection extend to a simple versioning mechanism, such as RFC8200.1 for RFC8200 plus accumulated errata? (Assuming that RFC8200 is also kept around, of course.)
> 
>       Brian
>   
> 
> 


From nobody Thu May 28 20:45: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 9A00A3A0A3B for ; Thu, 28 May 2020 20:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level: 
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMapZ9D_PloO for ; Thu, 28 May 2020 20:45:41 -0700 (PDT)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE363A0A29 for ; Thu, 28 May 2020 20:45:41 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id 131so547291pfv.13 for ; Thu, 28 May 2020 20:45:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=ajwkiJUNVmL7cLAAK0wZLu9uZmYlh6kcID5tsK8UGP8=; b=AoNw47xMBnJ0yLwtuiCeWpQFxZ5wb+OWwuEnTD2ytZjXLS2WUBA3/Cc6pQ+0CfOK4T D6vNnrKicwqbFP18hg/iQlNAGrKYDRTP2UpzmQBbtjKhgpqn6i5ozizDPu3uOzFqSaIq kS32m1lxETNKAJdjdNzHs2ShzkqOBi2FIlX5M3lYlJ3l2FbkPnGLsDe8yToXZyywLsoT Nc28YpOmIo5zkMtMhZAy3TY/EQggXcHAYfV2WYfcIRD/OO0H/wMLcD2Ub8YlheWp9jaW L/t1MRTBMSuK3EJLkJY44dTLCdw02y6LrOWGTclFI9pnkjXibl5T4y7Xci1vKGp4go7f 4Rdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=ajwkiJUNVmL7cLAAK0wZLu9uZmYlh6kcID5tsK8UGP8=; b=mbM24kGoNE7BjOEbCHh3ATpoRT75X1iCgwUG2X9/AVKAgOGUundf8s3zAMvt65C9zU A5GAVVJ9I4DpKvxdgcKvUZFHrYCs8NEqDs+fJ5CZP9uKkFx7YTs5iby0c5YcI+SPY269 C7UxCNx7/+u4eTlE6cDRY0uhFSceOvTUUZrVyMxvUNEx598Z62ofpSoeBErT9xdC/daD zykYj6sIgRrRvcp+VWRsNcXoSnWpBmTDxzCWN2gxGEBk8bBZEtzuGLJ3sUoWfeZD/gkK Yrw/ULigYZha/lByCVVerX6ucqvdGPshDc6RtpsznEXlIr8IYR1TmB13ry4sB3R1gCXG tHLw==
X-Gm-Message-State: AOAM533lpZgSUQF9CUcvmIQFjEQyugvaKMQED/WVGin0r3e2gziFUbW+ ZKv5fDl42OkWhQ4ZLLU7or+o8kfA
X-Google-Smtp-Source: ABdhPJxTUIsaRoedS9HvBqlaPiBpz3nqdzo2iAxpbBfffbWxB+u9fg44gz/Sb/wfc2lGKbFr6i6SGA==
X-Received: by 2002:aa7:8490:: with SMTP id u16mr6545895pfn.218.1590723940768;  Thu, 28 May 2020 20:45:40 -0700 (PDT)
Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id v13sm4510494pff.27.2020.05.28.20.45.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2020 20:45:39 -0700 (PDT)
Sender: Larry Masinter 
From: Larry Masinter 
X-Google-Original-From: "Larry Masinter" 
To: "'Mark Nottingham'" , "'Russ Housley'" , "'Colin Perkins'" 
Cc: 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net>
In-Reply-To: <065D5755-1C98-458B-993A-700228EE2259@mnot.net>
Date: Thu, 28 May 2020 20:45:37 -0700
Message-ID: <006901d6356b$9e707030$db515090$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQEoY6D0a0QPnIjDHFMaI714e+UOKACOlR5aAR6lbQMA7vrt3KoFDclA
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 03:45:43 -0000

Here's my reasoning:

The RFC series is known for being an archival format that never changes.
This is what its "brand" means, that  it serves as a unique identifier for
an explicit piece of intellectual  priority. 

there were canonical and derivative forms (TXT and PDF) 
before the format change and (XML and TXT,PDF,HTML)
after the format change, but it was done carefully enough
to not break too many things because the immutability
meant it didn't matter that the TXT was no longer canonical.

The format change damaged the brand some, but it is still
valuable.  
 
I don't think trying to "fix" RFCs is worth it because it
would damage the brand and would also break some
workflows

Establishing a new brand  for revisable, modifiable, 
easy to navigate series is actually much easier than
changing an old brand. Someone actually has to write
"DNS made EZ". Maybe someone could subsidize it.
It would make sense to make it a web site that
Linked to RFCs or applied errata as soon as the
errata was approved.

As far as old workflows, there used to be lots of
processes for replicating, distributing, analyzing RFCs
and I-Ds that assumed that their cache expiry
was infinite... you could do a fast rsync.

Changing this isn't worth the grief of finding those
assumptions in obsolete software and fixing them.





From nobody Thu May 28 22:43: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 A5B493A0888 for ; Thu, 28 May 2020 22:43:09 -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 q7obD7l8BU1P for ; Thu, 28 May 2020 22:43:08 -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 363923A0887 for ; Thu, 28 May 2020 22:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2749; q=dns/txt; s=iport; t=1590730988; x=1591940588; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ScO7SetX4Afhzq6iwZDYZLp93JYw0uKsL3EiopTxpGY=; b=YO0nGtP3hRV1JoSYHbOIhA9zQBuWX7Kp/1W1RXSiVX4QEvxT4OFxk1bs 6lYtrxEkKsbwEs0cCypYoFEZ0dAjvNKwjuea6zupuGoCr2WhkdwbY+yFJ L74wRTBdhbVoBg6FslSfJUB9ETu4yMqQzl13uaS2MmES2vInKTukuplBm A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDln9Be/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoNsASASLI0miAqJfYlkiBELAQEBDAEBLwQBAYR?= =?us-ascii?q?EAoIcJTgTAgMBAQsBAQUBAQECAQYEbYVlhXIBAQEBAgF5BQsLBAETLiE2BhO?= =?us-ascii?q?DJoJMAw4grxJ0gTSFUYJ3DYIigTiMX4IAgTgcgh8uPoIehXeCLQSyc0yCXoJ?= =?us-ascii?q?6kRGEXx6QT41BnR2NZINJAgQGBQIVgWoigVYzGggbFWUBgj4+EhkNnwo/AzA?= =?us-ascii?q?CNQIGCAEBAwmNdAEB?=
X-IronPort-AV: E=Sophos; i="5.73,447,1583193600"; d="scan'208,217"; a="26554725"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2020 05:43:04 +0000
Received: from [10.61.168.179] ([10.61.168.179]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04T5h3sO023947 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2020 05:43:04 GMT
From: Eliot Lear 
Message-Id: <66EF9358-C4FC-4E1E-ACBE-EAE3A28120F1@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A5605D47-AE7E-4D91-A4CF-9CCD3B1697F5"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 29 May 2020 07:43:03 +0200
In-Reply-To: <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com>
Cc: Mark Nottingham , Russ Housley , Colin Perkins , rfced-future@iab.org
To: Brian E Carpenter 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.168.179, [10.61.168.179]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 05:43:10 -0000

--Apple-Mail=_A5605D47-AE7E-4D91-A4CF-9CCD3B1697F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 29 May 2020, at 03:13, Brian E Carpenter =
 wrote:
>>>=20
>>> +1
>>=20
>> Could you give us some indication as to why you feel this way -- =
e.g., what would be impacted? I fear we're falling into the habit of =
just stating our preferences and expecting Eliot to tally the votes...
>=20
> I'd add a specific question to that: does the objection extend to a =
simple versioning mechanism, such as RFC8200.1 for RFC8200 plus =
accumulated errata? (Assuming that RFC8200 is also kept around, of =
course.)
>=20

I would ask that the question only be answered if it can be related to =
our task here.  That is- who should decide who gets to monkey with the =
series format?  If you can answer that one question, that is the right =
level for our conversation.

Eliot


--Apple-Mail=_A5605D47-AE7E-4D91-A4CF-9CCD3B1697F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On 29 May 2020, at 03:13, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

+1

Could you give us some indication =
as to why you feel this way -- e.g., what would be impacted? I fear =
we're falling into the habit of just stating our preferences and =
expecting Eliot to tally the votes...

I'd add a specific question to that: does the objection =
extend to a simple versioning mechanism, such as RFC8200.1 for RFC8200 =
plus accumulated errata? (Assuming that RFC8200 is also kept around, of =
course.)


I would ask that the question only be answered if it can be related to our task here.  That =
is- who should decide who gets to monkey with the series format? =
 If you can answer that one question, that is the right level for =
our conversation.

Eliot

=

--Apple-Mail=_A5605D47-AE7E-4D91-A4CF-9CCD3B1697F5--


From nobody Thu May 28 22:51: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 6A86E3A08A9 for ; Thu, 28 May 2020 22:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1fO7-0CmBHe for ; Thu, 28 May 2020 22:51:01 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 A231D3A08A3 for ; Thu, 28 May 2020 22:51:01 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id t4so864166vsq.0 for ; Thu, 28 May 2020 22:51: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=UonM/aIsnMAUpyDhdCP0+S1/Ulvhn7KOpiRvbip9z7g=; b=FRH7p/ErF+ymmlQegx8J9DGFBXFPGwhSsi9QOXYLY7DOYvnYuK7MupxaR+nO81Gs/Y WKMeG+4Tk6JmB1DMc19uIGYMP4d3c8NOwmvzj9QgTlvSHC58LxBDO8GyVru5mNcwDq0q irIUSViM3fp8as7yYSUkoy/0tzSNAcgK9E5kID4tubCeKCfLcUPLmiSCxrqrJWVoc8s/ AvHktpquavTlHvpkcTtTnmWtGq0+D++l/9WmKnz0S3DxPH5RlJE4V9159K+HGqx9ZEig QPYGctginA5UkhFTCLWzQlTMv5QtQeEuDGIjrmhPxa4rcbUCi5cwC/uBg4EY/tKfiC/2 FiWg==
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=UonM/aIsnMAUpyDhdCP0+S1/Ulvhn7KOpiRvbip9z7g=; b=JTviu/BM3+zhnwZu6cw+I2vvFGnagxTrnjsiAbgy2cWqPxUJacYoD7mPoR0OJFozyD u9bXyqHYbj36RnLqiliWR91TxGYDpX/hdxVgJyoe/hfLAFibuTgttqwVlgFIyeLTfdhe ZxVkPPJpsQA+7J4jgsExmtrl8nnTrtrQ6yb07RkB2gtwRu+CVtO1sSGqfCx/M5HF1AeV PHrlDR1wcrkbQsY63g8KtH/XoP7hTdaZhnMAzF6ie0ti7guiKcOKTWk2V+uAo7DOzs5p jdXDUI9Q+Ddwk8v26wsSN+s6x7/d6jmTdOZTsofZxtDccPc6yyccrY/622Nh9GjwmYR6 ipJA==
X-Gm-Message-State: AOAM533G+GHOPtJ+UnWz3gdzfnuss3QwnxC1nRyWcKGiwINLZkNSt0kl ocpXOH5slq0K51Snn0QEeV1oXas8lq0NPoI4+ULQNzdA2VM=
X-Google-Smtp-Source: ABdhPJweTYD/CdGgnaetfGo9vflU1jZkRBgHzJl31kMpiRcqYDzOJSxDjbODrjqm4unDKLHUOwRp4QNBpwI1sXQ4G9M=
X-Received: by 2002:a67:cf08:: with SMTP id y8mr4950775vsl.227.1590731459153;  Thu, 28 May 2020 22:50:59 -0700 (PDT)
MIME-Version: 1.0
From: Nevil Brownlee 
Date: Fri, 29 May 2020 17:50:32 +1200
Message-ID: 
To: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000008e505d05a6c30788"
Archived-At: 
Subject: [Rfced-future] RSE (and RPC) Duties
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 29 May 2020 05:51:03 -0000

--0000000000008e505d05a6c30788
Content-Type: text/plain; charset="UTF-8"

RFCs have an important property: when you read one, it is immediately
obvious that it is an RFC.  That identity is defined by the RFC Style
Guide. The RFC Style guide is at https://www.rfc-editor.org/styleguide/

Authors (via Stream Managers) submit Internet Drafts to the RFC Editor. One
of the RFC Editors will copy-edit each incoming Draft, so that the edited
version conforms to the RFC Style Guide.

>From time to time the Editors may find some text that doesn't quite fit
with the Style Guide, and may suggest changes to the Guide.  The RSE
attends weekly meetings with the Editors, suggestions for such changes are
discussed at those meetings; those that are agreed on are incorporated into
the Guide.

Therefore, one of the RSE's duties is to maintain the identity of the RFCs.

Another RSE duty is to handle suggestions for changes to the RFC Series.
Any IETF participant (we don't have 'members'!) can, of course, send such a
suggestion to the RSE.  However, right now we don't have a well-defined way
in which such change proposals can be discussed until either rough
consensus is reached, or the change is rejected.  Establishing a group in
which such discussions can be held is one of the goals of this (the
rfced-future) Program.

Cheers, Nevil

-----------------------------------
Nevil Brownlee, Taupo, NZ

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


RFCs have an important property: when you read one, i=
t is immediately obvious that it is an RFC.=C2=A0 That identity is defined =
by the RFC Style Guide. The RFC Style guide is at https://www.rfc-editor.org/styleguide/
Authors (via Stream Managers) submit Internet Drafts to the RFC Editor. On=
e of the RFC Editors will copy-edit each incoming Draft, so that the edited=
 version conforms to the RFC Style Guide.

From time to time the Edit=
ors may find some text that doesn't quite fit with the Style Guide, and=
 may suggest changes to the Guide.=C2=A0 The RSE attends weekly meetings wi=
th the Editors, suggestions for such changes are discussed at those meeting=
s; those that are agreed on are incorporated into the Guide.

Therefo=
re, one of the RSE's duties is to maintain the identity of the RFCs.
Another RSE duty is to handle suggestions for changes to the RFC Serie=
s.=C2=A0 Any IETF participant (we don't have 'members'!) can, o=
f course, send such a suggestion to the RSE.=C2=A0 However, right now we do=
n't have a well-defined way in which such change proposals can be discu=
ssed until either rough
consensus is reached, or the change is rejected.=
=C2=A0 Establishing a group in which such discussions can be held is one of=
 the goals of this (the rfced-future) Program. 

=

Cheers, Nevil

-----------------------------------
Nev=
il Brownlee, Taupo, NZ


--0000000000008e505d05a6c30788--


From nobody Fri May 29 05:36: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 D8E293A07DD for ; Fri, 29 May 2020 05:36:23 -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 uLgcKjaSpWL2 for ; Fri, 29 May 2020 05:36:22 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 525903A07DB for ; Fri, 29 May 2020 05:36:22 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id a25so2421974ljp.3 for ; Fri, 29 May 2020 05:36:22 -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=9KrZkuei2HJxPdKRJSfGjxapgn5pDjfOIQAa9Xxu5gY=; b=mqamLzvQWCzC/O9p/A7+z8vY5eftrtKg1NBxxu4EkYoZz3GFhZS6A3FzbVMadjyg0K gJpA/LilB3Tf8l4zgiRp+O25OGUoxGacUHhTGzpUSzZaYjWW47x4JAsLbrLXmwD+9tNs wC6+VISEltRHHPk1uiltOr2XyEZCeMJuEXFGCVZ+D0XFgir/y4IRdV2G5gBOXqwnLNTR ABlj41VtkCPOViBtVQ4SuLZxmO6OQCrXogm2h/0oJdjMTg2h0DV1DDB39Tesh951QDrS 8XfEO8IXoX6vSjoVzfW0i+iaHo5hNLMyaDtVQrYr15fDMu/QYQrrn1zrm8VMgTNjID+C 9qpA==
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=9KrZkuei2HJxPdKRJSfGjxapgn5pDjfOIQAa9Xxu5gY=; b=lKBmFlOAl+EbwFWRV9xFj4Ql0rutz9FOkesWrMGetkiyizY8ML39xNqJvR611mk8mU PFGcxS6FGQXzL/L0shPA5su8nlJZOtmGAip7ORKpNY0bPcwP4queRyrxxlBsCJ3j9apc 4rio10SPYO5dxeynVRiFG30l3HfZeU4nCJYd+Adtzqws881Y4Fn9QCV1/tk1DRbDo7tD SZMFSf5pbmqp7X71bseCg0S6bZt6ASlt67AEgJ90XWI1HJb0t8o5IaauwlY397hnssds 00JXHlS8OfJSufntTp+QcIZxSRjx0CFCIkKBaExWgmK2uMaH5oYvKHalVdQPS7ruGwoJ yP+A==
X-Gm-Message-State: AOAM533HLpQppG8RCrvkeld59sVAEqEAcwjgJIuqmrq6QesZl0Js2m8u lXPBZkDMpmiBNqDfqLAJHbpMIHeE8vgj2GraaivVUQ==
X-Google-Smtp-Source: ABdhPJylK20XKVkvdjDQbYtc3t+iblUf6NxodEAT60B8eMa4niCl1SWpZhmI92m+Kx65fOYJcUTPXbBcSr0mZpH9tqk=
X-Received: by 2002:a2e:8897:: with SMTP id k23mr4007954lji.184.1590755780248;  Fri, 29 May 2020 05:36:20 -0700 (PDT)
MIME-Version: 1.0
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <006901d6356b$9e707030$db515090$@acm.org>
In-Reply-To: <006901d6356b$9e707030$db515090$@acm.org>
From: Eric Rescorla 
Date: Fri, 29 May 2020 05:35:44 -0700
Message-ID: 
To: Larry Masinter 
Cc: Mark Nottingham , Russ Housley ,  Colin Perkins , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="00000000000035218005a6c8b112"
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 12:36:24 -0000

--00000000000035218005a6c8b112
Content-Type: text/plain; charset="UTF-8"

On Thu, May 28, 2020 at 8:45 PM Larry Masinter  wrote:

> Here's my reasoning:
>
> The RFC series is known for being an archival format that never changes.
>
This is what its "brand" means, that  it serves as a unique identifier for
> an explicit piece of intellectual  priority.
>

Do you have any evidence that this is true outside of this fairly narrow
community? My experience is that to the extent to which people know of RFCs
they think of them as "Internet Specifications" and they don't think about
mutability at all.

-Ekr



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




=

On Thu, May 28, 2020 at 8:45 PM Larry=
 Masinter <LMM@acm.org> wrote:
=

Here's my reaso=
ning:



The RFC series is known for being an archival format that never changes.

This is what its "brand" means, that=C2=A0 it serves as a unique =
identifier for

an explicit piece of intellectual=C2=A0 priority. 
Do you have any evidence that this is true outside of this fair=
ly narrow community? My experience is that to the extent to which people kn=
ow of RFCs they think of them as "Internet Specifications" and th=
ey don't think about mutability at all.

-Ekr






--00000000000035218005a6c8b112--


From nobody Fri May 29 05:50: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 EAE353A07F7 for ; Fri, 29 May 2020 05:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO6TNsV_peIf for ; Fri, 29 May 2020 05:50:44 -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 4D0D73A07F6 for ; Fri, 29 May 2020 05:50:44 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id z18so2415359lji.12 for ; Fri, 29 May 2020 05:50: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=WKQHn2XsZ57GLF+LXbVoxxb+nprOMNGonkD+r+lNXvc=; b=tiAEZaHWF5Rq7Z4j/LeRsF3h6wQeMWuUAViHjhw0oCOfx1PsxAH5mx7IZEjLjr2ut8 pAA0w0txER3+j4B1iCkTEwPqa+LwKbbOOkEd/BDLHFV0GmaVfbjbFeI6aSk1putv7o6j UrVL0/NjT86+aUhksJFz5K0q6BSHdzzU9sl1Bbsj0ciKY2ipm+P5V8UARqBQiecD2c+W VCkt5xbbiWwHB/Kc9t76KtdLZ8UkBC1Xh9N1PFaWkfaaGe0lIcN3YvMdHRYH6PunfYyx YHvdWvoqLStwgrE0G8Di7Zfxv94pYN4Lrhvz4bk0MKdQeVAp1kYotdfJg5kVB899VCHB E80A==
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=WKQHn2XsZ57GLF+LXbVoxxb+nprOMNGonkD+r+lNXvc=; b=P7KpsxQID/CH3q4lWe9XvKyLYBJhTV/6b0A/sf6bJyrUNJ9s59bV7WHeDyZ/e2lO97 mz+eyPNYqgOiRSkDZBGFFb+hnDZRDK+hMQMSJZxIZBqHarqB3pMP42LV+RshgrxS5HB+ FRTbuftUEhBhceJlXbgtuyZnTsf5m7Sae018GxX5B0L8yV+dCKAhh8AkHmp+WfJ0oNxr +vENI8xihF0oFB/2+EH16JTAPsa3VKhagupYXSawFjq7IItFR2tOU4YTzVSPACSwePYc XF31+tlfVkdesrodBoXt85pCWO/pGTF2rcClSCFv4XSzN/spEjUyZNfIF2Nlfjg/sz3b d9Ag==
X-Gm-Message-State: AOAM533r9gbZi8D9XYaATDH+ot0vXVWDchK4QW4cnvo9ULnzX/0QVVPz 7JaePTjsPopYUT+mL/rZaGU4Wq/06uJtH9lLIJpWvQ==
X-Google-Smtp-Source: ABdhPJyEgAwoFPyex82Z4w+Z3YPalI26raro4JbxDsnnLpS4dHboKxxJYzvBvdkh9pFTZbB+gXxsBXLXD1tPN9inmjo=
X-Received: by 2002:a2e:b4e2:: with SMTP id s2mr3703562ljm.17.1590756642463; Fri, 29 May 2020 05:50:42 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Eric Rescorla 
Date: Fri, 29 May 2020 05:50:06 -0700
Message-ID: 
To: Nevil Brownlee 
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000993f9705a6c8e499"
Archived-At: 
Subject: Re: [Rfced-future] RSE (and RPC) Duties
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 29 May 2020 12:50:46 -0000

--000000000000993f9705a6c8e499
Content-Type: text/plain; charset="UTF-8"

On Thu, May 28, 2020 at 10:51 PM Nevil Brownlee 
wrote:

> RFCs have an important property: when you read one, it is immediately
> obvious that it is an RFC.  That identity is defined by the RFC Style
> Guide. The RFC Style guide is at https://www.rfc-editor.org/styleguide/
>

Leaving aside the question of whether this is an important property....

1. Many documents look much like RFCs. In particular, I-Ds look almost
   identical, with the primary notable difference being the header
   (which is actually quite easy to miss). Ironically, the clearest
   indicator may be the header that tools puts on, which isn't
   part of the RFC). So to the extent to which the formatting is
   important, it's actually kind of confusing.

2. Much of style guide concerns itself with editorial rather than
   formatting issues, which I doubt have much if anything to do
   with it being recognizable as an RFC. To the contrary, you can
   take pretty much any text at all and format it with the RFC
   processing tools and people will get what it is (to the extent
   to which they get what any RFC is). I doubt very much that
   if (for instance, as Brian suggests) wholesale threw away CMS and
   moved to British spellings -- a fairly radical change in the
   editorial style -- that it would interfere with recognition,
   however annoying people might find it.

-Ekr

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




=

On Thu, May 28, 2020 at 10:51 PM Nevi=
l Brownlee <nevil.brownlee@g=
mail.com> wrote:
RFCs have an important property: when you rea=
d one, it is immediately obvious that it is an RFC.=C2=A0 That identity is =
defined by the RFC Style Guide. The RFC Style guide is at https://www.rfc-editor.=
org/styleguide/

Leaving=
 aside the question of whether this is an important property....

1. =
Many documents look much like RFCs. In particular, I-Ds look almost
=C2=
=A0 =C2=A0identical, with the primary notable difference being the header=C2=A0 =C2=A0(which is actually quite easy to miss). Ironically, the clea=
rest
=C2=A0 =C2=A0indicator may be the header that tools puts on, which =
isn't
=C2=A0 =C2=A0part of the RFC). So to the extent to which the f=
ormatting is
=C2=A0 =C2=A0important, it's actually kind of confusing=
.
=C2=A0 =C2=A0
2. Much of style guide concerns itself with editorial=
 rather than
=C2=A0 =C2=A0formatting issues, which I doubt have much if =
anything to do
=C2=A0 =C2=A0with it being recognizable as an RFC. To the=
 contrary, you can
=C2=A0 =C2=A0take pretty much any text at all and for=
mat it with the RFC
=C2=A0 =C2=A0processing tools and people will get wh=
at it is (to the extent
=C2=A0 =C2=A0to which they get what any RFC is).=
 I doubt very much that
=C2=A0 =C2=A0if (for instance, as Brian suggests=
) wholesale threw away CMS and
=C2=A0 =C2=A0moved to British spellings -=
- a fairly radical change in the
=C2=A0 =C2=A0editorial style -- that it=
 would interfere with recognition,
=C2=A0 =C2=A0however annoying people =
might find it.

-Ekr

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


--000000000000993f9705a6c8e499--


From nobody Fri May 29 06:53: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 16C7D3A08CD for ; Fri, 29 May 2020 06:53:54 -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, 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 vSK7JyDMu18Z for ; Fri, 29 May 2020 06:53:52 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 18FAA3A08CB for ; Fri, 29 May 2020 06:53:52 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id s1so2192962qkf.9 for ; Fri, 29 May 2020 06:53:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=F2O0iVW0mk6XlU17TN6hqvCjgcEbFzuxf1n3EKNBI0s=; b=oGZKV6uitHia+UCPMJnDpLrmxrbWaYtVK3Of2KsIXFq0ei2Zi55iYrLWy4Ffno43K7 EK0GCZHbYMLhnshonaH5UoYku7SNM+pT6UMoFfKDsuGMvk5l9wA3ywlNlQD9XUcEIK91 BW7Z8tFc5bmZyr1JQ5IPV9otdfUW6eT+t6TY4Wu5PIfyuoccSqisxu3MKj3AtpJ29B93 xx7HfTw1bksw190ywQ2n2Uidlx098ct5NzXvQFzbcHiyr0ZUf2q3bM4nOMcPpGyqjDix HF6WvjCLRhyK8R+D2AnV3zOU+CjGWh+okbj3Z7nOTbBSpBr3PmkJyJ4WySv1sdL5eSie vFxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=F2O0iVW0mk6XlU17TN6hqvCjgcEbFzuxf1n3EKNBI0s=; b=Lbt8yhQFGUBElIRBtRmJaiqMLU15EyB+zQUYs0a5+OEEcGQ9KQiraTq/MJhaDbRnz5 v+ksRK6jsZXE8BI91+Y0MZJB1mg3yxZ3jY9nm8+Y69vAvKozKXrwFHGPVhn/pK/1pZpI BsLGl77/bPrS4brzJXCpwvlcfhHUHqrNL0wla1suUHDeTRqDkI5mOcSf0aIze1gSo8RQ v95Ph8/4PyvSIDFc7lW4g36PxD1JeMI99+sjfp0VEeKtK55501OqkgXCeJxZB4BoMqc2 SWfiCH3GyXzmXbuWxHWjub7cqFQru2CUui4w4hK9W+PYh2drOwGv2mWiKbwmFKrM367w hRfQ==
X-Gm-Message-State: AOAM532X0FspKdmvwrbXjWZ0gGuVHXO+Ck2i0vziQg7rMVuQiLSZYPEh XGXsC9Su2xcB0MrMUYxsXqtLpQ==
X-Google-Smtp-Source: ABdhPJwPTujEOUm0I6qS4dMyrCRpBr8XEROcRz+8ayyvwwxPUx15OX7sTUTeWQSnJtN0AMXJ46LPXQ==
X-Received: by 2002:a37:af02:: with SMTP id y2mr8066299qke.389.1590760431148;  Fri, 29 May 2020 06:53:51 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:75ec:9858:45a5:8cd6? ([2601:18b:300:36ee:75ec:9858:45a5:8cd6]) by smtp.gmail.com with ESMTPSA id q126sm168225qka.98.2020.05.29.06.53.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 May 2020 06:53:50 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon 
Mime-Version: 1.0 (1.0)
Date: Fri, 29 May 2020 09:52:38 -0400
Message-Id: <7B1AB8C4-C24A-4A1A-8C7F-96555AB4C574@fugue.com>
References: 
Cc: Stephen Farrell , rfced-future@iab.org, Russ Housley , Colin Perkins 
In-Reply-To: 
To: Mark Nottingham 
X-Mailer: iPad Mail (17F75)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 13:53:54 -0000

On May 28, 2020, at 10:31 PM, Mark Nottingham  wrote:
> E.g., people still widely refer to RFC2616 as the authoritative reference f=
or HTTP, even though we obsoleted it in 2014, and have been working on somet=
hing to obsolete that more recently.

One way to immediately improve upon this would be to have a naive reference t=
o any obsoleted document redirect to the document that replaced it, or a sum=
mary of why it=E2=80=99s obsolete if nothing replaced it. If someone wants t=
o read the obsolete document specifically, a separate link could lead to tha=
t.

IOW, no need for the content of a document with a specific name to change. I=
 don=E2=80=99t know if this is really an RSE thing, but it arguably could be=
=E2=80=94right now there is no definitive place to look for a document, and a=
ttempts to make one have failed due to usability issues (e.g., tools.ietf.or=
g much more usable than datatracker). But in principle, if we decided to sol=
ve this problem, we could, and this is exactly the sort of thing I would exp=
ect an RSE to try to do.


From nobody Fri May 29 09:00: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 D19443A0D54 for ; Fri, 29 May 2020 09:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJb65zUSjeda for ; Fri, 29 May 2020 09:00:23 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C12B3A0D5A for ; Fri, 29 May 2020 09:00:23 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id q11so4297288wrp.3 for ; Fri, 29 May 2020 09:00:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WpfqpbX9rdfwGXJ6RP/SvgD3Nw9RsXrn6EtpEqOuznc=; b=QA6e5Hj8++P4MPLKafU6yhOdyl/i7oNdFAZ7PHr5pbt0/Zv8pmkjnXLqrirGtaSxVK Qq6e36SOz+K+Hy67T/PWhBijEzMFflBFmD4BcKDJMID9uATNMUXQSYlgZW6G/5DT2FL4 A4ZhBWZzU8NoBTN2AsdZodn4dta0hcz4NtEPbEVaduxefI95rYNDoeCFTYEF1lzLwJKO Wjgv2g9kmdRcYbMO9k5WAjN5YSmMLJj8Pq9bjc1gTRvqpEt3A21/pdW64i9tkejTnNgs J4HsuWbbmFDEHxkpEZApRa8EUOHNxRxetlX/ckXtITbo/RDusEXJN3acCiaXzsLwh6OX XmZg==
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=WpfqpbX9rdfwGXJ6RP/SvgD3Nw9RsXrn6EtpEqOuznc=; b=CbyXHob7taOeLMI1+Dqb1g2F9Xm7WisGIxbcFtKunCwuWtXD3LYKBV1oPVA01gpncY f2TK2e/CGCaMC6dr2KDdY7/NiqVP5Dv4EUyDk30E3VlKUVSwMukik1gAxTG2qj/5xdYF ly6aZ7BC3rhfdUdowh1lxC/CR7q1HlT+GPr5RhEb2akJQ8ALm8uKn0+7NH938knV3hYN 0fDgaCCmmd1kBf34iXNg0Tk/aKhUwXvzEACHVPsd4DpfxLl2vGYnJ93cd2wo7bm6g45J mRs+hCCbv0vV6adq1T6F4KKWnPvO4tBKSijUmJNAqnYtqF1T56aREIt9MmIW5kI23zxc AIIw==
X-Gm-Message-State: AOAM532rzDlqif1Kw1cCljSZuGxHN/5axAgIDdmV2pWLGL9gmkUQPZLP 5z+vTSPGJrX5zL9KZS3yM2s=
X-Google-Smtp-Source: ABdhPJw1msmDolwARb8jyCyU/SCpdtk9e3gQmjcq1e86C7jcngowzbUwXkKH+qyyyIR2BjGHs95XpQ==
X-Received: by 2002:adf:e58c:: with SMTP id l12mr9475060wrm.34.1590768020530;  Fri, 29 May 2020 09:00:20 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:e8f0:836d:9c33:de2? ([2601:647:5a00:ef0b:e8f0:836d:9c33:de2]) by smtp.gmail.com with ESMTPSA id f11sm10402508wrm.13.2020.05.29.09.00.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2020 09:00:19 -0700 (PDT)
From: Bob Hinden 
Message-Id: <65313CA8-333C-4181-B0F1-78113F64A4CB@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_66F02DC6-2622-43FD-A160-767616953DCF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Fri, 29 May 2020 09:00:13 -0700
In-Reply-To: <66a79d61-bfff-e825-f2f1-a7f3f44fefd9@cs.tcd.ie>
Cc: Bob Hinden , Brian Carpenter , Mark Nottingham , Russ Housley , Colin Perkins , rfced-future@iab.org
To: Stephen Farrell 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com> <66a79d61-bfff-e825-f2f1-a7f3f44fefd9@cs.tcd.ie>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 16:00:25 -0000

--Apple-Mail=_66F02DC6-2622-43FD-A160-767616953DCF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Stephen,

>>=20
>> I'd add a specific question to that: does the objection extend to a
>> simple versioning mechanism, such as RFC8200.1 for RFC8200 plus
>> accumulated errata? (Assuming that RFC8200 is also kept around, of
>> course.)
>=20
> My personal impression is that the vast majority of
> correctly approved errata are pedantic and no more.
> Given that's what I think, I've not been motivated to
> check it out in detail;-)

It is mixed.   There are some editorial, one is a real error, and others =
are an attempt to change the text without going through the w.g. =
process.

In the case of the real error, the issue was the errata was correct in =
pointing out the error (actually there were three errata on specific =
parts of the text, but same error), but he correction was not the best =
way to resolve the problem.   The outcome was to reject the errata, file =
a new one, with a better simpler correction.

This is why I think the current errata system is broken.

Bob




--Apple-Mail=_66F02DC6-2622-43FD-A160-767616953DCF
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl7RMY0ACgkQrut0EXfn
u6jECQgAhVcs1qfGZKD0jmc/yIOWckdBRqrrtikp886zCcVhyWVxUzERHGJYtFr9
oF0znvYQJcb1pmCcthgirG96uRoQcwIBc3bmpvuMXR2PgLs4KLpjUDP2sDQZkg4K
1TUPzr7wrSqoSOvIjUvOjmUYrZbYS4kcajU9aiaywGLBUVs1I5XpDPKXJEZF+8bG
fTnvxNMe9eInX/XOrfml0qtcqNdkKfs07WoVaEtK1aEpJVSbBzKiMYRbwSGuc3HT
C6G1FjkmPL+CnXH15GFGDShEPq9C9WHldeqbjG4epgNMdN9Pmt0H8Bl00JB9jZuJ
3ydtDIDt69Fc2+tl5YcK0Zi7c30U0A==
=NeH3
-----END PGP SIGNATURE-----

--Apple-Mail=_66F02DC6-2622-43FD-A160-767616953DCF--


From nobody Fri May 29 09:03:15 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9513A0D65 for ; Fri, 29 May 2020 09:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJFL52fo613M for ; Fri, 29 May 2020 09:03:12 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 A49FF3A0D67 for ; Fri, 29 May 2020 09:03:12 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id r9so3974082wmh.2 for ; Fri, 29 May 2020 09:03:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/1cZHBWQg5+e2cBBglT/WLmgQK6BMbKAfK3GAHMsF1o=; b=Y1JpV9YJ9uQ/MhZH7Y7+O5+miWqbHtUdPvV7Mec35MQhkELfOWof5ntsJHt+j+ab7F +5gTpxvb2lO0auYn9paYqr/BTI6FWrfaUKP2qXjXygtwoC1QjyFxzO2KjPMEe3G1ys5f NX1itF4/VglmnuEULq+x37lubxPbxTNL93gh5aBBaRBsgpYQ5eWQt1zVIcekR8YAz0ZC iZ2lHTD1WoGzZMINqn+O+kz/W0Ns9MWob4OOIhUXfIYTc0//lg2OhviHj5jiJ/0zSVGM ftxp8xcG4IyOX9pXbM9hIH6ILV3rSElYicH4MAPDqN2fRnUUdz1EH9nsmaRy3RLJuI0S 1UVg==
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=/1cZHBWQg5+e2cBBglT/WLmgQK6BMbKAfK3GAHMsF1o=; b=rifm+KJIzCJRFGxdmjn0DRxYcVoTldvM6NjHJmn+XRd9QbjxP8o+kRiygdXJv1N2aw wI1ZZDnPciN5CRwgn+zlhNLPXUq6W12Exyb6M/8TI5LFpjabfp6ogU2ITfKWvn/M0Uqe Y1B4BPVoaUugstyfHJk0B3qz2q8W8YM8PmnAjVuIRCQH4dpH33+bwffS2/nNeYt04N3Z tRg6hn1RTY0kQZArAsWdSkKRswvrxBncm7kgjuADdOOLlwwHKg3Rcu2Et+0iWE8+dt/S TGRwpKCxy+ZRITU9GIpj1Qk/tJKqbqhkCEmg/asxe8u9rCiddUOqPAukA9Yyj8EFZbLO WDuw==
X-Gm-Message-State: AOAM530lbSzopk5yWirZcLXdFLe1kxLdigFG5x89nOqTb9/V8p5N8doS lrZZf0nLs+WSGzG1ddi9250=
X-Google-Smtp-Source: ABdhPJxzxdrmxMO3DOayHHMLYUZLka1VjL28Yxr0pXKnnRSnI6z2SbzeDrhkPtROqhh/XMZf367k2g==
X-Received: by 2002:a7b:ce88:: with SMTP id q8mr2890089wmj.176.1590768189550;  Fri, 29 May 2020 09:03:09 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:e8f0:836d:9c33:de2? ([2601:647:5a00:ef0b:e8f0:836d:9c33:de2]) by smtp.gmail.com with ESMTPSA id f15sm837055wmb.26.2020.05.29.09.03.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2020 09:03:08 -0700 (PDT)
From: Bob Hinden 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_663FBF04-7730-4A62-A4BC-D077DAA34EA8"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Fri, 29 May 2020 09:03:04 -0700
In-Reply-To: 
Cc: Bob Hinden , Larry Masinter , rfced-future@iab.org, Mark Nottingham , Russ Housley , Colin Perkins 
To: Eric Rescorla 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <006901d6356b$9e707030$db515090$@acm.org> 
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 16:03:14 -0000

--Apple-Mail=_663FBF04-7730-4A62-A4BC-D077DAA34EA8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Eric,

> On May 29, 2020, at 5:35 AM, Eric Rescorla  wrote:
>=20
>=20
>=20
> On Thu, May 28, 2020 at 8:45 PM Larry Masinter  wrote:
> Here's my reasoning:
>=20
> The RFC series is known for being an archival format that never =
changes.
> This is what its "brand" means, that  it serves as a unique identifier =
for
> an explicit piece of intellectual  priority.
>=20
> Do you have any evidence that this is true outside of this fairly =
narrow community? My experience is that to the extent to which people =
know of RFCs they think of them as "Internet Specifications" and they =
don't think about mutability at all.

Yes, a lot.  When an RFC is referenced in an RFP and/or product =
specification.   If it was changeable, these would be useless.

Bob

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


--Apple-Mail=_663FBF04-7730-4A62-A4BC-D077DAA34EA8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl7RMjgACgkQrut0EXfn
u6iY4wgAwbwbhe/DpSFFEanE4SWHpS4+bbM37V2xEACJX2L7DU6191h2FS4KHiQR
QvbQfxna8zz7RMLRHrLa47FitF0jeznTYYn8I2+hXm3C83lOPpuE/mVTPbQwg9iS
GJEEdG3q5tCPF01zlBXqVsCrQbTUxU/V/fyn14hoR8ckxfsvLisvrcbjsOnyXcY4
sIBSbudnAOaZflHSOO5cgWP6FXqm+KAgJAsZbiqNwqmp0WmGOiAQyh8Ao8i6w0NR
ygHcB96c1fmUxosdlsMkb3tOHMkoS9d52bNH3QvwZa/Uw8rXGQEyYKsebtlfz1RG
blVSigL3VyVyFOAusWoQT14yiXpy5A==
=kpIJ
-----END PGP SIGNATURE-----

--Apple-Mail=_663FBF04-7730-4A62-A4BC-D077DAA34EA8--


From nobody Fri May 29 11:32:58 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226683A0FC2 for ; Fri, 29 May 2020 11:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_ptC3LWqGkI for ; Fri, 29 May 2020 11:32:54 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C73B3A0F02 for ; Fri, 29 May 2020 11:32:54 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id 64so236294pfg.8 for ; Fri, 29 May 2020 11:32:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=MOdkCAIuLpeeGkHKrIpfFy+AjBUv0FR2C2RrKVcYzpI=; b=Yk39f8d2CrdHY2AtEdmceP7PpZdpHgkwTjc/y7Y0acXmWOrfWPt3CC2HMDKcRZ7Wdy XQK/5nv+cQYqWcKdqi3GhfNOiL4xtW/GyU/yGD4gDpmipIS00EWpL6ASyqefCMudaFh6 OJT3E/pJItHSbSfs4kBu3GtuWtoEHrlJC5rMVfazSbkGzrxseAj/4vj8V+ZX3hh4LKxp 3KIJ924uz0mSrKBaWgbLwg/cZqIv3SGxWQBkTUbU6AeUqAX1B1f296TcvfVUHmeKy+E/ FuZk9n4iLg2okVU170jl0PzqQkeqKM88hj/nGRx5lyqku8S2NipivvZOapM8gpZeoPI3 UH5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-language:thread-index; bh=MOdkCAIuLpeeGkHKrIpfFy+AjBUv0FR2C2RrKVcYzpI=; b=Tb2ev6s0mdh+MTkyjC+XGkPBbyDME19HCqpgCkooUq2ru8TO6QRzZDopVQvvkbqJdj kqsL6BKY7un1Jf5hzTRSbcAIRXe4YG+k9G69lDSrnEdN/wAvDT6ZbrHw7B/zovwP+4/g JYRGkD8u0C0lRp7n8p6lSNcDdJipN3MPkM2KfPNO5z9s99AWv+vdUI+C2wrTuz6Goq32 CmtnADMqsuimMJA/TPew7Z8lQoluOjREAUqS8SfA5ksbqeWodn2WT6Ls7oZYmJXfpWx7 Eszm2dTCawm9aiEeJHLqTGKO7BnrPjZ0lGXxYM20HWIe5pZ84sHABeP6QDCowMCgvYYB rrFw==
X-Gm-Message-State: AOAM531RSP9E1A21H7jwIghy3RNoAksmFxHvzodUQc0ILmfdOcsvix7u F2fkvMNwZj3fQD3MGxq1gvcSKzo+
X-Google-Smtp-Source: ABdhPJzCxHnIxYdAnqBA3xYMy+9rExdNWmDZ4gCfu/g/ut6V8hdAxQmi80hG0vzsX8YExxchCE5Usw==
X-Received: by 2002:a63:a51b:: with SMTP id n27mr9741949pgf.40.1590777173696;  Fri, 29 May 2020 11:32:53 -0700 (PDT)
Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id b11sm8020003pfd.178.2020.05.29.11.32.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2020 11:32:52 -0700 (PDT)
Sender: Larry Masinter 
From: Larry Masinter 
X-Google-Original-From: "Larry Masinter" 
To: "'Eric Rescorla'" 
Cc: "'Mark Nottingham'" , "'Russ Housley'" , "'Colin Perkins'" , 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <006901d6356b$9e707030$db515090$@acm.org> 
In-Reply-To: 
Date: Fri, 29 May 2020 11:32:51 -0700
Message-ID: <010b01d635e7$90080310$b0180930$@acm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_010C_01D635AC.E3A9A040"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQEoY6D0a0QPnIjDHFMaI714e+UOKACOlR5aAR6lbQMA7vrt3AH9Kov6AOgllZ6p7vjTkA==
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 18:32:56 -0000

This is a multipart message in MIME format.

------=_NextPart_000_010C_01D635AC.E3A9A040
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

RFC 2648, although Informational, reflected the consensus of the =
community

=20

      Identifier persistence considerations:

=20

            Persistence of the URNs of this namespace is independent of

            the mutability of the underlying documents.  A URN once

            assigned will never be reassigned to a different resource;

            the assignment is persistent and immutable.  Immutability of

            RFCs, STDs, FYIs and BCPs is at the discretion of the RFC

            Editor.  They may be composites of one or more RFCs and the

            set of RFCs that includes them may change with time.  It is

            important to note that this mutability of some resources is

            independent of the immutability of URN assignment to a

            resource.

=20

=20

From: Eric Rescorla =20
Sent: Friday, May 29, 2020 5:36 AM
To: Larry Masinter 
Cc: Mark Nottingham ; Russ Housley =
; Colin Perkins ; =
rfced-future@iab.org
Subject: Re: [Rfced-future] On the question of a living series

=20

=20

=20

On Thu, May 28, 2020 at 8:45 PM Larry Masinter  > wrote:

Here's my reasoning:

The RFC series is known for being an archival format that never changes.

This is what its "brand" means, that  it serves as a unique identifier =
for
an explicit piece of intellectual  priority.=20

=20

Do you have any evidence that this is true outside of this fairly narrow =
community? My experience is that to the extent to which people know of =
RFCs they think of them as "Internet Specifications" and they don't =
think about mutability at all.

=20

-Ekr

=20

=20


------=_NextPart_000_010C_01D635AC.E3A9A040
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


RFC 2648, although =
Informational, reflected the consensus of the community
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Identifier persistence =
considerations:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Persistence of the URNs of this namespace is independent =
of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
the mutability of the underlying documents.=C2=A0 A URN =
once
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
assigned will never be reassigned to a different =
resource;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
the assignment is persistent and immutable.=C2=A0 Immutability =
of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
RFCs, STDs, FYIs and BCPs is at the discretion of the =
RFC
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Editor.=C2=A0 They may be composites of one or more RFCs and =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
set of RFCs that includes them may change with time.=C2=A0 It =
is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
important to note that this mutability of some resources =
is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0independent of the immutability of =
URN assignment to a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
resource.
 
 
From: Eric =
Rescorla <ekr@rtfm.com> 
Sent: Friday, May 29, 2020 5:36 =
AM
To: Larry Masinter <LMM@acm.org>
Cc: Mark =
Nottingham <mnot@mnot.net>; Russ Housley =
<housley@vigilsec.com>; Colin Perkins <csp@csperkins.org>; =
rfced-future@iab.org
Subject: Re: [Rfced-future] On the =
question of a living series
 
 
 
On =
Thu, May 28, 2020 at 8:45 PM Larry Masinter <LMM@acm.org> =
wrote:
Here's my =
reasoning:

The RFC series is known for being an archival format =
that never changes.
This is =
what its "brand" means, that  it serves as a unique =
identifier for
an explicit piece of intellectual  priority. =

 
Do you have any evidence that this is true outside of =
this fairly narrow community? My experience is that to the extent to =
which people know of RFCs they think of them as "Internet =
Specifications" and they don't think about mutability at =
all.
 
-Ekr
 
 

------=_NextPart_000_010C_01D635AC.E3A9A040--


From nobody Fri May 29 11:35:02 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4A93A0E99 for ; Fri, 29 May 2020 11:34:57 -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 GLcDY0uQcij5 for ; Fri, 29 May 2020 11:34:56 -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 166503A0E33 for ; Fri, 29 May 2020 11:34:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=119; q=dns/txt; s=iport; t=1590777296; x=1591986896; h=from:content-transfer-encoding:mime-version:subject: message-id:date:to; bh=hLgXIEZzx/JriWBJ1+oTcg79fIysy3cCTezV7EoVyjc=; b=lkpPSJLo66dU7/ql2qHem78xL9ZCbneGxmuVU8fYpSDJ0gdXu1X66i5Q 7GyeVbdGQdlwE5Ok0k9Elqb+/0o6mKRkZEm7EG2xO32NsGh/ZpvSANNWa IzvjQWeLIwBjIC0ZXl9Z7YiYeaDnVc4kP1tr4pmRwOvKgjmkl5zhL8fJz 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOAAC4VNFe/xbLJq1mHQEBAQEJARI?= =?us-ascii?q?BBQUBQIE2CAELAYNrASASjHJgogCBfAsBAQEMAQEvBAEBhmklNAkOAgMBAQs?= =?us-ascii?q?BAQUBAQECAQYEbYVlhjOFNoJ9oXOOEHSBNIVRhS+BOAGHXYUBggCBOByDdhk?= =?us-ascii?q?BhBaCeoItBLNDgl6CepVxFgiCVAGNfY1CqwSDSQIEBgUCFYFTOYFWMxoIGxU?= =?us-ascii?q?7KgGCPz0SGQ2QWI4yPwNnAgYIAQEDCY1YAQE?=
X-IronPort-AV: E=Sophos;i="5.73,449,1583193600"; d="scan'208";a="26632608"
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; 29 May 2020 18:34:52 +0000
Received: from [10.61.239.124] ([10.61.239.124]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 04TIYpTZ013806 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 29 May 2020 18:34:52 GMT
From: Eliot Lear 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Fri, 29 May 2020 20:34:51 +0200
To: rfced-future@iab.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.239.124, [10.61.239.124]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: [Rfced-future] IETF 108 session request
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 29 May 2020 18:34:58 -0000

If people send me WG conflicts, I will take the top few and stick them =
on the list when I do the session request.=


From nobody Fri May 29 12:36: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 2AD6A3A0FF1 for ; Fri, 29 May 2020 12:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBRM-ZroRTln for ; Fri, 29 May 2020 12:36:35 -0700 (PDT)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD813A0FD4 for ; Fri, 29 May 2020 12:36:35 -0700 (PDT)
Received: by mail-pj1-x1031.google.com with SMTP id a45so1988756pje.1 for ; Fri, 29 May 2020 12:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=wo2PrDd6nDCwTIVmPBu3T174t8XZfcE3oZxmFPvXa4E=; b=RoCSKXVmy33QZGB+IHftsvVux/EiWLHJQVZPQJUoML89Qsy6SjG0+eJFY0Uuzs7ldF wasM0bqgcjVYqmNvBh21St/RJX+PpufoYQZpRv8OEyowpE9pPUg7kGAtQc7J8VmN1Dnv GC4IP5Vo1iE14NB1ZyWu+mM3d2cf2chV+9XpR8l0ehB4SUAT2Py+N1y+bpyrQlYmZ3je RGvDOhy8cVJz0atHrrNV79h03vIspNnbd9o2RyZL2UHVobu7g+Rft/VRE2rjiO0jDt2/ /OK2ravCYZLjasYgi1iqvnuI/PCABZCsnJelVV0vDftozQiZFaxkxOn/E4k2rl+r0p8r fZNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=wo2PrDd6nDCwTIVmPBu3T174t8XZfcE3oZxmFPvXa4E=; b=bo2JWjgKEaANlVEJ/48z3cOeAfBl1yMXUVQ7KHtf4JicW3uOHb7Qe5VWSlV1tvoLSE Pc3lZ2HpViFbk914ATMKT6wR1ROVNobnrhSqmUi4dbzPUKqR1BHodTDFh4TNRQR+IsBz Cj9sLw3rzwYsCmeV6l3kmtB6yAiob4qfkB+01cD+1qV9GWrG8/KNsh+zgyZlu7u9ZZ47 NhqCg4s5uCz/4PDRviPBb5rFP5HUCiBa7jTizW0KQXWh5ofYuQzkaC1RbaWII+QVLs2h zO1h3Q/IHDOxXYUI4uqaxtF774vAwK43Y+/Uc1mnhsi2RORBckxFWuLFttjNddazth6o PL8A==
X-Gm-Message-State: AOAM533RwnIrOaNZ80p61hokJWMpD9bWnNh2vkbfWljnVNXfZ8zLMuer iDuTBhENQBt8XXNaTIub0eKvM2AJYwVQXDQ=
X-Google-Smtp-Source: ABdhPJzmc4fR49i9WFgCNFQLj2EPkotzavlFV/dNqWldkjicK+qYMxnelWsNuMWm1EZUAsUn9rLzJA==
X-Received: by 2002:a17:90a:20ae:: with SMTP id f43mr11412754pjg.29.1590780994654;  Fri, 29 May 2020 12:36:34 -0700 (PDT)
Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id u4sm465358pjf.3.2020.05.29.12.36.32 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 May 2020 12:36:33 -0700 (PDT)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org>
Organization: http://SoftwareAndServices.NET
Message-ID: <20ccbe8d-b905-0fbf-1e7d-d7d4732a16dc@gmail.com>
Date: Fri, 29 May 2020 13:36:32 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org>
Content-Type: multipart/alternative; boundary="------------3EFA814DC2C9A76F5208614E"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 19:36:37 -0000

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


How about keeping the original intact. And as errata arrive, creating extra one called

     RFC-####-errata.{txt,pdf,html}

that has the typos fixed? With all errata bundled into a single -errata as they are approved.


-- 
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

--------------3EFA814DC2C9A76F5208614E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
How about keeping the original intact. And as errata arrive,
      creating extra one called

    
    RFC-####-errata.{txt,pdf,html}

    
 that has the typos fixed? With all errata bundled into a single
      -errata as they are approved.

    

    


    

    
-- 

      Doug Royer - (http://DougRoyer.US)
      Douglas.Royer@gmail.com
      714-989-6135

  


--------------3EFA814DC2C9A76F5208614E--


From nobody Fri May 29 12:51: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 0ED813A1029 for ; Fri, 29 May 2020 12:51:46 -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 YNz40l0TYyTP for ; Fri, 29 May 2020 12:51:44 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96CB3A1028 for ; Fri, 29 May 2020 12:51:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3A68D300AEB for ; Fri, 29 May 2020 15:51:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ua5DjPx9fEcw for ; Fri, 29 May 2020 15:51:41 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id E8B9C300A93; Fri, 29 May 2020 15:51:40 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Russ Housley 
In-Reply-To: <065D5755-1C98-458B-993A-700228EE2259@mnot.net>
Date: Fri, 29 May 2020 15:51:42 -0400
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net>
To: Mark Nottingham 
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 19:51:46 -0000

> On May 28, 2020, at 7:58 PM, Mark Nottingham  wrote:
>=20
>=20
>> On 29 May 2020, at 6:47 am, Russ Housley  =
wrote:
>>=20
>>> I do not believe allowing amendments to published RFCs is desirable =
(with the possible exception: to fix bugs in the XML schema, provided =
there=E2=80=99s no content change).
>>=20
>> +1
>=20
> Could you give us some indication as to why you feel this way -- e.g., =
what would be impacted? I fear we're falling into the habit of just =
stating our preferences and expecting Eliot to tally the votes...

I find that people use the references to RFCs in many different ways.  =
Product planners use them as a starting point for interoperability, only =
deviating if there is a real need to interoperate with non-compliant =
peers.  Service providers and system integrators use them to name the =
protocols and protocol versions that then want supported.  Programmers =
and hardware designers use them to make products.  And so on.  In all of =
these cases, a stable specification is needed.

Russ


From nobody Fri May 29 12:54: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 021553A102B for ; Fri, 29 May 2020 12:54:24 -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 BK0c7pLWO8WD for ; Fri, 29 May 2020 12:54:22 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E0F3A102A for ; Fri, 29 May 2020 12:54:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9E53F300B21 for ; Fri, 29 May 2020 15:54:19 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yLKM-IWR_TcA for ; Fri, 29 May 2020 15:54:18 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 5EB16300A93; Fri, 29 May 2020 15:54:18 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Russ Housley 
In-Reply-To: <7B1AB8C4-C24A-4A1A-8C7F-96555AB4C574@fugue.com>
Date: Fri, 29 May 2020 15:54:19 -0400
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5889C2F9-29EA-4070-8628-ABC1B081B8F4@vigilsec.com>
References:  <7B1AB8C4-C24A-4A1A-8C7F-96555AB4C574@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 19:54:24 -0000

> On May 29, 2020, at 9:52 AM, Ted Lemon  wrote:
>=20
> On May 28, 2020, at 10:31 PM, Mark Nottingham  wrote:
>> E.g., people still widely refer to RFC2616 as the authoritative =
reference for HTTP, even though we obsoleted it in 2014, and have been =
working on something to obsolete that more recently.
>=20
> One way to immediately improve upon this would be to have a naive =
reference to any obsoleted document redirect to the document that =
replaced it, or a summary of why it=E2=80=99s obsolete if nothing =
replaced it. If someone wants to read the obsolete document =
specifically, a separate link could lead to that.
>=20
> IOW, no need for the content of a document with a specific name to =
change. I don=E2=80=99t know if this is really an RSE thing, but it =
arguably could be=E2=80=94right now there is no definitive place to look =
for a document, and attempts to make one have failed due to usability =
issues (e.g., tools.ietf.org much more usable than datatracker). But in =
principle, if we decided to solve this problem, we could, and this is =
exactly the sort of thing I would expect an RSE to try to do.

Yes, this is is often included in the "Changes since RFC XXXX" section.  =
Also, for backward compatibility reasons a programmer may need to =
support the old (obsolete) and the new.

Russ


From nobody Fri May 29 13: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 D9F6E3A103F for ; Fri, 29 May 2020 13:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7EkJn1sfcHp for ; Fri, 29 May 2020 13:03:31 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5371F3A103D for ; Fri, 29 May 2020 13:03:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E96ED300B68 for ; Fri, 29 May 2020 16:03:28 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LW_wV5zsYWsx for ; Fri, 29 May 2020 16:03:26 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 6BBA1300A11; Fri, 29 May 2020 16:03:26 -0400 (EDT)
From: Russ Housley 
Message-Id: <3BBAC769-1821-4F1F-9BD4-726EC08FBC99@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7893E43C-5B61-4448-A29F-38191966BADD"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Fri, 29 May 2020 16:03:27 -0400
In-Reply-To: <02f401d63392$db437000$91ca5000$@acm.org>
Cc: rfced-future@iab.org
To: Larry Masinter 
References:  <2507455b-a835-52fc-76e5-917ab2070288@gmail.com>  <02f401d63392$db437000$91ca5000$@acm.org>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 29 May 2020 20:03:33 -0000

--Apple-Mail=_7893E43C-5B61-4448-A29F-38191966BADD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On May 26, 2020, at 3:21 PM, Larry Masinter  wrote:
>=20
> A little searching turned up:
>=20
> ISO https://www.iso.org/developing-standards.html
> W3C https://www.w3.org/2019/Process-20190301/
> IEEE https://standards.ieee.org/develop/index.html
> ITU-T https://en.wikipedia.org/wiki/ITU-T
> WHATWG https://whatwg.org/workstream-policy
>=20
> I chose SDOs that I think IETF specs interact with (citations both =
ways)
> I'm sure there are others but these 5 span a range.
>=20
> None have a role like the RSE in duties and responsibilities.
> Each has a notion of what a series and a version is.
> They all have some safeguards and document formatting issues and =
restrictions.
>=20
> I think before changing the RFC series to be different, it might be =
worthwhile=20
> to understand what other SDOs do and the rationale for the =
differences.


My IEEE experience shows otherwise.

They have a style guide: =
https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf =


When the draft standard finishes the ballot process, it goes to a =
professional editor, and then back to the authors to make sure the =
meaning did not change (very similar to AUTH48).

So, while there not be a named individual performing an  RSE-like role, =
all of the tasks are happening within the process.

Russ


--Apple-Mail=_7893E43C-5B61-4448-A29F-38191966BADD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On May 26, 2020, at 3:21 PM, Larry Masinter <LMM@acm.org> =
wrote:

A little searching turned up:

ISO =
https://www.iso.org/developing-standards.html
W3C https://www.w3.org/2019/Process-20190301/
IEEE https://standards.ieee.org/develop/index.html
ITU-T https://en.wikipedia.org/wiki/ITU-T
WHATWG =
https://whatwg.org/workstream-policy

I chose SDOs that I think IETF specs interact with (citations =
both ways)
I'm sure there are others but these 5 span a =
range.

None have a role like the RSE in =
duties and responsibilities.
Each has a notion of what a =
series and a version is.
They all have some safeguards and =
document formatting issues and restrictions.

I think before changing the RFC series to be different, it =
might be worthwhile 
to understand what other SDOs do and =
the rationale for the differences.


My IEEE experience shows =
otherwise.

They =
have a style guide: https://mentor.ieee.org/myproject/Public/mytools/draft/styleman=
.pdf

When =
the draft standard finishes the ballot process, it goes to a =
professional editor, and then back to the authors to make sure the =
meaning did not change (very similar to AUTH48).

So, while there not be a named =
individual performing an  RSE-like role, all of the tasks are =
happening within the process.

Russ

=

--Apple-Mail=_7893E43C-5B61-4448-A29F-38191966BADD--


From nobody Fri May 29 13:14:58 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2737D3A0AA7 for ; Fri, 29 May 2020 13:14:57 -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 xBf0klrv9BTr for ; Fri, 29 May 2020 13:14:55 -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 A05F53A0AA3 for ; Fri, 29 May 2020 13:14:55 -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.15.2/8.15.2) with ESMTPSA id 04TKEfZI052002 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 29 May 2020 15:14:42 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1590783283; bh=/wM7FH0FfHYUYjVsl0NlCEYqyQgY53qDAHMIi1QHi9E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=CUtt13GcGK0i1CzVyS4SRmSg6s3LcaNyCdQEzrSESBpMMU02ekIAKOAfcNsyRj28f Oog/hf+DedfOT0cIHS49w5dkGgiUUDVmamAmkaXfj3Ugl4n1vHW2vxLLPkDJtyIuA/ rmKbXOex5qUOyIzsK3jgDqo9CYF4IRibAzW8UHBY=
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: Russ Housley , Larry Masinter 
Cc: rfced-future@iab.org
References:  <2507455b-a835-52fc-76e5-917ab2070288@gmail.com>  <02f401d63392$db437000$91ca5000$@acm.org> <3BBAC769-1821-4F1F-9BD4-726EC08FBC99@vigilsec.com>
From: Adam Roach 
Message-ID: <58a283a2-3434-0c8b-d0d5-121da7e84396@nostrum.com>
Date: Fri, 29 May 2020 15:14:35 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <3BBAC769-1821-4F1F-9BD4-726EC08FBC99@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------404E6557EFAA402AE8377E17"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 29 May 2020 20:14:57 -0000

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

On 5/29/2020 3:03 PM, Russ Housley wrote:
> My IEEE experience shows otherwise.
>
> They have a style guide: 
> https://mentor.ieee.org/myproject/Public/mytools/draft/styleman..pdf 
> 
>
> When the draft standard finishes the ballot process, it goes to a 
> professional editor, and then back to the authors to make sure the 
> meaning did not change (very similar to AUTH48).
>
> So, while there not be a named individual performing an  RSE-like 
> role, all of the tasks are happening within the process.


What you've described is an RPC role. I don't see an RSE role in your 
description. The presence of a style guide implies that there might be 
some entity that does RSE-ish things (and that guide does seem to 
parallel RFC 7322 in its function) -- do you know how it was created and 
how it is maintained?

/a


--------------404E6557EFAA402AE8377E17
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 5/29/2020 3:03 PM, Russ Housley
      wrote:

    

    

      
My IEEE experience shows otherwise.

      


      

      
      


      

      
When the draft standard finishes the ballot process,
        it goes to a professional editor, and then back to the authors
        to make sure the meaning did not change (very similar to
        AUTH48).

      


      

      
So, while there not be a named individual performing
        an  RSE-like role, all of the tasks are happening within the
        process.

    

    


    

    
What you've described is an RPC role. I don't see an RSE role in
      your description. The presence of a style guide implies that there
      might be some entity that does RSE-ish things (and that guide does
      seem to parallel RFC 7322 in its function) -- do you know how it
      was created and how it is maintained?

    

    
/a

    

  


--------------404E6557EFAA402AE8377E17--


From nobody Fri May 29 13:16: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 A4BF13A0AA8 for ; Fri, 29 May 2020 13:15: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=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 ZJcdn9m4aXlP for ; Fri, 29 May 2020 13:15:57 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C706B3A0AA7 for ; Fri, 29 May 2020 13:15:56 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id w3so3439866qkb.6 for ; Fri, 29 May 2020 13:15:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ElXRDYetoDYRHNvukPu2bUkRmY/qAo0TGVeRY4S2aSo=; b=hL4rC2+52ljgRmYHCkHb0hvoePoV2gNY/cfzAdzMuOjD14UgwxCQP2wDxPhcWqbQcy srp05ACMa7dj+drFhHTT4Dw4zDwRO2k0ozTkaNbV75QzbfGltR1oiVjJIlek+4KtL/DK zdcsHlRo4S1h+qXjtQ1E15lcrgQevh2RoPg6X030zYy2jES4k5QpGzfykTDj4g46poWc al4VZBWJQtVJ/W6QJ425bG1Z3KxBd6E3QyCEnbDYvg4MrbJeefrzLje/0o3Z64n+A1+D S3XI3TiylRHFCe9A0gD6VepB4wWdXjTING4zNdzJDPrKe79FPQDCj8GfuTYAPJRr6FTF XvlA==
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=ElXRDYetoDYRHNvukPu2bUkRmY/qAo0TGVeRY4S2aSo=; b=Hv7tcGJ3o0pOKiNN6AzZxuc/tj1Sxn55LB7A4E+82FNJcznfzLV+fNozvoVSLE3BpV LEl2vhYbGY1DP7yk9Ocr33ynFoXH5KRMnh6w4MHD7yQpnibVztQTQlEY3wiGT2mQnaAP kc+i1Pm+XGCmJF6XDpDy+t1F6OezhTDtxs4hpVuvWCRM56IKuotPbnWMGmMwcwoWnmQW 5S64CtwgZma0tCW9ulpc5A4L7fP7JurZztc03y7tyaeWDYWsbIqMB6iPQOb0QkUHT3Rk WxGnpqdq/drJz2PoR1pGDcml60RPW+UZYyf+67gxfZXi3Gc9wa5thxUchX1r2z7HwR/U pxOw==
X-Gm-Message-State: AOAM532pLS5Pb5B9+euDP5DZUrs378l1vvXunJKqnR/SWVC8WN42j0oc 32I3+WDyF82b0TgOX7gSPkYvMZXae+Y=
X-Google-Smtp-Source: ABdhPJxbcKKNa9wPCvTkwMFn+VXiT6ikboKEqLIhnxZ5f68Na7ayjmsBNjSTG5nLQYPQDc3/xY7ffg==
X-Received: by 2002:a37:b7c1:: with SMTP id h184mr82170qkf.183.1590783355058;  Fri, 29 May 2020 13:15:55 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id f7sm8112841qtg.96.2020.05.29.13.15.54 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 May 2020 13:15:54 -0700 (PDT)
To: rfced-future@iab.org
References:  <2507455b-a835-52fc-76e5-917ab2070288@gmail.com>  <02f401d63392$db437000$91ca5000$@acm.org> <3BBAC769-1821-4F1F-9BD4-726EC08FBC99@vigilsec.com>
From: Michael StJohns 
Message-ID: <59135207-73ce-2345-fb1d-ea87c86e0a3c@nthpermutation.com>
Date: Fri, 29 May 2020 16:15:53 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <3BBAC769-1821-4F1F-9BD4-726EC08FBC99@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------A9C28BEFDEBD3B089425B0B8"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 29 May 2020 20:15:59 -0000

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

On 5/29/2020 4:03 PM, Russ Housley wrote:
>
>
>> On May 26, 2020, at 3:21 PM, Larry Masinter > > wrote:
>>
>> A little searching turned up:
>>
>> ISO https://www.iso.org/developing-standards.html
>> W3C https://www.w3.org/2019/Process-20190301/
>> IEEE https://standards.ieee.org/develop/index.html
>> ITU-T https://en.wikipedia.org/wiki/ITU-T
>> WHATWG https://whatwg.org/workstream-policy
>>
>> I chose SDOs that I think IETF specs interact with (citations both ways)
>> I'm sure there are others but these 5 span a range.
>>
>> None have a role like the RSE in duties and responsibilities.
>> Each has a notion of what a series and a version is.
>> They all have some safeguards and document formatting issues and 
>> restrictions.
>>
>> I think before changing the RFC series to be different, it might be 
>> worthwhile
>> to understand what other SDOs do and the rationale for the differences.
>
>
> My IEEE experience shows otherwise.
>
> They have a style guide: 
> https://mentor.ieee.org/myproject/Public/mytools/draft/styleman..pdf 
> 
>
> When the draft standard finishes the ballot process, it goes to a 
> professional editor, and then back to the authors to make sure the 
> meaning did not change (very similar to AUTH48).
>
> So, while there not be a named individual performing an RSE-like 
> role, all of the tasks are happening within the process.
>
> Russ
>
>
To expand on this - the RFC series - for better or worse - contains 
quite a lot of non-standards track documents: IAB reports, IAB policy 
statements, IRTF research and standards-lite documents, Independent 
stream republications, alternate protocols, and the odd policy screed, 
as well as the April fools RFCs. If - as some people have argued for - 
this was only a standards series, then we might get away with just a 
professional editor with a style guide. Personally I think we need an 
identified RSE to balance competing interests amongst all of the various 
author sources, and I don't think that you can do that mechanically 
with fungible professional editors.

Mike


--------------A9C28BEFDEBD3B089425B0B8
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 5/29/2020 4:03 PM, Russ Housley
      wrote:

    

    

      
      

      


        

          
On May 26, 2020, at 3:21 PM, Larry Masinter <LMM@acm.org>
            wrote:

          

          

            
A little searching turned up:

              

              ISO https://www.iso.org/developing-standards.html

              W3C https://www.w3.org/2019/Process-20190301/

              IEEE https://standards.ieee.org/develop/index.html

              ITU-T https://en.wikipedia.org/wiki/ITU-T

              WHATWG https://whatwg.org/workstream-policy

              

              I chose SDOs that I think IETF specs interact with
              (citations both ways)

              I'm sure there are others but these 5 span a range.

              

              None have a role like the RSE in duties and
              responsibilities.

              Each has a notion of what a series and a version is.

              They all have some safeguards and document formatting
              issues and restrictions.

              

              I think before changing the RFC series to be different, it
              might be worthwhile 

              to understand what other SDOs do and the rationale for the
              differences.

            

          

        

      

      

      


      

      
My IEEE experience shows otherwise.

      


      

      
      


      

      
When the draft standard finishes the ballot process,
        it goes to a professional editor, and then back to the authors
        to make sure the meaning did not change (very similar to
        AUTH48).

      


      

      
So, while there not be a named individual performing
        an RSE-like role, all of the tasks are happening within the
        process.

      


      

      
Russ

      


      

      

      

    

    
To expand on this - the RFC series - for better or worse -
      contains quite a lot of non-standards track documents: IAB
      reports, IAB policy statements, IRTF research and standards-lite
      documents, Independent stream republications, alternate protocols,
      and the odd policy screed, as well as the April fools RFCs. If -
      as some people have argued for - this was only a standards series,
      then we might get away with just a professional editor with a
      style guide. Personally I think we need an identified RSE to
      balance competing interests amongst all of the various author
      sources, and I don't think that you can do that mechanically with
      fungible professional editors.

    
Mike

    

  


--------------A9C28BEFDEBD3B089425B0B8--


From nobody Fri May 29 13:32: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 BC2DD3A105E for ; Fri, 29 May 2020 13:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDCW0RTDl-_H for ; Fri, 29 May 2020 13:32:48 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB083A0B0B for ; Fri, 29 May 2020 13:32:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D5F25300B2B for ; Fri, 29 May 2020 16:32:45 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MuKIygIHZk0X for ; Fri, 29 May 2020 16:32:44 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 42BBF300A11; Fri, 29 May 2020 16:32:44 -0400 (EDT)
From: Russ Housley 
Message-Id: <05BCEFBF-12A6-4FC1-BBAD-6B8AAB2E0D33@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_12BA544D-D427-42AA-B635-32C8B61A90D4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Fri, 29 May 2020 16:32:45 -0400
In-Reply-To: <58a283a2-3434-0c8b-d0d5-121da7e84396@nostrum.com>
Cc: rfced-future@iab.org
To: Adam Roach 
References:  <2507455b-a835-52fc-76e5-917ab2070288@gmail.com>  <02f401d63392$db437000$91ca5000$@acm.org> <3BBAC769-1821-4F1F-9BD4-726EC08FBC99@vigilsec.com> <58a283a2-3434-0c8b-d0d5-121da7e84396@nostrum.com>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 29 May 2020 20:32:50 -0000

--Apple-Mail=_12BA544D-D427-42AA-B635-32C8B61A90D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On May 29, 2020, at 4:14 PM, Adam Roach  wrote:
>=20
> On 5/29/2020 3:03 PM, Russ Housley wrote:
>> My IEEE experience shows otherwise.
>>=20
>> They have a style guide: =
https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf =

>>=20
>> When the draft standard finishes the ballot process, it goes to a =
professional editor, and then back to the authors to make sure the =
meaning did not change (very similar to AUTH48).
>>=20
>> So, while there not be a named individual performing an  RSE-like =
role, all of the tasks are happening within the process.
>=20
> What you've described is an RPC role. I don't see an RSE role in your =
description. The presence of a style guide implies that there might be =
some entity that does RSE-ish things (and that guide does seem to =
parallel RFC 7322 in its function) -- do you know how it was created and =
how it is maintained?
>=20
I think it is a mix, bit just RPC.

The style guide is clear maintained.  It lists updates since the =
previous version.  I do not know the process that is used, but there is =
a consistency across the IEEE standards produced by this style guide.

Russ


--Apple-Mail=_12BA544D-D427-42AA-B635-32C8B61A90D4
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii



On May 29, 2020, at 4:14 PM, Adam Roach <adam@nostrum.com> wrote:


  
    
  
  

    
On 5/29/2020 3:03 PM, Russ Housley
      wrote:

    

    

      
My IEEE experience shows otherwise.

      


      

      
      


      

      
When the draft standard finishes the ballot process,
        it goes to a professional editor, and then back to the authors
        to make sure the meaning did not change (very similar to
        AUTH48).

      


      

      
So, while there not be a named individual performing
        an  RSE-like role, all of the tasks are happening within the
        process.

    


    
What you've described is an RPC role. I don't see an RSE role in
      your description. The presence of a style guide implies that there
      might be some entity that does RSE-ish things (and that guide does
      seem to parallel RFC 7322 in its function) -- do you know how it
      was created and how it is maintained?
I think it is a mix, bit just RPC.

The style guide is clear maintained.  It lists updates since the previous version.  I do not know the process that is used, but there is a consistency across the IEEE standards produced by this style guide.

Russ


--Apple-Mail=_12BA544D-D427-42AA-B635-32C8B61A90D4--


From nobody Fri May 29 13:53: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 B4BD03A1079 for ; Fri, 29 May 2020 13:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y8EQT2Nbf0tB for ; Fri, 29 May 2020 13:53:01 -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 DAA7A3A1076 for ; Fri, 29 May 2020 13:53:00 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id l15so877696lje.9 for ; Fri, 29 May 2020 13:53:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DwVAI1pJ+nzMLy7I05warBrybebTee98ljcncRGUWFQ=; b=aH2ULm+exfBvCfBR6a6UIQ/rx5qiPOsLkiE82NJuOKVLk31GX3hbPozaKTPfo6GGua Rm2l6BKRXPYn548e6nxoUhOtPcKH1kYTfJ0jAWCWq2s4AnkVoOA/LH70MSGbUppUhB7H 88+Xiad4u/kqIIJTe1PXAxw/612s4BW58IpSJuQu04l8nU2G2RrasEt6AfMDl3kr6Ko7 Ul+LnglEN87VnukrKKFeNynlivjQHa5FzqdaBu2je4Wyhp7duVXyAN/T7eZDab/xCIvu C8ey2ZqdGCv2MlwMsAScGhuXb80nCsP/MlJeQnfqrn6wmYxLCRiK+iU4vm46wMebrXeq epeA==
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=DwVAI1pJ+nzMLy7I05warBrybebTee98ljcncRGUWFQ=; b=l5f3VZUGZr8o+zMMhWg6/AR5+4y9x5K+DFiF3y6fi0w6NYXU6JqU7PID3fw4hQ7yn/ NvES3Prxkgy3tSM3J/cGN2TGsiOgXgksA9AJ2FW4ZUEj0FpFLI30XE6bkmsj3Y41wwlc +HiFSCOzNclDwY8cOvoFbuGVmBivxCWfMC//I5Mjn99+mJb9W35yhjOp97IgjG78x1xQ PzdZt/fGbAEUjfo/hx2f6U+fbbFp6nndD/0pwvleAyObauSbtHMhPU8/SDpPL7LRRsny Q6HjpPmrluXWDVQL0LYZ/VqApwKuUmyn2BLmgvpAD/l2H31lCIiFIkM0zOyGkyQgCNbx BB8A==
X-Gm-Message-State: AOAM5334AWFsEoH3jv/fz+31lzNcgZMih/jApAs2TjQWPP0+jRvi4YpY sUAI+wancrTiPrKJCXiT4NCXoep0XXXu+osEh14GOkIJ7DXbTg==
X-Google-Smtp-Source: ABdhPJzKc7plat+14tQSfCSF1Lde1KNQMXnb07V4Gim9aXkgzBNvYtPBQFRDjjn4LMnapLqhjet+/gh1MFkLQ6lv/qQ=
X-Received: by 2002:a2e:8897:: with SMTP id k23mr4944866lji.184.1590785578956;  Fri, 29 May 2020 13:52:58 -0700 (PDT)
MIME-Version: 1.0
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>
In-Reply-To: <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>
From: Eric Rescorla 
Date: Fri, 29 May 2020 13:52:22 -0700
Message-ID: 
To: Russ Housley 
Cc: Mark Nottingham , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000590c4b05a6cfa187"
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2020 20:53:03 -0000

--000000000000590c4b05a6cfa187
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 29, 2020 at 12:51 PM Russ Housley  wrote:

>
>
> > On May 28, 2020, at 7:58 PM, Mark Nottingham  wrote:
> >
> >
> >> On 29 May 2020, at 6:47 am, Russ Housley  wrote:
> >>
> >>> I do not believe allowing amendments to published RFCs is desirable
> (with the possible exception: to fix bugs in the XML schema, provided
> there=E2=80=99s no content change).
> >>
> >> +1
> >
> > Could you give us some indication as to why you feel this way -- e.g.,
> what would be impacted? I fear we're falling into the habit of just stati=
ng
> our preferences and expecting Eliot to tally the votes...
>
> I find that people use the references to RFCs in many different ways.
> Product planners use them as a starting point for interoperability, only
> deviating if there is a real need to interoperate with non-compliant
> peers.  Service providers and system integrators use them to name the
> protocols and protocol versions that then want supported.  Programmers an=
d
> hardware designers use them to make products.  And so on.  In all of thes=
e
> cases, a stable specification is needed.
>

II feel like perhaps we are talking past each other here.

At a high level, there are several levels of reference stability here:

- Bitwise identical (i.e., immutable)
- Semantically identical (editorial changes only)
- Semantically compatible (e.g., version N+1 is a superset
  of version N but the extensions are optional)

I believe that a good reference system would allow one to create all
three kinds of references and I would not be in favor of a system
which would not. However, the current system only really allows you to
create references to bitwise identical specifications, with the
mechanisms for creating references which are merely semantically
identical or semantically compatible are ad hoc at best.

It seems to me the questions at hand are:

1. Should we have mechanisms for creating all three kinds of
   references?

2. What kinds of references should we encourage people to cite
   for any given purpose?

I would note that for the purposes you are talking about, it
seems like a semantically identical reference is actually
more useful than a bitwise identical reference, because
we'd like people to refer to the clearest version of the specification.

-Ekr

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




=

On Fri, May 29, 2020 at 12:51 PM Russ=
 Housley <housley@vigilsec.com> wrote:



> On May 28, 2020, at 7:58 PM, Mark Nottingham <mnot@mnot.net> wrote:

> 

> 

>> On 29 May 2020, at 6:47 am, Russ Housley <housley@vigilsec.com> wrote:
>> 

>>> I do not believe allowing amendments to published RFCs is desi=
rable (with the possible exception: to fix bugs in the XML schema, provided=
 there=E2=80=99s no content change).

>> 

>> +1

> 

> Could you give us some indication as to why you feel this way -- e.g.,=
 what would be impacted? I fear we're falling into the habit of just st=
ating our preferences and expecting Eliot to tally the votes...



I find that people use the references to RFCs in many different ways.=C2=A0=
 Product planners use them as a starting point for interoperability, only d=
eviating if there is a real need to interoperate with non-compliant peers.=
=C2=A0 Service providers and system integrators use them to name the protoc=
ols and protocol versions that then want supported.=C2=A0 Programmers and h=
ardware designers use them to make products.=C2=A0 And so on.=C2=A0 In all =
of these cases, a stable specification is needed.

=

II feel like perhaps we are talking =
past each other here.

At a high level, there are several levels of r=
eference stability here:

- Bitwise identical (i.e., immutable)
- =
Semantically identical (editorial changes only)
- Semantically compatibl=
e (e.g., version N+1 is a superset
=C2=A0 of version N but the extension=
s are optional)

I believe that a good reference system would allow o=
ne to create all
three kinds of references and I would not be in favor o=
f a system
which would not. However, the current system only really allo=
ws you to
create references to bitwise identical specifications, with th=
e
mechanisms for creating references which are merely semantically
id=
entical or semantically compatible are ad hoc at best.

It seems to m=
e the questions at hand are:

1. Should we have mechanisms for creati=
ng all three kinds of
=C2=A0 =C2=A0references?

2. What kinds of r=
eferences should we encourage people to cite
=C2=A0 =C2=A0for any given =
purpose?

I would note that for the purposes you are talking about, i=
t
seems like a semantically identical reference is actually
more usef=
ul than a bitwise identical reference, because
we'd like people to refer to the clearest version of the specificat=
ion.

-Ekr




--000000000000590c4b05a6cfa187--


From nobody Fri May 29 16:49: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 B232D3A1205 for ; Fri, 29 May 2020 16:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEePue_IIoMc for ; Fri, 29 May 2020 16:49:36 -0700 (PDT)
Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 1D2AB3A120A for ; Fri, 29 May 2020 16:49:36 -0700 (PDT)
Received: by mail-pg1-x544.google.com with SMTP id m1so645784pgk.1 for ; Fri, 29 May 2020 16:49:36 -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=ZfGB7ZkuI0WBX0kERk1tsXcOLzaCC1e/JO9xGO3W1k8=; b=smUq8ddCz+P/Jhkhx2swL6bFaLCkPuYtrmW/CJju9A0LLA3Qpq2IUs+1qcoShmTw2x 8UtCO0ysnrLKz2Fh3vCsOrmRb85fuixfHdxA5mvpGejsDTlbHdqIDScrmy7Jm6DkLpoR 7WQy08H7yrYbwmEgflrxHPTJBy5cj6eBWt5e0A5n8nCwH5aScB7SegPPF9iQT/acWmBz MVT1ZCLt/IOjlzFoRWF1ZwrTL43u7VJ4wW4mG+9pqdUZfUUFLktRyVFRq+tJDzBMY760 zcSamH8ZL6T3SLxMsjml95UqGxxTkky6Js8ziGTUndK0QR7Dy8a/3HN3sj9B9TX8Z85w nIsA==
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=ZfGB7ZkuI0WBX0kERk1tsXcOLzaCC1e/JO9xGO3W1k8=; b=MvlzP8RgCV0DY+pFXpifVO3hvvhK45przV/L+nRW2wrBaOsoVDL3Lp1Fvw7QzGDL3G O0qaNbrvrczXyDZcDK8pgtR6J2K/FuxpJD1W1KbmMoyzhAMWOiNh+xZ2L/GrLZK4yciU XggQv94fK/mAFqXNv4Un0ZGJTZqe9bjNh4YJ46QHEtIuqLxx/H6fNkNcpiL/AqJ3cm3x ofNgWID2IN3e6x6G1IrSxCinJf912ET4xP71yJvYDMoSiT/HR8j6hOSiWF7Lkff2UQ85 bJqP/mfEnl+OmjyWL35Z3TBemHXcy65DqgBWVgfP7BrFgup28cCQj8hEE7JxEZRT0V+K 91Vg==
X-Gm-Message-State: AOAM530YhBbrEyoAT7VH8qorD+3zJLHoFKN4AW6C5ZaIO3TvhpXpo1nc DXtS3R4jvkuKUyR1YrXnoEdJiYWheZU=
X-Google-Smtp-Source: ABdhPJys3vIdc6PqBvFoLGjN9QN0ZYwcKvjuNFoU7wUMSghSHi5bn9j8tJEKszSAbP0kjM/EPEcsNA==
X-Received: by 2002:aa7:9816:: with SMTP id e22mr10616020pfl.205.1590796175058;  Fri, 29 May 2020 16:49:35 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id f7sm448657pjp.24.2020.05.29.16.49.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2020 16:49:34 -0700 (PDT)
To: Russ Housley , Adam Roach 
Cc: rfced-future@iab.org
References:  <2507455b-a835-52fc-76e5-917ab2070288@gmail.com>  <02f401d63392$db437000$91ca5000$@acm.org> <3BBAC769-1821-4F1F-9BD4-726EC08FBC99@vigilsec.com> <58a283a2-3434-0c8b-d0d5-121da7e84396@nostrum.com> <05BCEFBF-12A6-4FC1-BBAD-6B8AAB2E0D33@vigilsec.com>
From: Brian E Carpenter 
Message-ID: <652729cd-1402-ca59-07aa-c9aa4ffe42ca@gmail.com>
Date: Sat, 30 May 2020 11:49: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: <05BCEFBF-12A6-4FC1-BBAD-6B8AAB2E0D33@vigilsec.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 29 May 2020 23:49:39 -0000

On 30-May-20 08:32, Russ Housley wrote:
>=20
>=20
>> On May 29, 2020, at 4:14 PM, Adam Roach > wrote:
>>
>> On 5/29/2020 3:03 PM, Russ Housley wrote:
>>> My IEEE experience shows otherwise.
>>>
>>> They have a style guide:=C2=A0https://mentor.ieee.org/myproject/Publi=
c/mytools/draft/styleman.pdf
>>>
>>> When the draft standard finishes the ballot process, it goes to a pro=
fessional editor, and then back to the authors to make sure the meaning d=
id not change (very similar to AUTH48).
>>>
>>> So, while there not be a named individual performing an =C2=A0RSE-lik=
e role, all of the tasks are happening within the process.
>>
>>
>> What you've described is an RPC role. I don't see an RSE role in your =
description. The presence of a style guide implies that there might be so=
me entity that does RSE-ish things (and that guide does seem to parallel =
RFC 7322 in its function) -- do you know how it was created and how it is=
 maintained?
>>
> I think it is a mix, bit just RPC.
>=20
> The style guide is clear maintained. =C2=A0It lists updates since the p=
revious version. =C2=A0I do not know the process that is used, but there =
is a consistency across the IEEE standards produced by this style guide.

As it happens, I've just gone through the IEEE process for a journal arti=
cle, which is of course quite distinct from their standards publication p=
rocess. So I've had to deal with the journal's editor and anonymous revie=
wers (rather like dealing with the ISE) and then with the copy-editing fu=
nction (rather like dealing with the RPC), all mediated by some monstrosi=
ties called the "Author Center" on "ScholarOne Manuscripts", and later th=
e "IEEE Author Gateway", both of which were much more complicated than th=
e IETF datatracker. These are clearly IEEE-wide mechansims. There *must* =
be a presiding intelligence above this system, but Google seems unable to=
 find it.

    Brian


From nobody Fri May 29 18:30: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 2342F3A12E0 for ; Fri, 29 May 2020 18:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUThK_8kIdRr for ; Fri, 29 May 2020 18:30:37 -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 731F03A1103 for ; Fri, 29 May 2020 18:30:37 -0700 (PDT)
Received: (qmail 48024 invoked from network); 30 May 2020 01:30:36 -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=bb96.5ed1b73c.k2005; bh=xCYMCUHkrELTkOwjah3brMa9ao38dJoCEBWHpwiTf1U=; b=IEerFetkyAGjtsiSKk6vzwvA/XwWRua8wQMUjT9WyERQXv5jUdaPk4TmEEH/l40hJ9WhIWCedLLGmSFgCbKbFKiv8UYMin3iD2EZyybu8HqAv2eFuRAyhDmFzH2ndhTDIujAVhtEWzIJlfderwDQxhnYW3ISiDR1y7lQLIwPshpme+SyG7sTLyvok/igYaTcUQvHdkAR2TVFUb2p5UuZypKQbE9phgYNtslq+g33vFeSx0iKGPZaysjdWezlcvzs
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 30 May 2020 01:30:35 -0000
Received: by ary.qy (Postfix, from userid 501) id CB49B19DEE42; Fri, 29 May 2020 21:30:35 -0400 (EDT)
Date: 29 May 2020 21:30:35 -0400
Message-Id: <20200530013035.CB49B19DEE42@ary.qy>
From: "John Levine" 
To: rfced-future@iab.org
Cc: douglasroyer@gmail.com
In-Reply-To: <20ccbe8d-b905-0fbf-1e7d-d7d4732a16dc@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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 01:30:39 -0000

In article <20ccbe8d-b905-0fbf-1e7d-d7d4732a16dc@gmail.com> you write:
>How about keeping the original intact. And as errata arrive, creating extra one called
>
>     RFC-####-errata.{txt,pdf,html}
>
>that has the typos fixed? With all errata bundled into a single -errata as they are approved.

Like this?  https://www.rfc-editor.org/rfc/inline-errata/rfc1035.html

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 Fri May 29 19:10: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 D64273A12EA for ; Fri, 29 May 2020 19:10:08 -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 lZYBKAdngj8d for ; Fri, 29 May 2020 19:10:07 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3D73A12C8 for ; Fri, 29 May 2020 19:10:07 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id s10so754596pgm.0 for ; Fri, 29 May 2020 19:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NoyTLIFv9n/grz24TiJbvgTIoxk1uXq5vwHJcBuhUjs=; b=NpD2FPv4mjxU7+RFu9ieGOuZgVf7EJMZr9ls9GJA+IY0/Qu7p67KQ7Dy44qEcHkCGW vXeu6qhgFF7s7c/M5rZObkN9JqOtjA0+hEH8EdDNM1ZaqQYWQShfcejbbzPyy4dhUuqg z0WkQvPwj5yOcAtejpsrPSg4LrA6vRTVpycTcibdWogzbzufCW+3a+6NzbD2kyaOiRwe TtxfRpGCaMThvuITZd/+f/6TtkuAc9IZERhv/qfLHrjMGTXSAn3+dWNP3x86rs1ZotYV eClKKgFfkUBQNtYx54dEGdT4x2dGyMEUb+a6oBVIC9hy3QsjDE+xDqP4d+YZUjikdmCy tEPg==
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=NoyTLIFv9n/grz24TiJbvgTIoxk1uXq5vwHJcBuhUjs=; b=FEGQKvTXMRudfCTPkBXiJRmjQprsIINt+2kSXUfSLZJhtCyO3V0zhdOzT9ZUa4GXRy 5o+qACTVskfFYuQlXlpN2CyWpCyUENJCWdhg0l+AKCndtvuN7cbDeB+CwC2iHLhAVcuE JqsBVan/Vy4RhHnXrHEA7Jak2M1p+/DgaJQstBUXr+Dcfa9oPQIi7daRIqoSeTDUmyFX XWBofjVix6C0yIAiLOVLqcWoIPq2OypGGETN6pmeV8YFvkh9nArT6tRxgvd9OqsajpxV rJE0pwXFmJEzZQgnug1bzJUqLXc8xV/p9N/mO0jJXEgkfsrYgTcwWs6kids/TUX36fEj KEIA==
X-Gm-Message-State: AOAM531kaT/0/3lffLZOPK7eIVFoN7JWXNtFBMDX72cMkr3xlcXc6v3w ZgOseNeUXUTs9RF/KOgIkYu7RjXq44k=
X-Google-Smtp-Source: ABdhPJzygJSFsjR9ScsZmgP4LKHP/muCyI19vRdnS7lvFDYHxRNdYkACrhxh+/2WI0tg77IJRieYQg==
X-Received: by 2002:a63:f442:: with SMTP id p2mr10652745pgk.234.1590804606831;  Fri, 29 May 2020 19:10:06 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id 84sm8162002pfv.157.2020.05.29.19.10.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2020 19:10:06 -0700 (PDT)
To: Eliot Lear 
Cc: Mark Nottingham , Russ Housley , Colin Perkins , rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <7e024205-68be-ae0b-be4c-823a5ca56af5@gmail.com> <66EF9358-C4FC-4E1E-ACBE-EAE3A28120F1@cisco.com>
From: Brian E Carpenter 
Message-ID: <345826c9-6239-44e2-5f3c-a5c4a7cce83b@gmail.com>
Date: Sat, 30 May 2020 14:10:01 +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: <66EF9358-C4FC-4E1E-ACBE-EAE3A28120F1@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [Rfced-future] Who decides? [On the question of a living series]
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 02:10:09 -0000

On 29-May-20 17:43, Eliot Lear wrote:
>=20
>=20
>> On 29 May 2020, at 03:13, Brian E Carpenter > wrote:
>>>>
>>>> +1
>>>
>>> Could you give us some indication as to why you feel this way -- e.g.=
, what would be impacted? I fear we're falling into the habit of just sta=
ting our preferences and expecting Eliot to tally the votes...
>>
>> I'd add a specific question to that: does the objection extend to a si=
mple versioning mechanism, such as RFC8200.1 for RFC8200 plus accumulated=
 errata? (Assuming that RFC8200 is also kept around, of course.)
>>
>=20
> I would ask that the question only be answered *if*=C2=A0it can be rela=
ted to our task here. =C2=A0That is- who should decide who gets to monkey=
 with the series format? =C2=A0If you can answer that one question, that =
is the right level for our conversation.

Fair enough. So if, say, the IETF decides it wants something like RFC8200=
=2E1 or RFC8200.errata, and the IRTF is dead against, the *current* BCP39=
 rule is that the RSE proposes policy and the IAB [dis]approves it. Our q=
uestion is presumably whether that is correct, or needs to be changed.

(Note that there is no BCP that puts the RSOC in the loop.)

    Brian

   Brian


From nobody Fri May 29 21:39:02 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3408B3A13D2 for ; Fri, 29 May 2020 21:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_-Dmw32t8TA for ; Fri, 29 May 2020 21:38:58 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CA73A13D0 for ; Fri, 29 May 2020 21:38:58 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id f21so834032pgg.12 for ; Fri, 29 May 2020 21:38:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=iZfyr9OmKSMUS0vA65S2jjZI/vdGuV8cPBW7njn4jHg=; b=BKSPmIgjVjuZCvY5KuaTxvUDJPQDDtMEjILZohyx1H+RYjK4d4r4MZZw+rat6eQnWC da6lAr/uMFytHDBlhWZ2lhMf4EhwssMz2p8AxjqBQwmgG+HwE8j5IB69Ykf59A3gOg/O joil1tzxAMvQUucBANJqwnxzhhiaKVOLZPcWpllHOZ9LrWJM6p0bk7uc+4YwfEvro5As k/GljHMFLUrpdzTrDn3DauL5LkmAL3zX7sX/sneBWNrqrtmhkN/9hQZOgoNQb0XVuJ9X +PkHmUp0SBrYRKjSndhZPSGQucxexLUDK1SiP1oGbuv0pt7BGryQgdH/NcVjGs0c9Oku IxGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=iZfyr9OmKSMUS0vA65S2jjZI/vdGuV8cPBW7njn4jHg=; b=LiwotKDKcYfffY0L3z/mzWdb51Ty/g/VxbuqIgqrrqPscIYEOiEfRZVd9wcjKeciUm KA1MyWwvKQlPoVm+VvH4s88qA6GER4fmKH6hPIxSeNpOOI754Y16H8F03CneQxgkrhJX CapI0+REATLoZdFu5x3YL/YnAHLZLM6/868Gf+dBcb6iBPHHEThr9alRB987AvPh3nQy Q0i7rB3eCqkD/FJB5DUI5YGapU8z409WsUwisVYq5Zhvlem6TT4cWeV9ddLyBqKkhql4 SGdX4jpMB/0qOOsMIKpC0j+O7pEoTWmoxIGkMvU+c6lzR1lGqwn08ZJtzjANCAaZjmGV zZ0A==
X-Gm-Message-State: AOAM533Vpx/Fl3tkTyF1EH+QdMXXI8SjgIjGAHR02Xd7rIF2TEIPicJq nr7PB2fIbcP4itnRT2j3I7lbgOqF2+eVDLQ=
X-Google-Smtp-Source: ABdhPJyXTrJBX9Zt7Ty+J3bEmX84KqdKnmo+p9mdiKtgVRTf4C2EmlJKAGWANWKBGBAl439ol8rT6g==
X-Received: by 2002:aa7:9302:: with SMTP id 2mr11150137pfj.164.1590813536119;  Fri, 29 May 2020 21:38:56 -0700 (PDT)
Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id k12sm4758892pgm.11.2020.05.29.21.38.54 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 May 2020 21:38:55 -0700 (PDT)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: rfced-future@iab.org
References: <20200530013035.CB49B19DEE42@ary.qy>
Organization: http://SoftwareAndServices.NET
Message-ID: <26095ef1-5af4-325c-721a-97a4e1cec98c@gmail.com>
Date: Fri, 29 May 2020 22:38:53 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200530013035.CB49B19DEE42@ary.qy>
Content-Type: multipart/alternative; boundary="------------A0D263EE87A702DB6C4ABD37"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 04:39:00 -0000

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

On 5/29/20 7:30 PM, John Levine wrote:
> In article <20ccbe8d-b905-0fbf-1e7d-d7d4732a16dc@gmail.com> you write:
>> How about keeping the original intact. And as errata arrive, creating extra one called
>>
>>      RFC-####-errata.{txt,pdf,html}
>>
>> that has the typos fixed? With all errata bundled into a single -errata as they are approved.
> Like this?  https://www.rfc-editor.org/rfc/inline-errata/rfc1035.html

I had no idea that existed. Great.

So, revision control may not be needed?


-- 
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135

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


  
    
  
  
    
On 5/29/20 7:30 PM, John Levine wrote:

    

    

      
In article <20ccbe8d-b905-0fbf-1e7d-d7d4732a16dc@gmail.com> you write:


      

        
How about keeping the original intact. And as errata arrive, creating extra one called

    RFC-####-errata.{txt,pdf,html}

that has the typos fixed? With all errata bundled into a single -errata as they are approved.


      

      
Like this?  https://www.rfc-editor.org/rfc/inline-errata/rfc1035.html

    

    
I had no idea that existed. Great.

    
So, revision control may not be needed?

    


    

    -- 

    
Doug Royer - (http://DougRoyer.US)
      Douglas.Royer@gmail.com
      714-989-6135

  


--------------A0D263EE87A702DB6C4ABD37--


From nobody Sat May 30 01:11: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 D61023A07FB for ; Sat, 30 May 2020 01:11: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 eb4AYCthOlIP for ; Sat, 30 May 2020 01:11:12 -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 080293A07F9 for ; Sat, 30 May 2020 01:11:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7858; q=dns/txt; s=iport; t=1590826272; x=1592035872; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=iMv6SB9gymSe0T36OPi2h1b+F3STwnn8CH7qATDVUsg=; b=QRVPUvQ1fmgenHXG7yTHu7nVZm2wWNUYu9vlBn5o4kCJZGZWAnyZi69y 0qXWxvod+PjdAa21VjNmHPWYOl7KTCiAgBa4usGG1VA4Y6OMlLd1FohU0 8YavT/Tms6cHGLtRPRXOl1YL7x7wvjRhoQz81q4jGEHltcfwDwoF0/fno k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfBABsFNJe/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCCoNsASASLIQliQGHZCWTY4gRCwEBAQwBAS8EAQGERAKCIyU?= =?us-ascii?q?4EwIDAQELAQEFAQEBAgEGBG2FZYVyAQEBAQIBI1YFCwsOCicDAgJGEQYTFIM?= =?us-ascii?q?Sgl0gr1Z2gTKFUYR2gTiMX4IAgTgMEIIfLj6HYjOCLQSOZxuJN5sMgl6CepV?= =?us-ascii?q?wHpBSjUKrBoNKAgQGBQIVgWoigVYzGggbFWUBgj4+EhkNnwo/AzA3AgYBBwE?= =?us-ascii?q?BAwmNNwEB?=
X-IronPort-AV: E=Sophos; i="5.73,451,1583193600"; d="scan'208,217"; a="26644350"
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; 30 May 2020 08:11:07 +0000
Received: from [10.61.209.159] ([10.61.209.159]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 04U8B7wT020121 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 May 2020 08:11:07 GMT
From: Eliot Lear 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE4E0056-7A24-44FB-A38A-CA8262932F52"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 30 May 2020 10:11:06 +0200
In-Reply-To: 
Cc: Russ Housley , rfced-future@iab.org, Mark Nottingham 
To: Eric Rescorla 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.209.159, [10.61.209.159]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 08:11:15 -0000

--Apple-Mail=_DE4E0056-7A24-44FB-A38A-CA8262932F52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 29 May 2020, at 22:52, Eric Rescorla  wrote:
>=20
>=20
>=20
> On Fri, May 29, 2020 at 12:51 PM Russ Housley > wrote:
>=20
>=20
> > On May 28, 2020, at 7:58 PM, Mark Nottingham > wrote:
> >=20
> >=20
> >> On 29 May 2020, at 6:47 am, Russ Housley > wrote:
> >>=20
> >>> I do not believe allowing amendments to published RFCs is =
desirable (with the possible exception: to fix bugs in the XML schema, =
provided there=E2=80=99s no content change).
> >>=20
> >> +1
> >=20
> > Could you give us some indication as to why you feel this way -- =
e.g., what would be impacted? I fear we're falling into the habit of =
just stating our preferences and expecting Eliot to tally the votes...
>=20
> I find that people use the references to RFCs in many different ways.  =
Product planners use them as a starting point for interoperability, only =
deviating if there is a real need to interoperate with non-compliant =
peers.  Service providers and system integrators use them to name the =
protocols and protocol versions that then want supported.  Programmers =
and hardware designers use them to make products.  And so on.  In all of =
these cases, a stable specification is needed.
>=20
> II feel like perhaps we are talking past each other here.
>=20
> At a high level, there are several levels of reference stability here:
>=20
> - Bitwise identical (i.e., immutable)
> - Semantically identical (editorial changes only)
> - Semantically compatible (e.g., version N+1 is a superset
>   of version N but the extensions are optional)
>=20
> I believe that a good reference system would allow one to create all
> three kinds of references and I would not be in favor of a system
> which would not. However, the current system only really allows you to
> create references to bitwise identical specifications, with the
> mechanisms for creating references which are merely semantically
> identical or semantically compatible are ad hoc at best.
>=20
> It seems to me the questions at hand are:
>=20
> 1. Should we have mechanisms for creating all three kinds of
>    references?
>=20
> 2. What kinds of references should we encourage people to cite
>    for any given purpose?


My fault, but these aren=E2=80=99t the questions at hand for this group. =
The question at hand is this:

Who has the authority to answer those questions for the series?

Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF =
community through the RFC process (I view that as the degenerative =
case)?

This is the level of dialog we need to have at this point.

Eliot=

--Apple-Mail=_DE4E0056-7A24-44FB-A38A-CA8262932F52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 29 May 2020, at 22:52, Eric Rescorla <ekr@rtfm.com> =
wrote:



On Fri, May 29, 2020 at 12:51 PM Russ =
Housley <housley@vigilsec.com> wrote:




> On May 28, 2020, at 7:58 PM, Mark Nottingham <mnot@mnot.net> wrote:

> 

> 

>> On 29 May 2020, at 6:47 am, Russ Housley <housley@vigilsec.com> wrote:

>> 

>>> I do not believe allowing amendments to published RFCs is =
desirable (with the possible exception: to fix bugs in the XML schema, =
provided there=E2=80=99s no content change).

>> 

>> +1

> 

> Could you give us some indication as to why you feel this way -- =
e.g., what would be impacted? I fear we're falling into the habit of =
just stating our preferences and expecting Eliot to tally the =
votes...



I find that people use the references to RFCs in many different =
ways.  Product planners use them as a starting point for =
interoperability, only deviating if there is a real need to interoperate =
with non-compliant peers.  Service providers and system integrators =
use them to name the protocols and protocol versions that then want =
supported.  Programmers and hardware designers use them to make =
products.  And so on.  In all of these cases, a stable =
specification is needed.

II feel like perhaps =
we are talking past each other here.

At a =
high level, there are several levels of reference stability here:

- Bitwise identical (i.e., immutable)
- Semantically identical (editorial changes only)
- Semantically compatible (e.g., version N+1 is a superset
  of version N but the extensions are optional)

I believe that a good reference system would =
allow one to create all
three kinds of references and I =
would not be in favor of a system
which would not. =
However, the current system only really allows you to
create=
 references to bitwise identical specifications, with the
mechanisms for creating references which are merely =
semantically
identical or semantically compatible are ad =
hoc at best.

It seems to me the questions =
at hand are:

1. Should we have mechanisms =
for creating all three kinds of
  =
 references?

2. What kinds of =
references should we encourage people to cite
  =
 for any given purpose?


My fault, but these aren=E2=80=99=
t the questions at hand for this group. The question at hand is =
this:

  • Who has the authority to answer those questions for the =
series?

Is =
it this group?  The RSE?  A committee overseeing the RSE? =
 The IETF community through the RFC process (I view that as the =
degenerative case)?

This is =
the level of dialog we need to have at this point.

Eliot
=

--Apple-Mail=_DE4E0056-7A24-44FB-A38A-CA8262932F52--


From nobody Sat May 30 10:04: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 7D2A43A0882 for ; Sat, 30 May 2020 10:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs-O4dnkJ3Hd for ; Sat, 30 May 2020 10:04:27 -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 D83C43A0881 for ; Sat, 30 May 2020 10:04:26 -0700 (PDT)
Received: (qmail 31352 invoked from network); 30 May 2020 17:04:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=7a76.5ed29217.k2005; bh=L35y7iWHc517kklVrKlDZD5MusDTwh75+fSZeDMbvDU=; b=ss6takqJzAWVQvxIMvPFz244OtFwIbViKO+XeIkF2NBnoDWqtmMtHD/yBsJijxoCZHbxjGH8goE2Wq9AYWOXCEC4FF3oqeK64JW2Yp+zk6/LFSsy9aqjK3nzH2LefVm4zqTldYDQbvBTKku4TbbuERq0221ot3oWp6xTaNGYqWXdhhFXX+pWB84wzUvw8rSmLzx6QWd8TAsZ8Af2SQk/ni5QYoAsw4cE4miB0UuYAZU/4EjFxLRVP5Z4FaQCukzn
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 30 May 2020 17:04:23 -0000
Received: by ary.qy (Postfix, from userid 501) id 652AA19E2605; Sat, 30 May 2020 13:04:23 -0400 (EDT)
Date: 30 May 2020 13:04:23 -0400
Message-Id: <20200530170423.652AA19E2605@ary.qy>
From: "John Levine" 
To: rfced-future@iab.org
Cc: douglasroyer@gmail.com
In-Reply-To: <26095ef1-5af4-325c-721a-97a4e1cec98c@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] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 17:04:29 -0000

In article <26095ef1-5af4-325c-721a-97a4e1cec98c@gmail.com> you write:
>-=-=-=-=-=-
>
>On 5/29/20 7:30 PM, John Levine wrote:
>> In article <20ccbe8d-b905-0fbf-1e7d-d7d4732a16dc@gmail.com> you write:
>>> How about keeping the original intact. And as errata arrive, creating extra one called
>>>
>>>      RFC-####-errata.{txt,pdf,html}
>>>
>>> that has the typos fixed? With all errata bundled into a single -errata as they are approved.
>> Like this?  https://www.rfc-editor.org/rfc/inline-errata/rfc1035.html
>
>I had no idea that existed. Great.
>
>So, revision control may not be needed?

Those merged errata are unofficial and very hard to find if you don't
know exactly where to look, which reminds us that in a sensible system
people looking for the RFC itself would find them with the fixes, too.




From nobody Sat May 30 10:19: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 07D433A08A3 for ; Sat, 30 May 2020 10:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EBNEyslvoe6 for ; Sat, 30 May 2020 10:19:06 -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 792A63A089C for ; Sat, 30 May 2020 10:19:06 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id q9so2844265pjm.2 for ; Sat, 30 May 2020 10:19:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=9VffnD//CgOPgn1W3MOe91OEYq6AcvDObPOj4gXXHSw=; b=NxScCxPmKWS3zriOS5IfEStN5aP3F+bCWCRHmb/6xgijYdtktyI6ljceE9/13CpJmR 3ULzLhOwts9D4djzn2w6CBBRNURJk0xroguh/xbLvbI84nwLSVw7YXalaVc0QPVeX8qA IX/o5IG760Wr1uDwSy6wggmX1C8B824y8/Gq+2ok2nPllIrvB6RGj6nbNLXpxxUtcjX+ K7lKVwdayTTkq3uRL6GWSifzw3txTm7WQx5WuIYhHs5rwMhVRtiCMbDV4XzWyXebzLY4 HQOK28d4/JtCDMWmKR8NzZv4tby6EuVoX2aXDsnEK2dDNsQYpi2YN/hFOdwvmIAAsyhv fh6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=9VffnD//CgOPgn1W3MOe91OEYq6AcvDObPOj4gXXHSw=; b=sPZUvIyogR9wDY0YbYiHkeVdwOuUYdQXVYUp03p2WZhZI6n2FW/TkfNWX9G6ARW+SA ZdmsxMAtnF6UsmvEzAtda035KojXV+1lti47ht7NM/ZEoOHAVrbh3M8f3XFcXkjK4JmP +VnxEM7REzfC8wgOoUQ074hMAWlgWvDLNex5LamgK1jtsqICH5fqWcyVGbW+DiwqvCaO O8WQ42Fr2oebnVXccx1snvBz1dnkSbMwJG5zYcqajSxoByIzzY0CEmddy/h7KV/m6j9v FFZG75nFjOd0qJ4Z0UdFXnfXjbk2fUkJYzvz+CGNGl3V6w37IAI3kjr8CUhiZ2EiqPqj MamA==
X-Gm-Message-State: AOAM533nBElX55R8ju/vZMqCiIq+uXYSUnGbjYX/Ry92S8uN22+B2F+8 LMq0EcAPaDebijyCVKjNVGM=
X-Google-Smtp-Source: ABdhPJzd0kcKyKIud2YzAwL6ZH2XvH0TId7jfBzZF26Rg2069Lou5OGOmMz6U45LupMztm0lLYhn7A==
X-Received: by 2002:a17:90b:b10:: with SMTP id bf16mr3015902pjb.5.1590859145722;  Sat, 30 May 2020 10:19:05 -0700 (PDT)
Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id f11sm10413754pfk.58.2020.05.30.10.19.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2020 10:19:04 -0700 (PDT)
Sender: Larry Masinter 
From: Larry Masinter 
X-Google-Original-From: "Larry Masinter" 
To: "'Eliot Lear'" , "'Eric Rescorla'" 
Cc: , "'Mark Nottingham'" , "'Russ Housley'" 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>  
In-Reply-To: 
Date: Sat, 30 May 2020 10:19:03 -0700
Message-ID: <006e01d636a6$6b5ac470$42104d50$@acm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01D6366B.BEFC88B0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEoY6D0a0QPnIjDHFMaI714e+UOKACOlR5aAR6lbQMA7vrt3AC80KPzAmOy9sABRKcAeqnka4WA
Content-Language: en-us
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 17:19:08 -0000

This is a multipart message in MIME format.

------=_NextPart_000_006F_01D6366B.BEFC88B0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=20

Consider   changing the BCP series=3D=3Dturn those into =E2=80=9Cliving =
documents=E2=80=9D=20

Or changing the STD series =E2=80=93 that to go from Draft to Standard =
requires writing something that isn=E2=80=99t an RFC, it might cite RFCs =
for details but is understandable and well-written.

=20

STDs and BCPs already have the notion of being semantically updatable.

The guarantee I think is associated with RFCs is basically the same as a =
HTTP weak etag. It might not be the same byte sequence, but it is =
equivalent for the MIME type as far as the publisher is concerned.

=20

I don=E2=80=99t think the strong etag guarantee (that it=E2=80=99s the =
identical byte sequence for all renditions) is necessary, and might =
interfere with the kind of update recently to re-render PDFs to bring =
into PDF/A3 conformance.

=20

=20

At a high level, there are several levels of reference stability here:

- Bitwise identical (i.e., immutable)
- Semantically identical (editorial changes only)
- Semantically compatible (e.g., version N+1 is a superset
  of version N but the extensions are optional)

I believe that a good reference system would allow one to create all
three kinds of references and I would not be in favor of a system
which would not. However, the current system only really allows you to
create references to bitwise identical specifications, with the
mechanisms for creating references which are merely semantically
identical or semantically compatible are ad hoc at best.

It seems to me the questions at hand are:

1. Should we have mechanisms for creating all three kinds of
   references?

2. What kinds of references should we encourage people to cite
   for any given purpose?

=20

=20

My fault, but these aren=E2=80=99t the questions at hand for this group. =
The question at hand is this:

=20

*	Who has the authority to answer those questions for the series?

=20

Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF =
community through the RFC process (I view that as the degenerative =
case)?

=20

This is the level of dialog we need to have at this point.

=20

Eliot


------=_NextPart_000_006F_01D6366B.BEFC88B0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


 
Consider =C2=A0=C2=A0changing the BCP series=3D=3Dturn =
those into =E2=80=9Cliving documents=E2=80=9D 
Or changing the STD series =E2=80=93 that to go from =
Draft to Standard requires writing something that isn=E2=80=99t an RFC, =
it might cite RFCs for details but is understandable and =
well-written.
 
STDs and BCPs already have the notion of being =
semantically updatable.
The guarantee =
I think is associated with RFCs is basically the same as a HTTP weak =
etag. It might not be the same byte sequence, but it is equivalent for =
the MIME type as far as the publisher is concerned.
 
I =
don=E2=80=99t think the strong etag guarantee (that it=E2=80=99s the =
identical byte sequence for all renditions) is necessary, and might =
interfere with the kind of update recently to re-render PDFs to bring =
into PDF/A3 conformance.
 
 
At a high level, there are several levels of reference =
stability here:

- Bitwise identical (i.e., immutable)
- =
Semantically identical (editorial changes only)
- Semantically =
compatible (e.g., version N+1 is a superset
  of version N but =
the extensions are optional)

I believe that a good reference =
system would allow one to create all
three kinds of references and I =
would not be in favor of a system
which would not. However, the =
current system only really allows you to
create references to bitwise =
identical specifications, with the
mechanisms for creating references =
which are merely semantically
identical or semantically compatible =
are ad hoc at best.

It seems to me the questions at hand =
are:

1. Should we have mechanisms for creating all three kinds =
of
   references?

2. What kinds of references should =
we encourage people to cite
   for any given =
purpose?
 
 
My =
fault, but these aren=E2=80=99t the questions at hand for this group. =
The question at hand is this:
 
  • Who has the authority to answer those questions for the =
series?
 
Is it this group?  The RSE?  A committee =
overseeing the RSE?  The IETF community through the RFC process (I =
view that as the degenerative case)?
 
This is the level of dialog we need to have at this =
point.
 
Eliot

------=_NextPart_000_006F_01D6366B.BEFC88B0--


From nobody Sat May 30 10:42: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 189283A08FD for ; Sat, 30 May 2020 10:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QekpMsb-UlJ for ; Sat, 30 May 2020 10:42:27 -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 ED3E23A08FB for ; Sat, 30 May 2020 10:42:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49Z80256PQz6G8nv; Sat, 30 May 2020 10:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590860546; bh=WDwKCpnbqLU0NKDGzW+K6ko6Daoowk+DiWCN0KHQA0U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=As6x95HYJH4LpQWAAb1hTXmbqkdgWh5JEw3epLFOyCaT3smuQxTdFKBlssoOT8zjJ FXKtVYzAUAI/mSpPtJ7+9KBWreRBjhcUFHuF2RffQBevNcv5bUtzchoAfkqyLx14Lz Tx2/xsN7JZMcgaAeG1xHs21gT4o/iovFhrmi5Qsk=
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 49Z80211kmz6G88X; Sat, 30 May 2020 10:42:25 -0700 (PDT)
To: Larry Masinter 
Cc: rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>   <006e01d636a6$6b5ac470$42104d50$@acm.org>
From: "Joel M. Halpern" 
Message-ID: 
Date: Sat, 30 May 2020 13:42:25 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <006e01d636a6$6b5ac470$42104d50$@acm.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 17:42:28 -0000

We were explicit as part of adopting the new format that the byte-wise 
identical guarantee applied to the XML, not to the rendered format. 
That much foresight we did manage.

Yours,
Joel

On 5/30/2020 1:19 PM, Larry Masinter wrote:
> Consider   changing the BCP series==turn those into “living documents”
> 
> Or changing the STD series – that to go from Draft to Standard requires 
> writing something that isn’t an RFC, it might cite RFCs for details but 
> is understandable and well-written.
> 
> STDs and BCPs already have the notion of being semantically updatable.
> 
> The guarantee I think is associated with RFCs is basically the same as a 
> HTTP weak etag. It might not be the same byte sequence, but it is 
> equivalent for the MIME type as far as the publisher is concerned.
> 
> I don’t think the strong etag guarantee (that it’s the identical byte 
> sequence for all renditions) is necessary, and might interfere with the 
> kind of update recently to re-render PDFs to bring into PDF/A3 conformance.
> 
>     At a high level, there are several levels of reference stability here:
> 
>     - Bitwise identical (i.e., immutable)
>     - Semantically identical (editorial changes only)
>     - Semantically compatible (e.g., version N+1 is a superset
>        of version N but the extensions are optional)
> 
>     I believe that a good reference system would allow one to create all
>     three kinds of references and I would not be in favor of a system
>     which would not. However, the current system only really allows you to
>     create references to bitwise identical specifications, with the
>     mechanisms for creating references which are merely semantically
>     identical or semantically compatible are ad hoc at best.
> 
>     It seems to me the questions at hand are:
> 
>     1. Should we have mechanisms for creating all three kinds of
>         references?
> 
>     2. What kinds of references should we encourage people to cite
>         for any given purpose?
> 
> My fault, but these aren’t the questions at hand for this group. The 
> question at hand is this:
> 
>   * Who has the authority to answer those questions for the series?
> 
> Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF 
> community through the RFC process (I view that as the degenerative case)?
> 
> This is the level of dialog we need to have at this point.
> 
> Eliot
> 
> 


From nobody Sat May 30 10: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 D36F13A0905 for ; Sat, 30 May 2020 10:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S71akabOHdbR for ; Sat, 30 May 2020 10:47: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 BC83C3A08FF for ; Sat, 30 May 2020 10:47:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49Z85h4jh8z6GFxM; Sat, 30 May 2020 10:47:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590860840; bh=sH4nE+VnyGRznA4VmJoVfpz13CmH++6WT1u6ZZztXVc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GYQpsizp7XOvxXBVP/l/Ao4ESdp/QIR8i3rVw2/AL6CetSnPzMNb9YoWE8UAEbcQt VqpzrXgZt+ZMcLya58t3mRzYo/jvfZkEVUfKybbY5mgeoOIMMZZvntlw009TcOy3un ImZDiRSBc5Y8kWLdw69qScV1gXzsbiSdEphjB6eM=
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 49Z85h173Kz6G9Z9; Sat, 30 May 2020 10:47:20 -0700 (PDT)
To: Larry Masinter 
Cc: rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>   <006e01d636a6$6b5ac470$42104d50$@acm.org>
From: "Joel M. Halpern" 
Message-ID: 
Date: Sat, 30 May 2020 13:47:19 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <006e01d636a6$6b5ac470$42104d50$@acm.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] On the question of a living series -semantically identical?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.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, 30 May 2020 17:47:22 -0000

I would want to be very cautious about formally recognizing changes to 
the document which are "semantically identical" as being the same 
document.  (The current careful errata approach, assuming we make it 
more visible, is fine.)

For example, I have a document that the RPC is working on.  they noticed 
some contorted language and odd case usage.  So they fixed it.  That is 
their job.  However, it this particular case, the fix changed the 
meaning in a subtle but in my view important way.  (We are still 
discussing it.)

The point being that it is difficult to draw that line well.  As long as 
we are simultaneously careful and do not claim that the fixed document 
is the thing that the WG and IETF approved, it works for me.

Yours,
Joel

PS: As another example, someone submitted an erratum against an RFC to 
clarify the meaning of a few words.  However, the exact intended meaning 
of those few words is still a matter of WG contention, and the AD (in my 
view correctly) rejected the erratum.  But it could easily not have been 
obvious to someone not involved just how tricky the change was.

On 5/30/2020 1:19 PM, Larry Masinter wrote:
> Consider   changing the BCP series==turn those into “living documents”
> 
> Or changing the STD series – that to go from Draft to Standard requires 
> writing something that isn’t an RFC, it might cite RFCs for details but 
> is understandable and well-written.
> 
> STDs and BCPs already have the notion of being semantically updatable.
> 
> The guarantee I think is associated with RFCs is basically the same as a 
> HTTP weak etag. It might not be the same byte sequence, but it is 
> equivalent for the MIME type as far as the publisher is concerned.
> 
> I don’t think the strong etag guarantee (that it’s the identical byte 
> sequence for all renditions) is necessary, and might interfere with the 
> kind of update recently to re-render PDFs to bring into PDF/A3 conformance.
> 
>     At a high level, there are several levels of reference stability here:
> 
>     - Bitwise identical (i.e., immutable)
>     - Semantically identical (editorial changes only)
>     - Semantically compatible (e.g., version N+1 is a superset
>        of version N but the extensions are optional)
> 
>     I believe that a good reference system would allow one to create all
>     three kinds of references and I would not be in favor of a system
>     which would not. However, the current system only really allows you to
>     create references to bitwise identical specifications, with the
>     mechanisms for creating references which are merely semantically
>     identical or semantically compatible are ad hoc at best.
> 
>     It seems to me the questions at hand are:
> 
>     1. Should we have mechanisms for creating all three kinds of
>         references?
> 
>     2. What kinds of references should we encourage people to cite
>         for any given purpose?
> 
> My fault, but these aren’t the questions at hand for this group. The 
> question at hand is this:
> 
>   * Who has the authority to answer those questions for the series?
> 
> Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF 
> community through the RFC process (I view that as the degenerative case)?
> 
> This is the level of dialog we need to have at this point.
> 
> Eliot
> 
> 


From nobody Sat May 30 14:06: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 906BA3A0A24 for ; Sat, 30 May 2020 14:06:47 -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 1-WbpI4jCcIP for ; Sat, 30 May 2020 14:06:46 -0700 (PDT)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A170C3A0A0B for ; Sat, 30 May 2020 14:06:46 -0700 (PDT)
Received: by mail-pj1-x1035.google.com with SMTP id ga6so123384pjb.1 for ; Sat, 30 May 2020 14:06:46 -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=QXXeDRTiR487L1PVLH7QtQOAmSj881Hm2OyCUbwn0wg=; b=iW71oChVpDD0SPmPkmlcXWUi1HscZXVLqhbPVaT1t6ivgrRM+4lmR6TXoF69kQfiqM 0u850qZBHo5go47NxSvr/P8GvT+6bLVE377J+QllFwZQCHUfJ7ubHIjEtJDRhtH1DpU9 Mlx7jC7ZKyXuC/+9Rq0mB3lmiQoHBkQM/I0nXOyw/Ne68d3KNL11Q9mCevcSV1CFb5PS 2bdjYctAdK8OXhpJaeEC0LoO7cqFvNJ82cCqpFRgspfvmtFRP1DPanmN0NTBGMOp4Qld kjx26fwKZlECrm/H/o5N+h3xDCPY82ymoqyqVwNo0QpNdpn8sB3flMB0r7dmXYOkNN4N Np6w==
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=QXXeDRTiR487L1PVLH7QtQOAmSj881Hm2OyCUbwn0wg=; b=sT/IHUmWbWSlIyvVLbgKqPCJrdHxwcABZGEIOqKcMzRTgrKbfgOtm6mx0yZJHGiest 42wgZndGBFg37q+QZxDYIbnjWRWzjCTfQjlHMPl1v2ECa/CpaJ2mA/NZ44pou5caFIAL u8RdHrcI3vm826358NV9sFpsjbTmttiJDVGfESEfhNSr0x/m1OJajCeHMwLje9b9sXLh uBulnr5cC57tbY07/ENIQS1MhQzFMG+x4gSAISM9AcVRCLkzng72CldxtD8zlJlQPzhA I6Ii/x2VDyMpT22v0+NrN6q+dl+vfUdktdzQNDre64FMQqARztVJprShkkus8JJHVh5d dHQA==
X-Gm-Message-State: AOAM533hD+vhMaYEF/8182p0k/Y963HVeA8s9e8aJ6cdB7mKCazGiw7R NLbofUo6f+BA8dCG4ymB1H3Wj4pn1vk=
X-Google-Smtp-Source: ABdhPJzpKTBStg+NODi+ppArpkr4HCXZ4dnD7G7L3EWiCb1MfPD29PD46tqBNQkl2pi0bmM+Yc8R1w==
X-Received: by 2002:a17:90b:1002:: with SMTP id gm2mr16046441pjb.197.1590872805717;  Sat, 30 May 2020 14:06:45 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id mw5sm3457178pjb.27.2020.05.30.14.06.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2020 14:06:45 -0700 (PDT)
To: Eliot Lear 
Cc: rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>  
From: Brian E Carpenter 
Message-ID: <4c3de4c4-65c5-117e-6ade-baf0ef7cb8b3@gmail.com>
Date: Sun, 31 May 2020 09:06:40 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [Rfced-future] Who has the authority? [On the question of a living series]
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 21:06:48 -0000

On 30-May-20 20:11, Eliot Lear wrote:
=2E..
>> It seems to me the questions at hand are:
>>
>> 1. Should we have mechanisms for creating all three kinds of
>> =C2=A0 =C2=A0references?
>>
>> 2. What kinds of references should we encourage people to cite
>> =C2=A0 =C2=A0for any given purpose?
>=20
> My fault, but these aren=E2=80=99t the questions at hand for this group=
=2E The question at hand is this:
>=20
>   * Who has the authority to answer those questions for the series?
>=20
> Is it this group? =C2=A0The RSE? =C2=A0A committee overseeing the RSE? =
=C2=A0The IETF community through the RFC process (I view that as the dege=
nerative case)?

I think this is where Mike St J's idea of an RSE supported by an Editoria=
l Board comes in. As long as the Board is in some way responsible to the =
wider (not just IETF) community in some way, it seems to me that the powe=
r of decision about policy should belong to the RSE in consultation with =
this Board.

The current setup, where the nearest thing to this is the IAB approving "=
general policy" and the intermediate RSOC seeming to act as if it's only =
a contract management committee, has been demonstrated to have a catastro=
phic failure mode. And the evidence from both RSOC and IAOC is that we sh=
ould ban the word "oversight" from our vocabulary, because we're very bad=
 at it.

(A subsidiary benefit of Mike's proposal is that it removes a chunk of ad=
min stuff from the IAB's workload, which I hope the IAB will welcome.)

Regards
    Brian


From nobody Sat May 30 15:34: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 141AD3A0B37 for ; Sat, 30 May 2020 15:34:29 -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 XBRDUQPhc26N for ; Sat, 30 May 2020 15:34:27 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79F93A0B34 for ; Sat, 30 May 2020 15:34:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7E269300B60 for ; Sat, 30 May 2020 18:34:24 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XSDEzShRy2Fg for ; Sat, 30 May 2020 18:34:23 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 1BFFD300A3B; Sat, 30 May 2020 18:34:23 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Russ Housley 
In-Reply-To: 
Date: Sat, 30 May 2020 18:34:24 -0400
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>  
To: Eliot Lear 
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: [Rfced-future] Who has the authority? [On the question of a living series]
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 22:34:29 -0000

On 30-May-20 20:11, Eliot Lear wrote:
...
>> It seems to me the questions at hand are:
>>=20
>> 1. Should we have mechanisms for creating all three kinds of
>>    references?
>>=20
>> 2. What kinds of references should we encourage people to cite
>>    for any given purpose?
>=20
> My fault, but these aren=E2=80=99t the questions at hand for this =
group. The question at hand is this:
>=20
>  * Who has the authority to answer those questions for the series?
>=20
> Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF =
community through the RFC process (I view that as the degenerative =
case)?

We have four stream managers.  Ir seems to me that those stream managers =
would be a good sounding board for the RSE to use for changes that are =
under consideration.  If the four stream managers are satisfied, then =
the RSE can bring the idea to the broader technical community for =
further discussion, review, and refinement.  This might happen before or =
after a budget impact discussion with the IETF LLC, depending on the =
expected magnitude of the budget impact.

I think that creating a new group to do oversight will have the same =
pitfalls as the previous approach.

Russ


From nobody Sat May 30 16:48:53 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200803A0C6C for ; Sat, 30 May 2020 16:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWjjXEql9M6T for ; Sat, 30 May 2020 16:48:51 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148B63A0C68 for ; Sat, 30 May 2020 16:48:51 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id bh7so2761401plb.11 for ; Sat, 30 May 2020 16:48:51 -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=6+yb50iVpmoEmn7n7x0IBF8l3uVsvcOo7bC9ZDOADiE=; b=iQ3FYNSXP0a4FxgqIRomWvr8Q4t1T7FkkgK5jyC5NaH0khc6zNOwtGUZqa652iCGX3 rr4umYOYNYhjiZfBAXTEfaWoYgfVQvXQGS3PbrJsqP5HZa7h96QyJkKXnPv6KvDmvU3T s38RJMdauSBdVnYAe10k6AWCaM59pBJKUe4GEabtOIr1DqT9B6rJwQcXuF7A5jP4G2SL /Op1zilQxS5asUSrwarTC6RWsv5V2g3gkKuMnrlyAuzpdRIPzWU5tvj9i3ZaNag+elpQ j9b3QcgsHPUoPKVrx9xqpuPjTi7stOrEPxngxpZ7Mn+KfAkAnPuDFlmdbKM8019gntC9 cNqQ==
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=6+yb50iVpmoEmn7n7x0IBF8l3uVsvcOo7bC9ZDOADiE=; b=D2riBE2yJ+71T/0O07MwEjahNK6RFdnP2xZIBfg4e1ddIJrkcrKZgeWrI43wX3II3w wLm9b4q+3x1zQfNQAtJ+eiIogjY1VdGrdHIlrCAhKJe97iisPXkIuqAi1CK5AE9naPL5 AEpkEz/YhF2lJOImSIRL5xaiqwaYhc3Okr8rH+TfDIO7z9zZRGQfbqKR7eznxnMrWlgz Y4OeDpBK7A4qpi+FHdbPmWhVNCWpgeU5nSCfVyR+5SYHFYbTNynI2x5XL6xrIdQRBzba Y8lCZmM10a6K6fcjUWDt8ZVDZa5b+rXg7cx4sMOwCjbYTfj5ZECIRpZ96xeYLbOnIH3j x/kw==
X-Gm-Message-State: AOAM531e3jSDTCBGaga/+5x6hNnTUeN1pL//q/GCkZrHFqN/jCga+N/Q 9rMKgyXts4VduWoWcZh7ccYMSg3/QK8=
X-Google-Smtp-Source: ABdhPJyxYAFjv5RBolSjbe9qnaLf1AUjKtV57tXRnzalwvoyBExPuuT52Sra7lmWax58xuI3YhRkQA==
X-Received: by 2002:a17:902:41:: with SMTP id 59mr11166023pla.104.1590882529086;  Sat, 30 May 2020 16:48:49 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id v3sm3121066pja.8.2020.05.30.16.48.47 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2020 16:48:48 -0700 (PDT)
To: rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>   
From: Brian E Carpenter 
Message-ID: <3424f79d-72f2-4397-5cfe-c68f3f101953@gmail.com>
Date: Sun, 31 May 2020 11:48:44 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Who has the authority? [On the question of a living series]
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2020 23:48:52 -0000

On 31-May-20 10:34, Russ Housley wrote:
> On 30-May-20 20:11, Eliot Lear wrote:
> ...
>>> It seems to me the questions at hand are:
>>>
>>> 1. Should we have mechanisms for creating all three kinds of
>>>    references?
>>>
>>> 2. What kinds of references should we encourage people to cite
>>>    for any given purpose?
>>
>> My fault, but these aren=E2=80=99t the questions at hand for this grou=
p. The question at hand is this:
>>
>>  * Who has the authority to answer those questions for the series?
>>
>> Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF=
 community through the RFC process (I view that as the degenerative case)=
?
>=20
> We have four stream managers.  Ir seems to me that those stream manager=
s would be a good sounding board for the RSE to use for changes that are =
under consideration.  If the four stream managers are satisfied, then the=
 RSE can bring the idea to the broader technical community for further di=
scussion, review, and refinement.  This might happen before or after a bu=
dget impact discussion with the IETF LLC, depending on the expected magni=
tude of the budget impact.
>=20
> I think that creating a new group to do oversight will have the same pi=
tfalls as the previous approach.

We agree on that. I don't see Mike's proposed Editorial Board having an o=
versight role, and contract management is surely an LLC job.

    Brian


From nobody Sat May 30 17:25: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 B8D113A0E22 for ; Sat, 30 May 2020 17:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42OcA_yzhb7C for ; Sat, 30 May 2020 17:25:37 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DB83A0E19 for ; Sat, 30 May 2020 17:25:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49ZJxF3W8hz6GHdJ; Sat, 30 May 2020 17:25:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590884737; bh=u1IVa/ANSVChrcwnN72kfaIFKHuPmxUNBlSxG+vLPls=; h=Subject:To:References:From:Date:In-Reply-To:From; b=T/9QH+wgVmWD6BqaqSEelLld9mAOdnzmVCIddE7R/cylyMLkkQ1DiNSXZPojOkA6h 5aziGToiOaLRK9CPZq7+Bunp6vIRSFCy0NSyQtq1Wk1bUXzApTIwVlFC1ODh7W7XhN 9u6BXv01OTltubzV/WSaFc9+1Rr0Y1gT5iWGpPyE=
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 49ZJxF081vz6G8nv; Sat, 30 May 2020 17:25:36 -0700 (PDT)
To: Brian E Carpenter , rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>    <3424f79d-72f2-4397-5cfe-c68f3f101953@gmail.com>
From: "Joel M. Halpern" 
Message-ID: 
Date: Sat, 30 May 2020 20:25:21 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <3424f79d-72f2-4397-5cfe-c68f3f101953@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Who has the authority? [On the question of a living series]
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 00:25:39 -0000

the stream managers clearly have a role in the operation of the RFC 
Series.  I am concerned that putting them in charge introduces an 
inherent conflict.  The Stream managers have very specific objectives. 
Up till now, they have not been selected for a broad view, but rather, 
if I understand correctly, for a clear understanding of what their 
stream needs.  and particularly, what it needs now.

Long term planning, community responsiveness, and some form of 
management are not their tasks.

Could stream managers be selected and directed to have different 
objectives?  Presumably.  But it would make things complicated in a new 
fashion.

And it is not at all obvious that the stream managers are more 
accountable to the community.  Except in very extreme cases (lets hope 
we don't do that again) an AD who is serving as stream head is not going 
to get fired as an AD based on the quality of their management of the 
RSE.  I do not see how this is any better than the RSOC, which had many 
flaws and some benefits.

Yours,
Joel

On 5/30/2020 7:48 PM, Brian E Carpenter wrote:
> On 31-May-20 10:34, Russ Housley wrote:
>> On 30-May-20 20:11, Eliot Lear wrote:
>> ...
>>>> It seems to me the questions at hand are:
>>>>
>>>> 1. Should we have mechanisms for creating all three kinds of
>>>>     references?
>>>>
>>>> 2. What kinds of references should we encourage people to cite
>>>>     for any given purpose?
>>>
>>> My fault, but these aren’t the questions at hand for this group. The question at hand is this:
>>>
>>>   * Who has the authority to answer those questions for the series?
>>>
>>> Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF community through the RFC process (I view that as the degenerative case)?
>>
>> We have four stream managers.  Ir seems to me that those stream managers would be a good sounding board for the RSE to use for changes that are under consideration.  If the four stream managers are satisfied, then the RSE can bring the idea to the broader technical community for further discussion, review, and refinement.  This might happen before or after a budget impact discussion with the IETF LLC, depending on the expected magnitude of the budget impact.
>>
>> I think that creating a new group to do oversight will have the same pitfalls as the previous approach.
> 
> We agree on that. I don't see Mike's proposed Editorial Board having an oversight role, and contract management is surely an LLC job.
> 
>      Brian
> 


From nobody Sat May 30 19:55:58 2020
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77B53A1120 for ; Sat, 30 May 2020 19:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 bhQY7n9gYc0v for ; Sat, 30 May 2020 19:55:55 -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 B2CCB3A111F for ; Sat, 30 May 2020 19:55:55 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id f3so1819386pfd.11 for ; Sat, 30 May 2020 19:55:55 -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=aECTr7ONYw3Kb9RnBae2f6qVVVpufZQV0g4WHdPiAbQ=; b=MhsQBZC6gRBR1u8NnTlh+hGA1z1nv2g29UvspdmiJTOIUQzTxkoTvE+PBedEeBkEwA EeMfFnmDSTDMqX7NCRt2c2ppG4bhPShOwjIllPZq4NiCG/phbUdEx6oc/T1bsE3KXdVp qZlv2r8Sa0VTRjGWD7B6oV6nfwcPQzy/tgjv1OVr2ulICpvYa/2xkvRmNIajc13+52Z4 ysRpIXgo3DOLzSvvRi9ows3dGE1OfA9QXK/bBiUD4e1ZkblxdakO/A61EoQAlnBo6Xyl Lcsrv5sIvbq9aC8eyQeCSnqPANWCjtV1X2/kAoh02+A7FzPSu2Sj9zU7YUFEg9KPiccQ tl7A==
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=aECTr7ONYw3Kb9RnBae2f6qVVVpufZQV0g4WHdPiAbQ=; b=SCCIt1OFpbIa0yxIyUMV6Trg1d4XYpzPElw9QoiE704xD/ojItZcAmncW3ov16K+KU CZbB9jgXhhO4J1q6MT780UaCfX4AnQg7sPQHOjbssvvYVbwSGHufzJWvlaIlo5FN87my JDg6vJfsR/pF3Gnw1imfZh2LuP6ULajFP1NtjFk4EmJ8bMp+TcOOqqHrhx0XOYMw/wml qtFINoeRQpHYt4XdiU7TJPpqgiCdM5GCQMqvxQOLt87z1BzIRwfOL/n/mOS9OgWIfjd8 QgHEi3AWy4aNH1mNLe8Bl/f3AGZN7mXMTJEfVGajnROKlakZVLGyjFqSaseWK9EpN0rX AqzA==
X-Gm-Message-State: AOAM530vCw5TseuvKwn3v5MufZcDiptMHaWr5rGgOeJI/ANgmzdbikhA FV/Z3kvJauaijk2p6QfEM7RLXsDGhA4=
X-Google-Smtp-Source: ABdhPJzJAikt2bqz3hDFZuKERTdGAUxNE+DS9Yp9X48see/5BKPBjFi/+ruYcii47VO2HMuqzM/kFw==
X-Received: by 2002:a62:1dd3:: with SMTP id d202mr14147517pfd.99.1590893754767;  Sat, 30 May 2020 19:55:54 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id x9sm10477017pfi.13.2020.05.30.19.55.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2020 19:55:54 -0700 (PDT)
To: "Joel M. Halpern" , rfced-future@iab.org
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>    <3424f79d-72f2-4397-5cfe-c68f3f101953@gmail.com> 
From: Brian E Carpenter 
Message-ID: <0e12477e-53fa-83bc-e886-4645758859d3@gmail.com>
Date: Sun, 31 May 2020 14:55:50 +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] Who has the authority? [On the question of a living series]
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 02:55:57 -0000

On 31-May-20 12:25, Joel M. Halpern wrote:
> the stream managers clearly have a role in the operation of the RFC=20
> Series.  I am concerned that putting them in charge introduces an=20
> inherent conflict. =20

Indeed. But putting them in the editorial board, along with at-large
members, is not putting them in charge.

   Brian

> The Stream managers have very specific objectives.=20
> Up till now, they have not been selected for a broad view, but rather, =

> if I understand correctly, for a clear understanding of what their=20
> stream needs.  and particularly, what it needs now.
>=20
> Long term planning, community responsiveness, and some form of=20
> management are not their tasks.
>=20
> Could stream managers be selected and directed to have different=20
> objectives?  Presumably.  But it would make things complicated in a new=
=20
> fashion.
>=20
> And it is not at all obvious that the stream managers are more=20
> accountable to the community.  Except in very extreme cases (lets hope =

> we don't do that again) an AD who is serving as stream head is not goin=
g=20
> to get fired as an AD based on the quality of their management of the=20
> RSE.  I do not see how this is any better than the RSOC, which had many=
=20
> flaws and some benefits.
>=20
> Yours,
> Joel
>=20
> On 5/30/2020 7:48 PM, Brian E Carpenter wrote:
>> On 31-May-20 10:34, Russ Housley wrote:
>>> On 30-May-20 20:11, Eliot Lear wrote:
>>> ...
>>>>> It seems to me the questions at hand are:
>>>>>
>>>>> 1. Should we have mechanisms for creating all three kinds of
>>>>>     references?
>>>>>
>>>>> 2. What kinds of references should we encourage people to cite
>>>>>     for any given purpose?
>>>>
>>>> My fault, but these aren=E2=80=99t the questions at hand for this gr=
oup. The question at hand is this:
>>>>
>>>>   * Who has the authority to answer those questions for the series?
>>>>
>>>> Is it this group?  The RSE?  A committee overseeing the RSE?  The IE=
TF community through the RFC process (I view that as the degenerative cas=
e)?
>>>
>>> We have four stream managers.  Ir seems to me that those stream manag=
ers would be a good sounding board for the RSE to use for changes that ar=
e under consideration.  If the four stream managers are satisfied, then t=
he RSE can bring the idea to the broader technical community for further =
discussion, review, and refinement.  This might happen before or after a =
budget impact discussion with the IETF LLC, depending on the expected mag=
nitude of the budget impact.
>>>
>>> I think that creating a new group to do oversight will have the same =
pitfalls as the previous approach.
>>
>> We agree on that. I don't see Mike's proposed Editorial Board having a=
n oversight role, and contract management is surely an LLC job.
>>
>>      Brian
>>
>=20


From nobody Sun May 31 15:34: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 050D23A0770 for ; Sun, 31 May 2020 15:34: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 c_wVHiT2vdDh for ; Sun, 31 May 2020 15:34: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 3C2FA3A073D for ; Sun, 31 May 2020 15:34:14 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jfWWw-0003zH-GW; Sun, 31 May 2020 18:34:10 -0400
Date: Sun, 31 May 2020 18:34:04 -0400
From: John C Klensin 
To: "Joel M. Halpern" , Brian E Carpenter , rfced-future@iab.org
Message-ID: 
In-Reply-To: 
References:  <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com>    <3424f79d-72f2-4397-5cfe-c68f3f101953@gmail.com> 
X-Mailer: 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] Who has the authority? [On the question of a living series]
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 May 2020 22:34:23 -0000

--On Saturday, May 30, 2020 20:25 -0400 "Joel M. Halpern"
 wrote:

> the stream managers clearly have a role in the operation of
> the RFC Series.  I am concerned that putting them in charge
> introduces an inherent conflict.  The Stream managers have
> very specific objectives. Up till now, they have not been
> selected for a broad view, but rather, if I understand
> correctly, for a clear understanding of what their stream
> needs.  and particularly, what it needs now.

It seems to me that there is a more fundamental issue.  In the
present setup, two of the stream managers are chosen by the
Nomcom, not as stream managers, but for some other role.  While
we often throw the "stream manager" term around, it  has never
been clear to me whether, in the case of the IETF and IAB
Streams, the title belongs to one person or to the IESG and IAB
respectively (that ambiguity probably serves us well as long as
it isn't either abused or turned into a source of paralysis or
non-accountability).  I'm guessing that no job description for
the IETF Chair, an AD, or an IAB member has ever reached the
Nomcom with "needs to have the skills and experience needed to
contribute to the design, implementation, and strategy for a
technical publications series" high on the list of
requirements... or even on the list at all.   Similarly, I'm
guessing that the Nomcom has rarely received feedback that one
candidate should be chosen over another because the first is
more qualified for the stream manager role. I'd further guess
that, if one replaced the Nomcom with the relevant appointing
body for the other two streams, it would not change the
priorities much.  Prioritizing publications knowledge and
experience over networking knowledge and experience is just not
how we choose our leadership and we would regret changing things
so that it was.

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

> Long term planning, community responsiveness, and some form of
> management are not their tasks.
>... 
> And it is not at all obvious that the stream managers are more
> accountable to the community.  Except in very extreme cases
> (lets hope we don't do that again) an AD who is serving as
> stream head is not going to get fired as an AD based on the
> quality of their management of the RSE.  I do not see how this
> is any better than the RSOC, which had many flaws and some
> benefits.

Exactly.

best,
  john



> 
> 
> Could stream managers be selected and directed to have
> different objectives?  Presumably.  But it would make things
> complicated in a new fashion.
> 
> And it is not at all obvious that the stream managers are more
> accountable to the community.  Except in very extreme cases
> (lets hope we don't do that again) an AD who is serving as
> stream head is not going to get fired as an AD based on the
> quality of their management of the RSE.  I do not see how this
> is any better than the RSOC, which had many flaws and some
> benefits.