From nobody Mon Feb 1 00:59:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113243A0BF7 for ; Mon, 1 Feb 2021 00:59:21 -0800 (PST) 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 NCH3Vmu6ZtAr for ; Mon, 1 Feb 2021 00:59:19 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5172D3A0BF6 for ; Mon, 1 Feb 2021 00:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49533; q=dns/txt; s=iport; t=1612169958; x=1613379558; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=jYmw8yWGEW4SES8ssZRxSkeS0d1AlK0uPrZ+fCYwt2I=; b=hhGcE2hOzxukODzE5ylycnoYLmUIHPcczTAmU6dU9J66KnjX+rVCh94y RlN2N3ZAQToMgBQYdiaccNHrL763gJfrdWQxGZVQVYN7w7F+386TLAxQq vN2qBnQGR8O6EF54wGS27k7l/10Cu4j4PPs3ZvU6FW3dDsTXBSwlhNKhR A=; X-Files: PastedGraphic-3.png, signature.asc : 31360, 488 X-IPAS-Result: =?us-ascii?q?A0AjBwBlwhdg/xbLJq1iHQEBAQEJARIBBQUBgg+BLk6Be?= =?us-ascii?q?wEjEoRwiQSce4JjhToEBwEBAQoBAgEBLwQBAYRKAoF5JjgTAgMBAQEDAgMBA?= =?us-ascii?q?QEBBQEBAQIBBgRxhW6FdAYFAR1WEAsECg8BAQEiAgICFQEOMQYSBw6DEgGDB?= =?us-ascii?q?q9WdoEyhVmEbxCBOIFTgVuDTYE+AoUDQYIAgTgcglY+h1c0giwEgWZBGYEQE?= =?us-ascii?q?IIkAZxzkHSLRoMAgymBOYJslC8DH5Mrj2ixPWKDcgIEBgUCFoFtI4FXMxoIG?= =?us-ascii?q?xVlAYI/PRIZDY5YbgEMjRhAA2cCBgEJAQEDCYwVAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,392,1602547200"; d="asc'?png'150?scan'150,208,217,150";a="30676089" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Feb 2021 08:59:14 +0000 Received: from [10.209.198.254] ([10.209.198.254]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 1118xDOE027124 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Feb 2021 08:59:13 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A03CCD77-C4E6-4ED6-A9B2-90CA59703982"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 1 Feb 2021 09:59:12 +0100 In-Reply-To: Cc: rfced-future@iab.org To: Martin Thomson References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> <2625bf72-9eb2-4040-eeb9-f1c26b225e46@joelhalpern.com> <9d5ab6db-9422-8036-da3f-8ae46f024d19@gmail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.209.198.254, [10.209.198.254] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 08:59:21 -0000 --Apple-Mail=_A03CCD77-C4E6-4ED6-A9B2-90CA59703982 Content-Type: multipart/alternative; boundary="Apple-Mail=_507AE605-0622-403F-B9CA-991B6EBC797F" --Apple-Mail=_507AE605-0622-403F-B9CA-991B6EBC797F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin, Martin and all, Let us put aside blocks for the moment, assuming that we are likely to = find agreement that a block can be overridden. That assumption is worth = discussing, of course. I=E2=80=99ve tried to put this into tabular form = so that people have a feel for what we=E2=80=99re talking about: If the RSE does not have a vote, but convinces another stream manager to = block, the case we seem most worried about, then it takes three stream = managers to override. If the RSE does have a vote and also convinces a = stream manager to join, it still requires three stream managers to = override, and so there is no difference. If on the other hand, the block has to be sustained by a vote, then = there is a difference. In this case, if the RSE has a vote, there needs = to be agreement of two steam managers to sustain. If the RSE doesn=E2=80=99= t have a vote then three stream managers are needed to sustain. And if two votes are required to block rather than a majority and the = RSE has no vote, this means that all four stream managers would have to = vote to override the RSE. Thus the voting rules are important to understand. Obviously I=E2=80=99ve= only delved into one scenario, and there are others. And there are of = course other voting rules. One challenge here is to determine which is = the dog and which is the tail: Is it important to be respect streams so = that damage cannot occur? Is it important to support the will of the = WG? And of course, the parameters of why one can vote no matter. Eliot --Apple-Mail=_507AE605-0622-403F-B9CA-991B6EBC797F Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_0F3CCB33-92DA-4213-A16E-0E704662CF64" --Apple-Mail=_0F3CCB33-92DA-4213-A16E-0E704662CF64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Martin,

Martin = and all,

Let = us put aside blocks for the moment, assuming that = we are likely to find agreement that a block can be overridden. =  That assumption is worth discussing, of course.  I=E2=80=99ve = tried to put this into tabular form so that people have a feel for what = we=E2=80=99re talking about:

If the RSE does not have a vote, but = convinces another stream manager to block, the case we seem most worried = about, then it takes three stream managers to override.  If the = RSE does have a vote and also convinces a stream manager to join, it still requires three stream managers to override, = and so there is no difference.

If on the other hand, the block has to = be sustained by a vote, then there is a difference.  In this case, = if the RSE has a vote, there needs to be agreement of two steam managers = to sustain.  If the RSE doesn=E2=80=99t have a vote then three = stream managers are needed to sustain.

And if two votes are required to block = rather than a majority and the RSE has no vote, this means that all four = stream managers would have to vote to override the RSE.

Thus the voting rules = are important to understand.  Obviously I=E2=80=99ve only delved = into one scenario, and there are others.  And there are of course = other voting rules.  One challenge here is to determine which is = the dog and which is the tail: Is it important to be respect streams so = that damage cannot occur?  Is it important to support the will of = the WG?  And of course, the parameters of why one can vote no = matter. 

Eliot
= --Apple-Mail=_0F3CCB33-92DA-4213-A16E-0E704662CF64 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-3.png Content-Type: image/png; x-unix-mode=0666; name="PastedGraphic-3.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAAA28AAADyCAYAAADa3/38AAABQWlDQ1BJQ0MgUHJvZmlsZQAAKJFj YGASSCwoyGFhYGDIzSspCnJ3UoiIjFJgf8rAxMDIwMEgzyCUmFxc4BgQ4ANUwgCjUcG3a0C1QHBZ F2TWdrmzs17Mkaz0VvC7FjX960NM9SiAKyW1OBlI/wHixOSCohIGBsYEIFu5vKQAxG4BskWKgI4C smeA2OkQ9hoQOwnCPgBWExLkDGRfAbIFkjMSU4DsJ0C2ThKSeDoSG2ovCLAbmRu7+ngQcCkZoCS1 ogREO+cXVBZlpmeUKDgCQyhVwTMvWU9HwcjAyJCBARTeENWfb4DDkVGMAyFWIcTAYPufgYFpCkIs qoqBYd0tBgYxZoSYihcDg7A6A8OuqQWJRYlwBzB+YylOMzaCsLm3MzCwTvv//3M40MuaDAx/r/// /3v7//9/lzEwMAPNO/ANAMsZXnSzmhgtAAAAVmVYSWZNTQAqAAAACAABh2kABAAAAAEAAAAaAAAA AAADkoYABwAAABIAAABEoAIABAAAAAEAAANvoAMABAAAAAEAAADyAAAAAEFTQ0lJAAAAU2NyZWVu c2hvdE9eyDAAAAHWaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9 ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA2LjAuMCI+CiAgIDxyZGY6UkRGIHht bG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAg ICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGlt ZW5zaW9uPjI0MjwvZXhpZjpQaXhlbFlEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWERp bWVuc2lvbj44Nzk8L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICAgICAgICA8ZXhpZjpVc2VyQ29t bWVudD5TY3JlZW5zaG90PC9leGlmOlVzZXJDb21tZW50PgogICAgICA8L3JkZjpEZXNjcmlwdGlv bj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KdVaIrAAAQABJREFUeAHsnQm4FMXV9w+LIIuA gIC4gREQlVUQQ2RRFgPuoiIQRQE1CHGPewy+L4rRNyIuGNfEJQZUUBFQEL4IKCAIiLIKEWQTEJA9 yNZf/Q/W0NO3u6dn7tw7c+f+63nu7e7qWk796lRNn66lSzjGiXHz5s2TZs2a4ZSOBIo8Aepzka/C nCkAdTFnqrLIF4S6WOSrkAUoQAJsHwUIl0knTaBEiRLyi4mWJ27JPD70IAESIAESIAESIAESIAES IAESyDoCpfGmAa558+ZZJxwFIgESIAESIAESIAESIAESIIHiRsDaaN5yl7DTJjE8R0cCJEACJEAC JEACJEACJEACJJBZApw2mVn+zJ0ESIAESIAESIAESIAESIAE8kWAa97yhY+RSYAESIAESIAESIAE SIAESKBwCNB4KxzOzIUESIAESIAESIAESIAESIAE8kWAxlu+8DEyCZAACZAACZAACZAACZAACRQO ARpvhcOZuZAACZAACZAACZAACZAACZBAvgjQeMsXPkYmARIgARIgARIgARIgARIggcIhQOOtcDgz lyJAAJ/LqFWrllSvXj1paevXry+vvvqqPPPMM0nHZQR/Ao888oi88MILctppp/kHyGFf6mJ2VW5x 1sXsqglKQwLZRYB9dXbVRxRpcqI/x3fe4EyB+UcGOakDJ5xwgrNx40Zn27Zt+rd161ZnwYIFzr33 3uuUK1dOy3znnXc68Ldu0aJFTr169RxvXJvG5MmT41h17tzZRnVMZx53ryi1rebNmzutW7d2Kleu nPEy2Pq47LLL0ipLJsvo1SfqYvDvTibrydtmc1EXvWXkdbAukk3xY8O+Or11zv48NZ6xB0vPidhr dk6pgSW37OfWuHFjq+Z5jvfdd5/TtWvXmP+OHTucPXv26PWFF17oBMX98ssv4wyKXDHeLAiUJ9O6 XVAPzJksY5A+QSbqYnxfksl68up+Luqit4y8jtc/8ijePNhXp7f+2Z+nxtNy8x5Lmw6KjgSKDYFG jRrJzz//LFOnTtUpksZIETPKpOX/73//K8cff7xgGsQll1wiCxculKOOOirGxrw5kqVLl+r1/v37 Y/7ek6uuuko6dOggW7Zskddee00WL16saXbs2FHwV7NmTb3373//W8aOHYsXKHL++edLly5dVJbl y5fLSy+9JGa0MJY0ZAqLj4BmFFHuuOMOKVWqlLz++uuycuVKTW/gwIFSsmRJGTp0qBw4cEAgX7Nm zaR8+fKyZMkS+ec//ymbN2+WW2+9NZbf9ddfr9MVn3rqKalUqZL07NlTmjZtKsawlc8++0xGjRql cscimJMwGevUqSO9e/cWM+KpsoDPTz/9pHKaUU5Nxrzp1DAnn3yyfPHFF1K2bFl38nqe6TLmESgf HtRF6qJVn1Tam43LIwmQQMESKKp9dd26dRP+7uI31e+ZYMOGDTGomf7d5bNFrCoOn1hrzvhk/E07 ZWAdFIQOuN+gnXHGGU7FihWd1atXq+pPmDDB+fOf/2ybgfPKK684psOLtQV3XIxGYSoF/sqUKRML A5ndI2+xxMwJpllWq1bNMcaZ2zt2bowip1u3brFre3L11VfHpR8W3zKrUKGCYwxTTeKhhx7S+MYI tUk6xmh0ZsyYEbu2J5hSWrt2bXsZdzSdtjN37tw4P1w88cQTcfJBhjAZw/iYNYbKaN26dXnygYd7 2mSmy2hZp3p06xN1kbroVfhk2luqOsh4/J2lDiTWgVzoqxP97qK/CXsmsHqS6d/d4vxs4f2NsNec NkmjNc9DuG2wuXJ0d8JmpMn58ccfrf47v/vd7xzzVs3Zu3dvzM+MTjlmlMpBh+WOGwtgTn7729/G cXN3klhPZzYviQVHWKwjmz59utO3b1+nTZs2zldffaX3zcicY0bZ9HzevHnO6aef7tx+++1OkyZN 4tIPi++up/fee0/T+vrrbzQ+jFG4OXPmOGbkS8/x709/+pPmg7LCwYC98cYb9Rz/IH+fPn2ca6+9 Vv12797tmJFBx4zE6fX+ffvzrIsLkzGMD9L9/e9/r+ni37Bhw5SV9XAbbyhrJsvoZp3KuVufqIuH api6mFp7S0X/GCfxQzsZkRF0IBf66kS/u4meCdxtIZO/u8X52cI+B3mPNN5ovMUZCe7Gmivn7k7Y 3QDM9L9Y2c866yxn5syZ7tvOo48+GteB/+c//3Fmz56tfy1btozFBSd3J1mjRg2ndOnSzq5duzQ9 jK4hTIsWLdRoGj58uLNixQq998EHHziDBg2K5QsDrlevXr6bngTFd9cTRuysO/XUUx0zdVMvsSEL 8oWb9cWsmOzjxo1Tv3feeUf99ML8Q3mQLgwp6959911n2rRp9tJB+u68w8qYiM/TTz+t6YIv0qlS pYoDgxHOa7xluozeMidzTV10HOqi46SrvSWjewxLo4Q6EF0HcqGvTvS7G+WZwOpMpn93g55/EpWx qD9b6EOQzz+ueTOaSVd8CJgpinLDDTeIGQ0T8zZHGjZsqGvSZs2aJWeffbZ06tRJRo4cKUcffbS0 b99eRowYEYNz0UUXiV2fFfP0OTEje7oezEyZ1HVlmK9tDBAZPXq0T2iR5557TrCeDuljXdmbb74p xgDUNWo2Qlh8GwbHSZMmyb59++SII46Qxx9/XMsB/zFjxsjgwYNxKmvXrdUj/pkRRz0PWsNnpnzG wppOUs/Npi669m3nzp2xeziJKqMfH/CGW7NmjR7NBhEqG+bae10my+iVJT/X1EXqold/kmlv3ri8 JgESKBgCRbWvdtPw+921/U2UZ4JM/u7y2cJdk4fO+Z23vEzok8MEvv32W8EGHuZFhm6wcfPNNwv+ unfvrht+YDMOhIFDmHQ5dP5wZnRP0GFiQxI45IFNUbBhgZkyKfPnz1d/85ZJj/ZfWHwbBsdNmzbJ +PHj1QvGIJwZzZNly5bJ999/r9dt27RV4xDfs2vZ8iz1c2+OAg9s3IINQ1atWqX3v/vuO/XD5iWQ H0amNbQ0gPkXVUYb3n1cv369XrZr1043dEFnjbz8XCbL6CdPqn7URRHq4iHtSaW9pap3jEcCJJAc gaLaVycqZTLPBJn83eWzhU9N2tE4cyvPFCj6kUku6IB7+gM2iUCZzC6PqvqYmodvtsGZ3Sad7du3 6zn+3X///XHTJuGHtXH4wxRLNxv30L0ZadN7dgMOTIN8/vnnEV2nUrqnHr7//vuOGenTfDGFEhuc wCG8O/2w+O5wOO/Ro4emYf/dddddmhbW2lmHrc/Nbo/20rHTQK3MuIEw55xzTiyMMeSciRMn6ppB TCH15hsmYyI+7vtYT+d2xpDLk1emyugtc7LX1EXqInQ7He0tWd1jeP6eUwei60Au9NXu31W/55Io zwRuncnU725xfrZwPwu5z/HmX527gngevYGTVfazMlMjrZo7DRo0UEMAm4hYd91118XWhsEP33kz Uw51R0mzxX3su282PI52bZat//POO09vY7dH20marfrVz2zDq+vD7Do3eNoNUrCODGuA7MYhuIc1 adjR0qaNI9aXBcV3h8M5dm+0RijyOeWUU2JpDRgwIHYPeZntgB0z6hi7f9NNN8VkgXGHsnjjHDx4 0DGfIojFsfmHyZiIj/mUgW6GYjlgN1C7sYwZQcyTV6bKaMua6pG6SF1MV3tLVQcZL/t/s1hHma+j XOirE/3uQs+8v+/eZwK3Lmbqd7c4P1vgOc3PlYCnqRydQoYjHQnkIgGsnTJGh37jzZYPfsY4ETP6 pmvEjj32WP1Gmhl9igtnwyc64rtpWDtmDCYNinVn5pMCYjYuiV0fd9xxgu/J4RsqZjdLzQdxzAYd gmmMWE/m/r6KO0+kFxTfHQ7nZsMUOfLIIzV9rIFzO3zzDekYQ0lQVq+DLFiDhjnydl2bjQMZ8E04 rOfzc2EyJuKD9JA3/jCdA3WDOFYGb36ZKqNXjmSvqYuHiVm9oi6m1t4Ok+QZCZBAugnkQl8d5Xc3 UT/s5pqp393i+mzxi4nmrgI9p/GWBwk9SIAESIAESIAESIAESIAESCBzBIKMN25Ykrk6Yc4kQAIk QAIkQAIkQAIkQAIkEJkAjbfIqBiQBEiABEiABEiABEiABEiABDJHgMZb5tgzZxIgARIgARIgARIg ARIgARKITIDGW2RUDEgCJEACJEACJEACJEACJEACmSNA4y1z7JkzCZAACZAACZAACZAACZAACUQm UDpySAYkgUIkYD4CrdvVJ5ul+TaZ/OpXv0o2GsOTQCAB6mIgGt4oZALUxUIGzuyKFAG2jyJVXTkv bEHqI423nFefollAfGcMf3QkkGkC1MVM1wDztwSoi5YEjySQlwDbR14m9MkcgYLUR06bzFy9MucQ As5BR/B9i6T/TLxcco888oi88MILctppp+VSsYpUWdKti8ccc4ygXkePHi3PPfeclC1bNpAHOv8r rrhCOnXqpGHq168vr776qjzzzDOBcXgjdwmkWxejkCpRooTUqlVLqlevHiV4XBjqaxwOXhQwgXS3 D/bVBVxhOZ58uvUxDpd5OFZnPPHUyz8yyAod+PHHH50DBw4k/Yd4uaTHW7du1fZ52WWX5VS5ilId pVsX33jjjV96XcfZu3evYwy0wLq95pprNCzaQpUqVZzOnTvH4pqH6sB4RYkvZY3+u5tOXTzhhBOc jRs3Otu2bdM/9DULFixw7r33XqdcuXKqW3feeadj+yAo3qJFi5x69eo53rg2jcmTJ8fpZHHS1+bN mzutW7d2KleuHMeA+h1dv/PLKp3tA7Kwry68ustv3Wdj/HToY+wH33PCaZOmxulIgARIoLAItG/f XrN65ZVXZPz48bJr167ArFetWiXm4VnMQ7bs27cvMBxvkECyBDCqi5EFtzOGhwwZMkQw2jZ//nz5 v//7P729c+dOOeKII6Rhw4bSoEEDgV564yIg4hdXN2fOHC36+eefLxMnTiyuGHKq3Oyrc6o6c6ow NN5yqjpzpzDmJYNgyBnujTffkA0bNogZfchTwJIlS0qNGjWk97W99R7i+Tn8oHbp0kUfLpYvXy4v vfSSVKpUSXr16iXmrbE89dRTGu3WW28VM8Ih//znPwXh8DDyu9/9Tho3biw///yzfPDBB2LeLgf6 I82ePXtK06ZNZc+ePfLZZ5/JqFGjdPonMkh037zRlt69e8vJJ58sX3zxRZ4pdX7lwIM9XcERSJcu 4oH49ttvl+OPP16FrVq1qpQpU0aNMkyL7Nixo9SsWVO2bNki//73v2Xs2LGycuVKGTp0qPz3v/8N NPKoEwVX99mWcrp00VuuRo0aaf82depUnSJpRsxihhh0DzoL/b3kkktk4cKFctRRR8WSMCNOsnTp Ur3ev39/zN97ctVVV0mHDh1Uv1977TVZvHixpgm999N9lDWRbtetW1f7SzNiKPgtQPrYtOr1118X M0qoIphRREHezZo1k/Lly8uSJUu0f8dvinUIc8cdd0ipUqU0Ltod+v6BAwdqumiD+P3xS2fz5s2C 3w3rrr/+ep3mjt+URP29jcNjegikq32wr05PfRT3VNKlj34cabz5UaFfVhHAD+sPP/ygxlDp0qX1 Bx8C4kEBD7/HHXdcqLzdunWTd999Ny4MdgHCQ8mgQYNk9+7dMePt4Ycf1h/tr7/+WvOcPn163Hqz P/zhD7qRyueff+7r///+3//ThwSbGX7U8fb6j3/8o6Acn376aeD9atWqqcF27LHHanQ8BLhdUDlG jBjhDsbzAiSQH13Eg9xf//rXmHRmKqzUqVNHHzY//vjjmD9OYOThxcKmTZsEOglnR0H04pd/1Ak3 jeJ1nh9d9COFPtYaX2Y6r/aPCId8nnzySRk8eLDA6ILDyyzrMAIHPYVzG0T2vj26+6n+/fvrC6oW LVpIkO7jZZlfv+1Ox0zhlD//+c82i9gR6WPXYYxqo08+++yzY/dwYqaG6gu2devWqT8Mv4ceekh/ T+DxP//zP9LejJCjzHAvvviivP/++4HpuNvm1VdfLfjDWuWw/l4T5r8CI5Cf9sG+usCqpdgmnB99 9IPGDUv8qNAv4wTwxuKgc1D/zjmnjTRp0kTf9mJzhwoVKuiIFN7+nnHGGdK2bdtYWMTzut/+9rfq 9dVXX2l4vGHFW99EDj/AdqMQ/BDjxx2jXHhg9vO/+OKL1TCDUdi1a1cZNmyYZnH7bberQXjllVcm vG8Nt6efflpmzJgRJ2Kq5YhLhBdJE0iXLmKE98Ybb4zlj9FdPHju2LFD67pfv36qy5iuBodRh0SO OpGIUG7dT5cueqnASFqxYkVsVNis9dENdexU3T59+uhMBIxAof91uwkTJug0SkylPO+889y34s4x Yvf3v/9d/fBw3LJly1DdT1a3/dLHSJk13NB/o+8/ePCgTvm84YYbYvLByMMUZrgrrrhSj+jP4ebO nSuQJSydm266ScPiH8rYt29fSdTfxyLwJG0E0tU+2FenrUqKdULp0kc/iDTe/KjQL+ME8ANr/6pX rybnnnuuvknFSBtGyvCmFFN5zjv3PJ3mY8Pi6HVr165VL0xlfPPNN9UAw8haIofwcHio+f3vfy// +7//q9PagvzPPPNMDY83LPjxttelSpcSGGX2Oui+NQi//PJLnYYDAxCGoHWplsPG5zE1Am7dyq8u YroujDU4TKf98MMPBaO7t9xyi9SuXVt69OgRm66G6buJHHUiEaHcup9OXXSTwTo2u5skZhWgn/zm m2/knHPO0dkACIs+97bbbpMHHnjAHVW+++47QZ+FP0whDHIw7PDyAv03HKYNh+l+srrtTR9r+lq1 aqV5zZ41W/tvGJ92pA8v/txu5MiRetmo0Rly6qmnCkbG4d56662E6WBkzjqMDGJH2ET9vQ3PY/oI pLN9sK9OX70U15TSqY9ehpw26SXC66wkAOPHrjvDwwLWBmE07vgTDq0fChMa27FjXcZFF12kU2Xw YIJ1ckgHDusc/BzCwGE9hdsF+WPao3VYMwKHB3WsfcOC/0T38bABt2bNGj1iowpMX4KxBxdUDjyQ 0BUegfzoop+UeEjEZwNScdSJVKjlTpx06SJmE2AkCiNMZsdE3ZgEsxNmzZqlI05YkwnjBn0UphO6 py6iX7Xry8LImp3XdO0vRjWw9gzrisJ0P1nd9kvf9rlr1x16gQf50KfC2SmiemH+TZo0SdefYmOW xx9/PPad0TFjxsSmT0ZJx6Zn88a13++BDcdjwRFIV/uwEobpqw0TdExWn4PSoX/RJZBOfeTIW9HV g5yW/MCBwyNv9u0FFpy3adNGp9u0a9dOj/aePSKe12F6JdaPnX766bqDGu5jrQXWVMBhKiYW7GOj EUznsW716tV6irfPaHQwGDHNLcgf04bgYBRiVBBp4QccI3UwyBLdX79+vcZH2ZAXfijc8gSVQyPx X4ERSKcu+gmJB2e4mTNnqr7gjS8cplwkctSJRIRy635B6eK3336rm3NA52BU3XzzzfrXvXt3fXmE jZcQBi6KXkalHqb76dDt77//XkVp26atvrDD6GLLlmepn3ejJ6zbs1MnYZDCzZs3T5YtWybJpIO+ H78pifp7zYD/0kqgoNqHFTJMX22YoGM69DkobfpnJ4GC1EeOvGVnnVOqAALYqhp/yThsfY2dJrGD H3Yng9u+fbusNDuKWec3jRLTa8x3jvQNrA2LBxtMZ/Tzx7Sd++67TxfiY7QOu5rB4EReWDyPB4Ow +5988oncddddmt/aNWsF0y3dLqgc7jA8LzwCqeiin3R2GiVGlrGbKV4WRHXUiaikcjtcOnQRmzih j7rgggt02jfW3KJPw8wBrH3DwyfcuHHj4mBirZldG4f1YXZtWFyggIsw3U+HbmNaMjaLqlqtqhqf MDztdGTMwPA6jC5iR03rMGUSLko62PAFL/nwCRBs8HLhhReG9vc2Dx4LnkA62gekDNPXRKVIhz4n yoP3iwaBdOgjR96KRl1TynwQwNQfLLLHAnSMZGH9w6OPPqrGlXv3PxhodvQLDyOYRoP1HZhmg7V2 +Pv0009l2rRpvv6zZ8/Wt9fo4LHlP6YaYeQNa0jg8PYaW08H3Ud+2OQEo4gw3DBaZ3dxwxSfoHLk Aw2jZoDAvr2HvtdmH3hR59A9TCWD4Wb9Ued2apd3qpe9pk5koAJzJEurZyiOPX/22We1dJiqjU1L sO3+kUceqYYbZio88cQTuuspXkjZmQuIgKmG+PNOQffqL8Ja3UWeYbofRbcTpY++2va52PofhhtG 3LAZFfprr8MLNPuADvmwwyRclHSwKyz6bjgYiej3bd5+vwcakP+ymgD76qyunmItXAnTyejcHIwo 0JFAthDA1EQsaE/W4RtZ+KH0OvxoY8oMfpi921ljHQd+2DE1Bu0AD9FYo2YdpsBgMwnsSOaeahPk j4X9+HwBHmawgB9rPNwu0X3Iij8/ecLK4c6D5+kjkG5dhF7gRYD749zwg85ggxroJ1424OEYD6fQ RxztQ6/3mjqRvrrO9pTSrYsw0mBwuA0x+KEfxMYi0EuMJsEow7b67nBRWXn11av/YbofRbcTpQ85 bZ+Lb7XZzwMEyY/P0cBgRVmtUWvDJkoH8uL3BOvv7G+IjYNy+v0e2LR5zD+BdLcPr65CwjB99eqi 9zqKPuefAlPIFgLp0MdfTLQ8RaLxlgcJPbKBwNdff2MMmMpJi7J16zazsUmjpOMxAgkEEaAuBpGh f2EToC4WNnHmV5QIsH0UpdrKfVnToY803nJfT1hCEiABEiABEiABEiABEiCBHCAQZLxxzVsOVC6L QAIkQAIkQAIkQAIkQAIkkPsESmMrXDoSIAESIAESIAESIAESIAESIIHsIBBko8WteQsansuOIlAK EohOAAqPbfrpSCDTBKiLma4B5m8JUBctCR5JIC8Bto+8TOiTOQLYOCrILuO0yczVC3MmARIgARIg ARIgARIgARIggcgEaLxFRsWAJEACJEACJEACJEACJEACJJA5AjTeMseeOZMACZAACZAACZAACZAA CZBAZAI03iKjYkASIAESIAESIAESIAESIAESyBwBGm+ZY8+cSYAESIAESIAESIAESIAESCAyARpv kVExIAmQAAmQAAmQAAmQAAmQAAlkjgCNt8yxZ84kQAIkQAIkQAIkQAIkQAIkEJkAjbfIqBiQBEiA BEiABEiABEiABEiABDJHgMZb5tgzZxIgARIgARIgARIgARIgARKITIDGW2RUDEgCJEACJEACJEAC JEACJEACmSNA4y1z7JkzCZAACZAACZAACZAACZAACUQmQOMtMioGJAESIAESIAESIAESIAESIIHM EaDxljn2zJkESIAESIAESIAESIAESIAEIhOg8RYZFQOSAAmQAAmQAAmQAAmQAAmQQOYI0HjLHHvm TAIkQAIkQAIkQAIkQAIkQAKRCdB4i4yKAUmABEiABEiABEiABEiABEggcwRovGWOPXMmARIgARIg ARIgARIgARIggcgEaLxFRsWAJEACJEACJEACJEACJEACJJA5AjTeMseeOZMACZAACZAACZAACZAA CZBAZAI03iKjYkASIAESIAESIAESIAESIAESyBwBGm+ZY8+cSYAESIAESIAESIAESIAESCAyARpv kVExIAmQAAmQAAmQAAmQAAmQAAlkjgCNt8yxZ84kQAIkQAIkQAIkQAIkQAIkEJkAjbfIqBiQBEiA BEiABEiABEiABEiABDJHgMZb5tgzZxIgARIgARIgARIgARIgARKITIDGW2RUDEgCJEACJEACJEAC JEACJEACmSNA4y1z7JkzCZAACZAACZAACZAACZAACUQmQOMtMioGJAESIAESIAESIAESIAESIIHM ESiduayZMwkUHoEJEybIiy++KKtWrZJjjz1W7rzzTmnXrl3hCcCcMkrgwQcflAULFqgMZcuWld/8 5jfSv39/OeKII9Tvm28WyKOPPiLLly+Xo48+Wnr37i29evXSe+64thCXXHKJXH/99fYyqaM7vUzL AsG3bdsm9913n/z444/yzjvvJFUWBiYBEiABEiABEihcAhx5K1zezC0DBLZu3SoXXnihPqQ2a9ZM Zs6cKV27dpVly5YlJU337t2lW7duScVh4Owg8O6778rixYulevXqsnHjRrn11lsFBhjcls1bpGPH DjJv3jzp1KmTHHXUUXL//ffHBEfcRYsWaVzExx/CpOqySZb3339fTj/9dHn++efls88+S6lIbBcp YWMkEiABEiABEkiJAEfeUsLGSEWJQOXKlWX27NnStGlTFbtjx46CB06MxtWrVy9PUQ4ePKjhf/rp Jzn77LOlSpUqOmK3bt062b9/vyxZskSqVasmxxxzjCxcuFDq1q2rhsGuXbukbdu2mt6OHTtkzpw5 UqlSJWnSuImUKl0qls/8+fNl7dq1Gq9hw4Yxf5sW4n711Vdy5plnqqGwfft2mT59upx66qlSp06d WHj3SSpxE8mxe/duNWiaNGkiNWrUcGcnQXERaOnSpbJy5UqpVauWYGQJI1k1a9bU+EFcrPwwsCxH v3qIE8J1gVHU22+/XS699FKXb/wpeL788svqiVG1t956S8B2ytQpatDBqGrTpo3e37lzZ1zkFi1a xOLG3UjxorBkScTlySeflL59+8r69etlzJgxoaXxqw+MZLNdHMZWGO3icG48IwESIAESKJYEnF+c Kbw95ZEEijyBuXPnBpbho48+cqDvZhplnjDGcHCMkecYo8sxBodjDA8NY4wsjYN4+OvRo4f6ly9f 3jEGXuyemYLmjBw5UuMhLsIi7urVqx1jDOl56dKlHWP86T1jRMRkQFqdO3d2ypQpo/cQf+jQoSoH 0ilZsqQzfPjwWHj3STJxo8jRpUsXxxheKkeFChUc82Cv2SWK27NnT8dMRdTyW1ZmlFPjBnHBTT+O fvWgCfn8q127tvO3v/3N584hrwYNGsTqDD5myqTyRH1PmzZNy9mnTx9n/779edLwxs0TIIGHVxe9 6RWkLIm4WNEHDhzoGGPbXuY5sl0c0tFsaBd5KicJD68uJhGVQUkg5wmwfeR8FRepAuIZKsjF7oQF CopMfxLIVgJhnbAZdVPDZM2atXnEHz16tD7Im9E1vTd58mQ97tmzxzEjdo4ZyXDwILt37171h9GB v7FjxzrmrbuzZcsWNcyuu+46x4xUOJADhhoMAxg+Dz/8sGOm7Wlcs/ZJ8zKjHrG0EHbixInO8mXL HTPip/cHDx7swCiEkWhG+TSs9x9kiBo3ihxVq1Z1xo0b55h1UI4ZnXRat26tWYbF/fLLL1Xe9957 T/lcfPHFKi84hHFBwl6OQfXgLbe9TmSkwGBq3ry5M2TIEMesZ9P679evn43uXHTRRSp7/fr1HTM6 p3VnbyIuuJsps/p31VVXOQcOHLC3Ex69uliYsiTiYoVPZLwF1QfbReG2C1tfqR69uphqOoxHArlI gO0jF2u16JYpzC7jmjdDh674EMDUsLfffltuueUWOe642nkKftJJJ0mJEiV0zROm/5133nkaBtP/ SpUqJWbUTIyhEdvoAjfNg69ccMEF0rhxY5kyZYps3rxZGjVqJJiGhw0wTjjhBDE/ClKuXDl56KGH ND2suzMGkp5j2pl1mPqHdVe/OuVXgumKmIb5wAMP6PRLY2DoFDUb1nuMGjeKHHfccYeuC8T6Lkwz xTRPuLC4mHoHh6md2AgE6wuxGQZ4hnHRSOafm2NQPdiwON5zzz06HRNTMn/44YfYtTFYZN++fe6g em5GP+X111+XN954Q04++WQxo5ixMB988IGYkTsxRpkYo07MCKhgmqB1KA/qy/5Z/1SPBSlLslyi lCGoPtguCrddRKkrhiEBEiABEshtAlzzltv1y9K5CGBDCjMiJh06dJAhjw5x3Tl8akZn5IUXXhAz 2iVYj2ZGWXRtlJmyeDiQ5wwGjnVr1qzRUxgJZvqjnuPBH4adGa0TM61Q1xYdf/zxNgpGv2PnNg48 jjzySF1jZ2/iGsZFkIsaN1k5KlasGJMjLK4ZndMyg9m5556rxisMUbgwLrY8bo5R6uHaa69VAxHx BwwYIJdffrnWLQxsMPc6GKFY54Y/rHkbNmyY3HXXXRoMBuZNN90k/fr2kwEDB6gOwPhGWeCwRg27 labLFaQsyXKJUqYo9eFNx12fYfUfplM2zai6bcO7j1HjJitHJtqFu1w8JwESIAESKJ4Egp9IiycP ljpHCWCTEewwiREXM60vbgMRb5FvuOEGWbFihTz22GNi1mmJWSMXC+I3ohO7aU6sUfbKK6/IrFmz Yn/YKAP5jho1Ssx0RPnuu+/kzTffdEcttPP8yBEW10wdFbM+TjcNwYYf2LHxtdde03KFcQkqeFg9 IA52Sbz66qv1D4YtNhXB9RVXXBGUpPrDgG7VqpXusOg2nHETG8tgBBMOu1IWtCsIWVLlkqisYfXB dhHcttPdLhLVE++TAAmQAAnkNgGOvOV2/bJ0hsCmTZt0GpxZnyN333237twIMJgChwd+t4NxhR0I MYqDqWJwdhQHu05i9G7GjBlqpGA0zevat2+vO0TedtttOlJTs0ZN+XTKp5qGWS+mwTEF8fvvv5dB gwZ5oxfKdX7kCIsLQwifZfj666/1W3oYbfnwww/VmArjgumgXhdWD96wqVxjaiSMkfHjx+sW+Zi6 im+7YXdQsy5R66tdu/axpPENNEz9tO7EE0/U3ULtdX6OmZTlP8v/I2Y9omzYsEFHV2fPmi0Vj6qo o87uMoXVB9uFSGG1C3ed8JwESIAESKB4EuDIW/Gs92JVanyjC2uMYFjgEwHnn3++/mF6mddhBAEj L3ggxagIptfZqX94yP75558F0wMx5Q4O0yndUyoRD1Mmkd9pp50m1apX0zVUMA6QNz49gI87YwQQ 64VsGvboTsubtvdaI//yz3sv7Do/coTFhbGLdYH4NAOOZgMTufLKKwXb0Ydx8St7WD24y23PYYRh 1C3IgQdksg71iml9I0aM0M8DTJ06VadctmzZUuXG+rdGjc7Q4DDoJk2aJDBA7R8MvFRdYcqSiMs1 114jZ7U6Sz/OjZccOLffv3OXL6w+2C4ktG2ns12464TnJEACJEACxZNACezDgqJjzYd3ClHxRMJS 5wIBjJBhw4xUHNa+rF61WmrUrJHnY8ww3rAxB0Ze0GYwmgcjDOdeh2l3uI8NS9z3ER+bnsAowH1M +YPzpmWnotmRP7RP5G/Du/NLJW5UObBxB2Sxxiby9YuLh36MKOIbddaBEzZdcU8R9ePilR/xw+rB ph/1iLSwFg6Gk3XwK1WyVGwKLTY9wZpCO8XThsvv0auLmZQlP2UJqw+2i0NkC6Nd5KcOvbqYn7QY lwRyjQDbR67VaNEuT5hdxmmTRbtuKX0BEMAGB9jt0c/BgLHTKXHfz5Cy8bwftrb++Hi1de747nPc t0abDYuG7A1j73n9o8SNKgcMHrfhhjz94p5yyik6TRKjc/j4OXbYxBRR8008K6Ye/bh45UfAsHqI SzDChXvTChvc63fsscfaWwV69OaLzLx+hSVLMgWFjGwXh4llql0cloBnJEACJEACxZEAjbfiWOss MwkUAAFs8AIDbvr06bJgwQKdGopzbA5CRwLFlQDbRXGteZabBEiABAqGAKdNFgxXppphApz+kOEK YPYxAtTFGAqeZJgAdTHDFcDss5oA20dWV0+xEy5s2uThBSDFDgsLTAIkQAIkQAIkQAIkQAIkQAJF hwCNt6JTV5SUBEiABEiABEiABEiABEigGBOg8VaMK59FJwESIAESIAESIAESIAESKDoEaLwVnbqi pCRAAiRAAiRAAiRAAiRAAsWYAI23Ylz5LDoJkAAJkAAJkAAJkAAJkEDRIUDjrejUVSRJ58+fL2PG jIkUloFIgARIgARIgARIgARIgASKDoFA423QoEFy+eWXywcffOBbmn/84x9y6aWXyosvvuh73+v5 61//Wv74xz96vSNf79y5Uxo0aCDPPvts5Di5GDARh5deekluu+22XCx6Rss0fvx4ueyyy6RFixZy wQUXyCeffJJReZg5CZAACeSXAPu1/BJk/FwmMGHCBOnWrZu0bNlSLr74YpkyZUouF5dlK0IEAo23 ESNGyHvvvSe33nqrOI4TV6Tdu3fLXXfdpYYdOv8oDh/vPf7446ME9Q1zxBFH6AeAa9Wqpfe7d++u jco3cALP/MRNkHSB3/ZyKPAMmYFs27ZNX2SULFlSOnXqJAsXLlRDbuXKlUnRKcp6l1RBGbhACWSD HmWDDAUKuRgkzn6tGFQyi5gyga1bt8qFF16ov//NmjWTmTNnSteuXWXZsmVJpcm+MilcDByRQKDx hviNGjWS77//Xj788MO45F555RXZs2ePnHbaaXH+uMC0PRh0ixcvjrs36M+DpEePHnF+SGPGjBky bdo02bFjR9w9PCDDSJwzZ45MnTpVypYtK0888YQ+PK9atUrWrVunf0uWLJEff/xRG9T69evj0sDD 9Q8//BDn5xfXBgiTx4axx6Cw3377rXjlWLFihaxdu85G1bJ++umnMnfuXDmw/0DM31tm3PD6uTnY iBs3btSRIBz9HNj65ecXNpf9guoMZfZydnOoVKmSLFq0SEaNGiVDhgyRYcOGya5du7Qzd4ez5wcP HpQvvvhCPv74Y8EPAFyQ3gXlG1ZnQW3MprVhwwbBG8NNmzZp3tu3b1dZwozNVOImkgP5Y4TSTy+D 4kLgpUuXqvwIg/aN8lgXxMXKb/sLhPerB5tOpo+p6qKfHqGPxp91GJ0HO7eD/v70008xr7D8Y4HM iR9DPxkQx68O4B9UZ7gXpAc2LeryVGDyrQe9kY9/7Nc+Fr8+MZFOsl/Lh9IVoaiVK1eW2bNny6RJ k3SGGWZ94ZkUv61+jn3loWd2tg8/7SgAPzOqps4kbU/1aKYoOn369HHq1avndOnSJe6eMeqcK6+8 0jFTIZ1LLrlE7xmldho2bOiULl3aqVatGobqnF69esXiIZ0bb7wxdm0ehDUcwpsRDefoo492zGhf 7H758uWds88+W9NBWuYtoQO/xx9/XPOBn/0zRqGGbdy4cSz+3r17nerVqzsDBgyI+eEEMtp4OCIu XCJ5NNAv/8LCtmrVymnatGksuJXjD3/4g/qNHDlSy4ryIn/Is3r1ar0XVOYgDoj0zDPPOGY0TtMq V66c1lfdunU1PfwLyy8WKAdPjGEcV6qwOkNAP/ZxCbguHnvsMeVtXjy4fA+dGqNO6988GDk1a9bU usadIL3zyzeozhK1MaTVuXNnp0yZMiofdGzo0KEqB3QN7Wz48OF5ZIZHMnGjyIE+w7xoUDkqVKjg mHWYmm+iuD179lR9tu0Dcpu3nRo3iIuV39tO0A699aAJFfK/dOqinx6hLz7xxBNjpXrggQeUu3nw UD/0LyVKlHDMSze9TtQWbELU5UPtIpd02auLtq5xZL8W/gyDPjKXdMFd9zw/RCCsfXz00Ufar5ql Qnlwsa/Mvb4yTyVnwAPPP0EudscbCMZb3759nYcfflgfBtesWatpmDm/qsA4eo03hDVv2TXcgw8+ qOHMKJReu423LVu2qOGGB00zKuDg+pxzzlFjC0YaHDpK/I0dO9Yxb8JifjDezFtjp2PHjk67du0c NBoYSE899ZTmt2DBAg07evRovZ4+fbpe239+caPIY+MnCmtGBzVfMwKnUczUU73+/PPPtZwwbK+7 7jrHvKVx0FHgGkYyXFCZgzhs3rTZMW+HHDMXWzm+8cYbDh6UrfFmZQ3KTzPN0X/uTthySFbf3GiQ 3sCBAx2z3k2NIO9LARvW6p0ZMVKvyZMn69FP73DDW+dWVr86g+ET1saQFvRp4sSJzvJly50qVaqo 7g0ePFhffsC4sbqhQrn+JRM3ihxVq1Z1xo0b55hRcX2h0Lp1a80tLO6XX36p8qLNoE1DryEv2koY FyTs5RhUD64iF9ppOnXRT49ee+015TZv3jwtE/pl9Ofog+Gee+45famGvtlyDGsLGsn8C2LoJwPi eOvA5kVdzh5ddusi6oz92uE+MaxvsvrNfg0kctd524e7pGb6o76QtM/C7nvsKw/1/2wfbq3I/7nX LnOnmNB4M9MO1XjD21w4s4mJc/rpp+u523hTD/MPDwgYkXjyySf1AcI2Brfx9vbbb8c9bCCufath hqg1KTwI3H333Xpu/8EPxhvc+eef73To0MHecsyUIDVc7rzzTvW74oor9KExFsB14o0bRR4bPVFY M81Hef3pT3/SKFdddZVj1vvpuTXk/vrXvzpIB38YHbAjdUFlDuLw/vvvK0c89Fp30003xR7QE+Vn 4+Ti0eodypaozhDGjz38rTNTex2zYYm+ZMCI0qmnnupYA92GwdFM29NRDrQTa8DZ+169g7833yh1 FtTGkBYMNevwcqNt27b20nnkkUf0xyfm4TpJJW5UOfr37++cdNJJrtz8+wm8qEFnZY2QP//5zw5+ DOAScfFyDKuHOEEK4SLduujVIzM118Gou9lkyjFTFPUcvM0iey0dXjjAcIeL0hY0oPkXxtArA+J4 6yBRnSFOVB2iLpfQ315vnwKGyTi3LiIe+7W8fWJUnSzu/VoyeldUwnrbh5XbbNynv+tm0z3rFXdk X3mo/3c/f7B9xKlIShdhxltpczPUYYMQM8olb775ppjRBjFGlpiHwDxxzJtyMVOedJt698YkRuI8 Yc00HvU7+eSTY/eOO+7QZiabN2+O+Zlpj7HzRCdmlEHXw5k3IGIUSMyIh9x8882Joun9qPIgcKKw NWrUEPPArOujzJtvnS9tDCrNZ82aNXp8/fXXxUxt03NsQGKme+o5/vmV2c8PYe3aOjNlCpfqzDRU eypR8osFzuGTRHVmix7EGffNyLD+4dx08GJGkuSee+4R6JvbNW/eXF544QXVQTPFTYzxLm+99ZZg s5Mg5843rM6itDGrV8jryCOPlP3798eyxfWBA4fXWMZu/HISNW6yclSsWDEmR1hcMIUMYHbuuefK u+++q20a4oVxseVwc0ylHmw6BXlMhy565cPajLPOOkvXNTZp0kTQp5iXR2J+PHW9oJl9IOallkaL mj8Cp8LQXQdhdRamB7Z8UfXRhncfo8ZNVo5c02X2a4f7xOKuC+72w/PDBMzLRDGzB8QMFsiQR4cc vuE6Y195CIa73821vtJV3VlxGvxE6RKvX79+uiDejGbpw5WZTum6e+jUvGVVg8VMlZLvvvtOjb08 gX7xOO644/QMi+itW7Lk0AYndevUtV4Jj/v27YsLgwaGzUHwUI2NIsx0xLj77gt33GTkiRIWRizK 9pe//EU3Cbj++us1a2vUYsOXWbNmxf5efvllt2iRz4855hgN6979CJtTWJfu/Gy6Re0Ypc6SKRM6 ahjpdkMQb9wbbrhB9dCsIRGzTktfeNgwbr2zfu5jWJ0l08bcaab7PD9yhMU1I29ipv3qJ0iw6cb9 998vZkqgih/GJah8YfUQFKeg/dOli149uuiii3RzJzOypkYXtrc269zk3nvv1T7IrIvToiWbfxhD rwxedmF1FqYH3nQK8jo/coTFLYq6zH4t+jOMVydzTRe85Suu12akW3eYxEAD6rhU6VKBKNhXBqJR dmattfjZB0WxrwwuaeHdiWS8mU1JdJt/vMHFOXap8jozX1y91q5dq4YevhMX5PAGw2xIoJ8hwFsN sx5MMEqF3StbtGwRFC3OHyNtaFjYrfLrr7/We3iAqV27tjz99NP6Jto9sueO7I2bjDxRwmJrWLwN B4MzzzxTzJRRzb59+/Y6sobvsGE3zi2bt+jIjXc3T7esYecYncDbDTOlVXd6w4ioWfcWi5Lu/GIJ F7GTKHUWViTsLnXNNdfoN15gKENXMYJhpnLliYYO6u9//7vusGemrul9jITAefVOPT3/wuosmTbm STatl/mRIywuRunx0gXtGW/wMHJj20YYF7/ChdWDX/jC8suvLkJOPz3CizWMsv7rX//SN8QIg4fx f5jvcWIEuH79+lrEZPIPY+gng5dhWJ2F6YE3nYK8zo8cYXGLgi6zX4vXrLD6jA+Z9yosblHQhbwl og9ezpq1wbqzulm6Inj+NevJxSxTyQOHfWUeJHEebB9xONJyEWi8YZqXneqFI0aT8Cb3lltuiWXs DgODxayrEIwywWjClvZwNo1YJHOCqTV4qMB2/3jAaNOmjRqEaADIA86dtnp4/DAa+PPPP+v0NWzd Doc4eIiB836WQD1/+eeNG0UeGz9KWLP2Q8yuVLq9s9lx00bVhy5MmcSDPwzVatWrCWQBB7hEZbYJ 2XAwgM1GLfLVV1/JGWecIa+++qoaGbgPhwessPxserl+jFJnlqkfC0xLxUuG9sb4xkOwWc+p0yge euihPMExGnH77bcre7QZ1D++DQfn1Tv4efMNq7NEbcybVqJr5G9dorDu+/mRIywujN1SpUrpiw8c 8SOJESPwDuOCMrjlw3VYPeB+plx+dRFy++kR2GHKJPpPfEQeDt8kgsO3iqyLkr8NG8bQTwZvHYTV WZgeIH9vWomurczJxs2PHGFxi4Ius1+L17Ow+kykV2Fxi4IuuNsPzw8RwOwpPKvhhSLq16zz1b9r r702DyL2lfFtCYDcfTbbRx6Vyb+HeSukzqRkT/VoDCPHrI+J8/vvf/8bd23miDv79+2P88MGJ3bH SHd4M13HMSNOcWFx4Q7vvom42GXO7bx+2PXMfKclLpyZMqkL57HTWZjzi4vwQfL4pRUWFrJjJ8wg h41NzLeZ4mT3lg9xo/ihnuwOSMgXZfM6v/y8YXLpOmjhcVCd+XH28sDunmZKcB6d94ZD28Fuj9hJ 1eu8eheWb1CducuA+NZ500L7xJ910A13eOuPYypxo8oB/fTqpF9c7C5pDBC3WM4JJ5wQ98kR3PTj 4pUf4cLqAfcLyxWELnr1CGVBX+yt37A+yF0HQSzCGHpl8KsDm65fneGeWwa37N60qMvBfYplHOXo p4vs1w73ocnoZHHv16LoW1EL49c+opaBfWX8MzvbR1TNCQ7ntcvcIUvgAiYg3tj+corLtDl8gBvT GLH5AEbbevfunba0vQmZh1OpU6eObgCCebR0xZcARsqaNWtWfAEUwZJjUw3zXTodbcNUY/NDqh9E Nd+Ii40mFcFi6agtdbEo1lzqMmerLrNfTL1OU42ZrbqQanlyOR7bR+HXLttHMPMwu+zw1oTB8fN1 BwaVeWuqu+9h3VBBOvN2V6dhQhnoSIAEihYBbPBiPquhawvM9xp1+jXWGZgP3xetglDaYk+Aulzs VSAGgLoQQ8ETEshDgO0jD5JIHgU+8hZJCgYigTQT4Bu0NANlcikToC6mjI4R00ig/s15N1hKY/JM igRyhsC3w6fkTFlYkKJLIHTkDQ8W1iEgHQmQAAmQAAmQQG4RqNe/bW4ViKUhgQIiwGfhAgLLZJMm 4LbR3JE58uamwfOcIcDRjpypyiJfEOpika/CnCiAHXnjqEJOVCcLUQAE2EYKACqTTJlA2Mhb4KcC Us6NEUmABEiABEiABEiABEiABEiABNJOgMZb2pEyQRIgARIgARIgARIgARIgARJIPwEab+lnyhRJ gARIgARIgARIgARIgARIIO0EaLylHSkTJAESIAESIAESIAESIAESIIH0E6Dxln6mTJEESIAESIAE SIAESIAESIAE0k6AxlvakTJBEiABEiABEiABEiABEiABEkg/ARpv6WfKFEmABEiABEiABEiABEiA BEgg7QRovKUdKRMkARIgARIgARIgARIgARIggfQToPGWfqZMkQRIgARIgARIgARIgARIgATSToDG W9qRMkESIAESIAESIAESIAESIAESSD8BGm/pZ8oUSYAESIAESIAESIAESIAESCDtBGi8pR0pEyQB EiABEiABEiABEiABEiCB9BOg8ZZ+pkyRBEiABEiABEiABEiABEiABNJOgMZb2pEyQRIgARIgARIg ARIgARIgARJIPwEab+lnyhRJgARIgARIgARIgARIgARIIO0EaLylHSkTJAESIAESIAESIAESIAES IIH0E6Dxln6mTJEESIAESIAESIAESIAESIAE0k6AxlvakTJBEiABEiABEiABEiABEiABEkg/ARpv 6WfKFEmABEiABEiABEiABEiABEgg7QRovKUdKRMkARIgARIgARIgARIgARIggfQToPGWfqZMkQRI gARIgARIgARIgARIgATSToDGW9qRMkESIAESIAESIAESIAESIAESSD8BGm/pZ8oUSYAESIAESIAE SIAESIAESCDtBGi8pR0pEyQBEiABEiABEiABEiABEiCB9BOg8ZZ+pkyRBEiABEiABEiABEiABEiA BNJOgMZb2pEyQRIgARIgARIgARIgARIgARJIPwEab+lnyhRJgARIgARIgARIgARIgARIIO0EaLyl HSkTJAESIAESIAESIAESIAESIIH0Eyid/iSZIglkH4EJEybIiy++KKtWrZJjjz1W7rzzTmnXrl32 CUqJCoTAgw8+KAsWLNC0y5YtK7/5zW+kf//+csQRR6jfN98skEcffUSWL18uRx99tPTu3Vt69eql 99xxrXCXXHKJXH/99fYyqaM7vUzLAsG3bdsm9913n/z444/yzjvvJFUWBiYBEiABEiABEihcAhx5 K1zezC0DBLZu3SoXXnihPqQ2a9ZMZs6cKV27dpVly5YlJU337t2lW7duScVh4Owg8O6778rixYul evXqsnHjRrn11lsFBhjcls1bpGPHDjJv3jzp1KmTHHXUUXL//ffHBEfcRYsWaVzExx/CpOqySZb3 339fTj/9dHn++efls88+S6lIbBcpYWMkEiABEiABEkiJAEfeUsLGSEWJQOXKlWX27NnStGlTFbtj x46CB06MxtWrVy9PUQ4ePKjhf/rpJzn77LOlSpUqOmK3bt062b9/vyxZskSqVasmxxxzjCxcuFDq 1q2rhsGuXbukbdu2mt6OHTtkzpw5UqlSJWnSuImUKl0qls/8+fNl7dq1Gq9hw4Yxf5sW4n711Vdy 5plnqqGwfft2mT59upx66qlSp06dWHj3SSpxE8mxe/duNWiaNGkiNWrUcGcnQXERaOnSpbJy5Uqp VauWYGQJI1k1a9bU+EFcrPwwsCxHv3qIE8J1gVHU22+/XS699FKXb/wpeL788svqiVG1t956S8B2 ytQpatDBqGrTpo3e37lzZ1zkFi1axOLG3UjxorBkScTlySeflL59+8r69etlzJgxoaXxqw+MZLNd HMZWGO3icG48IwESIAESKJYEnF+cKbw95ZEEijyBuXPnBpbho48+cqDvZhplnjDGcHCMkecYo8sx BodjDA8NY4wsjYN4+OvRo4f6ly9f3jEGXuyemYLmjBw5UuMhLsIi7urVqx1jDOl56dKlHWP86T1j RMRkQFqdO3d2ypQpo/cQf+jQoSoH0ilZsqQzfPjwWHj3STJxo8jRpUsXxxheKkeFChUc82Cv2SWK 27NnT8dMRdTyW1ZmlFPjBnHBTT+OfvWgCfn8q127tvO3v/3N584hrwYNGsTqDD5myqTyRH1PmzZN y9mnTx9n/779edLwxs0TIIGHVxe96RWkLIm4WNEHDhzoGGPbXuY5sl0c0tFsaBd5KieiR73+bR38 0ZEACfgTYBvx50LfzBDAM1SQi90JCxQUmf4kkK0EvA/MbjnNqJsaJmvWrHV76/no0aP1Qd6Mrun1 5MmT9bhnzx7HjNg5ZiTDwYPs3r171R9GB/7Gjh3rmLfuzpYtW9Qwu+666xwzUuFADhhqMAxg+Dz8 8MOOmbancc3aJ83LjHrE0kLYiRMnOsuXLXfMiJ/eHzx4sAOjEEaiGeXTsN5/kCFq3ChyVK1a1Rk3 bpxj1kE5ZnTSaVjqq0cAADaqSURBVN26tWYZFvfLL79Ued977z3lc/HFF6u84BDGBQl7OQbVg7fc 9jqRkQKDqXnz5s6QIUMcs55N679fv342unPRRRep7PXr13fM6JzWnb2JuOBupszq31VXXeUcOHDA 3k549OpiYcqSiIsVPpHxFlQfbBeF2y5sfaVy5INpKtQYpzgRYBspTrWd/WUNs8u45s3QoSs+BDA1 7O2335ZbbrlFjjuudp6Cn3TSSVKiRAld84Tpf+edd56GwfS/UqVKiRk1E2NoxDa6wE3z4CsXXHCB NG7cWKZMmSKbN2+WRo0aCabhYQOME044QcwDvJQrV04eeughTQ/r7oyBpOeYdmYdpv5h3dWvTvmV YLoipmE+8MADOv3SGBg6Rc2G9R6jxo0ixx133KHrArG+C9NMMc0TLiwupt7BYWonNgLB+kJshgGe YVw0kvnn5hhUDzYsjvfcc49Ox8SUzB9++CF2bQwW2bdvnzuonpvRT3n99dfljTfekJNPPlnMKGYs zAcffCBm5E6MUSbGqBMzAiqYJmgdyoP6sn/WP9VjQcqSLJcoZQiqD7aLwm0XUeqKYUiABEiABHKb ANe85Xb9snQuAtiQwoyISYcOHWTIo0Ncdw6fmtEZeeGFF8SMdgnWo5lRFl0bZaYsHg7kOYOBY92a NWv0FEaCmf6o53jwh2FnRuvETCvUtUXHH3+8jYLR79i5jQOPI488UtfY2Zu4hnER5KLGTVaOihUr xuQIi2tG57TMYHbuueeq8QpDFC6Miy2Pm2OUerj22mvVQET8AQMGyOWXX651CwMbzL0ORijWueEP a96GDRsmd911lwaDgXnTTTdJv779ZMDAAaoDML5RFjisUcNupelyBSlLslyilClKfXjTcddnWP2H 6ZRNM6pu2/DuY9S4ycqRiXbhLhfPSYAESIAEiieB4CfS4smDpc5RAthkBDtMYsTFTOuL20DEW+Qb brhBVqxYIY899piYdVpi1sjFgviN6MRumhNrlL3yyisya9as2B82ykC+o0aNEjMdUb777jt58803 3VEL7Tw/coTFNVNHxayP001DsOEHdmx87bXXtFxhXIIKHlYPiINdEq+++mr9g2GLTUVwfcUVVwQl qf4woFu1aqU7LLoNZ9zExjIYwYTDrpQF7QpCllS5JCprWH2wXQS37XS3i0T1xPskQAIkQAK5TYAj b7ldvyydIbBp0yadBmfW58jdd9+tOzcCDKbA4YHf7WBcYQdCjOJgqhicHcXBrpMYvZsxY4YaKRhN 87r27dvrDpG33XabjtTUrFFTPp3yqaZh1otpcExB/P7772XQoEHe6IVynR85wuLCEMJnGb7++mv9 lh5GWz788EM1psK4YDqo14XVgzdsKteYGgljZPz48bpFPqau4ttu2B3UrEvU+mrXrn0saXwDDVM/ rTvxxBN1t1B7nZ9jJmX5z/L/iFmPKBs2bNDR1dmzZkvFoyrqqLO7TGH1wXYhUljtwl0nPCcBEiAB EiieBDjyVjzrvViVGt/owhojGBb4RMD555+vf5he5nUYQcDICx5IMSqC6XV26h8esn/++WfB9EBM uYPDdEr3lErEw5RJ5HfaaadJterVdA0VjAPkjU8P4OPOGAHEeiGbhj260/Km7b3WyL/8894Lu86P HGFxYexiXSA+zYCj2cBErrzySsF29GFc/MoeVg/ucttzGGEYdQty4AGZrEO9YlrfiBEj9PMAU6dO 1SmXLVu2VLmx/q1RozM0OAy6SZMmCQxQ+wcDL1VXmLIk4nLNtdfIWa3O0o9z4yUHzu3379zlC6sP tgsJbdvpbBfuOuE5CZAACZBA8SRQAvutoOhY8+GdQlQ8kbDUuUAAI2TYMCMVh7Uvq1etlho1a+T5 GDOMN2zMgZEXtBmM5sEIw7nXYdod7mPDEvd9xMemJzAKcB9T/uC8admpaHbkD+0T+dvw7vxSiRtV DmzcAVmssYl8/eLioR8jivhGnXXghE1X3FNE/bh45Uf8sHqw6Uc9Ii2shYPhZB38SpUsFZtCi01P sKbQTvG04fJ79OpiJmXJT1nC6oPt4hDZwmgXqdZh/ZvbadRvhx8eQU41LcYjgVwkwDaSi7VadMsU Zpdx2mTRrVdKXkAEsMEBdnv0czBg7HRK3PczpGw874etrT8+Xm2dO777HPet0WbDoiF7w9h7Xv8o caPKAYPHbbghT7+4p5xyik6TxOgcPn6OHTYxRdR8E8+KqUc/Ll75ETCsHuISjHDh3rTCBvf6HXvs sfZWgR69+SIzr19hyZJMQSEj28VhYplqF4cl4BkJkAAJkEBxJEDjrTjWOstMAgVAABu8wICbPn26 LFiwQKeG4hybg9CRQHElwHZRXGue5SYBEiCBgiFA461guDJVEih2BDDa179/f/0rdoVngUkggADb RQAYepMACZAACaRE4PACkJSiMxIJkAAJkAAJkAAJkAAJkAAJkEBhEKDxVhiUmQcJkAAJkAAJkAAJ kAAJkAAJ5JMAjbd8AmR0EiABEiABEiABEiABEiABEigMAjTeCoMy8yABEiABEiABEiABEiABEiCB fBKg8ZZPgIxOAiRAAiRAAiRAAiRAAiRAAoVBgMZbYVBOYx7z58+XMWPGpDFFJkUCJEACJEACJEAC JEACJFAUCAQab4MGDZLLL79cPvjgA99y/OMf/5BLL71UXnzxRd/7Xs9f//rX8sc//tHrHfl6586d 0qBBA3n22Wcjx8mGgOmW+6WXXpLbbrstG4qWVhnSzSmtwpnExo8fL5dddpm0aNFCLrjgAvnkk0/S nQXTIwESIIFCJcB+rVBxM7MiRmDChAnSrVs3admypVx88cUyZcqUIlYCipurBAKNtxEjRsh7770n t956qziOE1f+3bt3y1133aWGHTr/KA4f7z3++OOjBPUNg2/lII1atWrp/e7du2uj8g2cRZ5euQtS tGxjkow8hckp2TrYtm2bvsgoWbKkdOrUSRYuXKiG3MqVK5NKKhkeSSXMwMWKQDboUTbIUKwqvQAK y36tAKAyyZwhsHXrVrnwwgsF7aRZs2Yyc+ZM6dq1qyxbtiypMrKvTAoXA0ckEGi8IX6jRo3k+++/ lw8//DAuuVdeeUX27Nkjp512Wpw/LjCtDwbd4sWL4+4N+vMg6dGjR5wf0pgxY4ZMmzZNduzYEXcP D8gwEufMmSNTp06VsmXLyhNPPKEPz6tWrZJ169bp35IlS+THH3/UBrV+/fq4NPBw/cMPP8T54cKb tg0AGT799FOZO3euHNh/wHrrcePGjYK3MMgbjfnbb7+N3f/mmwWyffv22LWVBx5uuXGdat4Y6YEM Qc6PiQ0bxtmGwfHgwYPyxRdfyMcffyzouKwLK19QvDB5/HQkiNOmTZt0lCus7FbORMcwDkH1gjQr VaokixYtklGjRsmQIUNk2LBhsmvXLu3M/fL04xjEIyjfMF304wc5bFobNmxQXQU7OOgm6jTM2Ewl biI5wuouKC7kXbp0qcqPMGjfKI91QVys/La/QHi/erDpZPqYqi766RH6aPxZh1FssHM76O9PP/0U 8wrLPxbInPgx9JMBcfzqAP5BdYZ7QXpg06IuTwUm33rQG/n4x37Nv09MpJPs1/KhdEUoauXKlWX2 7NkyadIknWGGWV94JsVzoJ9jX3nomZ3tw087CsDPjKqpM0nbUz2aKYpOnz59nHr16jldunSJu2eM OufKK690zFRI55JLLtF7Rqmdhg0bOqVLl3aqVauGoTqnV69esXhI58Ybb4xdmwdhDYfwZkTDOfro ox0z2he7X758eefss8/WdJCWMZgc+D3++OOaD/zsnzEKNWzjxo1j8ffu3etUr17dGTBgQMzPnvil PXLkSJUBciBdlGX16tUa5bnnnnPMyJD6GyPDMUPoTt26dW1y6m8e6GPXyNN938qNAMnm/cwzz8Ty LleunNaHO22bKeS1PHAEE7hEnG18Y4w4TZs2dcwPulOzZk1lYe8hvaDyBcXzkyeRjng5Qe/AG/lX qFDBMWv9rEgJj8YAjwuTiINfvcQl4Lp47LHHVCbz4sHle+g0GR6I4ZdvkC5G4de5c2enTJkyKh90 eejQoVqfYIh2Nnz48DwyWzmixo0iR1DdJYrbs2dP1XfbDiG3edupMgdxsfJ7+4sgffYFUICe6dRF v3aFvvjEE0+MleCBBx7Q+jcPHuqHfqxEiRKOeemm14nagk2IunyofeaKLtfr39bBX5Bjvxb+DIO+ Old0IUgHirt/WBv56KOPtF81S4XyYGJfmVt9ZZ4KzpAHnn+CXOyONxCMt759+zoPP/ywPgyuWbNW 0zBzflWBcfQabwhrRkg03IMPPqjhzGiYXruNty1btqjhhodFMyrg4Pqcc85RYwtGGhw6SvyNHTvW MW/CYn4w3sxbY6djx45Ou3btHDQaGGpPPfWU5rdgwQINO3r0aL2ePn26Xrv/edO28lx33XWOeXvi 4GELBiiM182bNjvmDYxj5jurrG+88YYaEm4DCuyCjBvki/wgtz13lyu/eWui5p8fE5t2GGcb3/Iy Ix3qNXnyZHtLOQaVLyienzx4cA/TES+nqlWrOuPGjXPMSKYara1bt47JlOjE/cAchYNXJ7zpI72B Awc6Zr2bGkF+LwUQJxkeCO/N18rqp4tR+EFvJ06c6CxfttypUqWK1t3gwYP15QeMG7feIn/rIEfU uFHkCKq7sLhffvmlymuma2ubRpuDvGiTYVxQBi/HoHqw5S3MYzp10a9dvfbaa8pt3rx5Wiz0y+iT 0AfD4eUTXpKhb7Yc89Mn+MmAfLx1YPOiLu/V349M67Lfgyn7tcN9YljfZPWb/RpI5K7zayO2tGb6 o75Mts/C1h/HoN8b9pWHntnC2lau/u679SPVc69d5k4ndNqkiShmtAwHef754Xo0D/Fy+umnS9u2 bfXa/jOjQvLQQw/pJeYGm05OzzG90eswDL1582b5y1/+IkcddZSYt+xi3hYLhlsxTG2deVjWzSHM iJr10iOm2JUqVUrMA4mYBwbBeqnevXuLGZ2Rv//97xrmrbfeEmMwCjZK8XPutLEIFfJgmui7774r y5cvlxNOOEGnT077bJpOk0TZIOvvfvc7/fNLM6pfQeTtxyQqZ8h90kkniXk7L/fff79OWzvvvPMi FSconp88yegIMr/jjjt0jrkZQRVjrMvatWsjyeQNFJWDu168aZiXBJo/psxC34xx6zv3PRkeNg93 vmG6GIXf7bffrlOLf3XKr6RJkybaTtG2MEXqoosu0qnGNl/vMWrcKHIE1V1YXDvtuU6dOsoY6wzA G3oZxsWWw80xqB5s2Ewd86uLfu3KzH4QcMXmUpgy+dVXX2l7ttN7MI0dG+0cc8wxOgUoSt8LPkEM /WSwPN11EFZnYXpg04qqjza8+xg1bhQ5clmX2a8d7hOLuy642w/P4wlgh++3335bbrnlFjnuuNrx N80V+8pDSHK5r8xT6Rn2KJ0of2wQggfnN998U8xog5ihY3nkkUfyRDOjX2KmPOk29u6NSYylmCes mcajfieffHLs3nHHHdrMBA8W1uGhPaozowz60GregIgZadCH65tvvjkwujvtNWvWaLjXX39dzJQz PccDOoxG+0BppiXF0oLRmB9XWHlH5YyyNG/eXF544QVlZ6ZmyVVXXSUwgLFJR5hLJl4yOoI8bV3g vGLFirJ//36cJu2icnDXizcTMzIs+IMzb6vFjALKPffcI9A3t0uGh43nzjdMF6PwczM78sgj45jh +sCB+LWcVgYco8ZNVg533YXFBVPIAN0799xz9UUKNoiBC+OiAcw/N8dU6sGmU5DHdOiiVz6szTjr rLN0XSMMdvRdf/rTn6R///66XtDMPpA777xTo0XNH4FTYeiug7A6C9MDW76o+mjDu49R4yYrR67p Mvu1w31icdcFd/vh+WECZkaDmNkD0qFDBxny6JDDN1xn7CsPwXD3u7nWV7qqOytOw5/MfxGxX79+ uiD+iiuu0IcrM50yj/DYmdKspRAzzU2+++47NfbyBPrF47jjjtMzLKK3bsmSQxuc1K1T13olPO7b ty8uDBrYihUr9KEaG26YaY9x94MurLGJjVhmzZoV+3v55Zf1bTXiuXcYcm9Ognt4Y4cRAuvc59Yv 6JjfvL3pupkky/mGG25Qfmbtg5j1RWqoI/1E5QuKh7hueZLREcRNl0uWQ6J80VHXqFFDR4r9wkbl 4Rc3TB8yxc8rZ37kCItrpkjr6Dk+QYIRJIwCmymBmn0YF6989jqsHmyYwj6mSxfd7QplwKgqNmvB 22HoJ7a3xojlvffeqxuVmHVxWtRk8w9j6JXByzKszsL0wJtOQV7nR46wuEVRl9mvRX+G8epkrumC t3zF9RobZmGHSQw0oI5LlS4ViIJ9ZSAaZRdkHxTFvjK4pIV3J5Lxhmk5+CHGG1ycYwqW15k5reqF qW3Y+QzfiQtyeIOBqZL4DAHeanz++edi1mfo7pUtWrYIihbnj5E2NCzsVvn111/rPTzA1K5dW55+ +ml9E+0e2YuL7Llo3769vrXH99OwS+aWzVt0RAW7bGIEAG8QIB92QMOo4z//+c+4FDBk/q9//Usf nvDGG6OUUV2UvDHtzeZt1twFJu1lkgxnNCxMOcXOcCgPHN7gw4WVLyyeV55kdEQzTtO/ZDj4ZYnp Z9dcc41O3YMRD13ACIZZc5kneDI88kQ2HmH6kCl+XjnzI0dYXIzS46UL2jPe4GHkxu50G8bFKx+u w+rBL3xh+eVXFyGnt13BDy/WMDKNfgh5IAwexv/xj38IRtLr16+PYHovat8bxtBPBs3A9S+szsL0 wJVEgZ/mR46wuEVBl9mvxatXWH3Gh8x7FRa3KOhC3hLRB8t4zNpg3Vn97rvv1udfs55czBqtPHDY V+ZBEufB9hGHIy0XgcYbpsvZKXM4Ykok3uRizq917jD4loXZEEGuv/56fUuBdRFwNg0bB0dMrcFD BdbD4QGjTZs2ahCiASAPOHfa6uHxw2jgzz//rNPXsA4PDnHwEAPn/SyBev7yz5s2HkQwZRIP5Pj8 QbXq1QTpQz486JjNUHSq3BlnnKFTCzFFye0wUoXplVhXAsMOrNzldufnPkcaUfLGGhbk/eqrr6oR 4U7bLYeXSRTONj7eomOdCOSB/GanUJ2Givth5QuL55UnkY642bjPIYP3Gn5RXRQOYeljyixeMrQ3 Rj4egp988kmdRmHXeLrlSIYH4nnzDdOHZPj5pe3Nyy23917YdX7kCIuLlwRYy4ppgDjiRxIjRuAd xsWvrGH14C53YZ/nVxchr7ddwQ/sMGUS/Sc+Ig+HN8Zw+FaRdVHyt2HDGPrJ4NWZsDoL0wPk700r 0bWVOdm4+ZEjLG5R0GX2a/F6FlafifQqLG5R0AV3++H5IQKYGYZnQrxQRP2ef/75+nfttdfmQcS+ Mr4tAZC7z2b7yKMy+fcwb4XUmZTsqR6NYeSY9TFxfv/973/jrs0ccWf/vv1xfua7arqzHTzd4c10 HceMbMWFxYU7vPsm4mKXObfz+mEnH/PtqrhwZh2S7nqGnc6CnDcddzjzXSHHjBzGpYn7KKeZDqpM vJ8CsPfN9480KcgN2axz5+c+t/ftMShv1IPd4cibto1rj35McC+Is42HI+ocuxRiB1CvQ/mDyhcW z08etyzgYZ2bjfsc98HAzdTGCTq6d/hzh3Hn7fb35ue+Z8+x8yh0wKvz9r49JsMjLN8gfXCXAfGt 86aF9ok/66A77vDWH8dU4kaVw6/u/OJid0ljgLjFcszGQXGfHMFNPy5e+REurB5wv7BcQeiiX7uC XnrrF7vxBjl3HQSFCWPolcGvDmy6fnWGe24Z3LJ706IuB/fNlnGiY9BOeuzXDvehyehkce/XEulb Ubwf1EailIV9ZfwzO9tHFK0JD+O1y9yhS+ACJiDe2P5yisu0OXyAG9MYsYsjRtuwK2RBOfNwKnXM TnXYaATzaAvKYUc17OCGtX102UkAI2XYrZCu6BDAphrmu3Q62oadYrExDKZ2YacvO5pUdEpzWFLq 4mEWxeUsG3W5/s2Hpnl/O3xKcamGrChnNupCVoChECRgCLB9BKtBmF2Wv20Tg/OM3YFBZd6a6i6G WDdUkM683dVpmFCGgnTmI92CctGRAAmkjwCm555yyim6tsB8r1GnX2OdbatWrdKXCVMigUIgQF0u BMhFJAvqQvZXlH2x4ZaULzncNArunO0jNbYFPvKWmliMRQL5I8DRjvzxY+z0EaAupo8lU0qdgH1A 5UNp6gwZMzcJ2LbhLh3biZsGzzNBIHTkDQ8W1iEgHQmQAAmQAAmQQG4RMOt5tEB+D6q5VVKWhgSi Ewgy0vg8HJ0hQxYcAbeN5s6ltHtdUEGseXNnxnMSKCwCHO0oLNLMJxEB6mIiQrxfGARotBUGZeaR KwT4PJwrNVl0y4EXCG4bzV2SAl/z5s6M5yRAAiRAAiRAAoVPACMMfJFQ+NyZIwmQAAmkmwCNt3QT ZXokQAIkQAIkQAIkQAJFgoCdOsmXG0WiuiikIRD4kW7SIQESIAESIAESIAESIAESIAESyB4CNN6y py4oCQmQAAmQAAmQAAmQAAmQAAkEEqDxFoiGN0iABEiABEiABEiABEiABEggewjQeMueuqAkJEAC JEACJEACJEACJEACJBBIgMZbIBreIAESIAESIAESIAESIAESIIHsIUDjLXvqgpKQAAmQAAmQAAmQ AAmQAAmQQCABGm+BaHiDBEiABEiABEiABEiABEiABLKHAI237KkLSkICJEACJEACJEACJEACJEAC gQRovAWi4Q0SIAESIAESIAESIAESIAESyB4CNN6ypy4oCQmQAAmQAAmQAAmQAAmQAAkEEqDxFoiG N0iABEiABEiABEiABEiABEggewjQeMueuqAkJEACJEACJEACJEACJEACJBBIgMZbIBreIAESIAES IAESIAESIAESIIHsIUDjLXvqgpKQAAmQAAmQAAmQAAmQAAmQQCABGm+BaHiDBEiABEiABEiABEiA BEiABLKHAI237KkLSkICJEACJEACJEACJEACJEACgQRovAWi4Q0SIAESIAESIAESIAESIAESyB4C NN6ypy4oCQmQAAmQAAmQAAmQAAmQAAkEEqDxFoiGN0iABEiABEiABEiABEiABEggewjQeMueuqAk JEACJEACJEACJEACJEACJBBIgMZbIBreIAESIAESIAESIAESIAESIIHsIUDjLXvqgpKQAAmQAAmQ AAmQAAmQAAmQQCABGm+BaHiDBEiABEiABEiABEiABEiABLKHAI237KkLSkICJEACJEACJEACJEAC JEACgQRovAWi4Q0SIAESIAESIAESIAESIAESyB4CNN6ypy4oCQmQAAmQAAmQAAmQAAmQAAkEEigd eIc3SCDHCGzbtk3uu+8++fHHH+Wdd97JsdKxOCDw4IMPyoIFCxRG2bJl5Te/+Y30799fjjjiCPX7 5psF8uijj8jy5cvl6KOPlt69e0uvXr30njuueph/l1xyiVx//fX2Mi1Hdz6ZlnH8+PHy0ksvyerV q6VmzZpy2223SadOndJSTiZCAiRAAiRAAiSQfgIceUs/U6aYhQTef/99Of300+X555+Xzz77LCUJ u3fvLt26dUspLiMVDoF3331XFi9eLNWrV5eNGzfKrbfeqgYYct+yeYt07NhB5s2bpwbKUUcdJfff f39MMMRdtGiRxkV8/CFMul22yIiXGZdffrmULFlSeSxcuFAuu+wyWblyZVJFZrtIChcDkwAJkAAJ kEC+CHDkLV/4GLmoEHjyySelb9++sn79ehkzZkyo2AcPHpTZs2fLTz/9JGeffbZUqVJFVq1aJevW rZP9+/fLkiVLpFq1anLMMccIHnjr1q2rBsOuXbukbdu2mvaOHTtkzpw5UqlSJWnSuImUKl0qluf8 +fNl7dq1Gq9hw4Yxf5sW4n711Vdy5plnqgGxfft2mT59upx66qlSp06dWHj3SSpxE8mxe/duNXSa NGkiNWrUcGcnQXERaOnSpWoA1KpVSzCyhBEujOrABXGx8sPwcnPUSK5/7dq1k9tvv10uvfRSl2/8 Kbi9/PLL6olRtbfeekvAcMrUKWrQwXhq06aN3t+5c2dc5BYtWsTixt1I80VhyRjGC7oJY/Xkk0/W 0kHXwXXmzJm+esZ2caitZ7pd+NVDmtWTyZEACZAACWQzAecXZ2S0pzySQJEnMHfuXN8yDBw40DFG he89eBrDwWnatKljHmwdY3A4xvDQsMbIctBG7F+PHj3Uv3z58o556I35m9EMZ+TIkRoPcREecc20 NMc89Ol56dKlHWP86T1jXGg6+Ie0Onfu7JQpU0bvIf7QoUNVDqRjRkic4cOHx8K7T5KJG0WOLl26 OMbwUjkqVKjgGINXs0sUt2fPno6Zoqjlt6y6du2qcYO44KYfR43k+Ve7dm3nb3/7m8f38GWDBg0c WzfwNVMmlRvqddq0aVqePn36OPv37T8c6Zczb9w8AVL08OqiN5+ClDERL3eRHnvsMeUzY8YMt7ee s10c0tFsaBd+/VOeCgvw8OpiQDB6k0CxJMD2USyrPWsLjWeoIBe7ExYoKDL9SSBbCQR1womMt9Gj R+sDrBld06JNnjxZj3v27HE6duzomJEMNfD27t2r/jA68Dd27FjHjEY5W7ZsUcPsuuuuc8wbcgdy wFCDwQDD5+GHH3bMdD6Na9Y+aV5mNDCWFsJOnDjRWb5suWNG/PT+4MGDHRiFMBLNKJ+G9f6DDFHj RpGjatWqzrhx4xyzPtCpV6+e07p1a80yLO6XX36p8r733nsO+Fx88cUqLziEcUHCXo7e8tnrRMYI DKPmzZs7Q4YMccx6NjVA+/XrZ6M7F110kcpYv359x4zOaR3Zm4gLvmZqrP5dddVVzoEDB+ztlI9e XSxMGRPxgmxoExdccIEauQMGDPAtJ9vFIR3NdLsIqgffSvPx9OqiTxB6kUCxJcD2UWyrPisLHmaX cc2boUNHApbASSedJCVKlNC1UJj+d9555+ktTP8rVaqUmFEzMYZGbAMM3DQPv2IefqVx48YyZcoU 2bx5szRq1EgwPQ8bY5xwwglifhSkXLly8tBDD2l6mJpmHgT1HNMxrcOUQGwY8atTfiWYrohpmA88 8IBOvzSGh07dtGG9x6hxo8hxxx13iBkx02mbxmjVaZ7ILywupqTCYWonNghp1qyZYF0VeIZx0Ujm n5uj9cPxnnvu0WmXmHr5ww8/xK6NYSL79u1zB9VzbL7x+uuvyxtvvKFTAs1oZSzMBx98IGbkToxR JsaoEzPSKZiGZh3kRr3YP+uf7mNBypgML0xRxRRe1BPKbl5WyLJly/IUl+3iEJJMt4ugeshTYfQg ARIgARLIWQJc85azVcuCpULAjNrICy+8IGa0S7AezYy+6JopbOoQ5LCxhXVr1qzRUxgPZvqjnuOh GIadGY0SM61Q19wdf/zxNgpGv2PnNg48jjzySF1jZ2/iGkZHkIsaN1k5KlasGJMjLK4ZndMyg9m5 556rxqvduTCMiy2Pm6P1w/Haa69VQxDnZmRIN9no0KGDGtJg63UwNrHODX9Y8zZs2DC56667NBgM yZtuukn69e0nAwYO0LqGkQ2Z4bAW7cUXX9TzgvxXkDImw+ucc84R/MHhBQPqEMafGeGJKz7bxSEc 7jaWiXaRSj3EVSQvSIAESIAEijyB4CfSIl80FoAEUiNwww03yIoVK8SsARKzTks++uijWEJ+Iz2x m+bEGmWvvPKKzJo1K/aHDTTMdEIZNWqUmOmI8t1338mbb77pjlpo5/mRIyyumToqZn2cbnqBjUCw k+Nrr72m5Qrjkqjg2CX06quv1j8YsNhUBNdXXHFFaFQYyq1atdIdRt0GMiJhAxmMVMJhV8pMuYKQ MVVeMAywMc2mTZt8cbBd+GJRz8JsF2H1ECwh75AACZAACeQKAY685UpNshyhBP6z/D9i1l3Jhg0b dBRp9qzZUvGoijq65o4I4wo7E2ILdUxRgrOjO9h1EtvMmw0d1EjBaJrXtW/fXqca4ntZGMGpWaOm fDrlU03DrBfT4Jim9v3338ugQYO80QvlOj9yhMWFgbR161b5+uuv5dhjjxWMtn344YdqZIVxwXTQ gnKYGomHXXzPDJ+IwBRVsxZOp6Ga9YdaL+3atY9lj28AYoqndSeeeKLuCmqvC+KYKRknTJigLxCQ P6agwtDGdE7w8Tq2Cy+R+OvCahdh9RAvEa9IgARIgARylQBH3nK1ZlmuOALXXHuNnNXqLP04N0YW cI4PMHsdRtYwIgNDDaMimHZnp/7hIffnn3/WqWWYigeH6ZTuKZWIhymTeAg+7bTTpFr1arq2CkYD voeF7djx0Wdsz451dDYNe3Sn5U3be62Rf/nnvRd2nR85wuLC2MW6wMqVK+vRbGAiV155peAzDWFc /MruLpv7HEYYRt2CHMoNGaxD/WE65ogRI/TzAFOnThVMuWzZsqVAPqx/a9ToDA2OrfMnTZokMDTt Hwy8dLvClDGMFwxTvIxAWc0GLlpPZqOd2LpMd7nZLvK2dXcbK6x2EVYP7vriOQmQAAmQQO4SKIEt VlA8rAXxTi3K3WKzZLlOAA+l2DAjFYd1XatXrZYaNWvk+UgzjDdszIEHX7QZswulGmE49zpMx8N9 bFjivo/42PQExgLuYyognDctO0XTjvyhfSJ/G96dXypxo8qBDT0gizU2ka9fXBjDGFHEN+qsAyds uuKeIurHxSu/jZ/sEXWHTWXwYG0d/EqVLBX71h42PcHaQTuV04YrqKNXF7NNRny8fNv2bXLiCSfG GPmxYLuIb+uZahdh9eBXb24/ry667/GcBIo7AbaP4q4B2VX+MLuM0yazq64oTRYQwKYE2O3Rz8GA sdMpcd/PkLLxvB+2tv74eLV17vjuc9y3RpsNi4bsDWPvef2jxI0qBwwht+GGPP3innLKKTpNEqMQ 5vMCugEGpoia765ZMfXox8Urf1yEJC7cG0rYaF4/TOnMpPPKA1m8foUpY9VqZndN85fIQUa2i8OU MtUuwurhsHQ8IwESIAESyFUCNN5ytWZZLhIoZALY4AUG3PTp02XBggU6NRTn2DSEjgSKKwG2i+Ja 8yw3CZAACRQMAU6bLBiuTDXDBDj9IcMVwOxjBKiLMRQ8yTAB6mKGK4DZZzUBto+srp5iJ1zYtMnD C0OKHRYWmARIgARIgARIgARIgARIgASKDgEab0WnrigpCZAACZAACZAACZAACZBAMSZA460YVz6L TgIkQAIkQAIkQAIkQAIkUHQI0HgrOnVFSUmABEiABEiABEiABEiABIoxARpvxbjyWXQSIAESIAES IAESIAESIIGiQ4DGW5bV1fz582XMmDFZJhXFIQESIAESIAESIAESIAESyDSBQONtwoQJ0q1bN2nZ sqVcfPHFMmXKlEzLmpX579y5Uxo0aCDPPvtsWuR76aWX5LbbbktLWtmUSLo5FXbZ2B4KmzjzS0Rg yZIl0rVrV+ndu3eioLxPAr4E2K/5YqEnCSiB8ePHy2WXXSYtWrSQCy64QD755BOSIYGsIOBrvG3d ulUuvPBC2bZtmzRr1kxmzpypDwnLli1Lu9Ddu3dXIzHtCRdSgkcccYR+mLhWrVoFnmO2sUpGnsLk lO6KSFd7SIZXusvA9HKPQP/+/eWjjz4SPIAn66iLyRLLvfDs13KvTlmi9BHA8+/ll18uJUuWlE6d OsnChQvVkFu5cmVSmbCvTQoXA0ck4Gu8Va5cWWbPni2TJk2SF198UUeVdu/e7fuQ8O2338r69evj sluxYoWsXbsu5rdnzx6ZMWOGTJs2TXbs2BHzX7Vqlaxbt07/8Bb5xx9/jN1DuE8//VTmzp0rB/Yf iPkfPHhQvvjiC/n4448FPz5+Do0M8s6ZM0emTp0aCxKUJgJs3LhRyweZ0GhRLuu++WaBbN++3V6q nNaQLVu2rDzxxBPauBEg1bzxRgcyBLkwVkF8vWkFsQsrH9LwixcmD6Z+4o3V4sWLYyIEcdq0aZO+ zQoreyyRfJ6EcQqqN2SZTHtA+GR4BeUbpqt+fJGvTWvDhg2qy2ALB91Fewn70UklbiI5wuo2KC7k Xbp0qcqPMOgXUB7rgrhY+d1t3q8ebDqZPqaqi1bukSNHap+Kh4sw58cgqO36MUTaQcxxL6gebVrU xUO/P371AH6ZdOzX/PvERDrNfi2TWlt4eVeqVEkWLVoko0aNkiFDhsiwYcNk165dOpjhJ4VfG2df G08qqG0hVHH43Y+nkc8r5xdnkrGneY7m7a6D+8aQy3OvVatWTtOmTWP+e/fudapXr+784Q9/UD+j +E61atWc0qVLO+YNhnP00Uc7I0aM0HsNGzbUdJE2/nr06KH+5sFEwyEs/BFu9erVjmk4mpdpVE7N mjU1TCxj10n58uWds88+O5a2McacoDQR7bnnnnPMyJCGN0aGY6aKOnXr1o2lCBlMw41dDxgwIO4+ 8nv88cf1frJ5P/PMM7G8y5Ur59SrVy8ubZtpEKswvjYujmHswsoXFM9PHmMwa12hrlHnSLdXr14x MbycunTp4oA3wlWoUMExa/1iYfN7Yoz+uCQScfKrt7gEXBdh7SEZXkjSL98gXY3Ct3Pnzk6ZMmWU KdrP0KFDta2AMdrf8OHDXSU5fAo5osaNIkdQ3SaK27NnT20Ptu1DbjM1UAUN4oKbfhzRLyXqKw4T KLizdOsiGJ500kkO+qF7771X69dPeuriIb2gLh7WDq8uHr7jOOzXEv9+UZfcGpN752Ht47HHHtPf VTMQkafg7GvZ1+ZRijR44PknyMXuhAUyw776kL1mzdo86ZhRJ1VoM1Kl99577z29/vzzz50tW7bo QzweCs3bf70+55xz1LiDQWXePjsdO3Z02rVrp8YFDD8b57rrrnPMmwwHjQmGQJ8+fZzRo0dr2uZt vOY1efLkPPLAAw9y+Bs7dqxjLP3QNDdv2uyYN5COWdenMr7xxhtqSOTHeEtn3raAYayC+Nq4OIax Q90HGadB8fzkwUPlww8/7JhRNM36wQcf1PoyI7N6DS5uI7dq1arOuHHjHDPiqkZr69atNVw6/rk7 YatTYZy8OhMmQ1h7SIYX8vDma2X10/8ofNFWJk6c6CxfttypUqWK8h88eLCD9oYXGm69/v/tXTuI FkkQ7mUNDIz0FGRVThEREcXHaaSsyJ3hbaLBnQqiYiKIiAqur8QTA0VMRPCN7oIYuBhebiCCIgZG gp5itBqK7MpcfbXWbE//PfXP/K/9H9Xw7/R0d3VVf13dO/2q9ssIOYrSFpEjr2412hcvXrC86EPQ F6BNQl70AxouMRzz6sEvc6v8jdbFkydPJgsXLuQ61QZveRjE2m4MQw1zrR4lr6L6FNaD6WKISOPe fV0Mc7V+rfr/L+vXQq3prvewfeD98OHDCZ1348lPTJjFnPW1U98y1j5i2lF7mDYuqzp4GxsbS/r6 +pLjx49HJaBtMTzTf+bMGY7ftWtXsnz5cvY/evSIP8ZevnyZ0srsHm3J5LAdO3Yk27dvT+Nl8Hf5 8uUE9PhhBh0/2hLFstBWoUQGcCmh58E//xMnTqQhWp5PnjxhGfHhKO7QoUOZj1xtcAMa8PMHJY3k LTLhGWJVBF+h17DTyqfRhfIILwzeMDt15coVxlY6xBAnDCrE0fkdXk2Q93qfwhP5FMEp1Jk8/tXa Q1m8Qr6aropMGr4+ppgU2bp1q5AlFy5c4EmYNMDzQI6ytEXliNVtjBaTLdBF6S/OnTuX4J8BXDVc Qhy1evCK3RJvI3URg3KsUt+8eZNl1wZvGgaxthtiWA1zCBCrR4TXok+gg6uFtqgcpovZHQlTiCeJ 9WuCRHGd7nVdmkase3x+X41S0VGfhAyWJFh0wC6hlStXJrJQ4Zfa+trKftvah68htfm1wdssisx1 9BHlaAXA0eDKXfznYjTdggULHH0g8r5gWmnhc3I0+OG0tNWRn8uWLUtpBwYWsX98fDwN8z0fP37k 1/v37zva/sV+GLtYs2aNW79+vbtx44ajj0xH2/YcDRTdyMgIHyj184Cftm6mQVqecl5vyZIlaXra 9pf6a/G0incZfMtg55e5DB2tljja9sZXHSxaNFXPyIvU1s8y9Uv9ImDOnDlucnIyjWukpyhOfr3F +BdpD2XwEh4+X01Xi+DrYzp79uwMpnj/8WP6/Kjwl2dR2rJy+HWr0dLKK7d5tOtt27a5x48fp2dJ NVxEfh/HWupB8mnms15dHD49zBjBeuu1a9f4XC+tpLF/99+73dx5c1Pxa8HAx1DDXKtHEaCoPkl6 /1mUtqwcpos+ylN+69em+kTTpUrd6PUQGrQ5/OBoYOfwP4p2PjhaactAY33tFBx+v219bUZFGv4S NVgCLjAUADPUGHjRDKzrn9Wfyxwf7DjYeenSJff161e3b98+TjswMMBPxIl7+3bKiMXSX5dKkJuY mEj98tF/69Yt9/z58/RHM82c5uDBgw4GUWj/saMzMGxtLSXO8Wh5zp8/n6nEAAlefOMkeKezaGzE BH44GDQp6urlHfLxsSqKr+SRh1218uXRIV9fHugJDvfSVkj37t079+DBA2E9o8+yOMWELdMeiuIV 46PpS7vgW48cGi2tvDlaVXJDQ0MOg5NTp065e/fuMUwaLjEcEabVQx5Ns8Pr1UW0VUyYXb9+3dH5 Rffq1Ss+RA//h/8+VIivYeC33QpCCtAw1+oxllezwuqRQ6PtBV1EnVi/Nq2Zmj5Mp4r7NNpe0aU4 Mt0TigEa+l4xBBaWzPraEJHpd2sf01g0yhcdvEE56XyQw4wubQF0z549c3SOxtHWwihfmEKF5arz 58+7DRs2ODK6wemwYkeGB9yRI0ccZvfoHJzD6tyqVavcxt82cho6l8P/QGCN8vXr125wcJBXzXDX GawVfhn/wrMcT58+5YHBnTt32PoZHdhneqzKVXNanpjhxwwB5IKFNNpa5h4+fJjJErxGR0d5lpu2 h5YalBThPTw8nPKmM3cZ3v5LiFURfIUeg6o87LTyaXShPHQOhtl9+vTJvX//nvVB+M/kswxOMTnL tIcyeMV4afrSLvjWI4dGixVaWJBFP4AZPKz8oN3DabjEcNTqIZa+VWH16iLaMD645bd//35HZ8v4 nbaWZ4qhYRC23QzhzxcNc60eY3k1K6weOTTaXtBF69eyWqnpQzZl5ZtG2wu6VIlI54fgCpY9e/bw HceY3Mc3InZO0HGEisJZX1sBSSbA2kcGDvXlj6FRJz8tYXTwhpUyKCk+pDAwo/MR/Nu7d280Lzqj 4MgKE5tIJ+uCaRpswbl79y5fBYBZiy1btjiYX4Wi0zk6TnfgwAH3/ft3Xo6GKVZ8VGDLJPhjkDfv l3kOaXClAGaKjx49ymmw2gdeuH8jdLiXAz9xWp4YXF69epWXxFevXs3bMjdt2iSk/MQqH7ZX4qJG DOzA28/f5+f7QVyEN2bPwfv27dvcWfh5+4KEWBXBV+g17LTyaXShPNAVMorBK69YscX1AHBSHh8b 3y9pJB0TNfBPEZxCeXz2ZdpDGbxi5db0pQy+sby1MoZx2ns9cmi0mETo7+/niSA8MVm0c+dOR2cn 1XYUK6tWD37dttpfry6G8qKepC8N4zQMwrYL2rDOTRe7WxetX8vqvNY3xdqH31402l7o18K+pxve cZQGiw6DtKCwYsUK/j+EY0Rnz56tKJ71tdm2FLYXax8VKlN/AM0KsaOcxFvTExbhYC41z33+/Jmt o8XiYf2M7qBiq3J+PIyh0ApOJpwGemxJD9Yr89y3b98yNH66WJ6In5yYTGirX0JngtgEd2iVD/F0 ZwdnhbJCZnE+P98v8fLM4w2eYskzzFto5ZmHlYav0GrYaeXT6GLy+LIAD3E+Nr4f8cDAx1Roan2G B48lH182CcMzlMePK+svg5fGN09f/DKAXlyYF53hYKuNEg/d8tNLOJ610BaVI1a3MVpYl1y7dq0v VrJ48eLMdROIjOESyo90Wj0gvlWumboYw9Yvl4ZB2HZjGEpeMcwRF6tHhId5mS5W/78F3Jrt8nSx CF/Tpex3RaztxdpDt/ZrRXSm09LE2gcskuPbEN9ImrP2Ye1D04+icb//OZLITxuX9SFDDAExe/vT i9eedmQali+Zxrktc52JAGbM1q1b15nC96jUx44dc3QvHa+2Yes1/SPly7rp/j9Hppo7FhXTxc6r OtPFzquzdpW4W3WpXfGuRy7rq+tBrzZaax+Ot0nG0Pt37K/ccVl9ZhVj3LogjC7p5i2gXVAUK4Ih 0DEIYPsuXTPCZ2zfvHnDxpJw3nbz5s0dUwYTtDsQMF3sjnpsh1KYLrVDLZgM7YqAtY/aasZW3mrD zajaHAGbQWvzCuoh8UwXe6iy27yopottXkEm3owiYO1jRuHvWeYwUBJz6soblFVc3sF3ibenIWAI GAKGgCFgCBgChoAhYAgYAoZAcxHwx2g+p3TlzWYcfFjM3+kImD53eg12j/ymi91Tl51eEtPFTq9B k7+ZCFj7aCa6lndZBDR9nLanXzZXS28IGAKGgCFgCBgChoAhYAgYAoaAIdAyBGzw1jKojZEhYAgY AoaAIWAIGAKGgCFgCBgCtSNgg7fasTNKQ8AQMAQMAUPAEDAEDAFDwBAwBFqGwP8SuQzCl8uqdwAA AABJRU5ErkJggg== --Apple-Mail=_0F3CCB33-92DA-4213-A16E-0E704662CF64-- --Apple-Mail=_507AE605-0622-403F-B9CA-991B6EBC797F-- --Apple-Mail=_A03CCD77-C4E6-4ED6-A9B2-90CA59703982 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAXwuAACgkQh7ZrRtnS ejPTuAgAwCECF1bBypu33WV2BT4IL4DqJLDXXhYfn0aptF1puMeeI4ujfhOdAI/b Nep3VA+b7e8OMhq3JS/0iOYvY5bI+BBvAL9rynyKLsIJkkiPcpivw6es1gqEezkt lOEmkBxgZ+lHb9YON5M4I6i1hFbDpCIrFWpTzvsRjTBzZOsx41f/xlVkbIKFKpre wCpxP3VsInmqYPdwgFby2JvHYC27qmJkibo7LW8MN1z046GvIT4zUC6oPwzyMPyN rwFgs8uip500uAomVJvEFgdHiddmJNIqlu2IPyTe7f4k7TR+ZuHBMr11kaYdn4XW 3+5hDdF6VumL/ZnWa/yL9J+Sl6NMzg== =VQUk -----END PGP SIGNATURE----- --Apple-Mail=_A03CCD77-C4E6-4ED6-A9B2-90CA59703982-- From nobody Mon Feb 1 01:38:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B373A0C84 for ; Mon, 1 Feb 2021 01:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=J2V52lQ+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bjNrDGG4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8D8ebnROtFa for ; Mon, 1 Feb 2021 01:38:21 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C64F3A0C70 for ; Mon, 1 Feb 2021 01:38:21 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6E808B58 for ; Mon, 1 Feb 2021 04:38:19 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 01 Feb 2021 04:38:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=HBHLT AKhf4K8FDItcAL2BInP3kSoE3QSVhVRJ9/irW0=; b=J2V52lQ+YFzWUIpczi9cj VUVEs7GjwSDECLjZY5SMDCgsy+bM3K557oyIy66rrGW/eWF0vbrcOBUOTwlJB4En qmCYxoEEDnC8TPFJps8RR9ZPLzMuKgRhDhR6a8zEKomXXOkRChDIFAuE3szcAaiv 64cJy+/0UVRnXgQAQ3caZkP/kPNPqER2lOwVOQZTsuSQ81bQ9OnSJ74EoJivnc4x NyFHJ0+7NVR52ERTTEQZ90TTz4pJtQrbtiwr0QSVBQndslcjs/3QIUGAeUsrO2dH 8lt6ndbB64rPUlYq0G/1RpVm1o/YX0R0/iZ/4CiH47tDv7jCyYm3uzl81YBIVpWZ w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=HBHLTAKhf4K8FDItcAL2BInP3kSoE3QSVhVRJ9/ir W0=; b=bjNrDGG4ZjeC9cPpDKjeyOwtiYSxHNglTM+CCu29FeWB9l8RqTa3psIUa mrokx1Mz+ruD5aksZntzKesrAJkCnrXZeRA8eUMqZujrFLU4eybYQJVVhv+44EwU RLfOXr4VXKDC/hCZxq4p6j8d5GVu646hXEZNwT2ggew8dUII1qS7g0yzLghh3CCs yxdNT/sSrNNaQ1P11fq8jzwdaleWVV7KNDkrW/o4tFCX+UDnPr+JKjAQMmknhISS /zHNZ3OquX2lg7bV0Ws1Ro+b3Y8Z+mMxFMmgXOLuH5KyRu4M2Lz6075jrspEopit 97YFrVdf/WFrCxTxmgcco8LFvFaZw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeekgddthecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeegffethfetjefgjefhgf efveejhffffffffefhtdfggfejuedtleetkeevueduteenucffohhmrghinhepihgrsgdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 610CD4E0065; Mon, 1 Feb 2021 04:38:18 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-84-gfc141fe8b8-fm-20210125.001-gfc141fe8 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> <2625bf72-9eb2-4040-eeb9-f1c26b225e46@joelhalpern.com> <9d5ab6db-9422-8036-da3f-8ae46f024d19@gmail.com> Date: Mon, 01 Feb 2021 20:37:58 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Community_last_call_=28was_Re=3A_Propos?= =?utf-8?q?ed_=22Oversight_Body=22_structure=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 09:38:23 -0000 Maybe I should have been clearer. What I was talking about was an appro= val process that only really consisted of testing whether the approval b= ody blocked the proposal. I think that Russ phrased this as "two approv= als and no block positions". That would allow for abstention of two streams. I honestly don't think = that the number of approvals matters very much. You just need to avoid = approving proposals that are frivolous or that lack genuine interest. I= have no real position on whether the RSx should be allowed to engage in= an approval process, because I don't think that it matters all that muc= h. My interest is in what blocking looks like and how an attempt to block m= ight be overturned - if that is possible. With a "voting" RSx, you have to decide a) whether the RSx can block, b)= whether to automatically override a single block position, and c) what = conditions overriding the block would need. Without distinguishing RSx from stream manager roles, sensible values fo= r N_block are 1 or 2. But I would argue that overturning 2 block positi= ons (which might represent 2 whole streams out of four) from a simple ma= jority makes light of those taking block positions. So I'm going to sug= gest that it doesn't make sense to allow for 2 block positions to be ove= rturned, only 1 at most. If there were significantly more streams invol= ved, maybe 2 would make sense, but we aren't there. My other point is that the basis on which the RSx would be blocking are = not very clear. If you distinguish RSx from stream managers and only al= low stream managers to block, that might be better, but then you have th= e same problem as above. You could add the RSx to any vote to overturn = a block, but the real effect there is a new choice between 3/5 to overtu= rn and 4/5 to overturn. Note that in all cases, the individual (stream manager or RSx) were invo= lved in the discussions and were found by the chairs to have been heard = and their concerns addressed, even if they did not necessarily agree wit= h that. They are then exercising their unique option to formalize their= objections. For stream managers, who answer to their stream, I would expect their in= tentions to be clearly communicated and their block position only to occ= ur after wide consultation (would would include the RSx, but also the IR= SG/IESG/IAB/ISEB and various mailing lists as appropriate). Ultimately,= a stream manager has a system by which they are held accountable and I = would expect that to be effective. On Mon, Feb 1, 2021, at 19:59, Eliot Lear wrote: > Hi Martin, >=20 > Martin and all, >=20 > Let us put aside *blocks* for the moment, assuming that we are likely=20= > to find agreement that a block can be overridden. That assumption is=20= > worth discussing, of course. I=E2=80=99ve tried to put this into tabu= lar form=20 > so that people have a feel for what we=E2=80=99re talking about: >=20 >=20 > If the RSE *does* *not* have a vote, but convinces another stream=20 > manager to block, the case we seem most worried about, then it takes=20= > three stream managers to override. If the RSE *does* have a vote and=20= > *also* convinces a stream manager to join, it *still* requires three=20= > stream managers to override, and so there is no difference. >=20 > If on the other hand, the block has to be sustained by a vote, then=20= > there is a difference. In this case, if the RSE has a vote, there=20 > needs to be agreement of two steam managers to sustain. If the RSE=20= > doesn=E2=80=99t have a vote then three stream managers are needed to s= ustain. >=20 > And if two votes are required to block rather than a majority and the=20= > RSE has no vote, this means that all four stream managers would have t= o=20 > vote to override the RSE. >=20 > Thus the voting rules are important to understand. Obviously I=E2=80=99= ve only=20 > delved into one scenario, and there are others. And there are of=20 > course other voting rules. One challenge here is to determine which i= s=20 > the dog and which is the tail: Is it important to be respect streams s= o=20 > that damage cannot occur? Is it important to support the will of the=20= > WG? And of course, the parameters of why one can vote no matter.=20 >=20 > Eliot > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 > Attachments: > * PastedGraphic-3.png > * signature.asc From nobody Mon Feb 1 03:00:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AF33A0D6F for ; Mon, 1 Feb 2021 03:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz0S1AxjYPPc for ; Mon, 1 Feb 2021 03:00:23 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DA13A0D6D for ; Mon, 1 Feb 2021 03:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2975; q=dns/txt; s=iport; t=1612177223; x=1613386823; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=CVXOZ8lY+kIQQGp7UghBNbbHvpT4mSUIjL/hPf6cKz4=; b=MqArxROVkFB3JRK96kd+ncodWZm1ngOqboSTavbj8NVRWWou621l0Ril k+2Py+YRfUBaP/O3ev2Kso4LcDH9eNHf2rl6OxhqvOFo3YRLd8hSBxdQj z8yb/tVx7HDn+EVE7U1C9zBXk8xw4wghCK6wlWu17M+LChUXfrDTQUpfB 0=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BXBAC+3hdg/xbLJq1iHQEBAQEJARIBBQUBgg+DdwEjE?= =?us-ascii?q?jGEQIkEiFWaW4FoBAcBAQEKAwEBLwQBAYRKAoF5JjgTAgMBAQEDAgMBAQEBB?= =?us-ascii?q?QEBAQIBBgRxhW6FcwEBAQMBI1YFCwsOCioCAlcGExSDEgGCZiCvP3aBMoVZh?= =?us-ascii?q?HQQgTiBU4trQYIAgTgcglY+hAmDTjSCLASCExQZg0VhnBKKd5FDgwCDKYE5i?= =?us-ascii?q?1OLSAMfkyuPaLIfg3ICBAYFAhaBbSNncDMaCBsVZQGCPj4SGQ2OWI4TQAMwN?= =?us-ascii?q?wIGAQkBAQMJjBUBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,392,1602547200"; d="asc'?scan'208";a="30679362" 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; 01 Feb 2021 11:00:19 +0000 Received: from [10.209.219.155] ([10.209.219.155]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 111B0IZW021508 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Feb 2021 11:00:19 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A4C12BEF-8872-4509-8675-9BAF400BD866"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 1 Feb 2021 12:00:17 +0100 In-Reply-To: Cc: rfced-future@iab.org To: Martin Thomson References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> <2625bf72-9eb2-4040-eeb9-f1c26b225e46@joelhalpern.com> <9d5ab6db-9422-8036-da3f-8ae46f024d19@gmail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.209.219.155, [10.209.219.155] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 11:00:26 -0000 --Apple-Mail=_A4C12BEF-8872-4509-8675-9BAF400BD866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin, > On 1 Feb 2021, at 10:37, Martin Thomson wrote: > [=E2=80=A6] >=20 > My interest is in what blocking looks like and how an attempt to block = might be overturned - if that is possible. Clarifying the implications of the latter was the purpose of my email, = simply to articulate implications of different voting systems, including = what it would mean for a block to be overturned. >=20 > With a "voting" RSx, you have to decide a) whether the RSx can block, = b) whether to automatically override a single block position, and c) = what conditions overriding the block would need. Indeed. >=20 > Without distinguishing RSx from stream manager roles, sensible values = for N_block are 1 or 2. But I would argue that overturning 2 block = positions (which might represent 2 whole streams out of four) from a = simple majority makes light of those taking block positions. So I'm = going to suggest that it doesn't make sense to allow for 2 block = positions to be overturned, only 1 at most. If there were significantly = more streams involved, maybe 2 would make sense, but we aren't there. Right. What the table I generated shows is that if you go with =E2=80=9C2 = blocks cannot be overridden=E2=80=9D, that means, in order to override, = if the RSx has a vote, that requires all four streams to override. You = can decide for yourself whether you view that as a high bar or not, but = I think Joel also took this case off the table, by saying that the RSx = should not on his or her own be able to block, but perhaps I = misunderstood his position. If that is the prevailing view if the RSE = has a vote, then we are talking 3/5 to override; and if the RSE = doesn=E2=80=99t have a vote, we would be talking 3/4 to override, the = key # being 3. Things go a little differently if the RSE is in the = group that overrides. That would mean that it would be possible for two = stream managers to be overridden. Eliot --Apple-Mail=_A4C12BEF-8872-4509-8675-9BAF400BD866 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAX30EACgkQh7ZrRtnS ejMFWAf/V8NZZ8Cx7eWgf7SmhdMAUFY4gS5NprPf0cikbDl9bjtIrZ3DkAqPVuAj Zuyg/xmTs+B5q4NfOHcrvizoxAf0bxPFJbizRnrZwbZBspPQeB0LvyExMgeXU6qj zzXecarMgRLlmWNGkH00WL/lFAS2tug57K9LWMyJTcDgTmbMW+KmnSzxe25r48ni E5d57ySEMKUb89RI0p4WIAiI+GDjeCEhpcOteBwsLrW7u41gqxSc9YN8HHqylmiB CG787iUffm3huZwvngu729YYGIUm34e+V2Sll9/R7buo7bZ7p0Vv477UEP/ZJspG 5GhbD9bIpZ7cSebMArWMGQ89Cx70Pw== =QRfw -----END PGP SIGNATURE----- --Apple-Mail=_A4C12BEF-8872-4509-8675-9BAF400BD866-- From nobody Mon Feb 1 06:27:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848E83A11C4 for ; Mon, 1 Feb 2021 06:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCW7G1mxsfyD for ; Mon, 1 Feb 2021 06:27:10 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F9F3A11FD for ; Mon, 1 Feb 2021 06:27:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4DTqyg3gZnz1pGjK; Mon, 1 Feb 2021 06:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612189627; bh=o+CkiKFRKTrfPrT9UFMtj2v3++XbC8u0uXwtv/XfwME=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lg3dhrd1XkenoBP+Yz/W0lwGzRhL7+QjxrBS19TnI+mucKBfk0e6E/BdyyXqwR3eU I29TXjLATH7VFs5J8rBSiqQR52htZGcnbBLeOxoLLm1ObeXn8isOeeRSE5QlbpMn/W hsMEjhXsUriOjgYvFENH2EMJKmmLWM2H0irpIlDw= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4DTqyg05BXz1nyG3; Mon, 1 Feb 2021 06:27:06 -0800 (PST) To: Eliot Lear Cc: rfced-future@iab.org References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> <2625bf72-9eb2-4040-eeb9-f1c26b225e46@joelhalpern.com> <9d5ab6db-9422-8036-da3f-8ae46f024d19@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Mon, 1 Feb 2021 09:27:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 14:27:12 -0000 I think there are two aspects about which your table seems to be misleading. First, and most important, I want the structure to be robust if we add or remove a stream. Focusing on the exact number obscures that. Secondly, whether a person has a formal say in the decision (whether we call that a vote or a requirement for consensus, or a DISCUSS position doesn't matter) or does not have such a formal say inevitably affects the interaction with the rest of the body. I think it is important for the way I at least want the RSE/A viewed that they have the same kind of say that the stream managers have. Yours, Joel On 2/1/2021 6:00 AM, Eliot Lear wrote: > Hi Martin, > > > > >> On 1 Feb 2021, at 10:37, Martin Thomson wrote: >> […] >> >> My interest is in what blocking looks like and how an attempt to block might be overturned - if that is possible. > > Clarifying the implications of the latter was the purpose of my email, simply to articulate implications of different voting systems, including what it would mean for a block to be overturned. > >> >> With a "voting" RSx, you have to decide a) whether the RSx can block, b) whether to automatically override a single block position, and c) what conditions overriding the block would need. > > Indeed. > >> >> Without distinguishing RSx from stream manager roles, sensible values for N_block are 1 or 2. But I would argue that overturning 2 block positions (which might represent 2 whole streams out of four) from a simple majority makes light of those taking block positions. So I'm going to suggest that it doesn't make sense to allow for 2 block positions to be overturned, only 1 at most. If there were significantly more streams involved, maybe 2 would make sense, but we aren't there. > > Right. What the table I generated shows is that if you go with “2 blocks cannot be overridden”, that means, in order to override, if the RSx has a vote, that requires all four streams to override. You can decide for yourself whether you view that as a high bar or not, but I think Joel also took this case off the table, by saying that the RSx should not on his or her own be able to block, but perhaps I misunderstood his position. If that is the prevailing view if the RSE has a vote, then we are talking 3/5 to override; and if the RSE doesn’t have a vote, we would be talking 3/4 to override, the key # being 3. Things go a little differently if the RSE is in the group that overrides. That would mean that it would be possible for two stream managers to be overridden. > > Eliot > > > > From nobody Mon Feb 1 19:06:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458533A16D1 for ; Mon, 1 Feb 2021 19:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.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 LWv-gNC3ruDB for ; Mon, 1 Feb 2021 19:06:31 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400102.outbound.protection.outlook.com [40.107.140.102]) (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 C56533A16CE for ; Mon, 1 Feb 2021 19:06:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uye8D7tuHgBdUDMPV2xkjwoLe92AfLDzRD816J2SZE275ptweCQe8+ZpCtFrMDbP+f3oYERdhuroeHd0qeEp3DA70dIxh6rz7Y9D7oYahKG0IiR6DVgI3QiNx9vM39khY/U3mKvCvOTfRSmKaWpxtp8KDaV9fKkJ6Huv+0cW7QqQe3uChaiTGcJ/WHeIUbHI+H7sjnwxar+xcw+9AxmQjOhLvMSSHWBQECAb3TbTE+193pq//4LEXgsmlnQ4iCiMw3qcphpZV4oU/PMFQW2u9jHnIQl+4TQ7BQ/FJ2SyI+OYt3NZqmOoOsAD6kBNp8tWsRzU5QxozT53iFaipCGSoQ== 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=hDcTrh+U27IKagmzrNv5NM8l5zW/wk5iHfIJH5aRPmw=; b=cIzy7/CyWxh4GPhO9Elrz7I9K82UaPvkUbkql6TUsDQK8Saleir/0oZcnkLDEV+T8NlBmO/VNdPngtoQRyf1OOpnPOTcEQXh0VNMM/3KVSNR9XJAojZ6MFVLyL71vhBuhD0W7Qiy1yFoLpPxuPjJUKwKWHHgyvYB9hudCJBq9v0WRw+B+3WgJtFKzt23XwG5UczRwwjLIHsWPpbX4KaLrbGc2WONP7Z3e6d0CW3zgq7SO1h9FB6/4gLezE9DaKxo8Nk1pyn9BS9K6cFwEYPnpmU8btHIzRJ+waBRZ+SZAy/Rk95eKhYhlNNACIvyRMbt3BzS7qB85Rg8yaQref3CHg== 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=hDcTrh+U27IKagmzrNv5NM8l5zW/wk5iHfIJH5aRPmw=; b=bCus7zRXEQKgfR5nCiv778PdNTeoIYc2RM3qu8YwYSiA9ea2tRZuB5m6ehjfIM5OGDylA1BEZRvtyDv+qPxj53P97tTUdasQjKK5FCtb7wAKTsr/7xs0det0DFrifuGL21h0O6br7V3RHBxtxeN39qIPIHDazRvJwiko9DbX4vI= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYXPR01MB1647.jpnprd01.prod.outlook.com (2603:1096:403:11::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.16; Tue, 2 Feb 2021 03:06:25 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f%7]) with mapi id 15.20.3805.027; Tue, 2 Feb 2021 03:06:25 +0000 To: Christian Huitema , S Moonesamy , adrian@olddog.co.uk, rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <231598be-03f4-fe22-e4ba-5afff0e104d3@it.aoyama.ac.jp> Date: Tue, 2 Feb 2021 12:06:22 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.83] X-ClientProxiedBy: TYXPR01CA0048.jpnprd01.prod.outlook.com (2603:1096:403:a::18) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.11.2] (133.2.210.83) by TYXPR01CA0048.jpnprd01.prod.outlook.com (2603:1096:403:a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.16 via Frontend Transport; Tue, 2 Feb 2021 03:06:24 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8b8ee44a-da55-4b39-728b-08d8c727868f X-MS-TrafficTypeDiagnostic: TYXPR01MB1647: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: n7ut6/2IGbhq77F8lodIW/0VJjaOu1jVnvGVRUuIhRnoAYP+VgOWQerEqCyiLF9b6JDRN+7iBXZJO3LCmB3jQqK+bHaeY4CpzCwLSBbyEbXMLOwOjAbi864qp8Ue0vri3PeTmrKJYvCx/uPOArf/VSiUr+y0lFckR+vlruAutldkaClRyqKEpQNcXZg+6YwXaKAxxahvcDZQ/7bgrJpKnyfhRl3062NjsuA+R3PQli077Y+he/PLm4hcE3p5g7A/WmWz+xpCkwSDBzGJBkVo5bcVxwx3rGDmJK9vmf9orgFj5H+NUFKPYBw025LzAMADY9pAbsqpFesAN8xKCQz/d3rBayukBLSy2yb5pcfPjkgS7Ah4/1EGEhiz+wtZrbKoDaPLQk+9QvbL/MZKFPU8GzyDRC5UD20rpN24FTuZgsbF2pmY4y0LrKiexXyugko4rNdUia9+u2OjXJTsuLH3uGk96dKUUQGUg0Cgis1YM6FVIIRZK1APh7yOM9SAvDaupDJ48kdy7w1hAlRjU3mGEgQlSV/bbjcLEVU+3R54WN74C1wBZa/7xaxgyGowO5+Lm7wGNSzkqNwUF1t/DjN86qdwNFlnNed/8juFbwUdvCc= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(376002)(39840400004)(396003)(136003)(26005)(83380400001)(53546011)(8936002)(31686004)(956004)(2616005)(16526019)(186003)(8676002)(5660300002)(66946007)(66476007)(36916002)(16576012)(316002)(786003)(110136005)(478600001)(6486002)(31696002)(66556008)(52116002)(2906002)(86362001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?L245QWtRbkM4ZGt5c09LSkVaL3R4dU0zTFQydk5FeUgrbEl1eklJZFp2bjFL?= =?utf-8?B?eHVuWHpDNG5qRU9vY0FtbUFVdlNLUllXQm9ZTFhmSnNaMTlXcUZPeUk4RDJK?= =?utf-8?B?ZFAzOUpFRTlUNTJDek9KQTEwWU9sRVFuRFpiZ1BIQWxhQi9TSlppZ0VuS29E?= =?utf-8?B?SHFvUk95dktaMHNVNnh1SElvSmkra0VPeVBocXQ3WmxiTkJ6V1ExUkNIUi9N?= =?utf-8?B?N01ObGVTN08yOVFXR1d3aUtyMW1jMGpKV1FmZWdWOG02SnZndEFPSVhLK0g2?= =?utf-8?B?OVdUeUJrZzJOdE4wcXVGc01QTjhVRDEvM1N1Y1Q2RkxCbHhFbkhKZWU3aUhx?= =?utf-8?B?UFJGMkNLSEpKUE9hSGtUdzlFMTVNYS9YTDQ0RFV1VVozN3FscitEWnlQdUxv?= =?utf-8?B?RzRwSUllM0pBaStEcFdjNFpOSUtGRmswV28yRU0xWHBlY1d1RnAxaldQWVRO?= =?utf-8?B?WldHNThCcTJ2RU5rL3doaTZ5UGVqREFaeFhrSEdoaUk3RFF2a1kxL0ExWXRl?= =?utf-8?B?ZWxWRzA4YkJmTVJNdnBjV0I2ZmFZc1BtYkJOR0Y2V1RFcEdlMmhjSkVzanZa?= =?utf-8?B?MU9IVFkwc0d5THpVWHZsdmRpeS9oM0VENXhNTDlFVkRCZHowY3YwdjdGU3BZ?= =?utf-8?B?SFU4UFpsZGxYNW5RbWNtVkxsL3M5ZEVIOXRnL2JaUENMVjkwdklCRnZvSS9z?= =?utf-8?B?MUFDeldIbVczbUhHQWJjcTZJU2p0bmR4WEd2OTJ4RXhuWE5VTzQ1Wnp2NGJ5?= =?utf-8?B?ZGRGV0lTRDVOOThWcjU3WHl5UFQ2M0Rzais1eGxrV0Q3cCtxd1YxY0duaVJu?= =?utf-8?B?Z1h1ZGlDRzF2ekJONmdDY0dIeE1YU001Z2RWMXdMQTlPdHRNOXpHWkRSMERJ?= =?utf-8?B?clVCNi9vUUxWNkNDQkNJa2NzRVh4WHhDMHFIRHNjdjhvNFhWWVAyOE90NlRS?= =?utf-8?B?Rk9Jb2ZCK1Q1UVNMREtpMzFmTzc4V2ZTM1BpdzFnRXAybGRzRnBWYkpjVUl2?= =?utf-8?B?dkFWNjRMNy9icGFKY3dmRFQyWFZLSVJ5K1FlTVphWE5nMDVqZ3ozWURxUlZM?= =?utf-8?B?a0NoLy84a281QlY3OVVxbXZVQUsya0tZSjA3WXBTclpkNklucVJ0c1BJcUtz?= =?utf-8?B?NlVQUFBkdlZPbGg1MHM3VkU1RGFyc3E3dnlaQy9QcnhzTk5uSFlQOGVsS0s4?= =?utf-8?B?ckxyVTRCWFlrQjRvVyt2QjBjdnlrbjd0TnZxREc5QlkwaHp4b2pjamRWbjZB?= =?utf-8?B?VmxQMEppY1ZGVlFoNHowWlhKaHN6czhpUEtETXM1MUlQakwwanYzd2FmK2pX?= =?utf-8?B?QWhIWndIWTZNNmNGRE9POVcyb091WlBIL1krZkVidHlhazFlSnNGZUhCak5V?= =?utf-8?B?TTQ0NlR1K1IvaXc0L0JONjJIYlFkSERhRzJrYlNRRXE4TUlNS0J4Z1JMMmxl?= =?utf-8?Q?J8+sZLPg?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 8b8ee44a-da55-4b39-728b-08d8c727868f X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2021 03:06:25.0225 (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: qjmOWLa+5iPsAMbCuPqJfvptQjNyPB//2t2R3v4ne6GQ7O1fFk+YXQQDLCA21j5BbUd2fhNmH8C+VWDA/VqeOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB1647 Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 03:06:33 -0000 On 01/02/2021 06:53, Christian Huitema wrote: > > On 1/31/2021 12:43 PM, S Moonesamy wrote: >> The person who is better suited for that job is the RFC Series >> Editor.  It is unlikely that under-represented stakeholders would be >> regular participants of the group in which the decision is taken. > > > I don't think so. We have more or less agreed that this is a matter of > knowing who the RFC "consumers" are and understand what their unmet > needs might be. In a commercial business, that's a task for marketing > departments and business managers. If I look at past RSE hiring > processes, market research and business management were not high on the > list of hiring criteria. If I look at RFC 8728, I don't find any mention > of market studies, user panels and the like. Indeed, doing such studies > would be very hard when the budgeted workload is only "approximately 20 > hrs per week". So, no, the RFC Series Editor is not the better suited > person for that job. I fully agree that the RFC Series Editor (or what we're going to call them) isn't too suited for formal marketing research that takes a serious amount of time. But I think the RFC Series Editor is important when it comes to the voice of the stakeholders, in particular the "silent consumers" of RFC. The stream managers' backgrounds to first approximations all come from the writing side of the process, at least originally more interested in getting a new protocol to paper than in whether the series reaches the readership at large in the right way and serves them well. On the way to becoming a stream manager, the perspective will change somewhat, but probably only somewhat. For the participants in the WG, on average they will be even closer to the writers' side. The RFC Series Editor, if we find the right person, is by their expertise attuned to the needs of both readers and writers. Even if this goes only so far as to have "how does this affect our potential consumers" on a checklist. Regards, Martin. B.T.W.: I also agree that it may not be the best idea to spend a ton of money on marketing research. If we didn't do the right thing for the past 50 years, the RFC series wouldn't be in the position that we are now, and if we move forward steadily (but not too fast), we should be able to stay where we are or improve. From nobody Mon Feb 1 20:42:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6353A173D for ; Mon, 1 Feb 2021 20:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MblGDtYtK1k6 for ; Mon, 1 Feb 2021 20:42:50 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557063A173B for ; Mon, 1 Feb 2021 20:42:50 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id o16so14092695pgg.5 for ; Mon, 01 Feb 2021 20:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=mw4MsP3NTd18DDoqsvYXa3pZl1C+KsXEG9Edum7/aH8=; b=saJWj1vbaPi0+S2Vk+lW5fefXEGueH3174vS0jRPYFGBN0VRASLUUWoJfYiihgBl4T mw2Bs9bYUfW6nQkKvfibpTWo6PbtX/0xO9Q2lr/zmFj3ujIj4psIHIQb2VGbn1v6VEZI qc/pwpOv5eE+bYV/XkyxLmTEdiD+MAc+GZW+uEPAFDa0SDywbq6p7OsZoci6D2OwBxPn xgDnKMFJpiverNviYd3t40VCUoQojZfmnXWjVIZxgh30eCVzNpOthSZ0A/rYuSE/64Ip 9vk5aO/4dsglrz4KkbUjp0MFCR7HQ7y/C9vJrt/14wEdR2k+/4TTDI2uOUkGo2gSDUkx 9vqg== 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=mw4MsP3NTd18DDoqsvYXa3pZl1C+KsXEG9Edum7/aH8=; b=faEj3Cl9QSZ64p5i/h6BxHmJdBLb/6An2zJQdWl15Snip6L4VskidgRiReOUVPxXk9 IkTfAIU5QeqgrTOzVW94p34VbimKN0SoD/2qrgtTmvGl0r52IjWqmwBwNf2gbFrC3eMP gkRSkc5TCss0+Q8mJ45vJ0LNIhXouZO1Wk4UZFgqirXXbWD+f12+qpCkjducfh9dX3oB wvXULEXR8EoJmiE3Lcy+4B1i+D9smv3BA6rwP+ZXuj/l7aUmU4BJdHLyt2Qz82ANYK52 FOOSMd+ZTIvjkqPQ8lHhxy91Iud+iRsKNsA3egtf9gChurauPozkNuv6UwUL90i58BKx yuew== X-Gm-Message-State: AOAM531AE4b49Odq+WLwRzuDl5Dpr7/A/18LlFoZjCrigCWjLPYIvFf8 BzCM8uS33UhAkwrKNnzERSyi4fq9lVQ4qw== X-Google-Smtp-Source: ABdhPJxRiRcyE9oxyhbZY8uqKwWQYuMmvxfPkeijVEkRfEQrazXOeYYNlYhPeWrleqXs8Bp4nB8vyw== X-Received: by 2002:a65:56cb:: with SMTP id w11mr20683881pgs.88.1612240969064; Mon, 01 Feb 2021 20:42:49 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id 14sm10300323pgp.83.2021.02.01.20.42.46 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Feb 2021 20:42:48 -0800 (PST) To: rfced-future@iab.org References: <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> <2625bf72-9eb2-4040-eeb9-f1c26b225e46@joelhalpern.com> <9d5ab6db-9422-8036-da3f-8ae46f024d19@gmail.com> From: Brian E Carpenter Message-ID: <185f96c4-f979-f7e2-1c48-a6440ca1dc1e@gmail.com> Date: Tue, 2 Feb 2021 17:42:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 04:42:52 -0000 On 02-Feb-21 03:27, Joel M. Halpern wrote: > I think there are two aspects about which your table seems to be mislea= ding. >=20 > First, and most important, I want the structure to be robust if we add = > or remove a stream. Focusing on the exact number obscures that. >=20 > Secondly, whether a person has a formal say in the decision (whether we= =20 > call that a vote or a requirement for consensus, or a DISCUSS position = > doesn't matter) or does not have such a formal say inevitably affects=20 > the interaction with the rest of the body. I think it is important for= =20 > the way I at least want the RSE/A viewed that they have the same kind o= f=20 > say that the stream managers have. Exactly. Why are we in trouble? Because the previous RSE felt they were not being treated as a colleague with relevant expertise but as a hired hand. The one mistake to avoid above all is re-creating that situation. I think we shouldn't use the word "vote" at all, nor "block". The approving body rule should be: consensus. If that means long arguments to clear a "discuss" by any member, so be it. It's not as though this body will be reviewing a very large number of documents. Brian >=20 > Yours, > Joel >=20 > On 2/1/2021 6:00 AM, Eliot Lear wrote: >> Hi Martin, >> >> >> >> >>> On 1 Feb 2021, at 10:37, Martin Thomson wrote: >>> [=E2=80=A6] >>> >>> My interest is in what blocking looks like and how an attempt to bloc= k might be overturned - if that is possible. >> >> Clarifying the implications of the latter was the purpose of my email,= simply to articulate implications of different voting systems, including= what it would mean for a block to be overturned. >> >>> >>> With a "voting" RSx, you have to decide a) whether the RSx can block,= b) whether to automatically override a single block position, and c) wha= t conditions overriding the block would need. >> >> Indeed. >> >>> >>> Without distinguishing RSx from stream manager roles, sensible values= for N_block are 1 or 2. But I would argue that overturning 2 block posi= tions (which might represent 2 whole streams out of four) from a simple m= ajority makes light of those taking block positions. So I'm going to sug= gest that it doesn't make sense to allow for 2 block positions to be over= turned, only 1 at most. If there were significantly more streams involve= d, maybe 2 would make sense, but we aren't there. >> >> Right. What the table I generated shows is that if you go with =E2=80=9C= 2 blocks cannot be overridden=E2=80=9D, that means, in order to override,= if the RSx has a vote, that requires all four streams to override. You = can decide for yourself whether you view that as a high bar or not, but I= think Joel also took this case off the table, by saying that the RSx sho= uld not on his or her own be able to block, but perhaps I misunderstood h= is position. If that is the prevailing view if the RSE has a vote, then = we are talking 3/5 to override; and if the RSE doesn=E2=80=99t have a vot= e, we would be talking 3/4 to override, the key # being 3. Things go a l= ittle differently if the RSE is in the group that overrides. That would = mean that it would be possible for two stream managers to be overridden. >> >> Eliot >> >> >> >> >=20 From nobody Tue Feb 2 05:23:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BDA3A1AA0; Tue, 2 Feb 2021 05:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC8z6dSTb4cR; Tue, 2 Feb 2021 05:23:20 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690E93A1AB0; Tue, 2 Feb 2021 05:23:20 -0800 (PST) Received: from p200300dee71fe6004532821c9515d309.dip0.t-ipconnect.de ([2003:de:e71f:e600:4532:821c:9515:d309]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1l6veF-0000a9-1s; Tue, 02 Feb 2021 14:23:15 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 2 Feb 2021 14:23:08 +0100 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <8761FACD-0F79-40A5-BB26-0F0C4BE7A7FA@kuehlewind.net> References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> <2625bf72-9eb2-4040-eeb9-f1c26b225e46@joelhalpern.com> <9d5ab6db-9422-8036-da3f-8ae46f024d19@gmail.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1612272200;ef62b025; X-HE-SMSGID: 1l6veF-0000a9-1s Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 13:23:22 -0000 I think I could see a shepherd-like role for the RSx in the process, = where the RSx write some kind of short report for the approval body that = summarises the process and the impact on the series as a whole from = his/her point of view. In that process I think it would also make sense = for the RSx to directly participate in meetings of the approval body and = have an additional chance to discuss and explain any concerns directly = with stream managers. However, I support Martin=E2=80=99s proposal (I = might wrongly attribute this to Martin but he most recently expanded his = view on the list) where only stream managers can block (and only one is = needed for the block) but the block has to be back-up in some way by = community input for the respective stream. Mirja =20 > On 1. Feb 2021, at 15:27, Joel M. Halpern wrote: >=20 > I think there are two aspects about which your table seems to be = misleading. >=20 > First, and most important, I want the structure to be robust if we add = or remove a stream. Focusing on the exact number obscures that. >=20 > Secondly, whether a person has a formal say in the decision (whether = we call that a vote or a requirement for consensus, or a DISCUSS = position doesn't matter) or does not have such a formal say inevitably = affects the interaction with the rest of the body. I think it is = important for the way I at least want the RSE/A viewed that they have = the same kind of say that the stream managers have. >=20 > Yours, > Joel >=20 > On 2/1/2021 6:00 AM, Eliot Lear wrote: >> Hi Martin, >>> On 1 Feb 2021, at 10:37, Martin Thomson wrote: >>> [=E2=80=A6] >>>=20 >>> My interest is in what blocking looks like and how an attempt to = block might be overturned - if that is possible. >> Clarifying the implications of the latter was the purpose of my = email, simply to articulate implications of different voting systems, = including what it would mean for a block to be overturned. >>>=20 >>> With a "voting" RSx, you have to decide a) whether the RSx can = block, b) whether to automatically override a single block position, and = c) what conditions overriding the block would need. >> Indeed. >>>=20 >>> Without distinguishing RSx from stream manager roles, sensible = values for N_block are 1 or 2. But I would argue that overturning 2 = block positions (which might represent 2 whole streams out of four) from = a simple majority makes light of those taking block positions. So I'm = going to suggest that it doesn't make sense to allow for 2 block = positions to be overturned, only 1 at most. If there were significantly = more streams involved, maybe 2 would make sense, but we aren't there. >> Right. What the table I generated shows is that if you go with =E2=80=9C= 2 blocks cannot be overridden=E2=80=9D, that means, in order to = override, if the RSx has a vote, that requires all four streams to = override. You can decide for yourself whether you view that as a high = bar or not, but I think Joel also took this case off the table, by = saying that the RSx should not on his or her own be able to block, but = perhaps I misunderstood his position. If that is the prevailing view if = the RSE has a vote, then we are talking 3/5 to override; and if the RSE = doesn=E2=80=99t have a vote, we would be talking 3/4 to override, the = key # being 3. Things go a little differently if the RSE is in the = group that overrides. That would mean that it would be possible for two = stream managers to be overridden. >> Eliot >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Fri Feb 5 12:14:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88893A097B for ; Fri, 5 Feb 2021 12:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97kjuLUd1Tg8 for ; Fri, 5 Feb 2021 12:14:09 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94C43A0977 for ; Fri, 5 Feb 2021 12:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5999; q=dns/txt; s=iport; t=1612556049; x=1613765649; h=from:mime-version:subject:message-id:date:cc:to; bh=4HRYCbmeiWSN4UVVjxZmU7VBNRyd6U47ggqX/uFcx0M=; b=l9rLBAoe6jO0GqlWXxyHI23t+/N3JQSIBAb706mkEqJReXlYtRADdZWk uBIVumNBZzI7fAPm56LJ5UsSXloTsQRC1VlbmmZUjlppC9GqntJIWMjNw VmT3pP5nYF0N48dUyqpI20rTXlMl0BQzIo+fqLjSAmlM0RqVrrA0rLlkm 8=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0A6AAAdph1glxbLJq1YChwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?X4EAQELAYN2AScShHKJBIhYlCmIHQQHAQEBCgMBAS8EAQGES4IDJjcGDgIDA?= =?us-ascii?q?QEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAQEBhkOGHVYfPgKEGAGDBq9adoEyi?= =?us-ascii?q?lUQgTgBgVKFK4cGggCBOByDFIQRg0Y0giwEgWWBayF2ZhKIe5RqnEKDBIMpg?= =?us-ascii?q?TqLAoweAx+TNY9thV2JC6JsYoNyAgQGBQIWgWwigVkzGggbFTsqAYI/PRIZD?= =?us-ascii?q?Y47jjFAA2cCBgEJAQEDCYwYAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,156,1610409600"; d="asc'?scan'208,217";a="33247333" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Feb 2021 20:14:04 +0000 Received: from [10.61.248.160] ([10.61.248.160]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 115KE3m1011716 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Feb 2021 20:14:04 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_97597095-55B7-489D-A774-6FAD14ABA3EE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Fri, 5 Feb 2021 21:14:00 +0100 Cc: Brian Rosen To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.248.160, [10.61.248.160] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 Feb 2021 20:14:11 -0000 --Apple-Mail=_97597095-55B7-489D-A774-6FAD14ABA3EE Content-Type: multipart/alternative; boundary="Apple-Mail=_715557DF-9F89-426F-88FB-C597A173DCA3" --Apple-Mail=_715557DF-9F89-426F-88FB-C597A173DCA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, First, the chairs want to again thank Eric for bringing some text to the = discussion. =46rom our perspective, there is a lot on which we may = agree, and we would like to test consensus on some of the points, = knowing that discussion is ongoing on other aspects. Do people agree that the stream managers are part of the approval body? Do people agree that process proposals flow from the WG to the approval = body? Do people agree that the grounds for rejection of a proposal include = damage to a stream? Do people agree that any objections must be returned to the WG for = discussion? Do people agree that if the WG still wants to press forward, two = objections would still halt approval? Do people agree that damage to a stream would include long term = strategic damage to the series? Not on this list is whether the RSx is part of the approval body. To = summarize where we are there, one group of people believe that it is = important for the RSx to be a voting member, either because that person = would represent those not otherwise represented (and yes, we=E2=80=99ve = had some back and forth about that), while another group of people feel = strongly that the RSx not be a voting member. The chairs believe this is = a good topic for our upcoming meeting. What is important: proponents of each position (and perhaps there are = many different positions) should be prepared to present the principles = that they are arguing for. For each person arguing a particular = position, we ask that you also be prepared to identify what = accommodations or model changes would accommodate you if you couldn=E2=80=99= t get your first choice. We=E2=80=99ve some of this, and we are hoping = to see more, so that people can find common ground. Brian and Eliot --Apple-Mail=_715557DF-9F89-426F-88FB-C597A173DCA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi everyone,

First, the chairs want to again thank = Eric for bringing some text to the discussion.  =46rom our = perspective, there is a lot on which we may agree, and we would like to = test consensus on some of the points, = knowing that discussion is ongoing on other aspects.

  • Do people agree that the stream = managers are part of the approval body?
  • Do people = agree that process proposals flow from the WG to the approval = body?
  • Do people agree that the grounds for rejection = of a proposal include damage to a stream?
  • Do people = agree that any objections must be returned to the WG for = discussion?
  • Do people agree that if the WG still = wants to press forward, two objections would still halt = approval?
  • Do people agree that damage to a stream = would include long term strategic damage to the series?

Not on this list = is whether the RSx is part of the approval body.  To summarize = where we are there, one group of people believe that it is important for = the RSx to be a voting member, either because that person would = represent those not otherwise represented (and yes, we=E2=80=99ve had = some back and forth about that), while another group of people feel = strongly that the RSx not be a voting member. The chairs believe this is = a good topic for our upcoming meeting.

What is important: proponents of each = position (and perhaps there are many different positions) should be = prepared to present the principles that they are arguing for.  For = each person arguing a particular position, we ask that you also be = prepared to identify what accommodations or model changes would = accommodate you if you couldn=E2=80=99t get your first choice. =  We=E2=80=99ve some of this, and we are hoping to see more, so that = people can find common ground.

Brian and Eliot

= --Apple-Mail=_715557DF-9F89-426F-88FB-C597A173DCA3-- --Apple-Mail=_97597095-55B7-489D-A774-6FAD14ABA3EE 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAdpwgACgkQh7ZrRtnS ejM1Iwf8CoAkusY9BmQKJ4ldlspsEcUaZM5/mUCdVOy2u5D+mLCxKzyoaLAUuBv+ qVVtTDeibrEJ38tpd5czAqUqDsbxUKqm7DfbBL0YkerWPpaYZaLOIVHN49KajV8C MVhCBdRkrYm9FftPU8ftDuGrWC5m6ZrHg/MhLWIKW8KIq+zIGD0P7Ey0SECAUrtA +TaNMew1Rf/R9wxGnxzWoa/y2OLnztOaNjz7nCRXi7TNVoKEKeDihD79cZc+7qjy HOsq5W3hHkS4GwUBkqhM5294olmxXN/t5yrlhbn700/ZLSBIy2YLT5Mx52VYTKw8 C8ileEf/t9G4GvRz8d2ruVy9UgFt8A== =QS7B -----END PGP SIGNATURE----- --Apple-Mail=_97597095-55B7-489D-A774-6FAD14ABA3EE-- From nobody Fri Feb 5 13:40:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8103A0B9E; Fri, 5 Feb 2021 13:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oePmyz8Y4XA4; Fri, 5 Feb 2021 13:40:51 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37703A0B9B; Fri, 5 Feb 2021 13:40:49 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 115Lel8u027470; Fri, 5 Feb 2021 21:40:47 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F13D222044; Fri, 5 Feb 2021 21:40:46 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id DBA2822042; Fri, 5 Feb 2021 21:40:46 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.213.140]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 115LektI021864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Feb 2021 21:40:46 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , Cc: "'Brian Rosen'" References: In-Reply-To: Date: Fri, 5 Feb 2021 21:40:45 -0000 Organization: Old Dog Consulting Message-ID: <021601d6fc07$9010f790$b032e6b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0217_01D6FC07.901193D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIYaRiysfHThU9mQ6jMJgdJ+87H2anHNB0w Content-Language: en-gb X-Originating-IP: 87.112.213.140 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-25942.003 X-TM-AS-Result: No--17.586-10.0-31-10 X-imss-scan-details: No--17.586-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--17.585800-10.000000 X-TMASE-MatchedRID: 1ZHks2aQIkjxIbpQ8BhdbI61Z+HJnvsO82SgwNf6SK5JfyfUaPjAATmr XyG6fk0vX381PW63B5TH39dhEJpZcydARCKiy3r73nHtGkYl/VoXhPQmXMtIyx05C+fzCc4ue1x IFd7hF80Fw308tAFb1MfDJ5e8ALQmQCcVNodhPICBy++9FI444so0g7hj5evQsHEoeZMrWPnDRv ew35mZe5NupfWOa6Q58jOPhxGbqdYQ5gJEdH9K6hn0wrEetTLh4B4Qje1seFVNmgiruhkfsAtnz kCU3SIFLTRm0zBN5IQDXNqw39n8P0+SXKwkW5E0+ACG5oWJ7tIog3IF7wM1smKWkc3vEp/1GjDs M7wByqclvtgGJU6FYQWgef1C0L+e7GX0c1UlalzsjRHO89icwvQRmxcXXTEKsKDgHLT2eo/v/72 zC4hJFVhUDZOPhwqIr/EwLya77le0CeKFBeer6FICmG2RRehovO61PPXizylFdhD9u4+PBMTr/G 24o7RrhWQmZZ+uR46qKXbpBKHp1VKTeVVwHCqXJhFEQZiq2ZQ2Ajd4eN7gE4xRWJphhsrcTXOj1 XBAu3ApTvNzKFoS2tYHxVr9gN7RIU+ehk8Xygd7Gtyy745tZykDYTG6KmZauY38HaAuzo5PqN+r 8vk5EGNq8ZU9js3y6JBhFChuHBKbfaDvaGX/M2hQCsqhuTNiBaExZeqJZbI3Rx11yoeUQnlEDb1 OO87ou7C4hieFwVKAMuqetGVettLvsKjhs0lda9+JVKonO7eLZAVphLW/bXkguuQorcgMQtcrHC WMRW4mmp2lzfu2q8LhInH2AebxLWoQ/SH4mnx+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 Feb 2021 21:40:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0217_01D6FC07.901193D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Brian and Eliot. =20 Thanks for this. =20 Yes, but=E2=80=A6 =F0=9F=98=8A =20 Your list is nicely phrased as things I can agree with, but they are not = limiting statements. So, > Do people agree that the stream managers are part of the approval = body? I agree, but I=E2=80=99d be interested to know who else is there, and = whether those others can also object. > Do people agree that process proposals flow from the WG to the = approval body? I agree, and I suspect you mean to say that proposals originating in the = approval body (I think they are capable of original thought) must flow = into the WG. > Do people agree that the grounds for rejection of a proposal include = damage to a stream? Certainly that is one of the reasons. I wonder what other grounds are = considered. > Do people agree that any objections must be returned to the WG for = discussion? I think that one is unavoidable in that the WG will discuss what the WG = discusses. But maybe, the objection must be clearly set out and the = objector must make themselves available to discuss the objection. > Do people agree that if the WG still wants to press forward, two = objections would still halt approval? I agree that two objections would halt approval. But I also think that = one objection would halt approval. It would not be acceptable, in my = opinion, for the WG and the approval body to shut down the IAB stream = against the opinion of the manager of the IAB stream (nominally the = chair of the IAB). > Do people agree that damage to a stream would include long term = strategic damage to the series? I agree. I think that many other things might be uncovered as damage to = a stream. I am not sure that citing an example that is pretty much the = most significant damage to a stream is a useful thing to do. It might be = better to qualify the grounds for objection as =E2=80=9Csignificant = damage to the stream=E2=80=9D although that, too, is a subjective thing = so would be better accompanied by examples of non-grounds for objection. This could be compared to the IESG=E2=80=99s Discuss criteria list [1] = that is mainly a list of reasons why not to enter a Discuss, and [2] = that is a fuller list of why and why not to Discuss, but it must be = remembered that those references did not exist ab initio, they were = developed over time and with experience of what is and is not = reasonable. I caution against trying to define our list of reasons to = object and not object with any precision before we have running code. Cheers, Adrian =20 [1] https://www.ietf.org/standards/process/iesg-ballots/ [2] = https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ ------=_NextPart_000_0217_01D6FC07.901193D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Brian and = Eliot.

 

Thanks for = this.

 

Yes, = but=E2=80=A6 😊

 

Your list = is nicely phrased as things I can agree with, but they are not limiting = statements. So,

> Do = people agree that the stream managers are part of the approval = body?

I agree, = but I=E2=80=99d be interested to know who else is there, and whether = those others can also object.

> Do = people agree that process proposals flow from the WG to the approval = body?

I agree, = and I suspect you mean to say that proposals originating in the approval = body (I think they are capable of original thought) must flow into the = WG.

> Do = people agree that the grounds for rejection of a proposal include damage = to a stream?

Certainly = that is one of the reasons. I wonder what other grounds are = considered.

> Do = people agree that any objections must be returned to the WG for = discussion?

I think = that one is unavoidable in that the WG will discuss what the WG = discusses. But maybe, the objection must be clearly set out and the = objector must make themselves available to discuss the = objection.

> Do = people agree that if the WG still wants to press forward, two objections = would still halt approval?

I agree = that two objections would halt approval. But I also think that one = objection would halt approval. It would not be acceptable, in my = opinion, for the WG and the approval body to shut down the IAB stream = against the opinion of the manager of the IAB stream (nominally the = chair of the IAB).

> Do = people agree that damage to a stream would include long term strategic = damage to the series?

I agree. I = think that many other things might be uncovered as damage to a stream. I = am not sure that citing an example that is pretty much the most = significant damage to a stream is a useful thing to do. It might be = better to qualify the grounds for objection as =E2=80=9Csignificant = damage to the stream=E2=80=9D although that, too, is a subjective thing = so would be better accompanied by examples of non-grounds for = objection.

This could = be compared to the IESG=E2=80=99s Discuss criteria list [1] that is = mainly a list of reasons why not to enter a Discuss, and [2] that is a = fuller list of why and why not to Discuss, but it must be remembered = that those references did not exist ab initio, they were developed over = time and with experience of what is and is not reasonable. I caution = against trying to define our list of reasons to object and not object = with any precision before we have running = code.

------=_NextPart_000_0217_01D6FC07.901193D0-- From nobody Fri Feb 5 21:18:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9517F3A0CB4 for ; Fri, 5 Feb 2021 21:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=XejAdM2u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dlhINWcS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvcnjCuwzRw3 for ; Fri, 5 Feb 2021 21:18:20 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CBC3A0C70 for ; Fri, 5 Feb 2021 21:18:20 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1CB865C0170; Sat, 6 Feb 2021 00:18:18 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 06 Feb 2021 00:18:18 -0500 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=fm1; bh=1 D1aHrCZa/4q9yzlO6CULNEga766c9A6cQkX2vTy4hg=; b=XejAdM2u7owkXBXoo 6UXltZHQ3Vp+sf8dOno4Xn2XGvyDcfgKCqfgzLJTzLFrJbYijuXHH4CfZ54Kn/T1 WsYXRKYTvbqS/MG2j5vkRXYg2/1SWXeco/kBSYvTrEFQMFY1gyrEKnvEn5TIrRJ/ YgxsrJ6nToPBn3hHpVUVe6REyjO+f8w4jjwn95ukVWN2/Wzbmvuat77/xNV2c2dn 9P94vwwRf9jET+T1WoC0BbXC7Dark7WC+vEjP3WcoHdCFvqQq709iGRlK85/ebSE O6spIiWfYL6K46nfutzJpWSf/NNQmxOJVDSYyTplGT19U85FwKmy1uxKyBTmf3YC kMbtg== 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=1D1aHrCZa/4q9yzlO6CULNEga766c9A6cQkX2vTy4 hg=; b=dlhINWcSlv+t0V7cdZIZy7lVgPOpStTe2Fki+6AKgfgYSAwtn8jOobAQB t1z+/nMoKNEjwhS+V8STfCUrrOKCs29WQs2Wwo1TUrWMw9rjTjVVBRbwGIUIj0KO KE+sowe84ZPi8rHgr7/gNYuvx9MOgmRQhbxuJKkIiY1L3Co849k1/fg1K+aB2T3/ jKie+fZ1uXvN3DR7O6qgZjhCxVCWgcaEEVp1RKKR36Tn/kSIHygOIHzXASf9ljS2 9EveMzt5lXFZRSn4f+y15KUCD6tZ1zQKFnp/FA2GxLgrOFI8du6gQtIm2IdJslFN 00sr3GfBzlYyAzdT6WLXKm65JPpiA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgeejgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepuedtkefhtdfggfejjeegkeevheefhffguefgheefgfegkefhiedtgeduvedufeei necuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrud ejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 92AC8108005C; Sat, 6 Feb 2021 00:18:15 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> Date: Sat, 6 Feb 2021 16:18:11 +1100 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 Feb 2021 05:18:23 -0000 My .02 - I agree that the RSA/E would have some scope to do this.=20 I don't think it should rest completely on their shoulders; our = community may have diversity issues, but the folks here are somewhat = representative of many of those who are the audience. In particular, our documents are very often used by developers of = implementations. Implementers do participate in the IETF (at least in = some WGs), but they may hesitate to participate in our process-oriented = discussions (whether they're about RFC formats or not) because of the = overhead of wading in and the obscurity of how to do so. Improving both = would go a long way towards getting good feedback from them. Our documents are also used by non-developer organisations interested in = the Internet; e.g., civil society advocates. Again, they have some voice = in the IETF, and we should make sure to give them a path to being heard. = Having a WG is a good first step; establishing newcomer-friendly = policies, documentation and communication channels are excellent = improvement.=20 As part of that, I think the RSA/E should be explicitly responsible for = updating the woefully out-of-date RFC Editor web site, and making it = more user-oriented. However, that update should be guided and helped by = the community. Those improvements would also benefit "outside" parties who are = impacted. Adrian, you mention regulators. Considering that they're = already dealing with a wide variety of inputs, I strongly suspect that = regulators will take documents in whatever form we publish them, and = account for any unusual aspects when handling them. Taking their needs = into account is good, but I doubt if we'll be able to establish = concretely what those needs are, beyond very generic things (e.g., = well-defined identifiers for document revisions). Of course, regulators = are likely to have very specific needs or asks for what the documents = *contain*, but that's not of concern in this discussion. Cheers, > On 30 Jan 2021, at 12:11 am, Adrian Farrel = wrote: >=20 > Hi, >=20 > I've been chewing on this thought for a while and trying to keep up = with the > list (but please excuse me if this has come up and I missed it). >=20 > The thrust of Ekr's proposal (1/25) seems reasonable, but I have a = concern > about how we handle the people who might be considerably impacted by = any > changes the WG might come up with, but who are not present in the WG. >=20 > Now, I can usually get behind, "If you want to influence the work, > participate in the work." That is certainly how we have operated in = the > IETF, and generally it gives good results for producing quality = technical > specifications. But I think that this WG might be in a slightly = different > space. >=20 > In practice, we are asking people who are consumers of RFCs to = participate > in the discussions about the publication format etc. when they might = not > even be aware that the forum exists, and might anyway be unaccustomed = to > this way of working. In some cases, the stakeholders might even be one = step > removed from the RFCs (for example, regulators who want to point at = RFCs, > but who do not actually implement or read them). >=20 > My concern is that one or two people turning up from these large but > under-represented classes of stakeholder may be swamped by our normal = "rough > consensus" process. I am not saying that their voices will not be = heard, nor > that the correct mechanisms will not be used to consider their input. = But I > am worried that they will lack the experience and expertise to make = their > points stick in this WG, and that, if push comes to shove, their voice = will > be seen as a minority and they will be placed "in the rough". >=20 > Of course, the chairs of the WG will have a considerable = responsibility to > make sure that things go well for everyone, but in the end, they also = call > rough consensus. They are only advocates for participants in ensuring = that > their voice has the opportunity to be heard. >=20 > So my questions are: Who is the advocate for the under-represented > stakeholders? Whose job is it to actively search out relevant = opinions? Who > has the role of champion for these groups of RFC consumers to make = sure that > the decisions the WG make do not negatively impact them? >=20 > Thanks, > Adrian >=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 Sat Feb 6 04:26:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DB03A11E5 for ; Sat, 6 Feb 2021 04:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK5-OtdfUHsj for ; Sat, 6 Feb 2021 04:26:10 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2AA13A11DD for ; Sat, 6 Feb 2021 04:26:08 -0800 (PST) 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 116CQ6KL007129 for ; Sat, 6 Feb 2021 12:26:06 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B209822044 for ; Sat, 6 Feb 2021 12:26:06 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 9CBE622042 for ; Sat, 6 Feb 2021 12:26:06 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.213.140]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 116CQ6C5026585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 6 Feb 2021 12:26:06 GMT Reply-To: From: "Adrian Farrel" To: References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> In-Reply-To: <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> Date: Sat, 6 Feb 2021 12:26:06 -0000 Organization: Old Dog Consulting Message-ID: <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIxOzb1K7FOVzc7vzw9Sqa6JmeniwF/68HOqYqMfUA= Content-Language: en-gb X-Originating-IP: 87.112.213.140 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-25942.003 X-TM-AS-Result: No--6.405-10.0-31-10 X-imss-scan-details: No--6.405-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--6.404600-10.000000 X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbA9RDMhLd9LxIPwiH5Xl/Q+OVdQAiMmbZ8IY BSM4Ewz36NdheNSN9pJtmSir9NYJ2lGr6ohBh0/JzG0LtXz4gg8LKPaBHScRdcuSXx71bvSL7DW CYCEbYYAjK5rofJieudbP5w1UCcocJe7HBOQfEXEM6z3iDvziB7esiCwR1MqZI0FYZlCQVHz5fo TZVKB971Aa2WC3aDeYyJV1y3Bb8ieZfIEUmIhDjuLdprnA5EQRamKrgqy61cKIjNQMv4cWVh/po FKGNxRgcPGDt7QpVEzE4mRA11sk3HjWEqrIFFVBGUlF/M3Dxp+ZrgJQpYk0s6Y3y6dPFN/1tSzj idB3/zCHrLqxWmCofS9G4rNM7gvBam2DS6xi1qA5UYVNPDbxhxg6dAPBanTEgn6pqeAeoD3kYBD LwsbmZ/5OvY/Ps44pcLMYhk9iyhqiO3Qgdcs2/uT02pOa52nUrXkuON8pnlGwuKAMD8Wm9fkQr0 HUybaGEiafkruoBMdjfHml0KvmQgXp/7hssh2W1T7WuTapx0pKPWAEHR5iOx+ZGcvxEG4EIYok7 P49JF5RQd5yDx6da6jUAKRnPP1WIF2fzdjiJNKNCVVXBJuPJ4m9+/qM3b3Br1uVaZUKda8tWsZQ KJLuTG2c8p3lLh40pq6tain/U3yRMGo4Vx8d0Llex/rKSh4TKkm+fBCGp0DG6iWKMNj1gODCspZ 2HyWY/+kXWhtYH7Ob/0YxSONuXm/o6yyAq3W+qjZ865FPtppyKkg/f6CTQK4136m7d1Ma+KW9v3 rNxsjslvjRiTq2pylg90m5wvY39ypsAEjQDdueAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg/cUt5lc1lLglxhPCV6M7c0WWCXh9oq3D1PIARyky3GG4FLz4d/Ii8j8AXgd3XTd/waVdNeY o2cOlExlQIQeRG0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 Feb 2021 12:26:13 -0000 I knew, I just knew it as I typed it, that if I gave an example of a class of user that is not frequently present in our working meetings or on our mailing lists, someone would choose to debate that example rather than the wider topic. Mark rightly notes that some non-developer organisations that consume RFCs have some voice in the IETF. He also notes that the way we conduct business may inhibit participation. And this cuts somewhat to my concern, but not completely. I am worried that the way we in the IETF build and assess consensus is not well suited to making decisions about the RFC series in a "working group" because such a group is likely to be heavily populated by just one section of the community (the regular IETFer) so that any counter opinions (if, indeed, they are expressed at all) will be considered minor voices or in the rough. So it is good to hear some thoughts that the RSA/E would have some responsibility for considering other voices and bringing their needs and aspirations to the table. But it doesn't cut much ice with me to hear that "the folks here are somewhat representative of many of those who are the audience", in fact it worries we somewhat because it sounds similar to the way silent majorities are often excluded by those in power (I do not accuse anyone here present of such an intention). Now, suppose the RSA/E has the responsibility and expresses a concern to the WG. I know we all like to think ourselves reasonable people, and I suppose we like to hope that we will pass the baton on to similarly reasonable people, but suppose that the WG pushes ahead anyway disregarding the RSA/E's concerns? What then? - Is the RSA/E in the approval group to let them know the problems? - Can a stream manager block the change that is not a direct harm to their stream? - Can the RSA/E somehow make the WG think again? Cheers, Adrian -----Original Message----- From: Mark Nottingham Sent: 06 February 2021 05:18 To: Adrian Farrel Cc: rfced-future@iab.org Subject: Re: [Rfced-future] The voices of stakeholders My .02 - I agree that the RSA/E would have some scope to do this. I don't think it should rest completely on their shoulders; our community may have diversity issues, but the folks here are somewhat representative of many of those who are the audience. In particular, our documents are very often used by developers of implementations. Implementers do participate in the IETF (at least in some WGs), but they may hesitate to participate in our process-oriented discussions (whether they're about RFC formats or not) because of the overhead of wading in and the obscurity of how to do so. Improving both would go a long way towards getting good feedback from them. Our documents are also used by non-developer organisations interested in the Internet; e.g., civil society advocates. Again, they have some voice in the IETF, and we should make sure to give them a path to being heard. Having a WG is a good first step; establishing newcomer-friendly policies, documentation and communication channels are excellent improvement. As part of that, I think the RSA/E should be explicitly responsible for updating the woefully out-of-date RFC Editor web site, and making it more user-oriented. However, that update should be guided and helped by the community. Those improvements would also benefit "outside" parties who are impacted. Adrian, you mention regulators. Considering that they're already dealing with a wide variety of inputs, I strongly suspect that regulators will take documents in whatever form we publish them, and account for any unusual aspects when handling them. Taking their needs into account is good, but I doubt if we'll be able to establish concretely what those needs are, beyond very generic things (e.g., well-defined identifiers for document revisions). Of course, regulators are likely to have very specific needs or asks for what the documents *contain*, but that's not of concern in this discussion. Cheers, > On 30 Jan 2021, at 12:11 am, Adrian Farrel wrote: > > Hi, > > I've been chewing on this thought for a while and trying to keep up with the > list (but please excuse me if this has come up and I missed it). > > The thrust of Ekr's proposal (1/25) seems reasonable, but I have a concern > about how we handle the people who might be considerably impacted by any > changes the WG might come up with, but who are not present in the WG. > > Now, I can usually get behind, "If you want to influence the work, > participate in the work." That is certainly how we have operated in the > IETF, and generally it gives good results for producing quality technical > specifications. But I think that this WG might be in a slightly different > space. > > In practice, we are asking people who are consumers of RFCs to participate > in the discussions about the publication format etc. when they might not > even be aware that the forum exists, and might anyway be unaccustomed to > this way of working. In some cases, the stakeholders might even be one step > removed from the RFCs (for example, regulators who want to point at RFCs, > but who do not actually implement or read them). > > My concern is that one or two people turning up from these large but > under-represented classes of stakeholder may be swamped by our normal "rough > consensus" process. I am not saying that their voices will not be heard, nor > that the correct mechanisms will not be used to consider their input. But I > am worried that they will lack the experience and expertise to make their > points stick in this WG, and that, if push comes to shove, their voice will > be seen as a minority and they will be placed "in the rough". > > Of course, the chairs of the WG will have a considerable responsibility to > make sure that things go well for everyone, but in the end, they also call > rough consensus. They are only advocates for participants in ensuring that > their voice has the opportunity to be heard. > > So my questions are: Who is the advocate for the under-represented > stakeholders? Whose job is it to actively search out relevant opinions? Who > has the role of champion for these groups of RFC consumers to make sure that > the decisions the WG make do not negatively impact them? > > Thanks, > Adrian > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Sat Feb 6 12:36:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE383A2BBE for ; Sat, 6 Feb 2021 12:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TODReezgxu-E for ; Sat, 6 Feb 2021 12:36:41 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D5A3A2BBC for ; Sat, 6 Feb 2021 12:36:41 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id t25so7091523pga.2 for ; Sat, 06 Feb 2021 12:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=k/3FwbM56xNopNGVNNvGFYT/0YF96e7gDM/XR/r3RWo=; b=ThxmjpY2dnlYdsO5aFhPgZCnXcoNQTrtNHssU2kAEIUNNhr2IGaacNFXkDgq1ejBHD BZvIYkuuj7mi76p+hNpYLnlF7LyKIf/vajmwmGaoeKe/60LgjLpk7ALPm2YciMImqwaI T3UaQBlUv1iwyVEaGzGSiPIaZkeFYqqMTDnrvoe1dz3OgIr/CYuFuG61tvqgMhFsKPSh uB6ckAA2DXeY9MAH1aa1hAYNeQvSArRQEP7AMQJWkyS4SpuxT4TarCOi139MJJBsqIql Fm2EcWPhjRYe/evBdecaG8GxGlrNHUatbdcOTN8UZ2MZE3L+FjYYL5Bxn2vznosfjVsP j0bQ== 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=k/3FwbM56xNopNGVNNvGFYT/0YF96e7gDM/XR/r3RWo=; b=tkiuL8jX3yf9/iAR9zFFBe3gD8PvrRnc29z6bvlLdHo+ho3nmPpf2LO+AJWP/IO4jf u4xIjQD/iElFam1fdv+tyJZwks3PocuOHFYcnzfes2v1QtFl5IuWXe4Z9b1xzJ4mOQhQ bVgyF5+H4pXOUns7xcmhrXiFskfKFttT5oYtLPkn8As40pPdMhk+s8QD4pz3sK7lXl6X WnDrZXVADHoH7TSHYuvgrNHyBOoOB0x3mgSEXHc+dwbpwNZXhT2j6v0Itn7qLsnffrFK ctu6RBBl3JTQYqqLOWVpqzOTozGMFakoYV91tRBnQ3IlYS0Ly3QNfYHJjbHkPjETf+kt Jtgg== X-Gm-Message-State: AOAM533Ky/0tgxrXX2GdPrL1J8KvWUcrgTmXB97mz75FwZC6P+oQpADR TR8vMoXlameGEQFrU+GUEOuMx6uNXDEE9g== X-Google-Smtp-Source: ABdhPJzqBw8sIoKAKQnfwppZCSRXgk8849KRo0W2DWIDJTk3tMELozlp7BW1X5snPQoCKbuLiNiOsg== X-Received: by 2002:a63:5c61:: with SMTP id n33mr10980687pgm.153.1612643800419; Sat, 06 Feb 2021 12:36:40 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id j3sm5024145pgk.24.2021.02.06.12.36.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Feb 2021 12:36:39 -0800 (PST) To: Eliot Lear , rfced-future@iab.org Cc: Brian Rosen References: From: Brian E Carpenter Message-ID: <0fbee513-aa8d-80a2-0976-d2ca3e985d29@gmail.com> Date: Sun, 7 Feb 2021 09:36:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 Feb 2021 20:36:42 -0000 On 06-Feb-21 09:14, Eliot Lear wrote: > Hi everyone, >=20 > First, the chairs want to again thank Eric for bringing some text to th= e discussion. =C2=A0From our perspective, there is a lot on which we may = agree, and we would like to test consensus on=C2=A0*some*=C2=A0of the poi= nts, knowing that discussion is ongoing on other aspects. >=20 > * Do people agree that the stream managers are part of the approval b= ody? Yes > * Do people agree that process proposals flow from the WG to the appr= oval body? Yes > * Do people agree that the grounds for rejection of a proposal includ= e damage to a stream? Yes > * Do people agree that any objections must be returned to the WG for = discussion? Yes > * Do people agree that if the WG still wants to press forward, two ob= jections would still halt approval? No. I think we should require consensus, rather than defining voting rule= s. We're talking about a rather small group - consensus is not an unreaso= nable goal. Suppose the vote was 4:1 in favour of scrapping the normative/informative= distinction. Do we want the IETF Stream to be overruled on this? > * Do people agree that damage to a stream would include long term str= ategic damage to the series? Why ask that? The bullet above does not state that damage to a stream is = the *only* ground for objection. Certainly, damage to the series as a who= le must be a ground for objection, but that isn't what you are asking. Brian C >=20 >=20 > Not on this list is whether the RSx is part of the approval body. =C2=A0= To summarize where we are there, one group of people believe that it is i= mportant for the RSx to be a voting member, either because that person wo= uld represent those not otherwise represented (and yes, we=E2=80=99ve had= some back and forth about that), while another group of people feel stro= ngly that the RSx not be a voting member. The chairs believe this is a go= od topic for our upcoming meeting. >=20 > What is important: proponents of each position (and perhaps there are m= any different positions) should be prepared to present the principles tha= t they are arguing for. =C2=A0For each person arguing a particular positi= on, we ask that you also be prepared to identify what accommodations or m= odel changes would accommodate you if you couldn=E2=80=99t get your first= choice. =C2=A0We=E2=80=99ve some of this, and we are hoping to see more,= so that people can find common ground. >=20 > Brian and Eliot >=20 >=20 From nobody Sat Feb 6 12:42:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EB33A2BCC for ; Sat, 6 Feb 2021 12:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhNILi5prqG0 for ; Sat, 6 Feb 2021 12:42:56 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6F93A2BD6 for ; Sat, 6 Feb 2021 12:42:51 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id x23so5237165pfn.6 for ; Sat, 06 Feb 2021 12:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Bl93RJ7SW3XMIjch/EqUcfm3syNqXO2joj8U4ObyQUA=; b=qkBhIlzyrDi8sxZY7nmPgYfkyjdQqR9KlXPiSRAfGTSK+YnS4/NcGi4AAF7kL0hL6X oy3+NIdh55KzAHsWPdNAqiZj2SdM0N48usk7Y7ugmIM5SiNdO4uOCdt+pkGdDqyXN4QC vIo7FsEuwuB7LWmqwBiMZdHx/fIrcDL+Xe6COV6OetzSAI0CHVCHzVATbjbf8H2dXtnC n3KoD/gm7sbDpMOwtVBENq70go9n8sgMsv14XY3gLOiZi6n2133kSU4OZ4C7GAeT/rTU QuD+ydMHtAFXC0o96DTre1d/JEUkSVJn6dHmO7QnaXkmYW6gJuDvU2slDv+foTxcs86c HDjQ== 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=Bl93RJ7SW3XMIjch/EqUcfm3syNqXO2joj8U4ObyQUA=; b=ABIkFikTY+YuKeYCI9tVxvHFqN3nmRaYOIP79fUl2snRFBY/po+MDnBsBU7QM4ZuM4 /h2tKiXVQE5snSLNfPSOYXgoIGMqor1h44CyJwlz/BL+ycxadHru0GPPqyGaDtZJy1Hd IExHbNsbPPhq7QcqQWqam2wAiWAlHo4whPVWmvrxjaNcRqQ1QH6rIreEw4L8RzxntTGK LBw/dNFvkOSg2/lfjZqgSb4/7//MnWcfOWeiOMM9ZsbwGutBpSvHP/4jj2JjRLv33+Qb Y7qdJ4oe1VYpFndrrEXbX1Z+4b4SsYhpi+eUsOKchGeA4cpIlsagElrYxB8T95LGwZQI Bv3A== X-Gm-Message-State: AOAM533Q7mr7ejUnQjN5kg/KNJKl3Y+f7wHMvYX9d4P2/osRdSOgmZuI BXdi4U2tjCXA5+JZe/e9aHFal0j1/8JdOw== X-Google-Smtp-Source: ABdhPJzP73Pwun2Z99Wgc1SwNnRja5TQ/OZ8sfNFu3BJBM0w/8y8iiI64D/XiWnDnydnD5RLIJRpUg== X-Received: by 2002:aa7:8f13:0:b029:1bd:f965:66d8 with SMTP id x19-20020aa78f130000b02901bdf96566d8mr10366061pfr.80.1612644171060; Sat, 06 Feb 2021 12:42:51 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id m7sm10062695pgl.71.2021.02.06.12.42.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Feb 2021 12:42:50 -0800 (PST) To: adrian@olddog.co.uk, rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> From: Brian E Carpenter Message-ID: <182d57b3-847a-9af8-1f00-eef453c3d1df@gmail.com> Date: Sun, 7 Feb 2021 09:42:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 Feb 2021 20:42:58 -0000 On 07-Feb-21 01:26, Adrian Farrel wrote: ... > - Is the RSA/E in the approval group to let them know the problems? I consider that to be essential. The stream managers are not omniscient. > - Can a stream manager block the change that is not a direct harm to their > stream? Yes. Especially if they think it is harmful to the series as a whole. > - Can the RSA/E somehow make the WG think again? Yes, if (and only if) the RSA/E can also prevent consensus in the approval group. But that's a "reserve power" that will never be needed if the WG functions as it's supposed to, which includes listening to the RSA/E. Brian From nobody Sun Feb 7 16:14:35 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A82B3A0CE2 for ; Sun, 7 Feb 2021 16:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=haNPp2QC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nwmNK5GI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYt49FeRMEkU for ; Sun, 7 Feb 2021 16:14:33 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1205A3A0CDD for ; Sun, 7 Feb 2021 16:14:33 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1799F5C009B for ; Sun, 7 Feb 2021 19:14:32 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Sun, 07 Feb 2021 19:14:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=joLCG k0rGMwsE0swb2o8qVImFY33reLbOa1Gj/SdonM=; b=haNPp2QC5dGAoZJurs3LL ENGi7JQUlPiWcV0THbj8eJDepo55TQyiUN7azdXbjf0zXYiFepayD61eIkiw9jb0 KCZrDD/M3dyVxPlNrD0vWbCDa9xmTJMbAj8+1dgLiRZPWL3dYU6oJtec77MSuvso NGrKhurQvjjZw+evL+VQC1gpTcpK8MdyCeIsEmIo2t4kUG7XvAawBmBcqMVgFDsd x0RZZ56gCdE44CkQMc7R+rkDuIMjyKTf5OMNWeskDp6ao0O6UN9Yvn2+gatMRbaq ERM6eIcJO8pMQY9VlaD2+I+tCUzVUtMijyeJATk9jzokdzWJ1ti16ZrHhdicOhMR w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=joLCGk0rGMwsE0swb2o8qVImFY33reLbOa1Gj/Sdo nM=; b=nwmNK5GICqfrAht+nn8+V+Y75POusRr9cwbD6McV9iiJB+lV/kC1CNVmE lS+Wf51FFZhccLVf63kVqdxdfgfhwfF6QjP+wttZVBb/PwAcruaCfyxKY6LLCyWC lpw9D+VEz4l2yLTJQNVCmOm/e3RqQaERiRr20qEYi60YpxIq8gd4ifrWQYZikyb0 +e8Q5a8kUpoV4Ed30Mqe1L57CqTmvIY59DcA0V3mlcGtulr19+DALFnY/AuVBFSr DDUhzIVEJo8oDct43WwHzXBVjTUIgo/GgfIUjl0xzTCo91h6EIHBIFTASX/J/IuY yLWvZuYWBj6VnAw+VlH5qFQ90R/nw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrhedvgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgjeeuudeiffeltdegle ehjedvtedtjeduudehgfegfefgkefgueeiteegffdttdenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 947A34E0080; Sun, 7 Feb 2021 19:14:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-93-gef6c4048e6-fm-20210128.002-gef6c4048 Mime-Version: 1.0 Message-Id: <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> In-Reply-To: <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> Date: Mon, 08 Feb 2021 11:14:08 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Rfced-future] =?utf-8?q?Communities_and_representation_=28was_R?= =?utf-8?q?e=3A__The_voices_of_stakeholders=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 00:14:34 -0000 On Sat, Feb 6, 2021, at 23:26, Adrian Farrel wrote: > silent majorities are often excluded by those in power (I do not accus= e > anyone here present of such an intention). I find myself really liking the turn this discussion took. That is, I l= ike that we are explicitly considering the biases inherent in the design= s we're considering and how to counteract them. > Now, suppose the RSA/E has the responsibility and expresses a concern = to the > WG.=20 This my be my own lack of knowledge, but I'm hearing an assumption here,= and I want to repeat what I'm hearing out loud to see if it makes sense= to others. It doesn't add up for me. Are we assuming that the RSA/E has expertise in outreach to these divers= e communities of interest? Is this something that expertise in technical publication naturally come= s with? Which community or communities are then naturally represented? Effective representation is something we struggle with everywhere. But = I can give an example from an adjacent community. When we discuss wheth= er web API Foo is good for the web, one of the questions we try to under= stand is whether the web developer community would benefit. (Even there= , we routinely fail to capture the diversity of that community, usually = only getting input from large sites.) But browser-makers in particular = do spend non-trivial time and effort in gathering this input, and we als= o benefit from the experience of people in that community who aren't beh= olden to a browser-maker also. But we do not assume that those people a= lso represent the interests of communities in which they have not spent = that time; though these are paid professionals with deep expertise, that= expertise is narrow. And the conclusions reached on the basis of web d= eveloper feedback can, on some matters, demonstrate a bias against other= stakeholder interests (certain user communities, for instance). In the IETF, we have experience with people connected to various communi= ties that interact with the work we do. People who implement, deploy, o= perate, purchase, and so forth. As Mark points out, we are now lucky en= ough to sometimes have people participate from communities that study th= e effect of our decisions on people and societies. But my experience is= that the community of interest speaking is generally understood, usuall= y as a result of getting to know the person speaking a little. Of course no single person speaks for any community because no community= is ever so uniform as to have precisely one position on just about any = subject. And any who claim to speak for a community can only do so thro= ugh the filter of their own biases. Again, getting to know someone to b= etter understand those biases is also part of how we manage that. I use the long anecdote (rant?) to highlight that if we are looking for = someone to convey a particular viewpoint, we need to understand what we'= re looking for. If publication expertise is truly alien to us engineer-= y folks, I don't think that we have much hope of doing anything except i= nvest the RSA/E with power that leaves the series at the mercy of the LL= C hiring process. But, like the lawyer example, I think that we can lea= rn to recognize the shape of our lack of knowledge. To do that, maybe s= omeone can define the undefinable and tell me which community we might e= xpect a publication expert to be able to represent. From nobody Sun Feb 7 16:23:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FAA3A0D03 for ; Sun, 7 Feb 2021 16:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6CWVBMQsgJU3 for ; Sun, 7 Feb 2021 16:23:51 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16903A0D01 for ; Sun, 7 Feb 2021 16:23:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DYmwR4kWbz6G9yp; Sun, 7 Feb 2021 16:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612743831; bh=+qa/2fvlFrKizM8vjyvOJ4dicBkrgoqgaY9e+dc+t0E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gTEBB4wS2m2lRs02s+bRFJ+h5aYioSngzvWM1p7XRWd4WWrhw14cplGrzODPI5cee RMbIoX8km3V4ZYNpSCx5av2whmdPdRRqOKJTwVy0X5JoInw93MBTe/Ya0z0Es4fAmm g3CLCsvJw5vCfmRVuGr7KyD1rEddWAZbsgD2m/bI= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DYmwR17drz6G90K; Sun, 7 Feb 2021 16:23:51 -0800 (PST) To: Martin Thomson , rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> From: "Joel M. Halpern" Message-ID: <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> Date: Sun, 7 Feb 2021 19:23:50 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 00:23:53 -0000 SSBkbyBub3QgdGhpbmsgdGhhdCBhIHRlY2huaWNhbCBwdWJsaWNhdGlvbiBleHBlcnQgY2Fu IGluaGVyZW50bHkgDQpyZXByZXNlbnQgdGhlIGJyb2FkIHJhbmdlIG9mIG91ciBleHRlcm5h bCBjb21tdW5pdGllcy4NCg0KVGhlcmUgYXJlIGhvd2V2ZXIgdHdvIHJlbGV2YW50IGRpbWVu c2lvbnMuDQpGaXJzdCwgbXVjaCBvZiBzZW5pb3IgdGVjaG5pY2FsIHB1Ymxpc2hpbmcgZG9l cyBpbnZvbHZlIG1ha2luZyBzdXJlIHRoZSANCmNvbnN0aXR1ZW50IGNvbW11bml0aWVzIGFy ZSBoZWFyZCBmcm9tLiAgIFNvIHdoaWxlIG5vdCBhbiBpbmhlcmVudCANCmV4cGVydGlzZSwg aXQgaXMgYSByZWxldmFudCBleHBlcnRpc2UuDQpTZWNvbmQsIHdlIGNhbiB3cml0ZSBkb3du IChhcyB3ZSBoYXZlIGluIHRoZSBwYXN0KSB0aGF0IGl0IGlzIHBhcnQgb2YgDQp0aGUgam9i LiAgRHVyaW5nIHByZXZpb3VzIHNlYXJjaGVzIGZvciByZWxhdGVkIHBvc2l0aW9ucywgc2tp bGwgLyANCmV4cGVyaWVuY2UgLyBhYmlsaXR5IHRvIHByb3ZpZGUgdGhhdCBkaW1lbnNpb24g d2FzIG9uZSBvZiB0aGUgdGhpbmcgdGhhdCANCndhcyBhc2tlZCBhYm91dCAvIGNvbnNpZGVy ZWQgZHVyaW5nIHRoZSBzZWxlY3Rpb24uICAoV2hldGhlciB3ZSBkaWQgdGhlIA0Kam9iIHJp Z2h0IGlzIGEgZGlmZmVyZW50IHF1ZXN0aW9uLikgIERlY2lkaW5nIHdoYXQgd2Ugd2FudCBh bmQgaW5jbHVkaW5nIA0KaXQgdGhlIHNlYXJjaCBjcml0ZXJpYSBzZWVtcyByYXRoZXIgbmVj ZXNzYXJ5Lg0KDQpZb3VycywNCkpvZWwNCg0KT24gMi83LzIwMjEgNzoxNCBQTSwgTWFydGlu IFRob21zb24gd3JvdGU6DQo+IE9uIFNhdCwgRmViIDYsIDIwMjEsIGF0IDIzOjI2LCBBZHJp YW4gRmFycmVsIHdyb3RlOg0KPj4gc2lsZW50IG1ham9yaXRpZXMgYXJlIG9mdGVuIGV4Y2x1 ZGVkIGJ5IHRob3NlIGluIHBvd2VyIChJIGRvIG5vdCBhY2N1c2UNCj4+IGFueW9uZSBoZXJl IHByZXNlbnQgb2Ygc3VjaCBhbiBpbnRlbnRpb24pLg0KPiANCj4gSSBmaW5kIG15c2VsZiBy ZWFsbHkgbGlraW5nIHRoZSB0dXJuIHRoaXMgZGlzY3Vzc2lvbiB0b29rLiAgVGhhdCBpcywg SSBsaWtlIHRoYXQgd2UgYXJlIGV4cGxpY2l0bHkgY29uc2lkZXJpbmcgdGhlIGJpYXNlcyBp bmhlcmVudCBpbiB0aGUgZGVzaWducyB3ZSdyZSBjb25zaWRlcmluZyBhbmQgaG93IHRvIGNv dW50ZXJhY3QgdGhlbS4NCj4gDQo+PiBOb3csIHN1cHBvc2UgdGhlIFJTQS9FIGhhcyB0aGUg cmVzcG9uc2liaWxpdHkgYW5kIGV4cHJlc3NlcyBhIGNvbmNlcm4gdG8gdGhlDQo+PiBXRy4N Cj4gDQo+IFRoaXMgbXkgYmUgbXkgb3duIGxhY2sgb2Yga25vd2xlZGdlLCBidXQgSSdtIGhl YXJpbmcgYW4gYXNzdW1wdGlvbiBoZXJlLCBhbmQgSSB3YW50IHRvIHJlcGVhdCB3aGF0IEkn bSBoZWFyaW5nIG91dCBsb3VkIHRvIHNlZSBpZiBpdCBtYWtlcyBzZW5zZSB0byBvdGhlcnMu ICBJdCBkb2Vzbid0IGFkZCB1cCBmb3IgbWUuDQo+IA0KPiBBcmUgd2UgYXNzdW1pbmcgdGhh dCB0aGUgUlNBL0UgaGFzIGV4cGVydGlzZSBpbiBvdXRyZWFjaCB0byB0aGVzZSBkaXZlcnNl IGNvbW11bml0aWVzIG9mIGludGVyZXN0Pw0KPiANCj4gSXMgdGhpcyBzb21ldGhpbmcgdGhh dCBleHBlcnRpc2UgaW4gdGVjaG5pY2FsIHB1YmxpY2F0aW9uIG5hdHVyYWxseSBjb21lcyB3 aXRoPyAgV2hpY2ggY29tbXVuaXR5IG9yIGNvbW11bml0aWVzIGFyZSB0aGVuIG5hdHVyYWxs eSByZXByZXNlbnRlZD8NCj4gDQo+IEVmZmVjdGl2ZSByZXByZXNlbnRhdGlvbiBpcyBzb21l dGhpbmcgd2Ugc3RydWdnbGUgd2l0aCBldmVyeXdoZXJlLiAgQnV0IEkgY2FuIGdpdmUgYW4g ZXhhbXBsZSBmcm9tIGFuIGFkamFjZW50IGNvbW11bml0eS4gIFdoZW4gd2UgZGlzY3VzcyB3 aGV0aGVyIHdlYiBBUEkgRm9vIGlzIGdvb2QgZm9yIHRoZSB3ZWIsIG9uZSBvZiB0aGUgcXVl c3Rpb25zIHdlIHRyeSB0byB1bmRlcnN0YW5kIGlzIHdoZXRoZXIgdGhlIHdlYiBkZXZlbG9w ZXIgY29tbXVuaXR5IHdvdWxkIGJlbmVmaXQuICAoRXZlbiB0aGVyZSwgd2Ugcm91dGluZWx5 IGZhaWwgdG8gY2FwdHVyZSB0aGUgZGl2ZXJzaXR5IG9mIHRoYXQgY29tbXVuaXR5LCB1c3Vh bGx5IG9ubHkgZ2V0dGluZyBpbnB1dCBmcm9tIGxhcmdlIHNpdGVzLikgIEJ1dCBicm93c2Vy LW1ha2VycyBpbiBwYXJ0aWN1bGFyIGRvIHNwZW5kIG5vbi10cml2aWFsIHRpbWUgYW5kIGVm Zm9ydCBpbiBnYXRoZXJpbmcgdGhpcyBpbnB1dCwgYW5kIHdlIGFsc28gYmVuZWZpdCBmcm9t IHRoZSBleHBlcmllbmNlIG9mIHBlb3BsZSBpbiB0aGF0IGNvbW11bml0eSB3aG8gYXJlbid0 IGJlaG9sZGVuIHRvIGEgYnJvd3Nlci1tYWtlciBhbHNvLiAgQnV0IHdlIGRvIG5vdCBhc3N1 bWUgdGhhdCB0aG9zZSBwZW9wbGUgYWxzbyByZXByZXNlbnQgdGhlIGludGVyZXN0cyBvZiBj b21tdW5pdGllcyBpbiB3aGljaCB0aGV5IGhhdmUgbm90IHNwZW50IHRoYXQgdGltZTsgdGhv dWdoIHRoZXNlIGFyZSBwYWlkIHByb2Zlc3Npb25hbHMgd2l0aCBkZWVwIGV4cGVydGlzZSwg dGhhdCBleHBlcnRpc2UgaXMgbmFycm93LiAgQW5kIHRoZSBjb25jbHVzaW9ucyByZWFjaGVk IG9uIHRoZSBiYXNpcyBvZiB3ZWIgZGV2ZWxvcGVyIGZlZWRiYWNrIGNhbiwgb24gc29tZSBt YXR0ZXJzLCBkZW1vbnN0cmF0ZSBhIGJpYXMgYWdhaW5zdCBvdGhlciBzdGFrZWhvbGRlciBp bnRlcmVzdHMgKGNlcnRhaW4gdXNlciBjb21tdW5pdGllcywgZm9yIGluc3RhbmNlDQo+ICAg KS4NCj4gDQo+IEluIHRoZSBJRVRGLCB3ZSBoYXZlIGV4cGVyaWVuY2Ugd2l0aCBwZW9wbGUg Y29ubmVjdGVkIHRvIHZhcmlvdXMgY29tbXVuaXRpZXMgdGhhdCBpbnRlcmFjdCB3aXRoIHRo ZSB3b3JrIHdlIGRvLiAgUGVvcGxlIHdobyBpbXBsZW1lbnQsIGRlcGxveSwgb3BlcmF0ZSwg cHVyY2hhc2UsIGFuZCBzbyBmb3J0aC4gIEFzIE1hcmsgcG9pbnRzIG91dCwgd2UgYXJlIG5v dyBsdWNreSBlbm91Z2ggdG8gc29tZXRpbWVzIGhhdmUgcGVvcGxlIHBhcnRpY2lwYXRlIGZy b20gY29tbXVuaXRpZXMgdGhhdCBzdHVkeSB0aGUgZWZmZWN0IG9mIG91ciBkZWNpc2lvbnMg b24gcGVvcGxlIGFuZCBzb2NpZXRpZXMuICBCdXQgbXkgZXhwZXJpZW5jZSBpcyB0aGF0IHRo ZSBjb21tdW5pdHkgb2YgaW50ZXJlc3Qgc3BlYWtpbmcgaXMgZ2VuZXJhbGx5IHVuZGVyc3Rv b2QsIHVzdWFsbHkgYXMgYSByZXN1bHQgb2YgZ2V0dGluZyB0byBrbm93IHRoZSBwZXJzb24g c3BlYWtpbmcgYSBsaXR0bGUuDQo+IA0KPiBPZiBjb3Vyc2Ugbm8gc2luZ2xlIHBlcnNvbiBz cGVha3MgZm9yIGFueSBjb21tdW5pdHkgYmVjYXVzZSBubyBjb21tdW5pdHkgaXMgZXZlciBz byB1bmlmb3JtIGFzIHRvIGhhdmUgcHJlY2lzZWx5IG9uZSBwb3NpdGlvbiBvbiBqdXN0IGFi b3V0IGFueSBzdWJqZWN0LiAgQW5kIGFueSB3aG8gY2xhaW0gdG8gc3BlYWsgZm9yIGEgY29t bXVuaXR5IGNhbiBvbmx5IGRvIHNvIHRocm91Z2ggdGhlIGZpbHRlciBvZiB0aGVpciBvd24g Ymlhc2VzLiAgQWdhaW4sIGdldHRpbmcgdG8ga25vdyBzb21lb25lIHRvIGJldHRlciB1bmRl cnN0YW5kIHRob3NlIGJpYXNlcyBpcyBhbHNvIHBhcnQgb2YgaG93IHdlIG1hbmFnZSB0aGF0 Lg0KPiANCj4gSSB1c2UgdGhlIGxvbmcgYW5lY2RvdGUgKHJhbnQ/KSB0byBoaWdobGlnaHQg dGhhdCBpZiB3ZSBhcmUgbG9va2luZyBmb3Igc29tZW9uZSB0byBjb252ZXkgYSBwYXJ0aWN1 bGFyIHZpZXdwb2ludCwgd2UgbmVlZCB0byB1bmRlcnN0YW5kIHdoYXQgd2UncmUgbG9va2lu ZyBmb3IuICBJZiBwdWJsaWNhdGlvbiBleHBlcnRpc2UgaXMgdHJ1bHkgYWxpZW4gdG8gdXMg ZW5naW5lZXIteSBmb2xrcywgSSBkb24ndCB0aGluayB0aGF0IHdlIGhhdmUgbXVjaCBob3Bl IG9mIGRvaW5nIGFueXRoaW5nIGV4Y2VwdCBpbnZlc3QgdGhlIFJTQS9FIHdpdGggcG93ZXIg dGhhdCBsZWF2ZXMgdGhlIHNlcmllcyBhdCB0aGUgbWVyY3kgb2YgdGhlIExMQyBoaXJpbmcg cHJvY2Vzcy4gIEJ1dCwgbGlrZSB0aGUgbGF3eWVyIGV4YW1wbGUsIEkgdGhpbmsgdGhhdCB3 ZSBjYW4gbGVhcm4gdG8gcmVjb2duaXplIHRoZSBzaGFwZSBvZiBvdXIgbGFjayBvZiBrbm93 bGVkZ2UuICBUbyBkbyB0aGF0LCBtYXliZSBzb21lb25lIGNhbiBkZWZpbmUgdGhlIHVuZGVm aW5hYmxlIGFuZCB0ZWxsIG1lIHdoaWNoIGNvbW11bml0eSB3ZSBtaWdodCBleHBlY3QgYSBw dWJsaWNhdGlvbiBleHBlcnQgdG8gYmUgYWJsZSB0byByZXByZXNlbnQuDQo+IA0K From nobody Sun Feb 7 16:30:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4FC3A0E30 for ; Sun, 7 Feb 2021 16:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIyosIvf-Hq6 for ; Sun, 7 Feb 2021 16:29:57 -0800 (PST) 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 948353A0E02 for ; Sun, 7 Feb 2021 16:29:47 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id g3so6913570plp.2 for ; Sun, 07 Feb 2021 16:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=XzeaKBsc1fSdbnOug7Wqr6Y7xoJ4BNL8oxzLMSY8iJU=; b=c/8VRwdl2coYi9PWhpq/qVSjRfnIwhQdHQovKqmdncf2xHKfDE0Z6OW5VuUzkK3DEZ uElA6hwtpgWW+dPeU/cyRkDkwGUE4KOcL+70gSAL59ooJUnpJ8UurUmlevM3SzebnHHM Ls6/49Qvff/AqmGss+gZWMJoW+hO8awhItdD8nq2oNlaK1o61DBBjEHVkJ6Ar5aGwmdc 4ZfkNo91J1qwjTsZVgBLI/1H6dcgb0/IofV7GwYfFxD3mxjnLLotnxGIiLaCIpcwsLnA gWez9AYyzzfDsy+ctFqENshad1EnCBpXf5JwYlelvlNjxmh+w2C0PckHvBs57Hkivm53 l0iA== 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=XzeaKBsc1fSdbnOug7Wqr6Y7xoJ4BNL8oxzLMSY8iJU=; b=UJirXnjtDXkJmNhTQKDcwRUeS0Rm6Cctz2qoW6KBcUG2bVlxxT0UnrCKDx7mkzaNVX tvBUPygYnXRm84NkxBBywhsJ3XwGaK9sXACQf6FcIBFVjf/XBrH3Uo42U/SyR6wHKWp6 sA/k2qXz7TPvLiD+SBE2MhbW17aFjlEmrEZA9KzH4zI47FWP1K6sYL5ULYTFjCwv/140 cyzjeali+i1mfNW/2CoA1xfPB46rNfSwBPIBxaULVvQ1ZIgHJl3aybWpRjm2YXcjV6UG J2fkYcZkEcWCnOUsC8OCfvWwOTIX5rrYKPBgiBf7cbhExsI37nsl/s7U0CKSnuboj+FV dVEw== X-Gm-Message-State: AOAM533cbX+1o/lLxMUmMxobBY6Xyqv+p0OthLOyZqHAK/69bxzUu+jo 7ECzsYidaF2iMfT9xMacZogLjwa8kHnkvQ== X-Google-Smtp-Source: ABdhPJyaEWCKVzUaUcBl9fupUclgi2GIRf1t6mtb/fqBF+zqV72qVSygr4lgbjR1ewAr9z1Yi8aXjg== X-Received: by 2002:a17:902:bd4a:b029:e1:1ccd:35b7 with SMTP id b10-20020a170902bd4ab02900e11ccd35b7mr14086302plx.30.1612744186441; Sun, 07 Feb 2021 16:29:46 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id d133sm15922835pfd.6.2021.02.07.16.29.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Feb 2021 16:29:45 -0800 (PST) To: rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> From: Brian E Carpenter Message-ID: Date: Mon, 8 Feb 2021 13:29:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 00:30:05 -0000 T24gMDgtRmViLTIxIDEzOjE0LCBNYXJ0aW4gVGhvbXNvbiB3cm90ZToNCj4gT24gU2F0LCBG ZWIgNiwgMjAyMSwgYXQgMjM6MjYsIEFkcmlhbiBGYXJyZWwgd3JvdGU6DQo+PiBzaWxlbnQg bWFqb3JpdGllcyBhcmUgb2Z0ZW4gZXhjbHVkZWQgYnkgdGhvc2UgaW4gcG93ZXIgKEkgZG8g bm90IGFjY3VzZQ0KPj4gYW55b25lIGhlcmUgcHJlc2VudCBvZiBzdWNoIGFuIGludGVudGlv bikuDQo+IA0KPiBJIGZpbmQgbXlzZWxmIHJlYWxseSBsaWtpbmcgdGhlIHR1cm4gdGhpcyBk aXNjdXNzaW9uIHRvb2suICBUaGF0IGlzLCBJIGxpa2UgdGhhdCB3ZSBhcmUgZXhwbGljaXRs eSBjb25zaWRlcmluZyB0aGUgYmlhc2VzIGluaGVyZW50IGluIHRoZSBkZXNpZ25zIHdlJ3Jl IGNvbnNpZGVyaW5nIGFuZCBob3cgdG8gY291bnRlcmFjdCB0aGVtLg0KPiANCj4+IE5vdywg c3VwcG9zZSB0aGUgUlNBL0UgaGFzIHRoZSByZXNwb25zaWJpbGl0eSBhbmQgZXhwcmVzc2Vz IGEgY29uY2VybiB0byB0aGUNCj4+IFdHLiANCj4gDQo+IFRoaXMgbXkgYmUgbXkgb3duIGxh Y2sgb2Yga25vd2xlZGdlLCBidXQgSSdtIGhlYXJpbmcgYW4gYXNzdW1wdGlvbiBoZXJlLCBh bmQgSSB3YW50IHRvIHJlcGVhdCB3aGF0IEknbSBoZWFyaW5nIG91dCBsb3VkIHRvIHNlZSBp ZiBpdCBtYWtlcyBzZW5zZSB0byBvdGhlcnMuICBJdCBkb2Vzbid0IGFkZCB1cCBmb3IgbWUu DQo+IA0KPiBBcmUgd2UgYXNzdW1pbmcgdGhhdCB0aGUgUlNBL0UgaGFzIGV4cGVydGlzZSBp biBvdXRyZWFjaCB0byB0aGVzZSBkaXZlcnNlIGNvbW11bml0aWVzIG9mIGludGVyZXN0Pw0K DQpJIGRvbid0IHRoaW5rIHNvLiBJIHRoaW5rIHdlIGFyZSBzYXlpbmcgdGhhdCAqc29tZWJv ZHkqIG5lZWRzIHRvIGJlIHRhZ2dlZCB3aXRoIHJlc3BvbnNpYmlsaXR5IGZvciB0aGF0IHRv cGljLCBhbmQgdW5sZXNzIHdlIHByb3Bvc2VkIHRvIGhpcmUgYSBDb21tdW5pY2F0aW9ucyBE aXJlY3RvciBmb3IgdGhlIFJGQyBTZXJpZXMsIHRoZSBSU0EvRSBpcyB0aGUgb2J2aW91cyBw ZXJzb24gdG8gdGFnLg0KIA0KPiBJcyB0aGlzIHNvbWV0aGluZyB0aGF0IGV4cGVydGlzZSBp biB0ZWNobmljYWwgcHVibGljYXRpb24gbmF0dXJhbGx5IGNvbWVzIHdpdGg/DQoNCk5vdCBu ZWNlc3NhcmlseSwgYWx0aG91Z2ggdGhlc2UgZGF5cyBhIGxvdCBvZiBwZW9wbGUgYXJlIGdy YWR1YXRpbmcgd2l0aCBDb21tdW5pY2F0aW9ucy1yZWxhdGVkIGRlZ3JlZXMgYnV0IGVuZGlu ZyB1cCBpbiB0ZWNobmljYWwgb3Igc3BlY2lhbGlzdCB3cml0aW5nLiBTbyBJIHdvdWxkbid0 IGV4Y2x1ZGUgc29tZWJvZHkgaGF2aW5nIGJvdGggdGhlc2Ugc2tpbGwgc2V0cy4gQnV0IEkg ZG9uJ3QgdGhpbmsgd2UncmUgc2F5aW5nIHRoZSBSU0EvRSB3aWxsICpkbyogdGhlIG91dHJl YWNoLCBidXQgdGhhdCB0aGV5IHdpbGwgZ2V0IGl0IGRvbmUuDQoNCj4gV2hpY2ggY29tbXVu aXR5IG9yIGNvbW11bml0aWVzIGFyZSB0aGVuIG5hdHVyYWxseSByZXByZXNlbnRlZD8NCg0K SXNuJ3QgdGhhdCB2ZXJ5IG11Y2ggVEJEIGFuZCB3aHkgd2UgbmVlZCB0aGlzIG9uIHNvbWVi b2R5J3MgdG8tZG8gbGlzdD8gSWYgd2UgaGFkIGEgZmFjdHVhbCBsaXN0IG9mIHdobyByZWFk cyBvciBvdGhlcndpc2UgZGVwZW5kcyBvbiBSRkNzLCB3ZSdkIGJlIGhhbGZ3YXkgdGhlcmUg YWxyZWFkeS4gSW4gZmFjdCwgdW50aWwgd2UgaGF2ZSB0aGF0IGxpc3QsIEkgZG9uJ3QgdGhp bmsgd2UgY2FuIHRhY2tsZSB5b3VyIHF1ZXN0aW9uIGJlbG93Lg0KDQpSZWdhcmRzDQogICBC cmlhbiBDDQoNCj4gRWZmZWN0aXZlIHJlcHJlc2VudGF0aW9uIGlzIHNvbWV0aGluZyB3ZSBz dHJ1Z2dsZSB3aXRoIGV2ZXJ5d2hlcmUuICBCdXQgSSBjYW4gZ2l2ZSBhbiBleGFtcGxlIGZy b20gYW4gYWRqYWNlbnQgY29tbXVuaXR5LiAgV2hlbiB3ZSBkaXNjdXNzIHdoZXRoZXIgd2Vi IEFQSSBGb28gaXMgZ29vZCBmb3IgdGhlIHdlYiwgb25lIG9mIHRoZSBxdWVzdGlvbnMgd2Ug dHJ5IHRvIHVuZGVyc3RhbmQgaXMgd2hldGhlciB0aGUgd2ViIGRldmVsb3BlciBjb21tdW5p dHkgd291bGQgYmVuZWZpdC4gIChFdmVuIHRoZXJlLCB3ZSByb3V0aW5lbHkgZmFpbCB0byBj YXB0dXJlIHRoZSBkaXZlcnNpdHkgb2YgdGhhdCBjb21tdW5pdHksIHVzdWFsbHkgb25seSBn ZXR0aW5nIGlucHV0IGZyb20gbGFyZ2Ugc2l0ZXMuKSAgQnV0IGJyb3dzZXItbWFrZXJzIGlu IHBhcnRpY3VsYXIgZG8gc3BlbmQgbm9uLXRyaXZpYWwgdGltZSBhbmQgZWZmb3J0IGluIGdh dGhlcmluZyB0aGlzIGlucHV0LCBhbmQgd2UgYWxzbyBiZW5lZml0IGZyb20gdGhlIGV4cGVy aWVuY2Ugb2YgcGVvcGxlIGluIHRoYXQgY29tbXVuaXR5IHdobyBhcmVuJ3QgYmVob2xkZW4g dG8gYSBicm93c2VyLW1ha2VyIGFsc28uICBCdXQgd2UgZG8gbm90IGFzc3VtZSB0aGF0IHRo b3NlIHBlb3BsZSBhbHNvIHJlcHJlc2VudCB0aGUgaW50ZXJlc3RzIG9mIGNvbW11bml0aWVz IGluIHdoaWNoIHRoZXkgaGF2ZSBub3Qgc3BlbnQgdGhhdCB0aW1lOyB0aG91Z2ggdGhlc2Ug YXJlIHBhaWQgcHJvZmVzc2lvbmFscyB3aXRoIGRlZXAgZXhwZXJ0aXNlLCB0aGF0IGV4cGVy dGlzZSBpcyBuYXJyb3cuICBBbmQgdGhlIGNvbmNsdXNpb25zIHJlYWNoZWQgb24gdGhlIGJh c2lzIG9mIHdlYiBkZXZlbG9wZXIgZmVlZGJhY2sgY2FuLCBvbiBzb21lIG1hdHRlcnMsIGRl bW9uc3RyYXRlIGEgYmlhcyBhZ2FpbnN0IG90aGVyIHN0YWtlaG9sZGVyIGludGVyZXN0cyAo Y2VydGFpbiB1c2VyIGNvbW11bml0aWVzLCBmb3IgaW5zdGFuY2UNCj4gICkuDQo+IA0KPiBJ biB0aGUgSUVURiwgd2UgaGF2ZSBleHBlcmllbmNlIHdpdGggcGVvcGxlIGNvbm5lY3RlZCB0 byB2YXJpb3VzIGNvbW11bml0aWVzIHRoYXQgaW50ZXJhY3Qgd2l0aCB0aGUgd29yayB3ZSBk by4gIFBlb3BsZSB3aG8gaW1wbGVtZW50LCBkZXBsb3ksIG9wZXJhdGUsIHB1cmNoYXNlLCBh bmQgc28gZm9ydGguICBBcyBNYXJrIHBvaW50cyBvdXQsIHdlIGFyZSBub3cgbHVja3kgZW5v dWdoIHRvIHNvbWV0aW1lcyBoYXZlIHBlb3BsZSBwYXJ0aWNpcGF0ZSBmcm9tIGNvbW11bml0 aWVzIHRoYXQgc3R1ZHkgdGhlIGVmZmVjdCBvZiBvdXIgZGVjaXNpb25zIG9uIHBlb3BsZSBh bmQgc29jaWV0aWVzLiAgQnV0IG15IGV4cGVyaWVuY2UgaXMgdGhhdCB0aGUgY29tbXVuaXR5 IG9mIGludGVyZXN0IHNwZWFraW5nIGlzIGdlbmVyYWxseSB1bmRlcnN0b29kLCB1c3VhbGx5 IGFzIGEgcmVzdWx0IG9mIGdldHRpbmcgdG8ga25vdyB0aGUgcGVyc29uIHNwZWFraW5nIGEg bGl0dGxlLg0KPiANCj4gT2YgY291cnNlIG5vIHNpbmdsZSBwZXJzb24gc3BlYWtzIGZvciBh bnkgY29tbXVuaXR5IGJlY2F1c2Ugbm8gY29tbXVuaXR5IGlzIGV2ZXIgc28gdW5pZm9ybSBh cyB0byBoYXZlIHByZWNpc2VseSBvbmUgcG9zaXRpb24gb24ganVzdCBhYm91dCBhbnkgc3Vi amVjdC4gIEFuZCBhbnkgd2hvIGNsYWltIHRvIHNwZWFrIGZvciBhIGNvbW11bml0eSBjYW4g b25seSBkbyBzbyB0aHJvdWdoIHRoZSBmaWx0ZXIgb2YgdGhlaXIgb3duIGJpYXNlcy4gIEFn YWluLCBnZXR0aW5nIHRvIGtub3cgc29tZW9uZSB0byBiZXR0ZXIgdW5kZXJzdGFuZCB0aG9z ZSBiaWFzZXMgaXMgYWxzbyBwYXJ0IG9mIGhvdyB3ZSBtYW5hZ2UgdGhhdC4NCj4gDQo+IEkg dXNlIHRoZSBsb25nIGFuZWNkb3RlIChyYW50PykgdG8gaGlnaGxpZ2h0IHRoYXQgaWYgd2Ug YXJlIGxvb2tpbmcgZm9yIHNvbWVvbmUgdG8gY29udmV5IGEgcGFydGljdWxhciB2aWV3cG9p bnQsIHdlIG5lZWQgdG8gdW5kZXJzdGFuZCB3aGF0IHdlJ3JlIGxvb2tpbmcgZm9yLiAgSWYg cHVibGljYXRpb24gZXhwZXJ0aXNlIGlzIHRydWx5IGFsaWVuIHRvIHVzIGVuZ2luZWVyLXkg Zm9sa3MsIEkgZG9uJ3QgdGhpbmsgdGhhdCB3ZSBoYXZlIG11Y2ggaG9wZSBvZiBkb2luZyBh bnl0aGluZyBleGNlcHQgaW52ZXN0IHRoZSBSU0EvRSB3aXRoIHBvd2VyIHRoYXQgbGVhdmVz IHRoZSBzZXJpZXMgYXQgdGhlIG1lcmN5IG9mIHRoZSBMTEMgaGlyaW5nIHByb2Nlc3MuICBC dXQsIGxpa2UgdGhlIGxhd3llciBleGFtcGxlLCBJIHRoaW5rIHRoYXQgd2UgY2FuIGxlYXJu IHRvIHJlY29nbml6ZSB0aGUgc2hhcGUgb2Ygb3VyIGxhY2sgb2Yga25vd2xlZGdlLiAgVG8g ZG8gdGhhdCwgbWF5YmUgc29tZW9uZSBjYW4gZGVmaW5lIHRoZSB1bmRlZmluYWJsZSBhbmQg dGVsbCBtZSB3aGljaCBjb21tdW5pdHkgd2UgbWlnaHQgZXhwZWN0IGEgcHVibGljYXRpb24g ZXhwZXJ0IHRvIGJlIGFibGUgdG8gcmVwcmVzZW50Lg0KPiANCg== From nobody Sun Feb 7 16:41:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406033A0D42 for ; Sun, 7 Feb 2021 16:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRjWlIv6DGtf for ; Sun, 7 Feb 2021 16:41:42 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DD43A0D41 for ; Sun, 7 Feb 2021 16:41:42 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id u25so19879989lfc.2 for ; Sun, 07 Feb 2021 16:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IDGe6AgSjtnLBt7XvKRopDc/9GgmZD7U3wL0y+NU4vc=; b=tD48+Wd8MEKq9kvFfCLG08hfap1SXNuzGZgPcuLCJefSm3ElZciNy/loPAhlBeHyaQ V4lfzIds3evNDmw3ceJQK6Au4QQJbTh5ob3JRFu1CDkPp+ztFmB+E32Q5GVsPmEpiW1o 0/ZQC8JncHi/kazaGlwZQCUf0QFEPQikoA4axza2LCC3fL880Fq6czzgqG+HqyC0eIQC 2KJ9qdabOgn7QG5pThOL+SwM0vLivnf5eMWXz/H8wB8wjE2N8SKmhX65u32BWydI9Twj zf5IKpp0vxZXVIZuXIHdEQnBKTPqY3zZ3DRMxR6LGuALp4gsYYAJ/fzvfk159yUN7bbQ SvHA== 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=IDGe6AgSjtnLBt7XvKRopDc/9GgmZD7U3wL0y+NU4vc=; b=mpX+Co6oo/ypFDmVsRcqsBspYoVcAAlwAozAs1MO8oPCwCaLbDibxGQTpgxZ8UYYyA 54mgoTwrwlKaxf3NsqWEwBSltHWf8utqPDCpqw7M5nOqxL9X8VrTqQFnG/74rteY3KM4 vHjsBzU7GhNn0yzeIqccyo9Ck7iyYf4ZcQOh3ZR0XbpyopWBImdeVr1H1d2uvocDCPSk fti+rBifqhWGika4KULSxJZGFl8eECuyH2Hqo6afKnxDcxCnj3BEsnBEITxghMNbUt8h hbhSSBhc3gIeS6sKAre/fly9wLeXdv5uJLvb62GlZAhh5nt55Mna5F1+WfhS0WaJ6XSR lQuA== X-Gm-Message-State: AOAM530lYcTqMSoB4z5sd+uroAN4AfPCcYkfgjmB6bagJd+W7nc6Kg6c BJ70ovUvJa4Wi4j/CB31CAVkOvXKVGBwByPVp4Q5jg== X-Google-Smtp-Source: ABdhPJzkkDHDBzHaVHiAwb9ELq5jeksONQSIp7wuu5M8j8M5SoUkk4j3LyRbJg5DKDG8cPuOsiEadNIP7FFjli0lt70= X-Received: by 2002:a05:6512:3253:: with SMTP id c19mr8552303lfr.245.1612744900149; Sun, 07 Feb 2021 16:41:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sun, 7 Feb 2021 16:41:04 -0800 Message-ID: To: Eliot Lear Cc: rfced-future@iab.org, Brian Rosen Content-Type: multipart/alternative; boundary="000000000000e3184705bac86eb3" Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 00:41:44 -0000 --000000000000e3184705bac86eb3 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 5, 2021 at 12:14 PM Eliot Lear wrote: > Hi everyone, > > First, the chairs want to again thank Eric for bringing some text to the > discussion. From our perspective, there is a lot on which we may agree, > and we would like to test consensus on *some* of the points, knowing that > discussion is ongoing on other aspects. > > > - Do people agree that the stream managers are part of the approval > body? > > Yes, probably. > > - Do people agree that process proposals flow from the WG to the > approval body? > > Yes. > > - Do people agree that the grounds for rejection of a proposal include > damage to a stream? > > Yes. > > - Do people agree that any objections must be returned to the WG for > discussion? > > Yes. > > - Do people agree that if the WG still wants to press forward, two > objections would still halt approval? > > No, I don't think we're there yet, given that we don't understand the composition of the body. > - Do people agree that damage to a stream would include long term > strategic damage to the series? > > I'm not sure. That seems like a very speculative kind of harm. What I had in mind here was "this would make it impossible for me to operate my stream in the short term". I believe we should be deferring as much as possible to the community process on bigger picture issues. -Ekr --000000000000e3184705bac86eb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 5, 2021 at 12:14 PM Eliot= Lear <lear=3D40cisco.com@= dmarc.ietf.org> wrote:
Hi everyone,

Firs= t, the chairs want to again thank Eric for bringing some text to the discus= sion.=C2=A0 From our perspective, there is a lot on which we may agree, and= we would like to test consensus on=C2=A0some=C2=A0of the points, kn= owing that discussion is ongoing on other aspects.

  • Do people agree that the stream managers are part of the approval = body?
Yes, probably.
=
=C2=A0
  • Do people agree that process proposals flow from t= he WG to the approval body?
<= div>Yes.
  • Do people agree that the grounds for rejection of a pr= oposal include damage to a stream?
Yes.
  • Do people agree that any objections must be ret= urned to the WG for discussion?
Yes.
  • Do people agree that if the WG still wants to pres= s forward, two objections would still halt approval?
<= /div>
No, I don't think we're there yet, giv= en that we don't understand the composition of the body.

=
=
  • Do people agree that damage to a stream would include long term str= ategic damage to the series?
=
I'm not sure. That seems like a very speculative kind of harm. Wha= t I had in mind here was "this would make it impossible for me to oper= ate my stream in the short term". I believe we should be deferring as = much as possible to the community process on bigger picture issues.

-Ekr
--000000000000e3184705bac86eb3-- From nobody Sun Feb 7 16:50:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11173A0D58 for ; Sun, 7 Feb 2021 16:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 H_O4R3wGvl3A for ; Sun, 7 Feb 2021 16:50:47 -0800 (PST) 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 201B83A0D51 for ; Sun, 7 Feb 2021 16:50:47 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id f19so14957286ljn.5 for ; Sun, 07 Feb 2021 16:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zpuOTPqWBvvEoUM+uNL/q70JVUTBlCMi9Kv2qsSLGZc=; b=PuXR3GgNLGUXP9gkjBZbxvH7/W3draZ0wK5E8ZUBS76j3uAhOfE08fsNia21AnTyrX K7AcqR7pFjxINLo6PadOwinuBkLE8W092s0Hm82ajsJUzcc9BKE5yzVwnBAUwHfXdf0G xPe4XxHZkPGTg36Ghq41yAbfvTj2OuD88AaIcfpdrREN8Rje1lK/4OJSjEma4y4Lz7zi ZDVjhNajnRNlQslV7tyGbKuhf3ZdJrkaFVZUDEOaUWX3vCQMfSgJMsE7Pry37QIuUi3K s5vqABeh7vwQioVZ843rgBsIRaEoxTCwycN9M3er4Xx06JhQth7PS4h9HaIJ7GCnbbY/ AU5w== 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=zpuOTPqWBvvEoUM+uNL/q70JVUTBlCMi9Kv2qsSLGZc=; b=a+LTLUfsuPK71IK2/QQgWqtKrD7r8FsI1IUHZgT1ae7uraYlYIwMPFtAmmGueaWSam MSeEejXfMRp7VrTdT04SDQcDdYzJKDt/ivdjyHrmThrDPB4qeNV9HU8b09mDjy6uogfv OHcbYwF9kWkhn+IxClX+FpBBh/B6Ffan4gYgSLs/JlxCWQmevFBViJUvFgC51IvMCTy3 WUfmZXJ6dEIbbwXaE0UEWE4ByKWTKQObZ7M/GNDRQXvQPp5HQz5E0+IsXt34iY/hFuD8 HObVyUE5uiF7Nsd+WMoajFz3cLsvaYxBCW0BjTDDAGsO48XrXAyI+VgKX3g9pkJMYUrX VNFA== X-Gm-Message-State: AOAM532rSJD8j46gJvgcyDRgYI3VHIsfx8/MaYX2Sb3pUC/1sZjxi3CO 2nFG6Fq+hz4czExCxX0y22gNZ2XU8gsQd/N4cqwGDg== X-Google-Smtp-Source: ABdhPJyk8otTgXGAMNu5jOvjX90IuX7VspJw3A1cogYpNq9jznGNIDnfdoxqEmf3C1DdNoVKtmMDKMqn7vvngDv8t3U= X-Received: by 2002:a2e:7f04:: with SMTP id a4mr9056023ljd.3.1612745445222; Sun, 07 Feb 2021 16:50:45 -0800 (PST) MIME-Version: 1.0 References: <0fbee513-aa8d-80a2-0976-d2ca3e985d29@gmail.com> In-Reply-To: <0fbee513-aa8d-80a2-0976-d2ca3e985d29@gmail.com> From: Eric Rescorla Date: Sun, 7 Feb 2021 16:50:09 -0800 Message-ID: To: Brian E Carpenter Cc: Eliot Lear , rfced-future@iab.org, Brian Rosen Content-Type: multipart/alternative; boundary="000000000000603be505bac88fba" Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 00:50:49 -0000 --000000000000603be505bac88fba Content-Type: text/plain; charset="UTF-8" On Sat, Feb 6, 2021 at 12:36 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > * Do people agree that damage to a stream would include long term > strategic damage to the series? > > Why ask that? The bullet above does not state that damage to a stream is > the *only* ground for objection. Certainly, damage to the series as a whole > must be a ground for objection, but that isn't what you are asking. > Well, obviously people don't need to agree but the intent of my proposal was to sharply limit the grounds on which the approval body could object to documents. Taking a step back from the details one could imagine people on these bodies as having two roles: - Representing their equities (i.e., what is good for their streams) - Representing their own views of what's good for the series regardless of whether it affected their streams. I believe that we should attempt to limit the role of the approval body as much as possible to the former category. The reason for this is that the WG has inherent community legitimacy, whereas the stream managers does not (primarily because of how they are selected but also because of the interests they represent). I don't see any particular reason why the opinion of the stream managers should override the opinion of the WG on matters that don't directly threaten their streams. I suspect that this is another example of an issue where we actually have disagreement about principles, and hence a good topic for the live discussion. -Ekr --000000000000603be505bac88fba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Feb 6, 2021 at 12:36 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
>=C2=A0 =C2=A0* Do people agree that damage to a stream would include lo= ng term strategic damage to the series?

Why ask that? The bullet above does not state that damage to a stream is th= e *only* ground for objection. Certainly, damage to the series as a whole m= ust be a ground for objection, but that isn't what you are asking.
<= /blockquote>

Well, obviously people don't need to ag= ree but the intent of my proposal was to sharply limit the grounds on which= the approval body could object to documents.

Taking a step back from the details one could imagine people on these bodi= es as having two roles:

- Representing their equit= ies (i.e., what is good for their streams)
- Representing their o= wn views of what's good for the series regardless of whether it affecte= d their streams.

I believe that we should attempt = to limit the role of the approval body as much as possible to the former ca= tegory. The reason for this is that the WG has inherent community legitimac= y, whereas the stream managers does not (primarily because of how they are = selected but also because of the interests they represent). I don't see= any particular reason why the opinion of the stream managers should overri= de the opinion of the WG on matters that don't directly threaten their = streams.

I suspect that this is another example of= an issue where we actually have disagreement about principles, and hence a= good topic for the live discussion.

-Ekr

--000000000000603be505bac88fba-- From nobody Sun Feb 7 16:51:30 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347043A0D58 for ; Sun, 7 Feb 2021 16:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 574NFsXONLIY for ; Sun, 7 Feb 2021 16:51:27 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4344E3A0D55 for ; Sun, 7 Feb 2021 16:51:26 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id n28so2320453qtv.12 for ; Sun, 07 Feb 2021 16:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=n9jvwDjXWLhdWCOJLNjbQvuamisYSsLqPkdDEp9DMao=; b=E06AMXVNZM6r7B5ppmr0N1ScyA7gH547t1h02FmoBYAaxcesfuUu9064qc+gErcVLZ oII/nUB1cA33qJATsp+c7CS1FqwiOiYl2qWPrICMdkYWM0C/eqAjslsVe7pGF6x0SwyW /MOqPUOasdFYh5p9mT6TpVojADQsZDKveTSQfW6oIqZ1u7lOfxELZHzeyE9vQVG52zE5 6y731AdYqaOVJrB5tArOhKF2p2R3iij+ClqMHjL92KLuVaSHKJGgexwnJ3ICZ1jS+jpg 5C1wVBRtC34pYs5YaDcDkU9dFoHyaHzaTkTqiyKVbC0e4Oo0P6QDd8d5JXUwDCQDY9s+ /Exw== 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=n9jvwDjXWLhdWCOJLNjbQvuamisYSsLqPkdDEp9DMao=; b=lK4aYlpiVPw/Eq+8qy1rcfKKVUtjnsJA6DBubug1CTqUcSj+MiK0QmRaRnzryfYrzT yR8MNYwIPtKAHrw/IQng2WGPEJjyknHKcF8wn7B0MIKKAj8IEcJ7AKpx53cNPiN46ERw +iew3cpR+5yPvYBYzt8jlAqJsE4pwVW0/UskKBeQZmTfcrtTx/ij6p7e0B2k7JTJieqn 9vusfaJZiVt+CwHDJcxrSsOctHdUU/92vMPYWzx6uKZGBcqRuerysQNHFFQ64VCkOZLc 94abe3jHT61mIKtCyWOGr3L+5AvJ/fPGq21W8yAQIiZ9n4LZesGZbRTtcDK9OAQXBJMo +hPg== X-Gm-Message-State: AOAM531FGdU6SMbReulR0V5ScbEVkaRKI0l+w9tZQk/CuuvnSmzhqAfM vcMMxAyqAHvn/8vKfUVvv8+AxHZTwdO4oyeg X-Google-Smtp-Source: ABdhPJxa1BiBx47eXf2BR7baQun7Nf+EVM8xp35vDvrsxFFB1YEXDBKBYXOGvyq3gvx14OCQCWVRQg== X-Received: by 2002:ac8:2a4b:: with SMTP id l11mr13887719qtl.380.1612745485484; Sun, 07 Feb 2021 16:51:25 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id m5sm3059873qke.134.2021.02.07.16.51.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Feb 2021 16:51:24 -0800 (PST) To: rfced-future@iab.org References: From: Michael StJohns Message-ID: <5af2959c-93bd-94e2-f51d-bf07032176a8@nthpermutation.com> Date: Sun, 7 Feb 2021 19:51:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7EB1833D5A8E4C0C897E2C08" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 00:51:29 -0000 This is a multi-part message in MIME format. --------------7EB1833D5A8E4C0C897E2C08 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/5/2021 3:14 PM, Eliot Lear wrote: > Hi everyone, > > First, the chairs want to again thank Eric for bringing some text to > the discussion.  From our perspective, there is a lot on which we may > agree, and we would like to test consensus on *some* of the points, > knowing that discussion is ongoing on other aspects. > > * Do people agree that the stream managers are part of the approval > body? > Yes > > * Do people agree that process proposals flow from the WG to the > approval body? > Yes, but not exclusively.  The approval body should be able to originate documents (some model as IAB and IESG streams).  I also think that there may be non-WG submissions  (e.g. similar to AD sponsored) that may be appropriate to be approved in the editorial stream.  E.g. informative documents that apply to general publication issues. > > * Do people agree that the grounds for rejection of a proposal > include damage to a stream? > I think we actually just need to leave the approval body to figure out what gets rejected.   I think this is one only one of the grounds. Others include quality, relevance and community need (not just WG consensus). > > * Do people agree that any objections must be returned to the WG for > discussion? > I don't know what that actually does.   Rejected documents (not originating in the approval body) that don't get approved are in the state that all non approved documents end up in and the WG or authors can take whatever actions they want including revising and resubmitting.  I'd say instead that rejections from the approval body need a cover letter of some sort similar to how feedback works in the other streams and leave it at that. > * Do people agree that if the WG still wants to press forward, two > objections would still halt approval? > The approval body approves.  Failure to approve is not an objection, its a rejection - those words mean different things.   I don't have any problem with the WG or authors doing the try try again thing - but I'd hope the WG chairs would recognize futility when they see it. > > * Do people agree that damage to a stream would include long term > strategic damage to the series? > Yes. > > Not on this list is whether the RSx is part of the approval body.  To > summarize where we are there, one group of people believe that it is > important for the RSx to be a voting member, either because that > person would represent those not otherwise represented (and yes, we’ve > had some back and forth about that), while another group of people > feel strongly that the RSx not be a voting member. The chairs believe > this is a good topic for our upcoming meeting. The RSE/A is going to get some sort of veto with respect to anything within their contractual responsibilities - e.g. if a document purports to tell the RSE/A *how* to do something, and that something implicates the RSE/A's duties to provide [insert legalese here], the RSE will be perfectly within their rights to say "interesting document, but I'm not doing that".  That's just a fact.  A "bad" document that gets approved over the RSE's objections may  end up with an argument between the RSE and the LLC, or with the RSE terminating their contract or other actions. > > What is important: proponents of each position (and perhaps there are > many different positions) should be prepared to present the principles > that they are arguing for.  For each person arguing a particular > position, we ask that you also be prepared to identify what > accommodations or model changes would accommodate you if you couldn’t > get your first choice.  We’ve some of this, and we are hoping to see > more, so that people can find common ground. > Later, Mike --------------7EB1833D5A8E4C0C897E2C08 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/5/2021 3:14 PM, Eliot Lear wrote:
Hi everyone,

First, the chairs want to again thank Eric for bringing some text to the discussion.  From our perspective, there is a lot on which we may agree, and we would like to test consensus on some of the points, knowing that discussion is ongoing on other aspects.

  • Do people agree that the stream managers are part of the approval body?
Yes
  • Do people agree that process proposals flow from the WG to the approval body?
Yes, but not exclusively.  The approval body should be able to originate documents (some model as IAB and IESG streams).  I also think that there may be non-WG submissions  (e.g. similar to AD sponsored) that may be appropriate to be approved in the editorial stream.  E.g. informative documents that apply to general publication issues.
  • Do people agree that the grounds for rejection of a proposal include damage to a stream?
I think we actually just need to leave the approval body to figure out what gets rejected.   I think this is one only one of the grounds. Others include quality, relevance and community need (not just WG consensus).
  • Do people agree that any objections must be returned to the WG for discussion?

I don't know what that actually does.   Rejected documents (not originating in the approval body) that don't get approved are in the state that all non approved documents end up in and the WG or authors can take whatever actions they want including revising and resubmitting.  I'd say instead that rejections from the approval body need a cover letter of some sort similar to how feedback works in the other streams and leave it at that.


  • Do people agree that if the WG still wants to press forward, two objections would still halt approval?
The approval body approves.  Failure to approve is not an objection, its a rejection - those words mean different things.   I don't have any problem with the WG or authors doing the try try again thing - but I'd hope the WG chairs would recognize futility when they see it.
  • Do people agree that damage to a stream would include long term strategic damage to the series?
Yes.

Not on this list is whether the RSx is part of the approval body.  To summarize where we are there, one group of people believe that it is important for the RSx to be a voting member, either because that person would represent those not otherwise represented (and yes, we’ve had some back and forth about that), while another group of people feel strongly that the RSx not be a voting member. The chairs believe this is a good topic for our upcoming meeting.


The RSE/A is going to get some sort of veto with respect to anything within their contractual responsibilities - e.g. if a document purports to tell the RSE/A *how* to do something, and that something implicates the RSE/A's duties to provide [insert legalese here], the RSE will be perfectly within their rights to say "interesting document, but I'm not doing that".  That's just a fact.  A "bad" document that gets approved over the RSE's objections may  end up with an argument between the RSE and the LLC, or with the RSE terminating their contract or other actions.



What is important: proponents of each position (and perhaps there are many different positions) should be prepared to present the principles that they are arguing for.  For each person arguing a particular position, we ask that you also be prepared to identify what accommodations or model changes would accommodate you if you couldn’t get your first choice.  We’ve some of this, and we are hoping to see more, so that people can find common ground.


Later, Mike


--------------7EB1833D5A8E4C0C897E2C08-- From nobody Sun Feb 7 16:52:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C003A0D4B for ; Sun, 7 Feb 2021 16:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ_WljpDK5Ur for ; Sun, 7 Feb 2021 16:52:20 -0800 (PST) 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 876623A0D5C for ; Sun, 7 Feb 2021 16:52:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B4F37BE5C; Mon, 8 Feb 2021 00:52:18 +0000 (GMT) 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 JlkffspQcqUu; Mon, 8 Feb 2021 00:52:16 +0000 (GMT) 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 7DCABBE5B; Mon, 8 Feb 2021 00:52:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1612745536; bh=ojuI1p7ZXLFnmA4dtNSgNfAVZFjKdBvfW22QfqTdrsU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=StuiUTeN5tQeyTTZftLoMbKjQRLkYwI5dGn/IEaf6OROcBMoR2wgGrxaXB0ns0gWK SFagOODmux44V5KAWSuuVcMJ+0Y6Et9n6JYje1gFI5nZ4JZaejXb8VlgKJCJ2rRG2Z nqwNObE5iIxmauCk1uZuNL3R33FmgvbPV0gDFnoI= To: Martin Thomson , rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> From: Stephen Farrell Message-ID: Date: Mon, 8 Feb 2021 00:52:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fFYGopLsKUBiFpX3HK3NQDixkBnO6WcnN" Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 00:52:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fFYGopLsKUBiFpX3HK3NQDixkBnO6WcnN Content-Type: multipart/mixed; boundary="ne8QKqJbqFilXTSYrygEf53BsY2BDTc4t"; protected-headers="v1" From: Stephen Farrell To: Martin Thomson , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> In-Reply-To: <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> --ne8QKqJbqFilXTSYrygEf53BsY2BDTc4t Content-Type: multipart/mixed; boundary="------------DD871CBBCFE9AB2380F0617B" Content-Language: en-US This is a multi-part message in MIME format. --------------DD871CBBCFE9AB2380F0617B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Apologies for top posting: Martin, I think bringing in "representation" isn't a good idea. It's not a thing we do, nor process well. I think the main reason for that (and a good reason) is that we don't have an elector's register nor members. I do agree with Brian that having the RSE be the person who we hope can best consider viewpoints and interests (related to the RFC series) that are not otherwise represented is a good idea. But that doesn't mean the RSE is "representing" anyone, nor IMO should it. Cheers, S. On 08/02/2021 00:14, Martin Thomson wrote: > On Sat, Feb 6, 2021, at 23:26, Adrian Farrel wrote: >> silent majorities are often excluded by those in power (I do not >> accuse anyone here present of such an intention). >=20 > I find myself really liking the turn this discussion took. That is, > I like that we are explicitly considering the biases inherent in the > designs we're considering and how to counteract them. >=20 >> Now, suppose the RSA/E has the responsibility and expresses a >> concern to the WG. >=20 > This my be my own lack of knowledge, but I'm hearing an assumption > here, and I want to repeat what I'm hearing out loud to see if it > makes sense to others. It doesn't add up for me. >=20 > Are we assuming that the RSA/E has expertise in outreach to these > diverse communities of interest? >=20 > Is this something that expertise in technical publication naturally > comes with? Which community or communities are then naturally > represented? >=20 > Effective representation is something we struggle with everywhere. > But I can give an example from an adjacent community. When we > discuss whether web API Foo is good for the web, one of the questions > we try to understand is whether the web developer community would > benefit. (Even there, we routinely fail to capture the diversity of > that community, usually only getting input from large sites.) But > browser-makers in particular do spend non-trivial time and effort in > gathering this input, and we also benefit from the experience of > people in that community who aren't beholden to a browser-maker also. > But we do not assume that those people also represent the interests > of communities in which they have not spent that time; though these > are paid professionals with deep expertise, that expertise is narrow. > And the conclusions reached on the basis of web developer feedback > can, on some matters, demonstrate a bias against other stakeholder > interests (certain user communities, for instance ). >=20 > In the IETF, we have experience with people connected to various > communities that interact with the work we do. People who implement, > deploy, operate, purchase, and so forth. As Mark points out, we are > now lucky enough to sometimes have people participate from > communities that study the effect of our decisions on people and > societies. But my experience is that the community of interest > speaking is generally understood, usually as a result of getting to > know the person speaking a little. >=20 > Of course no single person speaks for any community because no > community is ever so uniform as to have precisely one position on > just about any subject. And any who claim to speak for a community > can only do so through the filter of their own biases. Again, > getting to know someone to better understand those biases is also > part of how we manage that. >=20 > I use the long anecdote (rant?) to highlight that if we are looking > for someone to convey a particular viewpoint, we need to understand > what we're looking for. If publication expertise is truly alien to > us engineer-y folks, I don't think that we have much hope of doing > anything except invest the RSA/E with power that leaves the series at > the mercy of the LLC hiring process. But, like the lawyer example, I > think that we can learn to recognize the shape of our lack of > knowledge. To do that, maybe someone can define the undefinable and > tell me which community we might expect a publication expert to be > able to represent. >=20 --------------DD871CBBCFE9AB2380F0617B Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------DD871CBBCFE9AB2380F0617B-- --ne8QKqJbqFilXTSYrygEf53BsY2BDTc4t-- --fFYGopLsKUBiFpX3HK3NQDixkBnO6WcnN Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAgiz8FAwAAAAAACgkQWrL68XsXK+pr /g//aZhUF8wVo/yuuUIvlVvr+DQ05K8emTNCvj7Z0ndKTnyHN5YhVBfWe/d13SJHwtyxVdUM+24V tJjQJ6hAyaqDTWLJ3Xy3U4MNY/dMjoPYPco+C5rqBbpJc9jzt7mtRz0FFo8gOJjnCf3duZOjLK29 Ve0trhpeDTPNuDZP/bf8g7t0xCwHlSgnXsLVPI/+Jz3d/SnHM/cV9fPgBt0s02byAFsHj70ZlYUk zK4ThXMRtLtrgcGd8Dg0Q18hoAZvt4js2mhcyQLHNt4EQpHAhbiEbi/Y5amBwAZVTSDgjPDjk/pp hk0jU+0CqCer2ZESBi262m57NMO5GdeED6UzG3fv9xUJ44hHov/8onrtf+5vmLhUjDvWGUqTgb1+ c+R9tWNFM7PvJKmwmN8e16zk20+I86ZvTJzj0Nc5vrGVFroYsjf6NDk5+1++sTtqSpDSXl9FBzGT VwViMnzOyEnNOCZL/Atvi4BsZg/CVibtsLXcRImLrlRrrgYT7mGwhDBkSuIJiycg6MJvUTgpH0JS Jn1jFK70OMRmvj/hmHQRpH3N4PDs+EOXSSuUfr4Qer6k0dFk5EseGIkJ2ZYIYY6Zdr4AHmAhPYo+ 3XoB6SgkVSL1/kxSF6TpQLWKiw5IFDqkaMQMltpj2imnMLZkU2U02m6xRpUdAbATnunjQQ13y1Fl 298= =oFm2 -----END PGP SIGNATURE----- --fFYGopLsKUBiFpX3HK3NQDixkBnO6WcnN-- From nobody Sun Feb 7 17:00:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0023A0D7A for ; Sun, 7 Feb 2021 17:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 x6jD8liBqrtP for ; Sun, 7 Feb 2021 17:00:26 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431603A0D79 for ; Sun, 7 Feb 2021 17:00:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DYnkf0DNDz6G9qX; Sun, 7 Feb 2021 17:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612746026; bh=DnR+js0XBdhE6ebKIwOo+t9UwLpaX7y8xOcypxoSZRs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CgN5vJRLb3Vo/vod+6p91MKU5T4oabcYh8XTEAlJGXhF/r2quCIGmtErq5059jV1W jJGhgGMmlekRufL0uaQ32orGizas+NB+bw9KqFAdEI2AIhArU6dgpF1BHX1W1rpMVm I6W7rw7c18BE6oskyfM864+DnjeonivClnVz1YIs= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DYnkd3tc6z6G80y; Sun, 7 Feb 2021 17:00:25 -0800 (PST) To: Eric Rescorla Cc: rfced-future@iab.org References: <0fbee513-aa8d-80a2-0976-d2ca3e985d29@gmail.com> From: "Joel M. Halpern" Message-ID: <06b84894-1b1c-d4f9-03ef-f591771f50ee@joelhalpern.com> Date: Sun, 7 Feb 2021 20:00:25 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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 approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 01:00:28 -0000 Hmmm. This seems to have an assumption that the WG is inherently presumed to be correct. As far as I know, even the IETF technical process does not have that assumption. If IESG members raise legitimate technical technical issues, the WG is required to address them. And ADs are not restricted to their own area to raise such issues. Yours, Joel On 2/7/2021 7:50 PM, Eric Rescorla wrote: > > > On Sat, Feb 6, 2021 at 12:36 PM Brian E Carpenter > > wrote: > > >   * Do people agree that damage to a stream would include long > term strategic damage to the series? > > Why ask that? The bullet above does not state that damage to a > stream is the *only* ground for objection. Certainly, damage to the > series as a whole must be a ground for objection, but that isn't > what you are asking. > > > Well, obviously people don't need to agree but the intent of my proposal > was to sharply limit the grounds on which the approval body could object > to documents. > > Taking a step back from the details one could imagine people on these > bodies as having two roles: > > - Representing their equities (i.e., what is good for their streams) > - Representing their own views of what's good for the series regardless > of whether it affected their streams. > > I believe that we should attempt to limit the role of the approval body > as much as possible to the former category. The reason for this is that > the WG has inherent community legitimacy, whereas the stream managers > does not (primarily because of how they are selected but also because of > the interests they represent). I don't see any particular reason why the > opinion of the stream managers should override the opinion of the WG on > matters that don't directly threaten their streams. > > I suspect that this is another example of an issue where we actually > have disagreement about principles, and hence a good topic for the live > discussion. > > -Ekr > > From nobody Sun Feb 7 17:26:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401463A0DDF for ; Sun, 7 Feb 2021 17:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1yLsMDjEN9e for ; Sun, 7 Feb 2021 17:25:59 -0800 (PST) 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 5E4173A0DDD for ; Sun, 7 Feb 2021 17:25:59 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id f8so5322422ljk.3 for ; Sun, 07 Feb 2021 17:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AI+iXaIMNOxh9XJI/tng5l5fKz2V/Zycu5KJS7CVUFs=; b=IhslDtfCVpHYIJUe/PgwAfeDyMhwHJuOHeZSTPj/6KOPL0dK2/mPPxhGCxKwZ9Aqnz DQZd3hdYmqk3w1XXRplFPRUfhf4oPZPHqy5VHKBbEtxbZsEqetptT240xOfu4XM2lMBA vdxTgIe3BoeaE8ga/W0ibiJV7BGWXyzM7EIHD6gt+GRJnhWVrdz6XLPCOIeHbKlmveH+ 6BRsVE4/3vXInwekEmD53r22IKoTp11rsBUCgBSJdDTDZTfPr3YZZ/75Z2EsopwLK0Jg XI0LCkHC1Te8fgss/0TX/90SDGXHazmQRhgkhRhvLH2bnsYYRQZ/1baUl+69FuFjRLvc zBKw== 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=AI+iXaIMNOxh9XJI/tng5l5fKz2V/Zycu5KJS7CVUFs=; b=JouuAc+MOQ5c/pSpxRCFQBtv/90+x8DzUOHab3EBuSzLrsEsTs67Bkh9RGUCN89LRJ DfWstEznk1XB8SzkA7qGXtKPBxAKg9XhtbCeXxvNMK2sbHFN03wWfRANg4MSmyZKekfv GPd8/MFACpoCu5v1ilXvpQX9vhE0c1v10WK13+/x9qSqsiQUwwDSvZyDKFQ/TEnVPOiJ LoDw+DoidHXio36PgPbqUqXCCTaulh38BX/rZSy47xH9PyJc4Z7h48jHLYwDaJ2Jangl Tb1F7X9452pDXHNtMjx0w8m458JiMCKLFJjk0ReSArX/hbrbnLYVUnxZw99PDopXvkqW BmVw== X-Gm-Message-State: AOAM531TTuJUBS5QKy/Yno2hBE++sLkIgVwExw134Kf/CENKx7PQL/pi nOUwXeIiN7KBjJUqm0W5183ioAn7DVlCHFXWBaT6A4OlzMQoUfBk X-Google-Smtp-Source: ABdhPJyHBaOsu8ZEzESSB6fvfIj858xNPYTY15GjdBXKRkWyDuW/LC/Qjt/Jc51ElKthsRddTKjy9cWEYzAqC8wZ1Vk= X-Received: by 2002:a05:651c:503:: with SMTP id o3mr9889709ljp.2.1612747557364; Sun, 07 Feb 2021 17:25:57 -0800 (PST) MIME-Version: 1.0 References: <0fbee513-aa8d-80a2-0976-d2ca3e985d29@gmail.com> <06b84894-1b1c-d4f9-03ef-f591771f50ee@joelhalpern.com> In-Reply-To: <06b84894-1b1c-d4f9-03ef-f591771f50ee@joelhalpern.com> From: Eric Rescorla Date: Sun, 7 Feb 2021 17:25:21 -0800 Message-ID: To: "Joel M. Halpern" Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000044fdee05bac90d3f" Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 01:26:01 -0000 --00000000000044fdee05bac90d3f Content-Type: text/plain; charset="UTF-8" On Sun, Feb 7, 2021 at 5:00 PM Joel M. Halpern wrote: > Hmmm. This seems to have an assumption that the WG is inherently > presumed to be correct. > As I said earlier, I don't think it's "presumed to be correct", but rather "is the most legitimate representative of the community". We don't have an oracle of what's correct or not, so at the end of the day, someone/some group has to decide. I believe in this case that authority is best vested in the WG. As far as I know, even the IETF technical process does not have that > assumption. If IESG members raise legitimate technical technical > issues, the WG is required to address them. And ADs are not restricted > to their own area to raise such issues. > Right. I do not think that structure is serving us particularly well on the IESG and I think it will serve even less well here, given the proposed constitution of this body. -Ekr > Yours, > Joel > > On 2/7/2021 7:50 PM, Eric Rescorla wrote: > > > > > > On Sat, Feb 6, 2021 at 12:36 PM Brian E Carpenter > > > > wrote: > > > > > * Do people agree that damage to a stream would include long > > term strategic damage to the series? > > > > Why ask that? The bullet above does not state that damage to a > > stream is the *only* ground for objection. Certainly, damage to the > > series as a whole must be a ground for objection, but that isn't > > what you are asking. > > > > > > Well, obviously people don't need to agree but the intent of my proposal > > was to sharply limit the grounds on which the approval body could object > > to documents. > > > > Taking a step back from the details one could imagine people on these > > bodies as having two roles: > > > > - Representing their equities (i.e., what is good for their streams) > > - Representing their own views of what's good for the series regardless > > of whether it affected their streams. > > > > I believe that we should attempt to limit the role of the approval body > > as much as possible to the former category. The reason for this is that > > the WG has inherent community legitimacy, whereas the stream managers > > does not (primarily because of how they are selected but also because of > > the interests they represent). I don't see any particular reason why the > > opinion of the stream managers should override the opinion of the WG on > > matters that don't directly threaten their streams. > > > > I suspect that this is another example of an issue where we actually > > have disagreement about principles, and hence a good topic for the live > > discussion. > > > > -Ekr > > > > > --00000000000044fdee05bac90d3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 7, 2021 at 5:00 PM Joel M. Halpern &l= t;jmh@joelhalpern.com> wrote:=
Hmmm.=C2=A0 =C2= =A0This seems to have an assumption that the WG is inherently
presumed to be correct.

As I said earli= er, I don't think it's "presumed to be correct", but rath= er "is the most legitimate representative of the community". We d= on't have an oracle of what's correct or not, so at the end of the = day, someone/some group has to decide. I believe in this case that authorit= y is best vested in the WG.


As far as I know, even the IETF technical process does not have that
assumption.=C2=A0 If IESG members raise legitimate technical technical
issues, the WG is required to address them.=C2=A0 And ADs are not restricte= d
to their own area to raise such issues.

Right. I do not think that structure is serving us particularly well on th= e IESG and I think it will serve even less well here, given the proposed co= nstitution of this body.

-Ekr

=

Yours,
Joel

On 2/7/2021 7:50 PM, Eric Rescorla wrote:
>
>
> On Sat, Feb 6, 2021 at 12:36 PM Brian E Carpenter
> <b= rian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wro= te:
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0* Do people agree that damage to = a stream would include long
>=C2=A0 =C2=A0 =C2=A0term strategic damage to the series?
>
>=C2=A0 =C2=A0 =C2=A0Why ask that? The bullet above does not state that = damage to a
>=C2=A0 =C2=A0 =C2=A0stream is the *only* ground for objection. Certainl= y, damage to the
>=C2=A0 =C2=A0 =C2=A0series as a whole must be a ground for objection, b= ut that isn't
>=C2=A0 =C2=A0 =C2=A0what you are asking.
>
>
> Well, obviously people don't need to agree but the intent of my pr= oposal
> was to sharply limit the grounds on which the approval body could obje= ct
> to documents.
>
> Taking a step back from the details one could imagine people on these =
> bodies as having two roles:
>
> - Representing their equities (i.e., what is good for their streams) > - Representing their own views of what's good for the series regar= dless
> of whether it affected their streams.
>
> I believe that we should attempt to limit the role of the approval bod= y
> as much as possible to the former category. The reason for this is tha= t
> the WG has inherent community legitimacy, whereas the stream managers =
> does not (primarily because of how they are selected but also because = of
> the interests they represent). I don't see any particular reason w= hy the
> opinion of the stream managers should override the opinion of the WG o= n
> matters that don't directly threaten their streams.
>
> I suspect that this is another example of an issue where we actually <= br> > have disagreement about principles, and hence a good topic for the liv= e
> discussion.
>
> -Ekr
>
>
--00000000000044fdee05bac90d3f-- From nobody Sun Feb 7 19:36:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029C43A0FD2 for ; Sun, 7 Feb 2021 19:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 KZCNLnn-tCWa for ; Sun, 7 Feb 2021 19:36:37 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7AEE3A0FC5 for ; Sun, 7 Feb 2021 19:36:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DYsBs3P8gz6G9vM; Sun, 7 Feb 2021 19:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612755397; bh=tN95xjs99NUpKANVZD5udSHDTsRVqxqvLiV/aPLYw44=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pbYea1HAbEV1YlEQt0F7J+sjVJ/wUO8bkujF66HBPRLXawBIdRcY3o/8/QGUDrSpH 7h6nWdkOiYXp+N7gTGnKlhjKSz/ukZUYvD1bIyREvMBVTI7GW25dHER0K23fkOp7aT FwnG3rYglMXv9tlLwR/WGkGbidDUd/Q5J/IE3Gxc= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DYsBr6RRPz6G9qW; Sun, 7 Feb 2021 19:36:36 -0800 (PST) To: Eric Rescorla Cc: rfced-future@iab.org References: <0fbee513-aa8d-80a2-0976-d2ca3e985d29@gmail.com> <06b84894-1b1c-d4f9-03ef-f591771f50ee@joelhalpern.com> From: Joel Halpern Direct Message-ID: Date: Sun, 7 Feb 2021 22:36:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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 approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 03:36:39 -0000 You refer to "the proposed constitution of the body" in your response below. I presume that refers to the constitution of teh approval body. I believe I have stated that in my view the concern is the fact that, like the IETF, there is no control on (or means to ensure participation from needed parties) in the constitution of the working group. Given the flakiness I have seen from working groups that really did (in most regards) know what they are doing, I am concerned if we do not create some form of insurance / ensurance. Yes, this is basically teh same reason that I have objected to streamlining proposals in the past that would have removed most of the IESG's grounds for objecting to IETF documents. I suspect this is an area where we have very basic disagreements. Yours, Joel On 2/7/2021 8:25 PM, Eric Rescorla wrote: > > > On Sun, Feb 7, 2021 at 5:00 PM Joel M. Halpern > wrote: > > Hmmm.   This seems to have an assumption that the WG is inherently > presumed to be correct. > > > As I said earlier, I don't think it's "presumed to be correct", but > rather "is the most legitimate representative of the community". We > don't have an oracle of what's correct or not, so at the end of the day, > someone/some group has to decide. I believe in this case that authority > is best vested in the WG. > > > As far as I know, even the IETF technical process does not have that > assumption.  If IESG members raise legitimate technical technical > issues, the WG is required to address them.  And ADs are not restricted > to their own area to raise such issues. > > > Right. I do not think that structure is serving us particularly well on > the IESG and I think it will serve even less well here, given the > proposed constitution of this body. > > -Ekr > > > Yours, > Joel > > On 2/7/2021 7:50 PM, Eric Rescorla wrote: > > > > > > On Sat, Feb 6, 2021 at 12:36 PM Brian E Carpenter > > > >> wrote: > > > >      >   * Do people agree that damage to a stream would include long > >     term strategic damage to the series? > > > >     Why ask that? The bullet above does not state that damage to a > >     stream is the *only* ground for objection. Certainly, damage > to the > >     series as a whole must be a ground for objection, but that isn't > >     what you are asking. > > > > > > Well, obviously people don't need to agree but the intent of my > proposal > > was to sharply limit the grounds on which the approval body could > object > > to documents. > > > > Taking a step back from the details one could imagine people on > these > > bodies as having two roles: > > > > - Representing their equities (i.e., what is good for their streams) > > - Representing their own views of what's good for the series > regardless > > of whether it affected their streams. > > > > I believe that we should attempt to limit the role of the > approval body > > as much as possible to the former category. The reason for this > is that > > the WG has inherent community legitimacy, whereas the stream > managers > > does not (primarily because of how they are selected but also > because of > > the interests they represent). I don't see any particular reason > why the > > opinion of the stream managers should override the opinion of the > WG on > > matters that don't directly threaten their streams. > > > > I suspect that this is another example of an issue where we actually > > have disagreement about principles, and hence a good topic for > the live > > discussion. > > > > -Ekr > > > > > From nobody Sun Feb 7 23:53:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1502E3A13F8 for ; Sun, 7 Feb 2021 23:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrvIhLEPf-_r for ; Sun, 7 Feb 2021 23:53:38 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBD93A13F7 for ; Sun, 7 Feb 2021 23:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3212; q=dns/txt; s=iport; t=1612770818; x=1613980418; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=h4Xrbn6uAKDSxkWscutS3ElN5LUlos6NIZCdkOkMbgE=; b=WPvspFPgIXVI88HA5PafmT7iLLfxiuP/hH9y4cZCWVaP1LeOZeJLMABD +k3xkJNZEJLUBh7XipzJqhceuGkOxbT04GuCi2KNu5rBefcqIoCWjqftv 4adqvGNhQlw4wz22wIedgU+1Lbofjl0WhccLMQQn4obJiFG5Vm7T+awwa s=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0D4AgDO7CBgjBbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+BI4JUAScSMY1FiDIoh3CMOYgdBAcBAQEKAwEBLwQBAYRLAoICJjgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgQUAQEBAYZHhXEBAQEDAXkFCwsEARMuVwYTgyYBg?= =?us-ascii?q?mYgrVx0gTSFWYR6EIE4gVOLcEGCAIE4DBCCVj6IC4IsBIFlAYN5gRaHZZRqi?= =?us-ascii?q?nyRRoMEgymBOpcgAx+TNY9tjmijToNyAgQGBQIWgW0hgVkzGggbFTsqAYI+P?= =?us-ascii?q?hIZDY47jjFAAzA3AgYKAQEDCYwYAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,161,1610409600"; d="asc'?scan'208,217";a="33237754" 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; 08 Feb 2021 07:53:34 +0000 Received: from [10.61.210.69] ([10.61.210.69]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 1187rXfj030429 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Feb 2021 07:53:33 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2612A0AF-DEA4-420F-9418-6DE7D2451A7B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 8 Feb 2021 08:53:33 +0100 In-Reply-To: <021601d6fc07$9010f790$b032e6b0$@olddog.co.uk> Cc: rfced-future@iab.org, Brian Rosen To: Adrian Farrel References: <021601d6fc07$9010f790$b032e6b0$@olddog.co.uk> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.210.69, [10.61.210.69] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 07:53:40 -0000 --Apple-Mail=_2612A0AF-DEA4-420F-9418-6DE7D2451A7B Content-Type: multipart/alternative; boundary="Apple-Mail=_C305FE94-E6CB-4F6A-AD9D-D651F6C3CB3A" --Apple-Mail=_C305FE94-E6CB-4F6A-AD9D-D651F6C3CB3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Adrian, Just one clarification. > On 5 Feb 2021, at 22:40, Adrian Farrel wrote: >=20 > Your list is nicely phrased as things I can agree with, but they are = not limiting statements. >=20 Nor need they be. Our goal is simply to understand where there is = agreement and where there is more work to be done. Eliot --Apple-Mail=_C305FE94-E6CB-4F6A-AD9D-D651F6C3CB3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Adrian,

Just one = clarification.

On 5 Feb 2021, at 22:40, Adrian Farrel = <adrian@olddog.co.uk> wrote:

Your list is nicely phrased as things I can agree with, but = they are not limiting statements. 


Nor need they be.  Our goal is simply = to understand where there is agreement and where there is more work to = be done.

Eliot
= --Apple-Mail=_C305FE94-E6CB-4F6A-AD9D-D651F6C3CB3A-- --Apple-Mail=_2612A0AF-DEA4-420F-9418-6DE7D2451A7B 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAg7f0ACgkQh7ZrRtnS ejNljQf/Z5MbrC/RlLfIiLmA9e4dAJGKJtOrOKvfE+XPe0UlrK23juD6rjEE0E4S yREhm4YCMj4kE4UjArnrOKAQCK5oWshYHeOFCcYxcDBSj+7NHqvASLFaf75RdBlP uS/PeDtQpjW80JJNRidE7FwmdcAZ2cpatKIUdgFSvzL2iKmuA8t/gNjrPwShuI7U XCbhtlXBp91N8Nbnyz28PMZdKL5l3dFXeAlP6DB9CZVsVwdz9+5YDMq1pKHr46fi kOa0Rcvh06qcY6V4Epm8X3BLsbQWjX2Gi4NoGyroE5B09EkCyyT5vJ8XzCumxmz8 viujXOJV8MtcLpkebUy8rOwYSaaUpw== =9nun -----END PGP SIGNATURE----- --Apple-Mail=_2612A0AF-DEA4-420F-9418-6DE7D2451A7B-- From nobody Mon Feb 8 01:26:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7148D3A1504 for ; Mon, 8 Feb 2021 01:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6mMlN5GORj4 for ; Mon, 8 Feb 2021 01:26:09 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B323A1503 for ; Mon, 8 Feb 2021 01:26:08 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1189Q0i9021817; Mon, 8 Feb 2021 09:26:06 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4B44222040; Mon, 8 Feb 2021 09:26:06 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 361172203D; Mon, 8 Feb 2021 09:26:06 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.213.140]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1189Q5Os028143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Feb 2021 09:26:05 GMT Reply-To: From: "Adrian Farrel" To: "'Martin Thomson'" , References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> In-Reply-To: <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> Date: Mon, 8 Feb 2021 09:26:04 -0000 Organization: Old Dog Consulting Message-ID: <006d01d6fdfc$6cf80db0$46e82910$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIxOzb1K7FOVzc7vzw9Sqa6JmeniwF/68HOAiHvuQEAjaJTOal4A1Tg Content-Language: en-gb X-Originating-IP: 87.112.213.140 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-25942.003 X-TM-AS-Result: No--1.876-10.0-31-10 X-imss-scan-details: No--1.876-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--1.876300-10.000000 X-TMASE-MatchedRID: wQVy7q402w3xIbpQ8BhdbPHkpkyUphL9TDUWYQJYPF0gbXncUlnhYN60 KzuvJ8HQF1ap610mzeI+J74ZZF+mQljAxBJHeoHdyqq4/eqFCmqUOCxPuT+1Pg2qUiRWrRAFo8W MkQWv6iV95l0nVeyiuFSqyRM1YGuhU6baA36eiazZs3HUcS/scCq2rl3dzGQ1sLm/LKA8BUQTmG GPHPBWlFhqIDCY6IbkOdLKNgFQPo8tUqs0R/Dyxg2LedqyCMbJ3WX713oZbxvz0CnN2Ti+EQ7uY //+nNi0UOJPyqOD2CavcsTuUejg0omQ2vqumwAFVUH85vIcwrlnNvCdxiuD10MMprcbiest X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 09:26:11 -0000 I like Martin's question: > Are we assuming that the RSA/E has expertise in outreach to these diverse communities of interest? I think Joel captured most of the important points. But: This is not solely about outreach, it is also about experience in publication for diverse communities. And: It is also also about who the "champion" will be when it is not the primary interest of any of the other parties (WG, approval group) to know or care about the diverse communities. Who is the stuckee for this? Adrian From nobody Mon Feb 8 04:58:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1C73A1724 for ; Mon, 8 Feb 2021 04:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 eZaodxl6ak53 for ; Mon, 8 Feb 2021 04:58:26 -0800 (PST) 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 64A843A16B6 for ; Mon, 8 Feb 2021 04:58:26 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id b24so428062qtp.13 for ; Mon, 08 Feb 2021 04:58:26 -0800 (PST) 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=2g/YfBT/yI59I8h2m+gJeoIxZQ35u1zVdZncO/aMz9M=; b=m7HA7tBfpeekTPbzIg+aqnlNJpRYyabjmsX4sdC7CwO/wFpgqBheS6QlB1Y7Tpq2Oz eSyBFI3We2tUsddg1dyx8WtKe2eoL/bw1eaaPNvK6/DlbPB7AVnR06dpNTdCKIk1/F0i TQ5Z+hLDQI5Tvc0zMR3tUEHpu3TfnMEFRuOHkUDTBfTG+IVQ5yK4Fqs5qLsPXJEg4p+X D7kNE16UvLca3nxaFLZ14wzm8tz/5CKDRY29HdKkfg27eillDKT9+1GgIjJCzoCvXI1a BBi5nq06nve+idjyutpF4nRm7DtPWZQNn30/K9hC3ejPCrwdFBP3vJum+TEWTtFCRNFO xwXQ== 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=2g/YfBT/yI59I8h2m+gJeoIxZQ35u1zVdZncO/aMz9M=; b=pm9lqzib3psz7wcNJdpJ3SKkaDgkE6bIvuDGKW60Ydlij0Q/MwI4lOGuOAINCESliP l0XM7FR/CmnFGBIcox3E3G4LkEIsHJC0b8oCM8aFosHEbEsX4tkzIUiNa1E7HlV6N0yM HkaNR1pWmkJmzduVv+5O3BxyOY+/OrlhdVAkCdf/K02J23bfocxLs28sm7vK/eEVIAxG 7rwuoyaPOF/znrvFY09eO2miWsD3ZQ6+IJYW1X3e3aLkXgaozVaTPYt5wKvq/MUukvzj Dd+g2CAZPcaJ7Lb357ngx1ND6/3TbrugNmkoCFgFsaZx6NOWkcI/IrB4yCT+mE4vsZvB weww== X-Gm-Message-State: AOAM533a5hXoWkGCvYRjZalhtiRw0u9UuzU8FBWaDSOheLPIGhb6bEub Z/dlUewVEH+op0Yygt9UOitj61BbLlFP9A== X-Google-Smtp-Source: ABdhPJwSYjd+MHwmCv9zOQlPyWSJnexwt7LTr4/BHbeqHTJ1ZRwxU9pWGv1/qMgYE/OhL3xvo4Xt1g== X-Received: by 2002:ac8:5e12:: with SMTP id h18mr15007207qtx.335.1612789105365; Mon, 08 Feb 2021 04:58:25 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id h5sm14652815qti.22.2021.02.08.04.58.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 04:58:24 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-BF0DAB62-EF8F-4994-B4A2-4537F9C70E91 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Mon, 8 Feb 2021 07:58:23 -0500 Message-Id: <73848B62-187E-4603-854E-09A48351CB16@fugue.com> References: Cc: Adrian Farrel , rfced-future@iab.org, Brian Rosen In-Reply-To: To: Eliot Lear X-Mailer: iPhone Mail (18E118) Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 12:58:28 -0000 --Apple-Mail-BF0DAB62-EF8F-4994-B4A2-4537F9C70E91 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Historically this has been the IETF as a whole, with the AD calling consensu= s. Why do you want to change that? > On Feb 8, 2021, at 02:53, Eliot Lear w= rote: >=20 > =EF=BB=BFHi Adrian, >=20 > Just one clarification. >=20 >> On 5 Feb 2021, at 22:40, Adrian Farrel wrote: >>=20 >> Your list is nicely phrased as things I can agree with, but they are not l= imiting statements.=20 >>=20 >=20 > Nor need they be. Our goal is simply to understand where there is agreeme= nt and where there is more work to be done. >=20 > Eliot > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail-BF0DAB62-EF8F-4994-B4A2-4537F9C70E91 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Historically this has been= the IETF as a whole, with the AD calling consensus. Why do you want to chan= ge that?

On Feb 8, 2021,= at 02:53, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:
=EF=BB=BFHi A= drian,

Just one clarific= ation.

On 5 Feb 2021, at 22:40, Adrian Farrel <adrian@olddog.co.uk> wrote:
<= br class=3D"Apple-interchange-newline">
Your list is nicely phrased as things I can agree with, but they a= re not limiting statements. 
=

Nor need they be.  Our goal is simply to understand where= there is agreement and where there is more work to be done.

Eliot
--
Rfced-future maili= ng list
Rfced-future@iab.org
https://www.iab= .org/mailman/listinfo/rfced-future
= --Apple-Mail-BF0DAB62-EF8F-4994-B4A2-4537F9C70E91-- From nobody Mon Feb 8 11:50:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0196A3A152D for ; Mon, 8 Feb 2021 11:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=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 OESoBTdHdQ7J for ; Mon, 8 Feb 2021 11:50:36 -0800 (PST) Received: from xyz.hosed.xyz (xyz.hosed.xyz [71.114.67.91]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F283A152C for ; Mon, 8 Feb 2021 11:50:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xyz.hosed.xyz (Postfix) with ESMTP id C9E1C13C0687; Mon, 8 Feb 2021 14:50:34 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at xyz.hosed.xyz Received: from xyz.hosed.xyz ([127.0.0.1]) by localhost (xyz.hosed.xyz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTCyNUedLcgS; Mon, 8 Feb 2021 14:50:34 -0500 (EST) Received: from [10.0.0.64] (c-73-71-250-98.hsd1.ca.comcast.net [73.71.250.98]) by xyz.hosed.xyz (Postfix) with ESMTPSA id 2ED1A13C03ED; Mon, 8 Feb 2021 14:50:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sarah Banks In-Reply-To: <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> Date: Mon, 8 Feb 2021 11:50:32 -0800 Cc: Martin Thomson , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <98FCDDB4-1F2C-455A-A0EA-EBDF34909F4E@encrypted.net> References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 19:50:38 -0000 Hi, A big +1 to Joel's points, and I'd like to "yes, and", and = address a point from Martin's last paragraph. I've never viewed the RSE = as a role we were "at the mercy" of; no more so than we are at the mercy = of the IAB, for example. Given the actions that have occurred over the = last 2 years, I very much support the idea of having the independent RSE = role, with less of a touch from the IAB. I also agree with Martin that = we need to define what we want, and I think we've learned from the first = time we documented the job description of the RSE. We can - and should - = do better and improve that description this time through. My hope is, if = we agree in the RSE role as an independent, publishing-expertise-savvy = role, that we'll crisply define the skills we need, the skills we want, = and outline the job description accordingly. Thanks, Sarah > On Feb 7, 2021, at 4:23 PM, Joel M. Halpern = wrote: >=20 > I do not think that a technical publication expert can inherently = represent the broad range of our external communities. >=20 > There are however two relevant dimensions. > First, much of senior technical publishing does involve making sure = the constituent communities are heard from. So while not an inherent = expertise, it is a relevant expertise. > Second, we can write down (as we have in the past) that it is part of = the job. During previous searches for related positions, skill / = experience / ability to provide that dimension was one of the thing that = was asked about / considered during the selection. (Whether we did the = job right is a different question.) Deciding what we want and including = it the search criteria seems rather necessary. >=20 > Yours, > Joel >=20 > On 2/7/2021 7:14 PM, Martin Thomson wrote: >> On Sat, Feb 6, 2021, at 23:26, Adrian Farrel wrote: >>> silent majorities are often excluded by those in power (I do not = accuse >>> anyone here present of such an intention). >> I find myself really liking the turn this discussion took. That is, = I like that we are explicitly considering the biases inherent in the = designs we're considering and how to counteract them. >>> Now, suppose the RSA/E has the responsibility and expresses a = concern to the >>> WG. >> This my be my own lack of knowledge, but I'm hearing an assumption = here, and I want to repeat what I'm hearing out loud to see if it makes = sense to others. It doesn't add up for me. >> Are we assuming that the RSA/E has expertise in outreach to these = diverse communities of interest? >> Is this something that expertise in technical publication naturally = comes with? Which community or communities are then naturally = represented? >> Effective representation is something we struggle with everywhere. = But I can give an example from an adjacent community. When we discuss = whether web API Foo is good for the web, one of the questions we try to = understand is whether the web developer community would benefit. (Even = there, we routinely fail to capture the diversity of that community, = usually only getting input from large sites.) But browser-makers in = particular do spend non-trivial time and effort in gathering this input, = and we also benefit from the experience of people in that community who = aren't beholden to a browser-maker also. But we do not assume that = those people also represent the interests of communities in which they = have not spent that time; though these are paid professionals with deep = expertise, that expertise is narrow. And the conclusions reached on the = basis of web developer feedback can, on some matters, demonstrate a bias = against other stakeholder interests (certain user communities, for = instan > ce >> ). >> In the IETF, we have experience with people connected to various = communities that interact with the work we do. People who implement, = deploy, operate, purchase, and so forth. As Mark points out, we are now = lucky enough to sometimes have people participate from communities that = study the effect of our decisions on people and societies. But my = experience is that the community of interest speaking is generally = understood, usually as a result of getting to know the person speaking a = little. >> Of course no single person speaks for any community because no = community is ever so uniform as to have precisely one position on just = about any subject. And any who claim to speak for a community can only = do so through the filter of their own biases. Again, getting to know = someone to better understand those biases is also part of how we manage = that. >> I use the long anecdote (rant?) to highlight that if we are looking = for someone to convey a particular viewpoint, we need to understand what = we're looking for. If publication expertise is truly alien to us = engineer-y folks, I don't think that we have much hope of doing anything = except invest the RSA/E with power that leaves the series at the mercy = of the LLC hiring process. But, like the lawyer example, I think that = we can learn to recognize the shape of our lack of knowledge. To do = that, maybe someone can define the undefinable and tell me which = community we might expect a publication expert to be able to represent. > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Mon Feb 8 13:24:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E813A14EC for ; Mon, 8 Feb 2021 13:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8WOu-sKWrr9 for ; Mon, 8 Feb 2021 13:24:33 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6113A133C for ; Mon, 8 Feb 2021 13:24:33 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id e7so14136424ile.7 for ; Mon, 08 Feb 2021 13:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FXe7fAG8uVCUne8pa6Arou2mLC89P57DO/iIIXwpzmQ=; b=eHuObY6u4XplkKWDtttaSV/LaomImEs8uu0JkXX5mKcKPGOgEVnXxKR3Gfmvcqp/Bd P+MhwdQfI0a/FJJKio3nsvGYMrigPjLUJoT15yWX4PebskMmtIfh107d5bro4eepLMue 7RO21S4NAY8NMp1qbOBAnT1VO3ZVrT1+HDUHA= 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=FXe7fAG8uVCUne8pa6Arou2mLC89P57DO/iIIXwpzmQ=; b=X327b13Ig33+cvzOtdYH+1CvyT7wiQSAXZG+5gX/tk4pDxJ0pF7Lu9LbstENn2YRrg zpRdNHFH+ldd96poc0mBH3cp67OiMpBtLt1uiJhs4nKNCsTTUBlGPbnFK5W85p/TsYSv WzpOft0VMU+yDKyynC8z5bYI5ByP/P9M7jKQqHwYrG52ViB/BnVhfZDX7SI/iePw6oLJ pMbNw2XkKgABgZUvVWGmjAXH6dJPjBMHSv1+t9eNhpTpf/X7C3l4C3RoNxk3XKxK7cN4 hpjuo/XMcsSOIb7yuqW1WdOq5z0LacdTzg1aqPUF9b84glsnITra+IZVh2xDDByUWZR7 um2A== X-Gm-Message-State: AOAM5336EwInAMP15zSG6c6K5zRVF4hqY2aNTeHutdZph1Y6FupRrQod jTXX9FaFq1+ThMFCpRgwc8uOYA== X-Google-Smtp-Source: ABdhPJxdpRIV3AguO3dT1kRABw4dOWqt2BobScEdnRPzEOR2BOihg6jKoeSS4eVmUeEMjACogZ8C/A== X-Received: by 2002:a05:6e02:216f:: with SMTP id s15mr17749154ilv.81.1612819472543; Mon, 08 Feb 2021 13:24:32 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id n7sm9392056ile.12.2021.02.08.13.24.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 13:24:31 -0800 (PST) To: "Joel M. Halpern" , Martin Thomson , rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> From: Peter Saint-Andre Message-ID: <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> Date: Mon, 8 Feb 2021 14:24:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 21:24:35 -0000 [ no hats ] On 2/7/21 5:23 PM, Joel M. Halpern wrote: > I do not think that a technical publication expert can inherently > represent the broad range of our external communities. There might be value in trying to describe this "broad range". (Pardon me if that's been done already.) Earlier in the thread, Mark Nottingham said: "our documents are very often used by developers of implementations." It strikes me that this is the *primary* use of our documents. Although this perspective might be seen as simplistic, I've always felt that my core task as an RFC author is to help design a sensible protocol and document it as clearly and accurately as possible so that engineers can write interoperable code. This might imply a different vision of "technical publishing" than what might come to mind if we're comparing the RFC series to, say, Physical Review or The Lancet. Yes, we have are other "customers" - civil society groups, regulators, patent lawyers, historians and sociologists of technology, etc. - but if engineers weren't using RFCs to write code and deploy services used by billions of people then it seems to me that very few of these other customers would care about the RFC series. Peter From nobody Mon Feb 8 13:37:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143F03A162B for ; Mon, 8 Feb 2021 13:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR2E4l9Gbtqf for ; Mon, 8 Feb 2021 13:37:51 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619963A1628 for ; Mon, 8 Feb 2021 13:37:46 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id r38so11078518pgk.13 for ; Mon, 08 Feb 2021 13:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=TTVBN5vKeyiZDAjTiEWGt3m2FiAiunOXXPu2yeNzyrA=; b=s7DIuUIxxElgtsuenu3XlYDkK+QCU2i6kv8fTw6/CiuKLpa6BjXOkpVnRr5YwYL+Qa ZF7Q179d+ihXVRQKdkZlys4dd/RiwXJeQ8cL8pmr4IfNEYI15jJ6FJYlR0r/DZTnm7f8 c6dIxqoeOPn+Rvcvcs8zRwV1MTTz83ZtWMV9aUClRYtD8gUn3ExYbJBrIUwDVkzPYtS6 Mxb3kZmn7W7y1lpv54dpp2tnsTQYg6z5GH/gd8II9aicpfqbbRe6fTwSQflurf+YIlgv d9XXKDVSWRSAC62ZcpVriRoirfbVFRAr9qu2BvmSiQikNv7NaFNuI1bLVvRYKPy2IYmU NBbQ== 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=TTVBN5vKeyiZDAjTiEWGt3m2FiAiunOXXPu2yeNzyrA=; b=TRo5F8FuHYnKhhoMg06I3+lIF7cN98Oo6YS1Rpfhye8pXvS95YYqNECgjrJK7D9Ci2 A/FxiDs3F8brB+ZeqNyvsrPSDq0yBsbHixJH5cKANFIhAfxKuoessc2+oxfktM94sTvZ wAaZExrUOAGPWCuF9yyQtfdizPkRpubMNsjnegUiiWVOqMMRv7OvwjYTTX3oX9aH4q11 btQ4T7matYQq0U083hMr018tOoxF0Y0Cni2bZS0EjzGp/Vbk/YcvXe957vHkpk6yh4Fk rl7BLnTrzZqOZOd1U8prOuOpCpa62sOk6J3tD115+JuVGocVwgzFI3QDZjZQHaj0RUVJ gS8w== X-Gm-Message-State: AOAM530tQYJzfFOnBcpdljutWqaRk5rMpeoWRrvKJllwpS+HdkLwmz2H TYoPsz0iDIDr3H3Rx8JR7x4TdK+v4nratQ== X-Google-Smtp-Source: ABdhPJyEAkhTjc0neZhQkv2ZBrK89A5qHXfBPd0N2gsY1gJj6t7PP9QwAVMmUeujjCyPJ4ocMkmfag== X-Received: by 2002:aa7:961b:0:b029:1db:532c:9030 with SMTP id q27-20020aa7961b0000b02901db532c9030mr10805347pfg.30.1612820265493; Mon, 08 Feb 2021 13:37:45 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id p68sm19377064pfb.60.2021.02.08.13.37.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2021 13:37:44 -0800 (PST) To: rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> From: Brian E Carpenter Message-ID: <58e7d15a-b305-50b7-01c4-a2a03e2bf992@gmail.com> Date: Tue, 9 Feb 2021 10:37:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 21:37:53 -0000 On 09-Feb-21 10:24, Peter Saint-Andre wrote: > [ no hats ] > > On 2/7/21 5:23 PM, Joel M. Halpern wrote: >> I do not think that a technical publication expert can inherently >> represent the broad range of our external communities. > > There might be value in trying to describe this "broad range". (Pardon > me if that's been done already.) > > Earlier in the thread, Mark Nottingham said: "our documents are very > often used by developers of implementations." > > It strikes me that this is the *primary* use of our documents. I'd put that equal first with use by operators. In fact, I suspect that operators outnumber developers. Otherwise, you're correct (but add educators and researchers). However I think we want all of them inside the big tent, don't we? Brian > > Although this perspective might be seen as simplistic, I've always felt > that my core task as an RFC author is to help design a sensible protocol > and document it as clearly and accurately as possible so that engineers > can write interoperable code. > > This might imply a different vision of "technical publishing" than what > might come to mind if we're comparing the RFC series to, say, Physical > Review or The Lancet. > > Yes, we have are other "customers" - civil society groups, regulators, > patent lawyers, historians and sociologists of technology, etc. - but if > engineers weren't using RFCs to write code and deploy services used by > billions of people then it seems to me that very few of these other > customers would care about the RFC series. > > Peter > From nobody Mon Feb 8 13:59:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5F93A164C for ; Mon, 8 Feb 2021 13:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8563wDAbLuXf for ; Mon, 8 Feb 2021 13:59:43 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C2C3A164B for ; Mon, 8 Feb 2021 13:59:42 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 118Lxe0M014527; Mon, 8 Feb 2021 21:59:40 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6E5CD22044; Mon, 8 Feb 2021 21:59:40 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 592AE22042; Mon, 8 Feb 2021 21:59:40 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.213.140]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 118Lxdns013645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Feb 2021 21:59:40 GMT Reply-To: From: "Adrian Farrel" To: "'Peter Saint-Andre'" , References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> In-Reply-To: <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> Date: Mon, 8 Feb 2021 21:59:39 -0000 Organization: Old Dog Consulting Message-ID: <016601d6fe65$b2a61870$17f24950$@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: AQIxOzb1K7FOVzc7vzw9Sqa6JmeniwF/68HOAiHvuQEAjaJTOQIDOselAx4ydpKpT8wbMA== Content-Language: en-gb X-Originating-IP: 87.112.213.140 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-25942.003 X-TM-AS-Result: No--2.257-10.0-31-10 X-imss-scan-details: No--2.257-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--2.257200-10.000000 X-TMASE-MatchedRID: L8tZF6zWW2rxIbpQ8BhdbM9R/UqWnLW4u/jPlvRik1hLjXXGQy6nlIu3 renu5Y0wXw8SDK+AsGnoRPSpZmYRJ4kWO3ctYmz1EclbAMYYY6yPSNdj1JMyAYBhPxJXPuLH2bw /J1GlL7DBj6mgdod7a5IYL57Zm6AYCGqH67UhpHtcrmR4Jr5uaDSqtJVqhgxbn7jOJQ+rgvGwP0 EaLtIAriixQ9JtYLpcxZbcuTpCHv8m2WWAELvR+cEvKlG0CjjIGDp0A8FqdMSbKItl61J/yY3BZ j4qY5QbFBpuM64i9KELbigRnpKlKZvjAepGmdoOmrXOF+SDqYpnPXOWjyPjTuAO0aV89QKSu9rV us4/jXKOJmi5V2FCeuF0p4tyo/D/ubFHYdaBzyoRId73gL5muN15xrdt5rlM9HmAsM11v0u45mj KIIYY3xiCad9aBKWfm9p/RC99TJ4LxcqOxVsmNQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 21:59:45 -0000 Hi Peter, At the risk of being accused of pedantry... > Earlier in the thread, Mark Nottingham said: "our documents are very > often used by developers of implementations." > > It strikes me that this is the *primary* use of our documents. > > Although this perspective might be seen as simplistic, I've always = felt > that my core task as an RFC author is to help design a sensible = protocol > and document it as clearly and accurately as possible so that = engineers > can write interoperable code. Tell us about RFC 4417. And RFC 6702. RFC 7259 gives an interesting slant. Etc. =F0=9F=98=8A Perhaps we also need to be a bit careful when we say, "use of *our* = documents." Who are the "we" that we refer to? Anyway, the point here is not that you and Brian are wrong about the = primary uses, but that we don't want to sacrifice other uses = accidentally along the way. Cheers, Adrian From nobody Mon Feb 8 14:24:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0A13A0E18 for ; Mon, 8 Feb 2021 14:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK4awyjLu5OA for ; Mon, 8 Feb 2021 14:24:22 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB083A0E17 for ; Mon, 8 Feb 2021 14:24:21 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id y17so14283084ili.12 for ; Mon, 08 Feb 2021 14:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=BiAAcJ1lHLTisgPoNvfIDcEuj32BEtVy7hWf88wjXKg=; b=UEv85/gBWlME5CoEW1qTwMXkTAVc9B1wheNfVZxGTqgLAWrSXJpfvQ42bOVnwPGg6/ O7gYGMWBkXcZdIaXjj8tMeAusFsJv3YYsZRvs2bwI6BfmIzoR+A0pxoCUZAgAr9eoREK SVIJjNtE0T/wrMZUrL8pCQpK7392ZdGBFaav8= 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=BiAAcJ1lHLTisgPoNvfIDcEuj32BEtVy7hWf88wjXKg=; b=jE3ZZvCkWZrmwgTXomW/4W9QpRyYovLw+nKdt+2Wo2GGi3/bS0CFXyOUpiImyMh+mP /cCKTOhKJ9c5WmUTk6VgFqGguLMzi1DE9uSAjPub8yZezw7qN2eWczig88o4N6BAYFPm srIiJjP7Kv7AuhjDcIm0IDE5gmAZAGvzkuJc1WIwpkbx8UJTn7cY9E+FlBWl1BnuU0QS cc29xMxBYroff9SJY062OT/aFMiTKuj7fEXmkbQ7cOAH5ZmwkDqsWwpzaABSHpF4yKu/ QbGN8loFFZxm+t6VsBLTyNbzGUof5dcKSVZwRDfknXNaRclc+xYHD5H3gSEn161fsaxw htzg== X-Gm-Message-State: AOAM532M0ZH+oTJY0TPxF6Fnkz/tgr7YqDTF2BGypAFLRgdUKV6F2LH2 00yuTCcmmBkyzSSBqgHdpsXnzw== X-Google-Smtp-Source: ABdhPJwmOEqKuIz1NiNzkDQND0d5/Qs13CUcnIQ2AtajhGsYuq+doDKXArprqDXeu6xltx34TUEgIA== X-Received: by 2002:a92:8e0c:: with SMTP id c12mr17748645ild.35.1612823061052; Mon, 08 Feb 2021 14:24:21 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id f11sm1421629ilc.69.2021.02.08.14.24.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 14:24:20 -0800 (PST) To: Brian E Carpenter , rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> <58e7d15a-b305-50b7-01c4-a2a03e2bf992@gmail.com> From: Peter Saint-Andre Message-ID: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> Date: Mon, 8 Feb 2021 15:24:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <58e7d15a-b305-50b7-01c4-a2a03e2bf992@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 22:24:23 -0000 On 2/8/21 2:37 PM, Brian E Carpenter wrote: > On 09-Feb-21 10:24, Peter Saint-Andre wrote: >> [ no hats ] >> >> On 2/7/21 5:23 PM, Joel M. Halpern wrote: >>> I do not think that a technical publication expert can inherently >>> represent the broad range of our external communities. >> >> There might be value in trying to describe this "broad range". (Pardon >> me if that's been done already.) >> >> Earlier in the thread, Mark Nottingham said: "our documents are very >> often used by developers of implementations." >> >> It strikes me that this is the *primary* use of our documents. > > I'd put that equal first with use by operators. In fact, I suspect that > operators outnumber developers. Likely so. However, operators offer services based on the code that developers write, so I think of these as one bundle. > Otherwise, you're correct (but add educators and researchers). See my comment below about people wouldn't care a whit about the RFC series if billions of developers and operators didn't have running code. > However > I think we want all of them inside the big tent, don't we? Although I can't object to a big tent, I think it would be helpful for us to think clearly about these different communities of interest so that we can prioritize their respective needs. Peter From nobody Mon Feb 8 14:43:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1AF3A167F for ; Mon, 8 Feb 2021 14:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 5HvNknDACuKg for ; Mon, 8 Feb 2021 14:43:50 -0800 (PST) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619553A167E for ; Mon, 8 Feb 2021 14:43:50 -0800 (PST) Received: by mail-qv1-xf2d.google.com with SMTP id h21so7788447qvb.8 for ; Mon, 08 Feb 2021 14:43:50 -0800 (PST) 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=Sxp13twEY2lKGOybNhRdEgF/BUBmqkL7BiZfsepnGCg=; b=gTpppvynYVym0vt2G3wp7n2IE1XiA+Myzel/+DZ3/5J4J4fquaeSKwrlSo9CJfBfb8 QRakdI2Q9liyD4Tp9RUwuss8VgL/aSIjTvwkntgkPJxpls+AwMXXCgAuoNADck8bPFRT erIPMM2KEuqmBPvjYNec4PunBcGaAjQwZxLlxIfFkeSNuasYfgNLYKmkQNPH8KRwtad4 fGgE8ZKNJz9hGZNEi76OT4fCoF5fiZFo6tsATd6VxYzvTqh12ceyCEA6LM1jxzErwx/6 rmxLBFik7FfrpraWk12ypVLXT5RHJmFVU5/G0l1GPJYntwgfTxcz9cvCNDuSZX+3wmIh f84Q== 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=Sxp13twEY2lKGOybNhRdEgF/BUBmqkL7BiZfsepnGCg=; b=ckuLkitrEUDfY3Pz7r2gXco8rbeh0DsA3w32AgcU/Xynsyl9x9j0G1GknVQIkWbZ/h No2THJvG6KEkVDsKBXdGJHXOWGgcTk7/iV24UrBuGVGUp+FD7K1OJTPRcFoiJySLo3d1 ZEJKZ0igbOF/J0Stsn8m4rGVTP+vDcc/BnVvqFXvIe4hxFdCGNJU9NaJNvDXpgWGPFQA e8rhSchg+uDKfiJZhwaYmApV1H26GUWAAbonyskw7P2zRWVqRKraUuPn9fQvSLcr4l1k 1qCBbEWJutTLL+5z7PP+PTCrQ20PdKFHteKwiY+Qd9nu4Zg2yJrFbR0C8GTb2b7Wsz11 oNlw== X-Gm-Message-State: AOAM530V29unWi8+fMgJXun3DJXwJ6tulCrYhjurP5nMMK4e+b4S/xn/ n01AQLx8b8zWh0ATPeHneRM0xw== X-Google-Smtp-Source: ABdhPJwcl9db0N8QJI65DIin6MS7WMUgRxG6w6GpbN94hl0dxaBp1BL+0IYUZk/I/7VAq+jWcNzzqA== X-Received: by 2002:a05:6214:76f:: with SMTP id f15mr17950717qvz.56.1612824229080; Mon, 08 Feb 2021 14:43:49 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 199sm435907qkj.9.2021.02.08.14.43.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2021 14:43:48 -0800 (PST) From: Ted Lemon Message-Id: <8AC26E8F-0AD7-435E-AE04-F106E163EC66@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_669AA32D-91C2-46F9-B512-30B29706B15C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 8 Feb 2021 17:43:47 -0500 In-Reply-To: <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> Cc: "Joel M. Halpern" , Martin Thomson , rfced-future@iab.org To: Peter Saint-Andre References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 22:43:53 -0000 --Apple-Mail=_669AA32D-91C2-46F9-B512-30B29706B15C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 8, 2021, at 4:24 PM, Peter Saint-Andre = wrote: > Earlier in the thread, Mark Nottingham said: "our documents are very > often used by developers of implementations." >=20 > It strikes me that this is the *primary* use of our documents. I=E2=80=99ve read documents like that too. We should probably do better. It=E2=80=99s not at all unusual for a document to come with so little = context that someone other than an SME implementor would have trouble = getting anything useful out of it. Which would be fine, if there were = some other document that explained what other users of the document = needed to know. Sometimes there is=E2=80=94sometimes we have operational = documents, for example. But it=E2=80=99s not uncommon for =E2=80=9Chow = this works=E2=80=9D to either be completely absent, or else only = available as a result of an SME-level survey of a bunch of documents. = The thing that=E2=80=99s missing is that if only SMEs can understand the = document, then the only way to get new SMEs is through a lineage of = existing SMEs who train them. Hopefully the reason this is a problem is = obvious. Now, whether you agree with the assertion I=E2=80=99m making here or = not, the reason I bring it up in this context is that your original = assertion, Peter, seems to substantiate the existence of unrepresented = document users. Perhaps it=E2=80=99s not our job (or the RSE=E2=80=99s) = to see to it that they are represented. However, looking back over my = checkered career as an IETF participant, there are quite a few documents = that, if I had it to do over again, I would have insisted ought to do a = better job of explaining to a new reader what the theory of operation of = the protocol was, before describing the implementation details. So I = would not object to some pushback when the RSE encounters a document = like this. The documents I have in mind are actually documents I should = have pushed back on as an AD, but so maybe the answer isn=E2=80=99t to = have the RSE fill this role, but it=E2=80=99s definitely a role that I = think someone should be filling. Bear in mind that if there=E2=80=99s an understanding that a poorly = explained protocol spec would get pushback, that=E2=80=99s going to = motivate the working group to do a better job prior to submission, so in = principle the RSE and/or ADs don't actually have to do anything other = than look stern. But the threat of pushback has to be there. --Apple-Mail=_669AA32D-91C2-46F9-B512-30B29706B15C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Feb 8, 2021, at 4:24 PM, Peter Saint-Andre <stpeter@mozilla.com>= wrote:
Earlier in = the thread, Mark Nottingham said: "our documents are very
often used by = developers of implementations."

It strikes me that this is the *primary* use of our = documents.

I=E2=80=99ve read documents like that too.

We should probably do = better.

It=E2=80= =99s not at all unusual for a document to come with so little context = that someone other than an SME implementor would have trouble getting = anything useful out of it. Which would be fine, if there were some other = document that explained what other users of the document needed to know. = Sometimes there is=E2=80=94sometimes we have operational documents, for = example. But it=E2=80=99s not uncommon for =E2=80=9Chow this works=E2=80=9D= to either be completely absent, or else only available as a result of = an SME-level survey of a bunch of documents. The thing that=E2=80=99s = missing is that if only SMEs can understand the document, then the only = way to get new SMEs is through a lineage of existing SMEs who train = them. Hopefully the reason this is a problem is obvious.

Now, whether you agree = with the assertion I=E2=80=99m making here or not, the reason I bring it = up in this context is that your original assertion, Peter, seems to = substantiate the existence of unrepresented document users. Perhaps = it=E2=80=99s not our job (or the RSE=E2=80=99s) to see to it that they = are represented. However, looking back over my checkered career as an = IETF participant, there are quite a few documents that, if I had it to = do over again, I would have insisted ought to do a better job of = explaining to a new reader what the theory of operation of the protocol = was, before describing the implementation details. So I would not object = to some pushback when the RSE encounters a document like this. The = documents I have in mind are actually documents I should have pushed = back on as an AD, but so maybe the answer isn=E2=80=99t to have the RSE = fill this role, but it=E2=80=99s definitely a role that I think someone = should be filling.

Bear in mind that if there=E2=80=99s an understanding that a = poorly explained protocol spec would get pushback, that=E2=80=99s going = to motivate the working group to do a better job prior to submission, so = in principle the RSE and/or ADs don't actually have to do anything other = than look stern. But the threat of pushback has to be there.

= --Apple-Mail=_669AA32D-91C2-46F9-B512-30B29706B15C-- From nobody Mon Feb 8 14:53:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B94E3A1696 for ; Mon, 8 Feb 2021 14:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 ZX9IvOWpJikx for ; Mon, 8 Feb 2021 14:53:14 -0800 (PST) Received: from [172.20.10.2] (115-189-133-199.mobile.spark.co.nz [115.189.133.199]) (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 D1BA63A1694 for ; Mon, 8 Feb 2021 14:53:13 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-698A3FE9-C4D3-42CF-B5B1-375A6B858880 Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Date: Tue, 9 Feb 2021 11:53:07 +1300 Message-Id: <4DAEBFA0-9732-4798-8C44-56EB472D6DDD@ietf.org> References: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> In-Reply-To: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> To: rfced-future@iab.org X-Mailer: iPad Mail (18C66) Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 22:53:16 -0000 --Apple-Mail-698A3FE9-C4D3-42CF-B5B1-375A6B858880 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =46rom the very informative discussion so far I understand why the RSE/A sho= uld be =E2=80=9Ca=E2=80=9D representative of the RFC reader community but no= t why they should be the =E2=80=9Cprimary=E2=80=9C representative. The main= reason I=E2=80=99ve heard so far is =E2=80=9Cthere=E2=80=99s a gap and they= are the natural person to fill it=E2=80=9D but from my relatively naive per= spective it seems as if the stream managers should have that role for their r= eaders because they control what is read and they need the direct feedback l= oop. What the streams won=E2=80=99t have and what the RSE/A therefore appea= rs to have is a more generic and broader overview in line with their experti= se e.g. machine readability, journal/library referencing and so on. =20 Or to put this another way, it reads as if some want the RSE/A to have a pro= duct manager role, which on the surface seems to fit but that seems to delib= erately disconnect the streams from their part in that. Have I understood t= his correctly? --=20 Jay Daley IETF Executive Director= --Apple-Mail-698A3FE9-C4D3-42CF-B5B1-375A6B858880 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=46rom the very informative d= iscussion so far I understand why the RSE/A should be =E2=80=9Ca=E2=80=9D re= presentative of the RFC reader community but not why they should be the =E2=80= =9Cprimary=E2=80=9C representative.  The main reason I=E2=80=99ve heard= so far is =E2=80=9Cthere=E2=80=99s a gap and they are the natural person to= fill it=E2=80=9D but from my relatively naive perspective it seems as if th= e stream managers should have that role for their readers because they contr= ol what is read and they need the direct feedback loop.  What the strea= ms won=E2=80=99t have and what the RSE/A therefore appears to have is a more= generic and broader overview in line with their expertise e.g. machine read= ability, journal/library referencing and so on.  

Or to put this another way, it reads as if some w= ant the RSE/A to have a product manager role, which on the surface seems to f= it but that seems to deliberately disconnect the streams from their part in t= hat.  Have I understood this correctly?

--&= nbsp;
= Jay Daley
IETF Executive Director
= --Apple-Mail-698A3FE9-C4D3-42CF-B5B1-375A6B858880-- From nobody Mon Feb 8 14:56:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1347A3A169A for ; Mon, 8 Feb 2021 14:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwoMsK9zJpeK for ; Mon, 8 Feb 2021 14:56:11 -0800 (PST) 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 314453A1698 for ; Mon, 8 Feb 2021 14:56:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19C53BE80; Mon, 8 Feb 2021 22:56:09 +0000 (GMT) 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 BzA0eNxSMUTe; Mon, 8 Feb 2021 22:56:07 +0000 (GMT) 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 315C7BE7C; Mon, 8 Feb 2021 22:56:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1612824962; bh=uirper3V1tdeRQGHbGXq/2NuKfElYOqL3X82GRCm+Z8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Crq2S5pDXENWSe869eojJUeM8QtkdDJrchq1PYGYChkunvnHId8cj3BhXEN+TIlEV Fcc9Vs21rK2dDgPROgXnSonGRbHXm2hrxyVt+q+s3v0piRymiDUHUxs+wBq4cod+od WJcs6kremDB4+2jmzVkYLVCBAV41HUPshTC7qukc= To: Peter Saint-Andre , Brian E Carpenter , rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> <58e7d15a-b305-50b7-01c4-a2a03e2bf992@gmail.com> <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> From: Stephen Farrell Message-ID: Date: Mon, 8 Feb 2021 22:56:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D4levL0ZmSWHdcTvrGsb9gpO5EGrarSWF" Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 22:56:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D4levL0ZmSWHdcTvrGsb9gpO5EGrarSWF Content-Type: multipart/mixed; boundary="8juIWkT4KquIOefFb6A0MiRsggGb0AohG"; protected-headers="v1" From: Stephen Farrell To: Peter Saint-Andre , Brian E Carpenter , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> <58e7d15a-b305-50b7-01c4-a2a03e2bf992@gmail.com> <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> In-Reply-To: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> --8juIWkT4KquIOefFb6A0MiRsggGb0AohG Content-Type: multipart/mixed; boundary="------------338686F6D1463149C67E9AF5" Content-Language: en-US This is a multi-part message in MIME format. --------------338686F6D1463149C67E9AF5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 08/02/2021 22:24, Peter Saint-Andre wrote: > Although I can't object to a big tent, I think it would be helpful > for us to think clearly about these different communities of interest > so that we can prioritize their respective needs. I think I agree with you both - that developers and then those deploying are our primary audience and that there are others too, as Brian said. One thing though: IMO when we say "developers" there, I interpret that to not only mean developers following today's fashions, but also those who might follow future fashions, to the extent those be reasonably considered. To put that another way, I think RFCs should probably never be exactly what any one developer wants at a given moment in time, as RFCs need to be more generic and longer-lasting. Cheers, S. --------------338686F6D1463149C67E9AF5 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------338686F6D1463149C67E9AF5-- --8juIWkT4KquIOefFb6A0MiRsggGb0AohG-- --D4levL0ZmSWHdcTvrGsb9gpO5EGrarSWF Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAhwYEFAwAAAAAACgkQWrL68XsXK+oe exAArFiXc+LD8SxX6T78WU9aN71U9bkNXssmoQv9xLMvgdzumbC/L/tD8J2O2hDURNf3T8VIWd98 tdOPKkC+dysS/8DGkPfFT6mAyTfO2OUa7i7ERiUArB504jbFWp7WAeSDESU6c9sUjrImjLf+JBHI SqujbZwMh0FVa74Z95mVK4TJ3vsGuP+5tpA2AmJDzkVwX3UjkCq4rNWJiVH2SZyiCQzuM+WVQRUw hnj4jqu6lMHyKuAqk8QwQ0kiwXGx2vp2JKdpKw4NTfTv+qyoYy1AT4YR+bKoftpmD4RpiOkqzo5P zx9kSHKj33gTicnyxb1oVPS72rz3Ff27gcn3qRh+wLoAZ7+aptkgXHodVrejp54KovpuwhXini2T Fwi/5sTkL7EO+GmrKbRsfH+IJUnK5CQ5t9GopkM4YW5HYJ0P1IIQBAIC9L/HxhAduLi9bNsoYh1B 1/gUCQWGyg/ERUTVGFK2rZUheIGz0gMnhfcL7fJjw1/dxN8yJXji1s/3pTCxz+7FL1iOWPf6TIls wZ8IlYMElsjJ26EUrAN933JBeb90541qpbXQBPPhdsEa3e0uDdDcEq6zEAn9L32WGYEZDLGlhKhG s9MHjnw2LNNnjaG5nY/195t2FnSJjTWUllzI0NEg/zCtE8FBFDTvGsyloeb0x8UIyQtl5bZ0D8Wo w6k= =JHu/ -----END PGP SIGNATURE----- --D4levL0ZmSWHdcTvrGsb9gpO5EGrarSWF-- From nobody Mon Feb 8 14:57:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2953A169D; Mon, 8 Feb 2021 14:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6KuFYbXhxUs; Mon, 8 Feb 2021 14:57:51 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E2A3A169B; Mon, 8 Feb 2021 14:57:50 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 118Mvmhe027758; Mon, 8 Feb 2021 22:57:48 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2FDF02203B; Mon, 8 Feb 2021 22:57:48 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 1B0552203A; Mon, 8 Feb 2021 22:57:48 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.213.140]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 118MvlIi014251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Feb 2021 22:57:47 GMT Reply-To: From: "Adrian Farrel" To: "'Jay Daley'" , References: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> <4DAEBFA0-9732-4798-8C44-56EB472D6DDD@ietf.org> In-Reply-To: <4DAEBFA0-9732-4798-8C44-56EB472D6DDD@ietf.org> Date: Mon, 8 Feb 2021 22:57:46 -0000 Organization: Old Dog Consulting Message-ID: <018101d6fe6d$d1758a80$74609f80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0182_01D6FE6D.D175D8A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH2pNjbBcOQBOR0VgoOs8TZVbERwQFABO8LqgWQ/8A= Content-Language: en-gb X-Originating-IP: 87.112.213.140 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-25942.003 X-TM-AS-Result: No--24.184-10.0-31-10 X-imss-scan-details: No--24.184-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--24.184200-10.000000 X-TMASE-MatchedRID: 9vvqFUF7IWnxIbpQ8BhdbIeAntdoMxBaqROwUsrCyCKA6UrbM3j3qXl7 JxCcS+ZhR7E/wXWd4eZfqqgUkvHrg4dzzepNGjtPLIrMljt3adtGW8e3M1fRcyNBWGZQkFR8oN5 QQkSt0Bn+Tr2Pz7OOKSuE81J1jT84J4x82tFuABhllJ+NC2avSTr+rETeFUOvO7BMOlfyKLSrP7 SdkORsuiANBAZm6YQ5YvdKTvDNVGZftlZ0AGvdlcqquP3qhQpq9avse85ISVotferJ/d7Abz9T/ nDS5tm4aJj2K3Ikmli3s+xj36/z3kB40z3xsh6MOVGFTTw28Yc2vbWaKPnQ2w+XMlIFkG/VWZqt it4kVMJ+Mj7k2lLYb1nX1DwGZpZHYhOI1A6oX99V1zhVw8duYg5k1ea+clp6xWwvfxzKj7s9o/z fJjIK5DuQFCdOBXk/qRMErq1gSlFq0QqhYus7ZP0peXGEEBlvDvKSaIxu6kpXG3yI9k2vbIfNL7 D/HMEOKHWHnxIi33mD28NNt7xCyCkBeV/1d1sZ30kDaWZBE1TQTttTsZbKLwcR01yaR+FBXR/hn +4QIq0SK6JzGSKc0tAAI+C3I6/FZT+TG5UY4x7uQhjG5o7plP98fIf4wIXlBnREgaSmvMIsWVdl 3YcDsI8lwu8j52eIFABeLgZr0ZEfE8yM4pjsD4MbH85DUZXyAzmRhRrMoRWw7M6dyuYKg47dS6z vwQvCLkIkC/hFTJwH1fvX+MfhfZCRwIg5gogroE2i8mlOkGU= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 22:57:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0182_01D6FE6D.D175D8A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Jay, =20 It may be as simple as the distinction between content and form. =20 The stream manager knows (or should know) how the content can be useful = to the consumers. But it seems unlikely that the stream manager = understands the ways in which the content (i.e., the documents) will be = stored, accessed, read, and otherwise used by a disparate community. =20 Cheers, Adrian =20 From: Rfced-future On Behalf Of Jay Daley Sent: 08 February 2021 22:53 To: rfced-future@iab.org Subject: Re: [Rfced-future] Communities and representation (was Re: The = voices of stakeholders) =20 >From the very informative discussion so far I understand why the RSE/A = should be =E2=80=9Ca=E2=80=9D representative of the RFC reader community = but not why they should be the =E2=80=9Cprimary=E2=80=9C representative. = The main reason I=E2=80=99ve heard so far is =E2=80=9Cthere=E2=80=99s a = gap and they are the natural person to fill it=E2=80=9D but from my = relatively naive perspective it seems as if the stream managers should = have that role for their readers because they control what is read and = they need the direct feedback loop. What the streams won=E2=80=99t have = and what the RSE/A therefore appears to have is a more generic and = broader overview in line with their expertise e.g. machine readability, = journal/library referencing and so on. =20 =20 Or to put this another way, it reads as if some want the RSE/A to have a = product manager role, which on the surface seems to fit but that seems = to deliberately disconnect the streams from their part in that. Have I = understood this correctly? --=20 Jay Daley IETF Executive Director ------=_NextPart_000_0182_01D6FE6D.D175D8A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Jay,

 

It may be = as simple as the distinction between content and = form.

 

The stream = manager knows (or should know) how the content can be useful to the = consumers. But it seems unlikely that the stream manager understands the = ways in which the content (i.e., the documents) will be stored, = accessed, read, and otherwise used by a disparate = community.

 

Cheers,

Adrian

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of Jay = Daley
Sent: 08 February 2021 22:53
To: = rfced-future@iab.org
Subject: Re: [Rfced-future] Communities = and representation (was Re: The voices of = stakeholders)

 

From = the very informative discussion so far I understand why the RSE/A should = be =E2=80=9Ca=E2=80=9D representative of the RFC reader community but = not why they should be the =E2=80=9Cprimary=E2=80=9C representative. =  The main reason I=E2=80=99ve heard so far is = =E2=80=9Cthere=E2=80=99s a gap and they are the natural person to fill = it=E2=80=9D but from my relatively naive perspective it seems as if the = stream managers should have that role for their readers because they = control what is read and they need the direct feedback loop.  What = the streams won=E2=80=99t have and what the RSE/A therefore appears to = have is a more generic and broader overview in line with their expertise = e.g. machine readability, journal/library referencing and so on. =  

 

Or to put this another way, it reads as = if some want the RSE/A to have a product manager role, which on the = surface seems to fit but that seems to deliberately disconnect the = streams from their part in that.  Have I understood this = correctly?

-- 

Jay Daley
IETF Executive = Director

------=_NextPart_000_0182_01D6FE6D.D175D8A0-- From nobody Mon Feb 8 14:59:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10B53A169B for ; Mon, 8 Feb 2021 14:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFkQU80Xo1dG; Mon, 8 Feb 2021 14:58:59 -0800 (PST) Received: from [172.20.10.2] (115-189-133-199.mobile.spark.co.nz [115.189.133.199]) (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 65A623A169A; Mon, 8 Feb 2021 14:58:58 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-FE1FE5BA-AD93-4915-A947-2B5647D90B97 Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Date: Tue, 9 Feb 2021 11:58:54 +1300 Message-Id: <4FCE7DCF-4492-4FEA-9327-595265DDFAF7@ietf.org> References: <018101d6fe6d$d1758a80$74609f80$@olddog.co.uk> Cc: rfced-future@iab.org In-Reply-To: <018101d6fe6d$d1758a80$74609f80$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: iPad Mail (18C66) Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 22:59:01 -0000 --Apple-Mail-FE1FE5BA-AD93-4915-A947-2B5647D90B97 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 9/02/2021, at 11:57 AM, Adrian Farrel wrote: >=20 > =EF=BB=BF > Jay, > =20 > It may be as simple as the distinction between content and form. > =20 > The stream manager knows (or should know) how the content can be useful to= the consumers. But it seems unlikely that the stream manager understands th= e ways in which the content (i.e., the documents) will be stored, accessed, r= ead, and otherwise used by a disparate community. I like that distinction. Thanks. --=20 Jay Daley IETF Executive Director > =20 > Cheers, > Adrian > =20 > From: Rfced-future On Behalf Of Jay Daley > Sent: 08 February 2021 22:53 > To: rfced-future@iab.org > Subject: Re: [Rfced-future] Communities and representation (was Re: The vo= ices of stakeholders) > =20 > =46rom the very informative discussion so far I understand why the RSE/A s= hould be =E2=80=9Ca=E2=80=9D representative of the RFC reader community but n= ot why they should be the =E2=80=9Cprimary=E2=80=9C representative. The mai= n reason I=E2=80=99ve heard so far is =E2=80=9Cthere=E2=80=99s a gap and the= y are the natural person to fill it=E2=80=9D but from my relatively naive pe= rspective it seems as if the stream managers should have that role for their= readers because they control what is read and they need the direct feedback= loop. What the streams won=E2=80=99t have and what the RSE/A therefore app= ears to have is a more generic and broader overview in line with their exper= tise e.g. machine readability, journal/library referencing and so on. =20 > =20 > Or to put this another way, it reads as if some want the RSE/A to have a p= roduct manager role, which on the surface seems to fit but that seems to del= iberately disconnect the streams from their part in that. Have I understood= this correctly? >=20 > --=20 > Jay Daley > IETF Executive Director > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail-FE1FE5BA-AD93-4915-A947-2B5647D90B97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 9/02/2021, at 11:57 AM, Adrian Farrel <adrian@olddog.co.uk> w= rote:

=EF= =BB=BF=

Jay,

&nb= sp;

It may be as simple as the distinction between content and form.

 

The stream manager knows (or should know) how th= e content can be useful to the consumers. But it seems unlikely that the str= eam manager understands the ways in which the content (i.e., the documents) w= ill be stored, accessed, read, and otherwise used by a disparate community.<= /span>


I like that distinction. &= nbsp;Thanks.

-- 
Jay Daley
IETF Executive Director<= /span>

 

Cheers,

Adrian

 

From: Rfced-future <rfced-future-= bounces@iab.org> On Behalf Of Jay Daley
Sent: 08 Februar= y 2021 22:53
To: rfced-future@iab.org
Subject: Re: [Rfce= d-future] Communities and representation (was Re: The voices of stakeholders= )

 <= /p>

=46rom the very informative discussion so far= I understand why the RSE/A should be =E2=80=9Ca=E2=80=9D representative of t= he RFC reader community but not why they should be the =E2=80=9Cprimary=E2=80= =9C representative.  The main reason I=E2=80=99ve heard so far is =E2=80= =9Cthere=E2=80=99s a gap and they are the natural person to fill it=E2=80=9D= but from my relatively naive perspective it seems as if the stream managers= should have that role for their readers because they control what is read a= nd they need the direct feedback loop.  What the streams won=E2=80=99t h= ave and what the RSE/A therefore appears to have is a more generic and broad= er overview in line with their expertise e.g. machine readability, journal/l= ibrary referencing and so on.  

 

Or to put this another way, it reads as if some want the R= SE/A to have a product manager role, which on the surface seems to fit but t= hat seems to deliberately disconnect the streams from their part in that. &n= bsp;Have I understood this correctly?

-- 

Jay Daley
IETF Executive Director

=
--
Rfced-future mailing list=
Rfced-future@iab.org
https://www.iab.org/mailman/l= istinfo/rfced-future
= --Apple-Mail-FE1FE5BA-AD93-4915-A947-2B5647D90B97-- From nobody Mon Feb 8 15:05:45 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76063A16B2 for ; Mon, 8 Feb 2021 15:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 zvh09ztPuhur for ; Mon, 8 Feb 2021 15:05:41 -0800 (PST) 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 E73603A16B3 for ; Mon, 8 Feb 2021 15:05:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 876E9BE80; Mon, 8 Feb 2021 23:05:35 +0000 (GMT) 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 KCUPfQakY6YL; Mon, 8 Feb 2021 23:05:34 +0000 (GMT) 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 74AB3BE7C; Mon, 8 Feb 2021 23:05:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1612825533; bh=jHbrNjOpc/VB4bcutNp7TxbBL5cTu6Be3do/xOmvrgs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kQwgTtyL+CpPkYvWyI3j8Kll9nUneoj9q1wpj/VcHXxUhn1YMJ0OdrotwMOP5WW/H o42JJkmuTEJqrLnV0PA2bHVnmKJKeq427PdxKYJUlm/ZA7pNinbVK6j6FGR+gEdP4a Sij9dk0LJuHOu96uJVE1b9CZQhwexMIAZSMwYbFg= To: Jay Daley , rfced-future@iab.org References: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> <4DAEBFA0-9732-4798-8C44-56EB472D6DDD@ietf.org> From: Stephen Farrell Message-ID: <6f7b6f92-ea14-9fa7-8962-f9734ff0ae72@cs.tcd.ie> Date: Mon, 8 Feb 2021 23:05:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <4DAEBFA0-9732-4798-8C44-56EB472D6DDD@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kiFOgU3C3C39Wi1gAf9pNfQ76KKKKfdwu" Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 23:05:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kiFOgU3C3C39Wi1gAf9pNfQ76KKKKfdwu Content-Type: multipart/mixed; boundary="oHPPAMEGUTVY0Z5LZZOxOcY75P3J6i6Xs"; protected-headers="v1" From: Stephen Farrell To: Jay Daley , rfced-future@iab.org Message-ID: <6f7b6f92-ea14-9fa7-8962-f9734ff0ae72@cs.tcd.ie> Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) References: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> <4DAEBFA0-9732-4798-8C44-56EB472D6DDD@ietf.org> In-Reply-To: <4DAEBFA0-9732-4798-8C44-56EB472D6DDD@ietf.org> --oHPPAMEGUTVY0Z5LZZOxOcY75P3J6i6Xs Content-Type: multipart/mixed; boundary="------------6747097CC4D3BB3B39E827E4" Content-Language: en-US This is a multi-part message in MIME format. --------------6747097CC4D3BB3B39E827E4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 08/02/2021 22:53, Jay Daley wrote: > from my relatively naive perspective it seems as if the stream > managers should have that role for their readers because they control > what is read and they need the direct feedback loop I don't disagree, but I would note that the intricacies of RFCs are not really the primary job of the stream managers - maybe the ISE is closest, but the IETF, IAB and IRTF stream managers have I think mostly so far always been people who are pretty busy elsewhere. So I think there're also pragmatic reasons to plump for the RSE as this "gap filler" - if one sees this as related to the question as to why/how the series has (so far) been so long-lived but has remained useful. Cheers, S. --------------6747097CC4D3BB3B39E827E4 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------6747097CC4D3BB3B39E827E4-- --oHPPAMEGUTVY0Z5LZZOxOcY75P3J6i6Xs-- --kiFOgU3C3C39Wi1gAf9pNfQ76KKKKfdwu Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAhw7wFAwAAAAAACgkQWrL68XsXK+r1 +hAAnj/MXH/kFiQimUfqXZYMdFFVoDwZx5E2Ft6YIaIhHlxiIOEgz9B3rGqZRwSwe8cCwKiRg6Sz aH69l9Xuvr4zDel/NBhOyudQucrxFiFYLEc+umHIULHvoSFs1ypSLUMQzdejfOpd5SsSfQeOEGbl l0a97OCUgGo9PEyggRRzpdWqm5O0U3NoQ7RmSdCJ6gM6PF8QXwxSTRqwpVWgsO+z8beeANDX6SDV 0C5jUmQhwoVTQqJDZz8fGaB1KW8tLjjiWSA52d6fdQ7GF5Fe5cgss9YZBC4YgWdmWWIhoWikkyNr esYdQAmOKJ8GPkz0yxq2XaNZNdyi/RCVHcd0+1oeHXhVTPFole0Vh4qaZfzaLipiHc8Sw6AAjFQZ kYH4SNrPIWG16eJknR9ty0Of4t4h1t/0zsGmCckC0RBUoYxS4b4/6Cy1vv9YF858GHrRqTbo6R1+ On87lIGMma6S2zK8O7eHki3vYLVWMRItUGdIyM3eK+7EhMDQPI5RtdVkIXmABFqnhTY30Bg+W31A eV9bryZbiSjoaX3KgfrJAxqR341+9d+Z+dgc1tLt6VFXSVu7DiEsVO7jbyqo1kx2y1ECO8iw9vIh nI3peBr/Ja/PJHb4gdqrIexeF2rZZN9tvS4Ysg0No7vcu9gtoVYD8mGfaMh1/fyt1w4O4UFbxrhj Yok= =QyL5 -----END PGP SIGNATURE----- --kiFOgU3C3C39Wi1gAf9pNfQ76KKKKfdwu-- From nobody Mon Feb 8 15:07:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD9A3A16B5 for ; Mon, 8 Feb 2021 15:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI4MT9ND1Eot for ; Mon, 8 Feb 2021 15:07:11 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9476B3A16B4 for ; Mon, 8 Feb 2021 15:07:11 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id e133so16807799iof.8 for ; Mon, 08 Feb 2021 15:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=N6qXd2ChC7Cx+6AwOPIClpSW4hcI/o46LfNGqQAh01E=; b=HfpIigughYQwKXoNnb7CPh7DWV9ibSFug/IkhgMtQWN/Al8Uw2hoJt9QgpRTsxUZHL mmAqYeuxQX8C2OLTz87cph/sXAHDRYQiG+HhQKWQvwcV7sh3uu0+hxp0Qr//ZF3PG5eb ObVJyIrliy1DQR01HO1UFt6Bsab/A/0wxxpYA= 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=N6qXd2ChC7Cx+6AwOPIClpSW4hcI/o46LfNGqQAh01E=; b=LL646b45g1tUVWHsdH1wO6wiJ4b+JndZDHEh1acJ4hP3ziRAZUgSqj7hW2993Hgofp NAuG+isTB0o09U6vPEzWGmrK12F//CjUiwcotXh5axBGoky4QkioeGCj2gbEhIbfAqa6 j41H4fzX7yYuMw0UcBAkSSu/8txWl0QSnGmsFh3jjlf06G8KR6t/FqxtEusKhSCeZiAv o9YdB09kVXqAy7QtQw3Xr7Y39dGJ9A9p79wR1RW/XN7CdHjBp2xqJJnJMlr6oEN4MJxk 3fzD2neej3FhYauDpR31aXxEloskBfT23j0Xbrw3XIbD16XLcZybRyXxY2QRcbWYq/Jl jWZg== X-Gm-Message-State: AOAM533DJMG8NsBjpgyntweIgY7LOW7VC5z8b40QRT26+0xloNeijjCi DUMhwK8dZejNfwu+PTXRn7EUWg== X-Google-Smtp-Source: ABdhPJwJUvZ0396IKlurzryl0qY5+r3cTvN7nMMK9Hl4TgRO/uIxJvj1HVJFz8zoaTkOUfcubWDjOg== X-Received: by 2002:a05:6638:1909:: with SMTP id p9mr20167075jal.53.1612825630604; Mon, 08 Feb 2021 15:07:10 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id y8sm9467970ili.71.2021.02.08.15.07.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 15:07:10 -0800 (PST) To: adrian@olddog.co.uk, rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> <016601d6fe65$b2a61870$17f24950$@olddog.co.uk> From: Peter Saint-Andre Message-ID: <79805991-74cc-4f14-256b-cdeaa7ed1389@mozilla.com> Date: Mon, 8 Feb 2021 16:07:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <016601d6fe65$b2a61870$17f24950$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 23:07:14 -0000 On 2/8/21 2:59 PM, Adrian Farrel wrote: > Hi Peter, > > At the risk of being accused of pedantry... > >> Earlier in the thread, Mark Nottingham said: "our documents are very >> often used by developers of implementations." >> >> It strikes me that this is the *primary* use of our documents. >> >> Although this perspective might be seen as simplistic, I've always felt >> that my core task as an RFC author is to help design a sensible protocol >> and document it as clearly and accurately as possible so that engineers >> can write interoperable code. > > Tell us about RFC 4417. Good old 4417. Documentation of an IAB messaging workshop, cited by no other RFCs, and perhaps deservedly disappeared down the memory hole. > And RFC 6702. We do need to document our own procedures, don't we? Proving the rule (in the original sense), this is more documentation, albeit internally focused. > RFC 7259 gives an interesting slant. A cute experiment, never widely implemented. > Etc. 😊 > > Perhaps we also need to be a bit careful when we say, "use of *our* documents." Who are the "we" that we refer to? Those of us writing the documents, commenting on them, implementing them, etc. > Anyway, the point here is not that you and Brian are wrong about the primary uses, but that we don't want to sacrifice other uses accidentally along the way. For sure. I'm not suggesting that we sacrifice anyone's interests, only first of all that we understand them. :-) However, I would suggest that at some point we will need to weight them because not everyone's interests can be the top priority. Peter From nobody Mon Feb 8 15:20:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39103A16E1 for ; Mon, 8 Feb 2021 15:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFXYmqNS9dKj; Mon, 8 Feb 2021 15:20:56 -0800 (PST) Received: from [172.20.10.2] (115-189-133-199.mobile.spark.co.nz [115.189.133.199]) (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 E17AC3A16D7; Mon, 8 Feb 2021 15:20:55 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-0DEB7BE4-8975-4EA2-8A3A-7BD7EC1F6658 Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Date: Tue, 9 Feb 2021 12:20:52 +1300 Message-Id: <5619B12A-BD02-4116-97D2-EB1FCAC62BB7@ietf.org> References: <6f7b6f92-ea14-9fa7-8962-f9734ff0ae72@cs.tcd.ie> Cc: rfced-future@iab.org In-Reply-To: <6f7b6f92-ea14-9fa7-8962-f9734ff0ae72@cs.tcd.ie> To: Stephen Farrell X-Mailer: iPad Mail (18C66) Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 23:20:58 -0000 --Apple-Mail-0DEB7BE4-8975-4EA2-8A3A-7BD7EC1F6658 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 9/02/2021, at 12:05 PM, Stephen Farrell wro= te: >=20 > =EF=BB=BF > Hiya, >=20 >> On 08/02/2021 22:53, Jay Daley wrote: >> from my relatively naive perspective it seems as if the stream >> managers should have that role for their readers because they control >> what is read and they need the direct feedback loop > I don't disagree, but I would note that the intricacies of > RFCs are not really the primary job of the stream managers - > maybe the ISE is closest, but the IETF, IAB and IRTF stream > managers have I think mostly so far always been people who > are pretty busy elsewhere. >=20 > So I think there're also pragmatic reasons to plump for the > RSE as this "gap filler" - if one sees this as related to > the question as to why/how the series has (so far) been so > long-lived but has remained useful. Thinking aloud now, but I wonder if any thought has been given to a new stru= cture designed to create that feedback loop more directly. For example, som= ething as simple as a feedback form accessible from each RFC page would be a= good start. I imagine it would be used most when a new RFC is published. Jay --=20 Jay Daley IETF Executive Director >=20 > Cheers, > S. > --Apple-Mail-0DEB7BE4-8975-4EA2-8A3A-7BD7EC1F6658 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 9/02/2021, at 12:05 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie= > wrote:

=EF=BB=BF
Hiya,

= On 08/02/2021 22:53, Jay Daley wrote:
from my relatively naive perspective it seems as if the stream
managers should have that role= for their readers because they control
what is read and they need the direct feedback loop
I don't disagree, but I would note that the intricac= ies of
RFCs are not really the primary job of the stream man= agers -
maybe the ISE is closest, but the IETF, IAB and IRTF= stream
managers have I think mostly so far always been peop= le who
are pretty busy elsewhere.
So I think there're also pragmatic reasons to plump for theRSE as this "gap filler" - if one sees this as related to
<= span>the question as to why/how the series has (so far) been so
long-lived but has remained useful.
Thinking aloud now, but I wonder if any thought has been given to a n= ew structure designed to create that feedback loop more directly.  For e= xample, something as simple as a feedback form accessible from each RFC page= would be a good start.  I imagine it would be used most when a new RFC= is published.

Jay

--&= nbsp;
= Jay Daley
IETF Executive Director



Cheers,
= S.
<OpenPGP_0x5AB2FAF17B172BEA.asc>
= --Apple-Mail-0DEB7BE4-8975-4EA2-8A3A-7BD7EC1F6658-- From nobody Mon Feb 8 15:21:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7203A16E1 for ; Mon, 8 Feb 2021 15:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 NVooXAHJmbps for ; Mon, 8 Feb 2021 15:21:09 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04343A16DF for ; Mon, 8 Feb 2021 15:21:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DZMTd3PVCz6G913; Mon, 8 Feb 2021 15:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612826469; bh=codtfxI+NCssdSe0nTpEEFQzH/px68bKVLxbjVogRak=; h=Subject:To:References:From:Date:In-Reply-To:From; b=N3J3upD6RSJ4h+c2mVEbDAKhpoZ4t7bU8x8TVGDFOrQ9nK79++wewH383LIDtwHhU IZ/aKxvMfIXI3wyr/QrS8Qn72VWcI4ONHmET6d0oSo+ottxLGUWO9f/Hx2PasSRBBE y4h5hFvuRCtX0JQHMaUU9XQzMXTC14NladtvJR/s= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DZMTc5vYKz6G8Vq; Mon, 8 Feb 2021 15:21:08 -0800 (PST) To: Peter Saint-Andre , rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> <58e7d15a-b305-50b7-01c4-a2a03e2bf992@gmail.com> <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> From: "Joel M. Halpern" Message-ID: <4b3dda56-bbb9-6cff-3e3d-bfc9540e4af2@joelhalpern.com> Date: Mon, 8 Feb 2021 18:21:07 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Feb 2021 23:21:11 -0000 Peter, that does not match my understanding or observations; many operators read our RFCs, and attempt to get what they want from vendors (as they should). How effective they are at it varies. Also, other SDOs use our RFCs to build solution profiles that are used by Operators. Product line managers read (or at least try to decipher) our RFCs to try to drive what will go into products. And the list goes on. While implementors are an important constituency, they are by no means the only one. And I doubt that they constitute even 50% of the readership. Yours, Joel On 2/8/2021 5:24 PM, Peter Saint-Andre wrote: > On 2/8/21 2:37 PM, Brian E Carpenter wrote: >> On 09-Feb-21 10:24, Peter Saint-Andre wrote: >>> [ no hats ] >>> >>> On 2/7/21 5:23 PM, Joel M. Halpern wrote: >>>> I do not think that a technical publication expert can inherently >>>> represent the broad range of our external communities. >>> >>> There might be value in trying to describe this "broad range". (Pardon >>> me if that's been done already.) >>> >>> Earlier in the thread, Mark Nottingham said: "our documents are very >>> often used by developers of implementations." >>> >>> It strikes me that this is the *primary* use of our documents. >> >> I'd put that equal first with use by operators. In fact, I suspect that >> operators outnumber developers. > > Likely so. However, operators offer services based on the code that > developers write, so I think of these as one bundle. > >> Otherwise, you're correct (but add educators and researchers). > > See my comment below about people wouldn't care a whit about the RFC > series if billions of developers and operators didn't have running code. > >> However >> I think we want all of them inside the big tent, don't we? > > Although I can't object to a big tent, I think it would be helpful for > us to think clearly about these different communities of interest so > that we can prioritize their respective needs. > > Peter > From nobody Mon Feb 8 16:13:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FF33A1724 for ; Mon, 8 Feb 2021 16:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6NphdWCw-MM for ; Mon, 8 Feb 2021 16:13:06 -0800 (PST) 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 78CB33A1715 for ; Mon, 8 Feb 2021 16:13:06 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id e15so11760646qte.9 for ; Mon, 08 Feb 2021 16:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=TSNnc9OvclMPcjKvyrY/O+rFRKljvJNfsXnJ/XHt1ds=; b=Lbsu7PcJ94Dp2fdB8qxp+TlQEpBQR2YW5VdPLn6kmubkfGgmkYkmDkhPkMGIyC9vO+ b5OAcxWCE7E7EBR/gM/jdgrS1ijsihPgJOAhijNTNj7biDiK7psxSFbckdeuDhaEUeAH UdvhTigpy+xSm1TW9EvFzCKYRgK4kGWjva5Gkcgp4fiIlMk8JPry8LMk8TPXbXkRVrGy ZtGPL8cv8VW40HW+dKpFl5oLIyYrpEDPqwhxkP4G81DBF+c9MGHvhm/gukHUNBiwwV5V uJUpbrYFyUmruhUjsMfDh/ZnRpb7uQHLQOo8pXQjnsh1+Z/XeEswPf0JxVCUeYy6nWLa YD1g== 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=TSNnc9OvclMPcjKvyrY/O+rFRKljvJNfsXnJ/XHt1ds=; b=dWIogQff4rpEIQ5SS6nZbG4mwyKEbpd5IcliuyHA7+tjtgeJw6rldc5u8ZR7bp3he/ /XifGaK3Pq/w6HQ0zYyaBinw/UWqTEVeRtxYgTNuWY6xFKo5ScKIGskVFyWuUFlHEo2v duHTGc3VK7zamDldpwd1L61ewzxLvG+Rym53Vwn5icA0r/Qneuo26dsWI1q373YPLq49 vWHQQWFseuTDy2i0+jQRH0ySna8c0486yXaJh3R5Z91bX5hd0h4skBZdvFlvsZBgpuUt sWtsNi41o07PXYCI5mKDPPSyXUxdCUTSdhdCGXOhCxGa/gYOyscW+U8pGexlLyAN5Ppe 6a8A== X-Gm-Message-State: AOAM532nIPSb5IErjPwnAwWBgL9EvXFnTYuQsjniaUoGQLGVuNpmrKsN uApFH78hz4xpdRQ1KIAUB5CTw0Sw1OAr+q1J X-Google-Smtp-Source: ABdhPJz4MC748TZ2X8vLYHN3GwDbPKNW8l0GYCR0FpOUu96lVxyJUwM/5cneQGqSogemAhoM7RvePQ== X-Received: by 2002:a05:622a:3ca:: with SMTP id k10mr17957792qtx.270.1612829583772; Mon, 08 Feb 2021 16:13:03 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id n82sm3333704qkn.114.2021.02.08.16.13.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 16:13:02 -0800 (PST) To: rfced-future@iab.org References: <6f7b6f92-ea14-9fa7-8962-f9734ff0ae72@cs.tcd.ie> <5619B12A-BD02-4116-97D2-EB1FCAC62BB7@ietf.org> From: Michael StJohns Message-ID: <1132f0e2-7cb1-981e-e2e6-62d461f61146@nthpermutation.com> Date: Mon, 8 Feb 2021 19:13:01 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <5619B12A-BD02-4116-97D2-EB1FCAC62BB7@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 00:13:08 -0000 On 2/8/2021 6:20 PM, Jay Daley wrote: > >> On 9/02/2021, at 12:05 PM, Stephen Farrell >> wrote: >> >>  >> Hiya, >> >> On 08/02/2021 22:53, Jay Daley wrote: >>> from my relatively naive perspective it seems as if the stream >>> managers should have that role for their readers because they control >>> what is read and they need the direct feedback loop >> I don't disagree, but I would note that the intricacies of >> RFCs are not really the primary job of the stream managers - >> maybe the ISE is closest, but the IETF, IAB and IRTF stream >> managers have I think mostly so far always been people who >> are pretty busy elsewhere. >> >> So I think there're also pragmatic reasons to plump for the >> RSE as this "gap filler" - if one sees this as related to >> the question as to why/how the series has (so far) been so >> long-lived but has remained useful. > > Thinking aloud now, but I wonder if any thought has been given to a > new structure designed to create that feedback loop more directly. >  For example, something as simple as a feedback form accessible from > each RFC page would be a good start.  I imagine it would be used most > when a new RFC is published. > > Jay Surveys are useful when tightly targeted and there's an immediate use of their outputs.  In the case of just published RFC's, that use may be years or decades in the future when the next version of the document starts to wend its way through the IETF.   Every question you might ask on the survey would have hopefully been asked during the documents development or during the approval process. So - I can't imagine this tool to be very useful.  Or am I misguessing what types of questions you had in mind asking? Mike From nobody Mon Feb 8 16:52:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE42A3A173E for ; Mon, 8 Feb 2021 16:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IysyAaOLxoqS for ; Mon, 8 Feb 2021 16:52:55 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974B33A1741 for ; Mon, 8 Feb 2021 16:52:55 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id e9so652810pjj.0 for ; Mon, 08 Feb 2021 16:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Un4lUgwA2XM6smcc1z6D3jHbhROY+AE4UwkCFe5bfX4=; b=TLRZ66nqWIed4FzIGthSYdGaHILO/zjRA7sHwFbLZ4EKQDbORIIvP+ngR3kyE0jOJ6 UbarXYq7YiEJl2ThaRedEzkUdT4C3Z2a1wWdSFhEsDhDK82UDf0i7VXJ0dlKGYk8S4oS alGVWBI21ys4P9laH3zCejL4gI/0xIMJmrUL2kvNk47EDTRCO/N2hTc83+wKwXBfkexB J5ulMkysu2s4BwdpcWsQQ/Prdm0U5dEJc9wQKaCDu+vy2pZUPCe598jBpqxglNyCGNaO zFKeyEu8jkROQH6uMVj7NAGOe0TYHFjYJtSeJJS8BqqRTuN8z4Cein89Ogi1tgZP+N5d uA/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=Un4lUgwA2XM6smcc1z6D3jHbhROY+AE4UwkCFe5bfX4=; b=maHv3qbI0S8BqmpU4/HgrFjpGlAcMnXSwmkS21XMwUtgTG19b4w4CShSOPkTMHaQnt BZ8J8gdlktBlR+Ymo322x0E3xupv9u6OYrTt3T7esnm/w1ZCqvITm0lu6LMsKp8paAcV pDQWxC3JdALMrwYRtU5bSRikqAJbid3mbib81va7LOm7nqFNMR/ZMWH1PCxH4zN5Jw0h xn+ZEHbPvZfBPfidtw1neRQwrZ6ifa3bzNLKvNksSnij1UZocdUZ7dYIl9tIF3/OegVO xvlG9RugtZ/4umJH3d2TufdAvVeXC33Bi7jz5Pwv0BSDAG4GFq2NtnUo+4pdmvz7BZeq DF0g== X-Gm-Message-State: AOAM531DMkNW/V2eRWTDIQFRmti2EClL7Ha8oU9Nb1AtgQzmEGSYyM3F /ilWQ7L9cbZzKDcFpiktxbMi/0WM1kfj7A== X-Google-Smtp-Source: ABdhPJxK7V/1tQqg3Itqq+TR/2yj/QwSJzWI9ELwEgKSgg7swS0gQAI3jtYh8bcVKmHKLY8facrlmA== X-Received: by 2002:a17:902:c702:b029:e2:f204:baf9 with SMTP id p2-20020a170902c702b02900e2f204baf9mr1445310plp.35.1612831974375; Mon, 08 Feb 2021 16:52:54 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id ke13sm434419pjb.44.2021.02.08.16.52.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2021 16:52:53 -0800 (PST) To: Jay Daley , Stephen Farrell Cc: rfced-future@iab.org References: <6f7b6f92-ea14-9fa7-8962-f9734ff0ae72@cs.tcd.ie> <5619B12A-BD02-4116-97D2-EB1FCAC62BB7@ietf.org> From: Brian E Carpenter Message-ID: Date: Tue, 9 Feb 2021 13:52:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5619B12A-BD02-4116-97D2-EB1FCAC62BB7@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 00:52:57 -0000 On 09-Feb-21 12:20, Jay Daley wrote: >=20 >> On 9/02/2021, at 12:05 PM, Stephen Farrell = wrote: >> >> =EF=BB=BF >> Hiya, >> >> On 08/02/2021 22:53, Jay Daley wrote: >>> from my relatively naive perspective it seems as if the stream >>> managers should have that role for their readers because they control= >>> what is read and they need the direct feedback loop >> I don't disagree, but I would note that the intricacies of >> RFCs are not really the primary job of the stream managers - >> maybe the ISE is closest, but the IETF, IAB and IRTF stream >> managers have I think mostly so far always been people who >> are pretty busy elsewhere. >> >> So I think there're also pragmatic reasons to plump for the >> RSE as this "gap filler" - if one sees this as related to >> the question as to why/how the series has (so far) been so >> long-lived but has remained useful. >=20 > Thinking aloud now, but I wonder if any thought has been given to a new= structure designed to create that feedback loop more directly. =C2=A0For= example, something as simple as a feedback form accessible from each RFC= page would be a good start. =C2=A0I imagine it would be used most when a= new RFC is published. The things are called "Request for *Comments*" but the boilerplate doesn'= t even hint where Jane Doe could send her comments. People with a bit of = esoteric knowledge know how to submit errata, and people could send email= to the authors (except that for older RFCs, the addresses listed are oft= en obsolete). So yes, something should probably be done in this area. But= it has to be more meaningful than https://tinyurl.com/2xl6fys2 Brian From nobody Mon Feb 8 16:56:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA4D3A1745 for ; Mon, 8 Feb 2021 16:56:48 -0800 (PST) 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 xN7Rckx9Im2j for ; Mon, 8 Feb 2021 16:56:47 -0800 (PST) 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 5276B3A1743 for ; Mon, 8 Feb 2021 16:56:47 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 7BBAF2CF41; Mon, 8 Feb 2021 16:56:46 -0800 (PST) From: Wes Hardaker To: Brian E Carpenter Cc: rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> <692b8341-1c50-4d24-9b1c-e8821e2b6f79@www.fastmail.com> <990b46b3-816e-fd7e-2ab3-c1bc9a018e46@joelhalpern.com> <1b19c9fe-8e69-abf3-2624-be4dab32d13f@mozilla.com> <58e7d15a-b305-50b7-01c4-a2a03e2bf992@gmail.com> Date: Mon, 08 Feb 2021 16:56:46 -0800 In-Reply-To: <58e7d15a-b305-50b7-01c4-a2a03e2bf992@gmail.com> (Brian E. Carpenter's message of "Tue, 9 Feb 2021 10:37:41 +1300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 00:56:49 -0000 Brian E Carpenter writes: > I'd put that equal first with use by operators. In fact, I suspect that > operators outnumber developers. It's a fun game to play: let's create a list of people that might want to read (and understand) our RFCs: Grandma Kernel Protocol Software Engineers Then we can fill it in and draw a line somewhere for 'who our community is?' and hope it's the same line as 'who we are writing these things for?' and hope it's the same line as 'who's opinions do we care about?'. Average computer owners Savvy computer owners Layers CEOs CTOs Product managers (thanks Joel) Commercial and Government procurement managers Open source in their spare time authors Commercial Application developers Network operators Machine Language researchers Security researchers Networking researchers Networking equipment engineers Kernel Protocol Software Engineers I'm sure the list is much longer. I'm sure others would sort it differently. But in the end, isn't there a line somewhere, or a rating to apply per line for "how much we optimize our documents for that set of people"? And the question then becomes "how do we get feedback from them?" and "does the RSA/E need to have skills to and the requirements to conduct that study?" (I'll note that if the answer to the last question is "no" then maybe the topic is out of scope for the near term at least?) -- Wes Hardaker USC/ISI From nobody Mon Feb 8 16:58:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60343A1747 for ; Mon, 8 Feb 2021 16:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNjoMbyabicM for ; Mon, 8 Feb 2021 16:58:05 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E5F3A14A1 for ; Mon, 8 Feb 2021 16:58:05 -0800 (PST) Received: from xse426.mail2web.com ([66.113.197.172] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1l9HLq-000fke-J8 for rfced-future@iab.org; Tue, 09 Feb 2021 01:57:59 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4DZPdH53twzLkK for ; Mon, 8 Feb 2021 16:57:55 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1l9HLn-0007xb-Hy for rfced-future@iab.org; Mon, 08 Feb 2021 16:57:55 -0800 Received: (qmail 9674 invoked from network); 9 Feb 2021 00:57:54 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.208]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Feb 2021 00:57:54 -0000 To: Stephen Farrell , Jay Daley , rfced-future@iab.org References: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> <4DAEBFA0-9732-4798-8C44-56EB472D6DDD@ietf.org> <6f7b6f92-ea14-9fa7-8962-f9734ff0ae72@cs.tcd.ie> From: Christian Huitema Message-ID: <89bf2f6a-563e-64a8-da9e-325f167ca5bb@huitema.net> Date: Mon, 8 Feb 2021 16:57:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <6f7b6f92-ea14-9fa7-8962-f9734ff0ae72@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------6ABAB0CF81FB8281AF7484E8" Content-Language: en-US X-Originating-IP: 66.113.197.172 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: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KoHI GN2xycREVyE2Gi+quEjzBSzw8schYcQ6DREOWcl9SxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLVdh3YTLaUf1T/vJjBHMeQhZotTbzF8bFslzcWfB/84WX1KHe/ FVcvFYE7DSY4uAuvkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkgOaZXY1D 3Tei6L4lTC3Kzv6blagzf/fouhj8KehojfmLb5mum9xAXSaS3KKPtTZXWZip9+GhedmPokL8D3vh veYLhIg92+wH02ylfDiSQ0sYFBl6VX84fRovDGikEvLu7vlxwPg5iSJU22qtYbc2zIvhSJcbnX/H QqL/X9rNCJCc6iESJvKm1NV8gkr+Wu8ScVDXinOVyuIpITQ9z3M3DCinc6hm4Yij/9/ori/8mFV4 V97ui3VA1OEF+KxGdWeoCnZS3HP58lZgYQ7E+SiWuQ67BKWhr/strns5cs6eI/DYpEFoi75E4I64 qGaGHDSiyaxfFQ1w34FqYc4W3dbMgAFVnde1UJCYLdcfX0Bx8d3g5Ppw3LRu20mEzTNZoW/3dxzr jEdND/YXvvLU0wS7sYUObdt44X9GzwYH6xdeOnsB72nQDn8Czjzzp3Xh6KKeXPWlFdaGOH191uXj gjQN/UgmFnDejR5GAcPZptnyFMGo8rMFZc+/2+3NZnw02woIXw+nBpSCKZIbZZvSwd+SQxZlzVty mVydDKFB2f6LxLLeNHk15VolAGHS5rCXQKDy9EJw0oDs3IuV1P3CACJRKC3Z/gUfBR81DfdjOw7H zLAtNKciZu/UXm5Ymo0KIdV9iR3bHfnMCIEU+nrglojKwHii07T4YjLFruZMfnLuYZ8= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 00:58:07 -0000 This is a multi-part message in MIME format. --------------6ABAB0CF81FB8281AF7484E8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/8/2021 3:05 PM, Stephen Farrell wrote: > > On 08/02/2021 22:53, Jay Daley wrote: >> from my relatively naive perspective it seems as if the stream >> managers should have that role for their readers because they control >> what is read and they need the direct feedback loop > I don't disagree, but I would note that the intricacies of > RFCs are not really the primary job of the stream managers - > maybe the ISE is closest, but the IETF, IAB and IRTF stream > managers have I think mostly so far always been people who > are pretty busy elsewhere. > > So I think there're also pragmatic reasons to plump for the > RSE as this "gap filler" - if one sees this as related to > the question as to why/how the series has (so far) been so > long-lived but has remained useful. I think that Jay is making an important point: the reason we have the streams in the first place is because we want to provide useful content, which is very much the task of the stream managers or the organizations that they represent. To answer Stephen's question, I think the main reason why "the series has (so far) been so long-lived but has remained useful" is, because the IETF managed to produce specifications that are useful for the Internet. This is primarily a matter of producing good content. The form matters two, specifically the property that specifications are available to everybody without restrictions, and, for the continuity part, the property that the IETF publication are easily recognized as part of a long duration series. But if we do believe that this is primarily about "producing the right content", then the responsibility of verifying that belong to the stream managers, not to a technical expert. -- Christian Huitema --------------6ABAB0CF81FB8281AF7484E8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 2/8/2021 3:05 PM, Stephen Farrell wrote:

On 08/02/2021 22:53, Jay Daley wrote:
from my relatively naive perspective it seems as if the stream
managers should have that role for their readers because they control
what is read and they need the direct feedback loop
I don't disagree, but I would note that the intricacies of
RFCs are not really the primary job of the stream managers -
maybe the ISE is closest, but the IETF, IAB and IRTF stream
managers have I think mostly so far always been people who
are pretty busy elsewhere.

So I think there're also pragmatic reasons to plump for the
RSE as this "gap filler" - if one sees this as related to
the question as to why/how the series has (so far) been so
long-lived but has remained useful.


I think that Jay is making an important point: the reason we have the streams in the first place is because we want to provide useful content, which is very much the task of the stream managers or the organizations that they represent. To answer Stephen's question, I think the main reason why "the series has (so far) been so
long-lived but has remained useful" is, because the IETF managed to produce specifications that are useful for the Internet. This is primarily a matter of producing good content. The form matters two, specifically the property that specifications are available to everybody without restrictions, and, for the continuity part, the property that the IETF publication are easily recognized as part of a long duration series. But if we do believe that this is primarily about "producing the right content", then the responsibility of verifying that belong to the stream managers, not to a technical expert.

-- Christian Huitema

--------------6ABAB0CF81FB8281AF7484E8-- From nobody Mon Feb 8 17:21:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A222F3A178C for ; Mon, 8 Feb 2021 17:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 v7dnmUfHU_OC for ; Mon, 8 Feb 2021 17:21:01 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94133A178A for ; Mon, 8 Feb 2021 17:21:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DZQ7x3Q3jz6G9cl; Mon, 8 Feb 2021 17:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612833661; bh=RVwfqDPvdMUQSqIflSYSpzNcLGJKtl8M+PhakeKL9CE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=onEPkWtG3sJ+6j2mOactJnGKtWANBsF5j+YZOE0QP62RRmkjGmA5dHQkbwCZjZ6Xq VrgD8AZ3ah2BKLv9h9PbJ84w1CjTD/TqTBupvaF1S5I63D15qalccRWRchdquRk5pD scKpjDTEl45ZAHcitIU1EZOzonnveCIchVWFDIrU= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DZQ7w6Kbyz6G9G4; Mon, 8 Feb 2021 17:21:00 -0800 (PST) To: Christian Huitema , rfced-future@iab.org References: <46b55ad5-8035-c9b9-0987-540479ba9048@mozilla.com> <4DAEBFA0-9732-4798-8C44-56EB472D6DDD@ietf.org> <6f7b6f92-ea14-9fa7-8962-f9734ff0ae72@cs.tcd.ie> <89bf2f6a-563e-64a8-da9e-325f167ca5bb@huitema.net> From: "Joel M. Halpern" Message-ID: Date: Mon, 8 Feb 2021 20:21:00 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <89bf2f6a-563e-64a8-da9e-325f167ca5bb@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 01:21:05 -0000 I agree Christian that the content is primary. But the point of this part of the process is about the form and clarity, not the technical substance. We do not select people to be stream managers. For the various roles from which stream managers come (except maybe the ISE) technical publication expertise, understanding of the impact of presentation form, and even receptivity to the many outside communities that use our documents are not high on the list of criteria that the nomcom uses. WWe can, and I think should, make sure those are included in the RSE/A selection criteria. And then give them the participation and voice to go with that. Yours, Joel On 2/8/2021 7:57 PM, Christian Huitema wrote: > > On 2/8/2021 3:05 PM, Stephen Farrell wrote: >> >> On 08/02/2021 22:53, Jay Daley wrote: >>> from my relatively naive perspective it seems as if the stream >>> managers should have that role for their readers because they control >>> what is read and they need the direct feedback loop >> I don't disagree, but I would note that the intricacies of >> RFCs are not really the primary job of the stream managers - >> maybe the ISE is closest, but the IETF, IAB and IRTF stream >> managers have I think mostly so far always been people who >> are pretty busy elsewhere. >> >> So I think there're also pragmatic reasons to plump for the >> RSE as this "gap filler" - if one sees this as related to >> the question as to why/how the series has (so far) been so >> long-lived but has remained useful. > > > I think that Jay is making an important point: the reason we have the > streams in the first place is because we want to provide useful content, > which is very much the task of the stream managers or the organizations > that they represent. To answer Stephen's question, I think the main > reason why "the series has (so far) been so > long-lived but has remained useful" is, because the IETF managed to > produce specifications that are useful for the Internet. This is > primarily a matter of producing good content. The form matters two, > specifically the property that specifications are available to everybody > without restrictions, and, for the continuity part, the property that > the IETF publication are easily recognized as part of a long duration > series. But if we do believe that this is primarily about "producing the > right content", then the responsibility of verifying that belong to the > stream managers, not to a technical expert. > > -- Christian Huitema > > From nobody Mon Feb 8 18:26:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2337C3A17E0 for ; Mon, 8 Feb 2021 18:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUq7-lyQfHBU; Mon, 8 Feb 2021 18:26:23 -0800 (PST) Received: from [172.20.10.2] (115-189-133-199.mobile.spark.co.nz [115.189.133.199]) (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 D61453A17DF; Mon, 8 Feb 2021 18:26:22 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-D9B057DE-25E9-4F81-ABC8-8FDE8C62B6D4 Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Date: Tue, 9 Feb 2021 15:26:18 +1300 Message-Id: References: <1132f0e2-7cb1-981e-e2e6-62d461f61146@nthpermutation.com> Cc: rfced-future@iab.org In-Reply-To: <1132f0e2-7cb1-981e-e2e6-62d461f61146@nthpermutation.com> To: Michael StJohns X-Mailer: iPad Mail (18C66) Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 02:26:25 -0000 --Apple-Mail-D9B057DE-25E9-4F81-ABC8-8FDE8C62B6D4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 9/02/2021, at 1:13 PM, Michael StJohns wrote: >=20 > =EF=BB=BFOn 2/8/2021 6:20 PM, Jay Daley wrote: >>=20 >>>> On 9/02/2021, at 12:05 PM, Stephen Farrell w= rote: >>>=20 >>> =EF=BB=BF >>> Hiya, >>>=20 >>> On 08/02/2021 22:53, Jay Daley wrote: >>>> from my relatively naive perspective it seems as if the stream >>>> managers should have that role for their readers because they control >>>> what is read and they need the direct feedback loop >>> I don't disagree, but I would note that the intricacies of >>> RFCs are not really the primary job of the stream managers - >>> maybe the ISE is closest, but the IETF, IAB and IRTF stream >>> managers have I think mostly so far always been people who >>> are pretty busy elsewhere. >>>=20 >>> So I think there're also pragmatic reasons to plump for the >>> RSE as this "gap filler" - if one sees this as related to >>> the question as to why/how the series has (so far) been so >>> long-lived but has remained useful. >>=20 >> Thinking aloud now, but I wonder if any thought has been given to a new s= tructure designed to create that feedback loop more directly. For example, s= omething as simple as a feedback form accessible from each RFC page would be= a good start. I imagine it would be used most when a new RFC is published.= >>=20 >> Jay >=20 >=20 > Surveys are useful when tightly targeted and there's an immediate use of t= heir outputs. In the case of just published RFC's, that use may be years or= decades in the future when the next version of the document starts to wend i= ts way through the IETF. Every question you might ask on the survey would h= ave hopefully been asked during the documents development or during the appr= oval process. >=20 > So - I can't imagine this tool to be very useful. Or am I misguessing wha= t types of questions you had in mind asking? The purpose would be to capture the views of those that were not involved in= the production and hopefully not involved in the IETF - i.e. the extant use= r community that many have inferred exists. I didn=E2=80=99t use the word s= urvey because I would imagine that the main mechanism is free text comment w= ith tighter questions to understand who is giving the feedback and a basic r= eadability type score. Jay --=20 Jay Daley IETF Executive Director >=20 > Mike >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail-D9B057DE-25E9-4F81-ABC8-8FDE8C62B6D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 9/02/2021, at 1:13 PM, Michael StJohns <msj@nthpermutation.com&= gt; wrote:

=EF=BB=BFOn 2/8/2021 6:20 PM, Jay Daley wrote:

On 9/02/2021, at 12:05 PM, Stephen Farrell <= stephen.farrell@cs.tcd.ie> wrote:

=EF= =BB=BF
Hiya,

On 08/02= /2021 22:53, Jay Daley wrote:
fr= om my relatively naive perspective it seems as if the stream
managers should have that role for= their readers because they control
what is read and they need the direct feedback loop<= br>
I don't disagree, but I would note that the intricac= ies of
RFCs are not really the primary job of the stream m= anagers -
maybe the ISE is closest, but the IETF, IAB and I= RTF stream
managers have I think mostly so far always been= people who
are pretty busy elsewhere.
<= /span>
So I think there're also pragmatic reasons to plump for th= e
RSE as this "gap filler" - if one sees this as related to=
the question as to why/how the series has (so far) been s= o
long-lived but has remained useful.

Thinking aloud now, but I wonder if any thought h= as been given to a new structure designed to create that feedback loop more d= irectly.  For example, something as simple as a feedback form accessibl= e from each RFC page would be a good start.  I imagine it would be used= most when a new RFC is published.

Jay


Surveys are usef= ul when tightly targeted and there's an immediate use of their outputs. = ; In the case of just published RFC's, that use may be years or decades in t= he future when the next version of the document starts to wend its way throu= gh the IETF.   Every question you might ask on the survey would ha= ve hopefully been asked during the documents development or during the appro= val process.

So - I can't imagine this tool= to be very useful.  Or am I misguessing what types of questions you ha= d in mind asking?

The purpo= se would be to capture the views of those that were not involved in the prod= uction and hopefully not involved in the IETF - i.e. the extant user communi= ty that many have inferred exists.  I didn=E2=80=99t use the word surve= y because I would imagine that the main mechanism is free text comment with t= ighter questions to understand who is giving the feedback and a basic readab= ility type score.

Jay

-- <= /div>Jay Daley
= IETF Executive Director


Mike


--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/= listinfo/rfced-future
= --Apple-Mail-D9B057DE-25E9-4F81-ABC8-8FDE8C62B6D4-- From nobody Mon Feb 8 18:38:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBAD3A10A4 for ; Mon, 8 Feb 2021 18:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6hDxfrpJChy for ; Mon, 8 Feb 2021 18:38:19 -0800 (PST) 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 974F33A107F for ; Mon, 8 Feb 2021 18:38:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 08B50BE80; Tue, 9 Feb 2021 02:38:17 +0000 (GMT) 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 MRwHtPHZcQ41; Tue, 9 Feb 2021 02:38:15 +0000 (GMT) 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 D0ACBBE7B; Tue, 9 Feb 2021 02:38:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1612838294; bh=SXs//Xu0kwDAfzLegCOXdtB4Oh30XLNgosz6HPPXSME=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ti0BoGMM8pBoheoWNYGylgmUiYXzwHpdDR+wT6iBBprDuxOnBlvlSNDY5/n9koK7e aXE7cGaOO+Ol4hESWhSMgIQNjc7Cvy/NYAtffbrtypHaN/0yp5DOQ2Rc82ya6JncGK 8OewUoNYqNbi9pWmZHDJvfirhD56hHmyxsXrptXM= To: Jay Daley , Michael StJohns Cc: rfced-future@iab.org References: <1132f0e2-7cb1-981e-e2e6-62d461f61146@nthpermutation.com> From: Stephen Farrell Message-ID: <5445266f-0802-e239-c8d7-4a8b389d52d6@cs.tcd.ie> Date: Tue, 9 Feb 2021 02:38:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZjaEKEtrvFeuaz3sct2cl0UMKJv87plfY" Archived-At: Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 02:38:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZjaEKEtrvFeuaz3sct2cl0UMKJv87plfY Content-Type: multipart/mixed; boundary="N2qnoHwHeTXbMw0Mdr1U7J26dVqZz4ADp"; protected-headers="v1" From: Stephen Farrell To: Jay Daley , Michael StJohns Cc: rfced-future@iab.org Message-ID: <5445266f-0802-e239-c8d7-4a8b389d52d6@cs.tcd.ie> Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders) References: <1132f0e2-7cb1-981e-e2e6-62d461f61146@nthpermutation.com> In-Reply-To: --N2qnoHwHeTXbMw0Mdr1U7J26dVqZz4ADp Content-Type: multipart/mixed; boundary="------------8C956D798767F8935DBBE67B" Content-Language: en-US This is a multi-part message in MIME format. --------------8C956D798767F8935DBBE67B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 09/02/2021 02:26, Jay Daley wrote: > The purpose would be to capture the views of those that were not > involved in the production and hopefully not involved in the IETF - > i.e. the extant user community that many have inferred exists. I > didn=E2=80=99t use the word survey because I would imagine that the mai= n > mechanism is free text comment with tighter questions to understand > who is giving the feedback and a basic readability type score. Personally, I think ways to garner input and review of published RFCs is a major missing mechanism. The errata process as-is seems to me a very weak late 20th-C attempt at that on which it really ought be easy to improve. And I'd say a good RSE, with time and time-to-focus available, ought be able to oversee a vast improvement on status quo. I do think there's an editorial element to that - we already see spam-errata fairly regularly, as well as random comments on no-longer-interesting RFCs, so whatever better scheme might be put in place will require judgement and management as to proper disposition of comments. That couldn't and shouldn't be done by an RSE in isolation, but managing it seems to me to be a fine task for an RSE to me. Cheers, S. --------------8C956D798767F8935DBBE67B Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------8C956D798767F8935DBBE67B-- --N2qnoHwHeTXbMw0Mdr1U7J26dVqZz4ADp-- --ZjaEKEtrvFeuaz3sct2cl0UMKJv87plfY Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAh9ZYFAwAAAAAACgkQWrL68XsXK+rD lBAApVQRVLn3udLH0KQDN1/MPBfvA9E89O/uF7e1St6J9iExhOO8ZedRXR7O3k9JMfrjy6ZqHvXj rnaHcIBBuzaRKqj9mCx5kiWU3ztdx9W8J4VlRJzWGbPK0ib/Wpb9Sr7YvW9mXChZ7UTjqc7XxrlJ a39w18Z8sZMoC9v4j4xHY4h9aV6Skra4mLc4+ZweSgl89q7LwLIR1y/VOf+9/sGBB2zxXIsW+TGB R8444urNbf6+FAvdXhCFHpHH8T3H+LOza3jOu4PvZcGJzZTEvegW20+KPVXM7tYKMlH1oXkkPP+w L3eEzk3gFo92b8lGfNv7PXw+DHA2NHt5hp5SXLy1pK2Hxu0tZeNycCRxqNpG9xZYuKOhlOB+1TCX cnpaoAK6a7tf+oTB/0PCeLdsRNy4t2j1cAoYYcC8NqYO/O1EnOG0pkQn0oiI2k3payRF7JwpuErT yUxvcoQNcQBENcodjaEcVhT14Ll+ddnEwP3QfXp6FZLLxg51tv5NehiOESRSL0ZtA9g+1yuzfDTA fwqD2NhcQaECuazQRcaiuxG4HhFi0h4hxrK5uwcdxoNcamnj9VsZ62GDJYhFPlLG5CYJSoj4d0pH r0u+OvUO1EQ1+DVzWGmbDSdAK2Rc1i89SBm1bZc08+vftn1HGYIQhbl20DPg0cl1WyxONUa/oqJr BCQ= =r1eA -----END PGP SIGNATURE----- --ZjaEKEtrvFeuaz3sct2cl0UMKJv87plfY-- From nobody Mon Feb 8 22:56:31 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029323A119A for ; Mon, 8 Feb 2021 22:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=GuaeQNH8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A4C7+v1T Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOr8ErWQNb6W for ; Mon, 8 Feb 2021 22:56:29 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBF43A11A0 for ; Mon, 8 Feb 2021 22:56:29 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 400825C01E1; Tue, 9 Feb 2021 01:56:28 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 09 Feb 2021 01:56:28 -0500 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=fm1; bh=C pRiynCg2Zs3zCupG04p9eY7UpP4WLa9f57+Js+qRc0=; b=GuaeQNH83Rt218H4m HN0RVI0TLGYxcaPVb4ORG52yVQRpR2kt31amac5HmW+MKgTQIiUCRKEajkZcxf8i 6EvlEKgW5M3B7/0uwNkqyRpOBIb3TiD2kX3BI9xjtZ7KSEq35n9SSxu0aVi3QhRK tyY98vakTmwNZ1rt4cGgK/w9pb059/bKmAbMLmIOzHmW5uBgdZy/M2NAXrq6fLbY dqZB4nIndLdn01IcsgTgzXXPb61HzL5lDP0uiC2nEGx4aitPyLjCXWViyJEgsJk5 4MboOdc22kzGPWt7dmiIVJI0IlSUgex+QzRDvxpwp2vsmzswrnR9QzeJCe2F8YeD Ma49Q== 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=CpRiynCg2Zs3zCupG04p9eY7UpP4WLa9f57+Js+qR c0=; b=A4C7+v1TpywE2arDes854YnsNFANUsrmXzcdzLuEaeCIGh7xdt9RzK1MI Hu0v4tHvbHUe5vcQkvlfHiLlIiStU61jlwlDMzqwLzZTimw4gnsZudBlobK7+MJP hoKvFZy94/fzfgneDKGziwxVE6JYF8bzFJS4YWyBy4WtPmjtwc4yAi8eGgy2Lq0A eLJimwo0MpLsqvlCVPAdrEfh8Sbm7jN7OCUjbmsNzJzEgfBDBQfu3AyAATeklpea gdpjljVLwiwtnlV/ZJ3cC9jsBpV98Sp7drya5ZFMnQ524GaGae7dsTVLtnQ5fp0E 3flkipOiZxXe0QxnUyvo3tU+OV/bw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrheeggddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeetfeelffejfffhheehfeefgedulefgueejudekieegvdeghefffedvheffieel keenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 0384024005D; Tue, 9 Feb 2021 01:56:23 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: Date: Tue, 9 Feb 2021 17:55:50 +1100 Cc: rfced-future@iab.org, Brian Rosen Content-Transfer-Encoding: quoted-printable Message-Id: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> References: To: Eliot Lear X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 06:56:31 -0000 > On 6 Feb 2021, at 7:14 am, Eliot Lear = wrote: >=20 > Hi everyone, >=20 > First, the chairs want to again thank Eric for bringing some text to = the discussion. =46rom our perspective, there is a lot on which we may = agree, and we would like to test consensus on some of the points, = knowing that discussion is ongoing on other aspects. >=20 > =E2=80=A2 Do people agree that the stream managers are part of = the approval body? Yes. > =E2=80=A2 Do people agree that process proposals flow from the = WG to the approval body? Yes. If the approval body wants to originate a document, I'd expect them = to introduce it in the WG early in its lifetime. > =E2=80=A2 Do people agree that the grounds for rejection of a = proposal include damage to a stream? Yes. > =E2=80=A2 Do people agree that any objections must be returned = to the WG for discussion? Yes. > =E2=80=A2 Do people agree that if the WG still wants to press = forward, two objections would still halt approval? Not sure, we need to understand the composition of the approval body. > =E2=80=A2 Do people agree that damage to a stream would include = long term strategic damage to the series? That seems... fuzzy. Examples? -- Mark Nottingham https://www.mnot.net/ From nobody Mon Feb 8 23:01:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08DF3A11AC for ; Mon, 8 Feb 2021 23:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Jj1qAZd3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Qe+pAnz3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9S4M7MWkCcB for ; Mon, 8 Feb 2021 23:01:04 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2EA3A19ED for ; Mon, 8 Feb 2021 23:00:52 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3FD065C0228; Tue, 9 Feb 2021 02:00:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 09 Feb 2021 02:00:51 -0500 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=fm1; bh=E NQpBXYYlH5jcQIgcdeXgJ75S4XfBu5PDwGKKmJV/wU=; b=Jj1qAZd3QFweZC3Y0 lzZ275sag9gqMI+oB7HoTlsL6BUrgzLMYiCIU10Q/Zva0w79RzW6lAwvztcI7gtJ 4Im4dLsFI9sICzqfkeWuL+NeHVeIr15/eSzCCrPYP5+558Hlzk0AzowMw143guuk ZX7G63Ds5G68fwE80imDPmThlYJyf44Y+6oDbptJjCEVdhriUqfzpFgWA413kW0W iNzMR1ZNunohNVNvb67T+Afa/tuLMeWFpqsfIReNqC4+qlLu3EY89sWDjimVu5aI 2mEIl9puDKsnJbUDICmBns+Q+TOVBKbrxTpcJ92xR5aGNOtkz0+JNf/1dJfdTaKX VIWzQ== 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=ENQpBXYYlH5jcQIgcdeXgJ75S4XfBu5PDwGKKmJV/ wU=; b=Qe+pAnz3Fei8uZEzx3Jf6pvYBCvD9rTzkr9bmeOMpsaMLA/vmhDn0NmT4 WeRwvRXGzwqSr7+ToPmPMrWPmoUFzeRTXQv6HYJrF9N6k9otEJfTpz88b0u7NkAz OfL442krnnaXR8R1ZERnwGWYjcYw5apGVGiY9JDvdhfuyoeBhVmCL0K/YF3DgyXP tMilPDNT6SzLBUyVO5sGYVVsCFSHFz4i+7S9zHDRA0hYAnDvPxbMe1ZP9EdPCBzX xQPFEEId9O+9VEwI0povs3NlzPn8BTc1ovrCh/zvpLltCCBdoK0jj93dthbYysga V7Hzp1CO80Eu8fORl9sFUanDSSJpw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrheeggddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id BCBED24005E; Tue, 9 Feb 2021 02:00:48 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> Date: Tue, 9 Feb 2021 18:00:46 +1100 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <939388B7-52DC-4880-A333-0F5E27CF11C4@mnot.net> <002201d6fc83$3e8112d0$bb833870$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 07:01:08 -0000 Hi Adrian, > On 6 Feb 2021, at 11:26 pm, Adrian Farrel wrote: >=20 > I am worried that the way we in the IETF build and assess consensus is = not > well suited to making decisions about the RFC series in a "working = group" > because such a group is likely to be heavily populated by just one = section > of the community (the regular IETFer) so that any counter opinions = (if, > indeed, they are expressed at all) will be considered minor voices or = in the > rough. >=20 > So it is good to hear some thoughts that the RSA/E would have some > responsibility for considering other voices and bringing their needs = and > aspirations to the table. But it doesn't cut much ice with me to hear = that > "the folks here are somewhat representative of many of those who are = the > audience", in fact it worries we somewhat because it sounds similar to = the > way silent majorities are often excluded by those in power (I do not = accuse > anyone here present of such an intention). This is in no way unique to the governance of the RFC Series. IETF WGs = make decisions all the time about things that affect folks that don't = show up, or are only partially represented by those in the room. = Recently, I wrote an RFC about that, and how we should handle it. As such, I remain unconvinced that the RFC Series is a special case that = needs extraordinary processes or powers for a designated expert. > Now, suppose the RSA/E has the responsibility and expresses a concern = to the > WG. I know we all like to think ourselves reasonable people, and I = suppose > we like to hope that we will pass the baton on to similarly reasonable > people, but suppose that the WG pushes ahead anyway disregarding the = RSA/E's > concerns? What then? Then the consequences will be felt. I am unwilling to bless someone as a monarch over the series just = because something bad might happen one day, and we need someone to = rescue us by telling us what to do. That much responsibility should not = sit on one head, no matter what their heredity, credentials or = provenance. We're currently trying to untangle such a position from the = governance of the W3C, and it's a real bear.=20 Better to stay with the well-worn path that the IETF has paved: create = multiple layers of appeal that get more infrequently used and more = deliberative as you work your way up, in the hope that time, distance = and cooler heads will prevail. If the RSA/E gives good advice, it should = be listened to. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Feb 9 02:42:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E433A19A4 for ; Tue, 9 Feb 2021 02:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E93WPl3J-YdF for ; Tue, 9 Feb 2021 02:42:05 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61F33A199D for ; Tue, 9 Feb 2021 02:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1770; q=dns/txt; s=iport; t=1612867324; x=1614076924; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=EAIj+UfSAA25gnV2aDVl9ZcGQmdFboHljwgYpHD4ZlI=; b=ULstreSmw9C2TK0PrewIJgso6WzmtXbXkDh562d6Vxd5G/5+1hSn8oBD 4S4lkmjt7QGVh4L99fcV9k5v+HPC2Wxa5Rltd/9TuZS2u3AYoMyO76j7M PQXaXMzI3vKy1CIePzJpy/2C7VZaptptymBHfitIwxaEIfrht88E1goQD Q=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ALAAAsZiJgjBbLJq1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAYF7BgEBAQsBg3YBJxKEcogkYIgwmnKBfAQHAQEBCgMBAS8EAQGESwKCA?= =?us-ascii?q?yY0CQ4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBhkeGRAMDI1YQCw40AgJXB?= =?us-ascii?q?oMDAYMGrXt2gTKFWIRaEIE4AYFSi2ZBggCBOAwQglY+h1Q0gisEgWVhgTmBY?= =?us-ascii?q?Ih8iESMJpxDgwSDKYE6lyQDH4MukAosj0GOaqNOg3ICBAYFAhaBVTiBWTMaC?= =?us-ascii?q?BsVZQGCPz0SGQ2OOY4xQANmAgYBCQEBAwmMEwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,164,1610409600"; d="asc'?scan'208";a="33270684" 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; 09 Feb 2021 10:42:00 +0000 Received: from [10.61.238.19] ([10.61.238.19]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 119AfvCA006566 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Feb 2021 10:42:00 GMT From: Eliot Lear Message-Id: <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A40581C3-D1CE-4C09-8A04-973DD95A1D16"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 9 Feb 2021 11:41:57 +0100 In-Reply-To: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> Cc: Eliot Lear , rfced-future@iab.org, Brian Rosen To: Mark Nottingham References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.238.19, [10.61.238.19] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 10:42:06 -0000 --Apple-Mail=_A40581C3-D1CE-4C09-8A04-973DD95A1D16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mark, >=20 >> =E2=80=A2 Do people agree that damage to a stream would include = long term strategic damage to the series? >=20 > That seems... fuzzy. Examples? The example I gave earlier applies: what if the WG decides to approve a = format that blind people can=E2=80=99t read? Another example would be = the WG approving a format change that would put archival value at risk = (let=E2=80=99s say, HTML over EBCDIC, tarred up and compressed with an = algorithm that people might have stopped using long ago, back in 2030). = A third example would be to destabilize the referential nature of the = series. The key point is that any harm would not be immediate, but rather the = change would, in the opinion of TBD # streams, risk the long term = viability of the series. Eliot --Apple-Mail=_A40581C3-D1CE-4C09-8A04-973DD95A1D16 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAiZvUACgkQh7ZrRtnS ejMUtgf/arDN2jBW7B2gl9YWskUDg5g0HZ9sgF0X/XoxDrQ5wWyJd9dQ+WyMMNcl PGzucqN47yFFymWwkeYv0797RaCDC/7F8XhrePJf4Ydt/Uzo0g2x+p5PZMpU4gKp dLc1UyqS0QhKgfxQPdyHC7zf1AuKZG/k8fKts8/wnSroO1xQQPNscVDRdULosR/m /QPXJWWmzN9u1iDVocUI44V0ON5jI1JPcpCHGhfBBsIiV4NdsPXcYFhZqfjJiBZC s3DEDb0suhOnxoUfIA1N6UBB4s8IBg/7y3inqo1W17qVupnlUWLXJmTipsh24oAO 7Orbu8j/5GfUxd3NFhTnHhKDlgfuyg== =00RU -----END PGP SIGNATURE----- --Apple-Mail=_A40581C3-D1CE-4C09-8A04-973DD95A1D16-- From nobody Tue Feb 9 05:41:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEB03A0B8F for ; Tue, 9 Feb 2021 05:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRIhG2Oqa8h7 for ; Tue, 9 Feb 2021 05:41:14 -0800 (PST) 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 D404F3A0B05 for ; Tue, 9 Feb 2021 05:41:13 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id e18so22271326lja.12 for ; Tue, 09 Feb 2021 05:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mlX9bt6WLCmLn2a+hQq12qTiSOfbo4OF3VPAZ614Ozo=; b=KaDF+iIEeB/HLKRrf8ENCBsdmff4E2wKYJfc3bPyU04FdT7gZCHVZKUhFeOLQCANHC wCdRpmhe949wbng4QiiI0ObJWIQQYlWcG85U1vq2TmGnBYyjPgez3pkziaM5ZOmlkP0h y5WLcN0yBRu22Hovy7IGi9405LoAl5Je5ftkq0c40/S6vbc7TArrQjz7IA7DiWE33R00 c4Ybtz3bqeV8xaU5J+P9h6ckeA/LYLc1wv5Mn9G8XtklDmTSJvaaTFfNSYVUBo3TnQUZ O1Fl0BgRvVvVWhg8921qAJChCJwrl/xaeE9nRJpNKB4znmNXakEGGA8fd5aSCcppaC9B QsNg== 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=mlX9bt6WLCmLn2a+hQq12qTiSOfbo4OF3VPAZ614Ozo=; b=DJu34O46BIf8U1Wp3ByaDPsmuUVbxqnY3UOFkc64kUMyvCuRQ3s4I4YA/0iXRHT92i GkEElYRZLThooN2mI1SxAy/a8ouwD6ij3oCbn+U97yKtl/E1+wATe0KgM+7b1u61GlFr uZKL5epLM/zPT9h3rNWkLgiQDd/WMRISvhizM94k4UT4mTndoQP2ehpLX/2isjdo4RKz s1UJQHk4B/tcgNpyME+Zc3ybQMbZi2n/9Kdwd3aNkNmQTF+UqHbG7F7ubNbrHN6j//l5 X+QBsUUyGehldO8B54KMn+JlCyoYmUfa6G+LuvCC4BoUD/rorPjeW3Ax9XB5vdJKdv9E JsZQ== X-Gm-Message-State: AOAM531yNWwlz/asapazth25qxQLvk/F2Y1p5e2m6UK1b00l03lJFQFf jIx4WD3bdhAVl46S45ByehDSxe2mLyuRSKb37J6AVw== X-Google-Smtp-Source: ABdhPJzka1AyLSDiZoiQRHwKrQVW35zJxZqJvgEQUabRGwY8Ni3pvZmg4qod+MdWXpzP9ZN4pSaKS9DDkLyaTrwU98M= X-Received: by 2002:a2e:8986:: with SMTP id c6mr7117001lji.82.1612878072025; Tue, 09 Feb 2021 05:41:12 -0800 (PST) MIME-Version: 1.0 References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> In-Reply-To: <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> From: Eric Rescorla Date: Tue, 9 Feb 2021 05:40:35 -0800 Message-ID: To: Eliot Lear Cc: Mark Nottingham , rfced-future@iab.org, Brian Rosen Content-Type: multipart/alternative; boundary="0000000000008ca86805bae7700e" Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 13:41:15 -0000 --0000000000008ca86805bae7700e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 9, 2021 at 2:42 AM Eliot Lear wrote: > Hi Mark, > > > > >> =E2=80=A2 Do people agree that damage to a stream would include l= ong term > strategic damage to the series? > > > > That seems... fuzzy. Examples? > > > The example I gave earlier applies: what if the WG decides to approve a > format that blind people can=E2=80=99t read? I think this example is quite clarifying, so I'm going to stop here. While the question of whether a particular format is accessible requires specialized expertise, the question of how accessible to make things is a policy question of the kind we ordinarily leave to WGs. Why would (for instance) the ISE have particular insight into this matter or particular legitimacy to object? -Ekr --0000000000008ca86805bae7700e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 9, 2021 at 2:42 AM Eliot = Lear <lear=3D40cisco.com@d= marc.ietf.org> wrote:
Hi Mark,

>
>>=C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Do people agree that damage to a str= eam would include long term strategic damage to the series?
>
> That seems... fuzzy. Examples?


The example I gave earlier applies: what if the WG decides to approve a for= mat that blind people can=E2=80=99t read?

I= think this example is quite clarifying, so I'm going to stop here. Whi= le the question of whether a particular format is accessible requires speci= alized expertise, the question of how accessible to make things is a policy= question of the kind we ordinarily leave to WGs. Why would (for instance) = the ISE have particular insight into this matter or particular legitimacy t= o object?

-Ekr

--0000000000008ca86805bae7700e-- From nobody Tue Feb 9 05:53:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069423A0C56; Tue, 9 Feb 2021 05:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-bQOCt8eZ57; Tue, 9 Feb 2021 05:53:41 -0800 (PST) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57C03A0C46; Tue, 9 Feb 2021 05:53:39 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 119Drav7014774; Tue, 9 Feb 2021 13:53:36 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 80F352203D; Tue, 9 Feb 2021 13:53:36 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 6B7022203C; Tue, 9 Feb 2021 13:53:36 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.213.140]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 119DrZPT031246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Feb 2021 13:53:35 GMT Reply-To: From: "Adrian Farrel" To: "'Eric Rescorla'" , "'Eliot Lear'" Cc: , "'Mark Nottingham'" , "'Brian Rosen'" References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> In-Reply-To: Date: Tue, 9 Feb 2021 13:53:35 -0000 Organization: Old Dog Consulting Message-ID: <027201d6feea$f62cecb0$e286c610$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0273_01D6FEEA.F62DB000" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIYaRiysfHThU9mQ6jMJgdJ+87H2QI+iZuTAhGhqmECzV/skqmUFTdA Content-Language: en-gb X-Originating-IP: 87.112.213.140 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-25942.003 X-TM-AS-Result: No--15.074-10.0-31-10 X-imss-scan-details: No--15.074-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--15.073600-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbJFL3OZgJTJBAgvM6h73BtrH5hkGg5b4DXER bS7OZpEDuITQoMZotq9Ky9WqVkK3ttFyFpuXxyOFDOs94g784gelY4F8r0vXPwp+tuYb4NtQI6p pAYiaFiWoHvVRgwSeCCB+H2tBcniMMKK3MQ624rUsIMJqMNlandPaSXiLjsu7h/YGhgE7yQW7iQ WompiC0S9y/iOFeXgj+oNHQn/iVN0YLyv8+KzdMc87s4OnYGuCa2pCAnJvQFGjYfq6Zu/gF9NZn qbwOWHjTb3GsT57V53nMREDxKFah/GlZAWZDj8yAjoaSw0EjFVMhH/KpYxyuytByTG7yeRhq9Pq l3Fsvi7JSk1nJkwYd0aHaPfxl4UYPg9yfk4YC0YzXSc4V3pE9k5hnW7nLCaJU20Pec0W1lbHIUy M5hQ18lc7bdeKsnaLRr+xSq27283YlSFDo0mGIEmSRRbSc9s3K/YFZTiDf+pQjKOoHqklHpfCHg c/kzDNYcPSCC29lsHu7KwxJ+GqhMkpWKxckagH71Wx2uUbPLdDr8MVm6DK3Vti/oq364XYzEVDG nc+EfKahG/i8Ja1Yx++j1Rb0iZe/7PvFa8I/I9ZwLSBgxghaI5UafLmrvaGI9L0l0rdbj/NTgfZ zqBOOo0DuTXUKKLrnT2mBREOJhXygTNqQkscD+5CGMbmjumUNgI3eHje4BOMUViaYYbK3ObL1As FMa/G2DDxWAJ+P//NyJKpWVsW63/Km5Y4UxMQIj0zFI5DoJLAtpDNMLs81pgjZJ0l7MH/D2OxHN LVnpNwrONoNuGf8yhiPa95Af6o1V3aAHMAe82eAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg4QViJlGwPJ1TkGYGoHljbNDYYzUEKWnFGHeYnZKNqoTltesewM95pFj5MByz1whkg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 13:53:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0273_01D6FEEA.F62DB000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, clearly, the ISE (or any Stream Manager, so we erm, don=E2=80=99t = risk getting personal?) might have personal experience and insight. But = that is entirely distinct from the legitimacy to object. =20 But who *does* object, and why? =20 Consider if the WG is not aware that their proposals will have the = negative impact. Should someone on the approval group have the ability = to say =E2=80=9CHold on, wait. Take this back and consider what you are = doing.=E2=80=9D This is, frankly, the equivalent of a Discuss in the = IETF Stream.=20 =20 Of course, if the WG decides as a matter of policy to make the change in = the full knowledge of what they are doing, then that might be fine. I = would like to see that sort of thing backed up by text that says = =E2=80=9CWe know the effect of what we are doing, and this is why = we=E2=80=99re doing it.=E2=80=9D Who goes back to the WG and says = =E2=80=9CYou must/should include this.=E2=80=9D That=E2=80=99s somewhere = between a Discuss and a Comment on the IETF Stream. =20 The answer to =E2=80=9Cwho=E2=80=9D for both of these paragraphs could = be =E2=80=9Cno need to do this because it will be handled by normal = discussion in the WG=E2=80=9D but we know from the technical work that = this doesn=E2=80=99t always happen. We know that the final review cycle = adds value and catches issues, and we have process for handling that. =20 So (back to the issue at hand) if the Stream Managers cannot raise this = type of =E2=80=9CDiscuss=E2=80=9D off their own bat or because of advice = received, then someone else needs to be able to do it. =20 Cheers, Adrian =20 =20 From: Rfced-future On Behalf Of Eric = Rescorla Sent: 09 February 2021 13:41 To: Eliot Lear Cc: rfced-future@iab.org; Mark Nottingham ; Brian Rosen = Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS = for you =20 =20 =20 On Tue, Feb 9, 2021 at 2:42 AM Eliot Lear = > = wrote: Hi Mark, >=20 >> =E2=80=A2 Do people agree that damage to a stream would include = long term strategic damage to the series? >=20 > That seems... fuzzy. Examples? The example I gave earlier applies: what if the WG decides to approve a = format that blind people can=E2=80=99t read? =20 I think this example is quite clarifying, so I'm going to stop here. = While the question of whether a particular format is accessible requires = specialized expertise, the question of how accessible to make things is = a policy question of the kind we ordinarily leave to WGs. Why would (for = instance) the ISE have particular insight into this matter or particular = legitimacy to object? =20 -Ekr =20 ------=_NextPart_000_0273_01D6FEEA.F62DB000 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Well, clearly, the ISE (or any = Stream Manager, so we erm, don=E2=80=99t risk getting personal?) might = have personal experience and insight. But that is entirely distinct from = the legitimacy to object.

 

But who = *does* object, and why?

 

Consider if = the WG is not aware that their proposals will have the negative impact. = Should someone on the approval group have the ability to say = =E2=80=9CHold on, wait. Take this back and consider what you are = doing.=E2=80=9D This is, frankly, the equivalent of a Discuss in the = IETF Stream.

 

Of course, = if the WG decides as a matter of policy to make the change in the full = knowledge of what they are doing, then that might be fine. I would like = to see that sort of thing backed up by text that says =E2=80=9CWe know = the effect of what we are doing, and this is why we=E2=80=99re doing = it.=E2=80=9D Who goes back to the WG and says =E2=80=9CYou must/should = include this.=E2=80=9D That=E2=80=99s somewhere between a Discuss and a = Comment on the IETF Stream.

 

The answer = to =E2=80=9Cwho=E2=80=9D for both of these paragraphs could be = =E2=80=9Cno need to do this because it will be handled by normal = discussion in the WG=E2=80=9D but we know from the technical work that = this doesn=E2=80=99t always happen. We know that the final review cycle = adds value and catches issues, and we have process for handling = that.

 

So (back to = the issue at hand) if the Stream Managers cannot raise this type of = =E2=80=9CDiscuss=E2=80=9D off their own bat or because of advice = received, then someone else needs to be able to do = it.

 

Cheers,

Adrian

 

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of Eric = Rescorla
Sent: 09 February 2021 13:41
To: Eliot Lear = <lear=3D40cisco.com@dmarc.ietf.org>
Cc: = rfced-future@iab.org; Mark Nottingham <mnot@mnot.net>; Brian Rosen = <br@brianrosen.net>
Subject: Re: [Rfced-future] On = approval bodies and EKR's text: QUESTIONS for = you

 

 

 

On = Tue, Feb 9, 2021 at 2:42 AM Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org= > wrote:

Hi = Mark,

>
>>      =E2=80=A2 Do people = agree that damage to a stream would include long term strategic damage = to the series?
>
> That seems... fuzzy. = Examples?


The example I gave earlier applies: what if the WG = decides to approve a format that blind people can=E2=80=99t = read?

 

I = think this example is quite clarifying, so I'm going to stop here. While = the question of whether a particular format is accessible requires = specialized expertise, the question of how accessible to make things is = a policy question of the kind we ordinarily leave to WGs. Why would (for = instance) the ISE have particular insight into this matter or particular = legitimacy to object?

 

-Ekr

 

------=_NextPart_000_0273_01D6FEEA.F62DB000-- From nobody Tue Feb 9 09:11:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B503A109C for ; Tue, 9 Feb 2021 09:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NONE=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 lnFhec7jtEJe for ; Tue, 9 Feb 2021 09:11:03 -0800 (PST) Received: from xyz.hosed.xyz (xyz.hosed.xyz [71.114.67.91]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC203A104B for ; Tue, 9 Feb 2021 09:11:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xyz.hosed.xyz (Postfix) with ESMTP id 7802813C06A5; Tue, 9 Feb 2021 12:11:00 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at xyz.hosed.xyz Received: from xyz.hosed.xyz ([127.0.0.1]) by localhost (xyz.hosed.xyz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6hUly8bUt88; Tue, 9 Feb 2021 12:11:00 -0500 (EST) Received: from [10.0.0.64] (c-73-71-250-98.hsd1.ca.comcast.net [73.71.250.98]) by xyz.hosed.xyz (Postfix) with ESMTPSA id C59DB13C0550; Tue, 9 Feb 2021 12:10:59 -0500 (EST) From: Sarah Banks Message-Id: <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_80241D20-7427-4809-85AC-EC8C8CC313FB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Tue, 9 Feb 2021 09:10:58 -0800 In-Reply-To: Cc: Eliot Lear , rfced-future@iab.org, Mark Nottingham , Brian Rosen To: Eric Rescorla References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 17:11:11 -0000 --Apple-Mail=_80241D20-7427-4809-85AC-EC8C8CC313FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Inline. >=20 >=20 > The example I gave earlier applies: what if the WG decides to approve = a format that blind people can=E2=80=99t read? >=20 > I think this example is quite clarifying, so I'm going to stop here. = While the question of whether a particular format is accessible requires = specialized expertise, the question of how accessible to make things is = a policy question of the kind we ordinarily leave to WGs. Why would (for = instance) the ISE have particular insight into this matter or particular = legitimacy to object? >=20 Because the ISE might happen to have that experience from other work = experiences. However, I would expect the RSE would have the purview here = to raise this issue, and/or object accordingly. One of the benefits here = would be that while the WG is generally focused on what the WG cares = about (and less about the larger issues of the RFC Series, longevity, = archival issues, etc), that HAS been in the wheelhouse of the RSE. = Further, having a group of folks who can provide reasonable input or = feedback on the issues is seems prudent. The ISE in your example might = not have direct experience with the issue of "approving a format blind = people can't read", but when the RSE raises an objection and outlines = the why, I'd expect stream managers to understand the argument for (or = against). Thanks, Sarah= --Apple-Mail=_80241D20-7427-4809-85AC-EC8C8CC313FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,
   Inline.

<snip>


The example I gave earlier applies: what if the WG decides to approve a = format that blind people can=E2=80=99t read?

I think this example is = quite clarifying, so I'm going to stop here. While the question of = whether a particular format is accessible requires specialized = expertise, the question of how accessible to make things is a policy = question of the kind we ordinarily leave to WGs. Why would (for = instance) the ISE have particular insight into this matter or particular = legitimacy to object?


Because the ISE might happen to have that = experience from other work experiences. However, I would expect the RSE = would have the purview here to raise this issue, and/or object = accordingly. One of the benefits here would be that while the WG is = generally focused on what the WG cares about (and less about the larger = issues of the RFC Series, longevity, archival issues, etc), that HAS = been in the wheelhouse of the RSE. Further, having a group of folks who = can provide reasonable input or feedback on the issues is seems prudent. = The ISE in your example might not have direct experience with the issue = of "approving a format blind people can't read", but when the RSE raises = an objection and outlines the why, I'd expect stream managers to = understand the argument for (or against).

Thanks,
Sarah
= --Apple-Mail=_80241D20-7427-4809-85AC-EC8C8CC313FB-- From nobody Tue Feb 9 11:34:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882423A119D for ; Tue, 9 Feb 2021 11:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBzZXLfYuXPH for ; Tue, 9 Feb 2021 11:34:23 -0800 (PST) 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 328933A119E for ; Tue, 9 Feb 2021 11:34:22 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id q72so2146805pjq.2 for ; Tue, 09 Feb 2021 11:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7IfU5R6BSdXzOlJOAyuvZ4yAYB5EXyPcbAm7okJO9Ak=; b=Nf1Ej4zP1jZDm97rJ3PeAp63TXfBG5PDHGGiaJgucng9Rfm0cnz8WUSILy9K0yUPQU 6PH4056ZVPUxR7Y3OQjur5m6zKY/oVaj3BM4w9ieT2dGIKskQrBNJzYbeTxIgLAXTlkg bhEz7biWqwUb5tU/D9FZylpav6RFY2pQ6xwoqmZIYLCNHQ0siA90QWtElPr4v4X4tWK1 2RevSIbMsGqis6SoFOeuSR1sNMGygGGO+p25cMkSLW5ocDHtxw6aD6ukZXA6/U9oorXo bSNskB/vlO0Vk1s0SVq39k6gDnDYueaJoxrZnslSApbaY4X4FxoliJl8JxCiDctKVWrm x9jQ== 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=7IfU5R6BSdXzOlJOAyuvZ4yAYB5EXyPcbAm7okJO9Ak=; b=JA9aVifpTTw4a3+eTvJsF24weOokffkzwj7A078E9k6guGlKBAruy9fsHtLdZlrdDh Egfwt4KlZuoHDtTUBG2V8jDLhiezrP5GL3+1X1kSDRyTqaJC9hWwG+x+HNSUmMeA3t9a t+PhAk1CatQ6r7hTE3Iq1XifAdyXALdMf/tCwagRhBvq+ITZ97eplkyyjZuLcn5eWjx7 KlDhw8baJol7v8k7wjy0qF/VrzG9twmr6iEqfXQ4hRlqmXHkIgo4rKkisipXx+3m1Rat wTQoYhl87ju5SI1divGNQdQheOe7tkqm07EyeTHz4j4dbyBGaHPZGYDKOL8b7dD4d4wB KQug== X-Gm-Message-State: AOAM5310a6uROg9ZjXEj/uNqGp7MKAqXni2DJU6KhmUx+gXULUGqcF7M peHdtSnjw066QPG3WVcrML0= X-Google-Smtp-Source: ABdhPJzFCrxX/KXyOS+4o67qpbt2S26jVAdhZI4qUhKf4S8nNk1aZCGLW+18/hlJMWMQCkBqQHGfEQ== X-Received: by 2002:a17:90a:fd0f:: with SMTP id cv15mr5739297pjb.36.1612899261442; Tue, 09 Feb 2021 11:34:21 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id n15sm23103814pgl.31.2021.02.09.11.34.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Feb 2021 11:34:20 -0800 (PST) To: Sarah Banks , Eric Rescorla Cc: rfced-future@iab.org, Mark Nottingham , Eliot Lear , Brian Rosen References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> From: Brian E Carpenter Message-ID: Date: Wed, 10 Feb 2021 08:34:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 19:34:25 -0000 On 10-Feb-21 06:10, Sarah Banks wrote: > Hi, > =C2=A0 =C2=A0Inline. >=20 > >> >> >> >> The example I gave earlier applies: what if the WG decides to appr= ove a format that blind people can=E2=80=99t read? >> >> >> I think this example is quite clarifying, so I'm going to stop here. W= hile the question of whether a particular format is accessible requires s= pecialized expertise, the question of how accessible to make things is a = policy question of the kind we ordinarily leave to WGs. Why would (for in= stance) the ISE have particular insight into this matter or particular le= gitimacy to object? >> >=20 > Because the ISE might happen to have that experience from other work ex= periences. However, I would expect the RSE would have the purview here to= raise this issue, and/or object accordingly. One of the benefits here wo= uld be that while the WG is generally focused on what the WG cares about = (and less about the larger issues of the RFC Series, longevity, archival = issues, etc), that HAS been in the wheelhouse of the RSE. Further, having= a group of folks who can provide reasonable input or feedback on the iss= ues is seems prudent. The ISE in your example might not have direct exper= ience with the issue of "approving a format blind people can't read", but= when the RSE raises an objection and outlines the why, I'd expect stream= managers to understand the argument for (or against). Yes. But what strikes me in ekr's line of argument, and also in mnot's co= mment elsewhere: >> As such, I remain unconvinced that the RFC Series is a special case th= at needs extraordinary processes or powers for a designated expert. is very bluntly an implication that "we" (for some value of "we" that see= ms to mainly comprise protocol engineers) know better than an experienced= technical publisher about non-protocol-engineering aspects of technical = publishing. We don't. Brian From nobody Tue Feb 9 12:51:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B1F3A0BF2 for ; Tue, 9 Feb 2021 12:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iqDJvvFun20 for ; Tue, 9 Feb 2021 12:51:18 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B263A0BF1 for ; Tue, 9 Feb 2021 12:51:18 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id f6so20289474ioz.5 for ; Tue, 09 Feb 2021 12:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=N0pvpgvbFMbaWLzw/zmCUiqe/i/pm50jVxehi5wqAh8=; b=UYkK1AOY9wyATfZJq6wJRYXdmKqdVUMhjtIfzk7J5mcp8ibBfGvadNtFnMNnyo/SjL cv+QIe7gcG/HuAQnu+5lEwSjvcT8YDGZ/DlKHGd+cQa+/1ZDYlF5Wxq8NY5OyvRbq2JX GRfE9+I/OqW/B6gyqG69XqCPsPUxaqzkJQKQo= 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=N0pvpgvbFMbaWLzw/zmCUiqe/i/pm50jVxehi5wqAh8=; b=fpkgzP+f2NcrDV0hGBCszgsZXVRWrjbLeZnQ2th7TafkSzvrX++i/HIWsVi3ANSt+M 5RRrWg7f/wofY6VJojLYjBgf30amY+M9evKtmEL0XzS9vZ5WL1aPMCxrkPpPyrnMu8MO UoMdb3CFXpi3bOnCSjD/6mbRV6hinGezVJDzOCM1/5ptdFjnP4yuXlA4k6q7B7taZwLc h3eN+mYbusoM122TkvtDKlS2jtAZaAsXStICDI9UuI+iXGCoJFo8v1fTbcK94bjOTFvU JUB4lZpbwVfX3iWtldMAz+8H5K4M33dmR8mvEco+7l2CNdsHYHIzX/iECe4ZO5ZHXtL+ pLPQ== X-Gm-Message-State: AOAM531Wdk8hzW/HQojFRthwa8f2UBTWddvttDOBcwtl94xoD/mPh1MN k449yyltTftLY1Dxxg6K6YBpvA== X-Google-Smtp-Source: ABdhPJzUm37lUXTbmQDDquOQb4G58Dz1IGciMMYjxbf+TII+X6NUfi57jLUeeV+ZrM/vyLrgjEVckw== X-Received: by 2002:a6b:d007:: with SMTP id x7mr20756533ioa.88.1612903877807; Tue, 09 Feb 2021 12:51:17 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id h9sm10770767ili.43.2021.02.09.12.51.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Feb 2021 12:51:17 -0800 (PST) To: Brian E Carpenter Cc: rfced-future@iab.org References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> From: Peter Saint-Andre Message-ID: <2a1ffec1-7ac8-4605-8aa1-cd4fdbb25cf7@mozilla.com> Date: Tue, 9 Feb 2021 13:51:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 20:51:21 -0000 [ no hats ] On 2/9/21 12:34 PM, Brian E Carpenter wrote: > On 10-Feb-21 06:10, Sarah Banks wrote: >> Hi, >>    Inline. >> >> >>> >>> >>> >>> The example I gave earlier applies: what if the WG decides to approve a format that blind people can’t read? >>> >>> >>> I think this example is quite clarifying, so I'm going to stop here. While the question of whether a particular format is accessible requires specialized expertise, the question of how accessible to make things is a policy question of the kind we ordinarily leave to WGs. Why would (for instance) the ISE have particular insight into this matter or particular legitimacy to object? >>> >> >> Because the ISE might happen to have that experience from other work experiences. However, I would expect the RSE would have the purview here to raise this issue, and/or object accordingly. One of the benefits here would be that while the WG is generally focused on what the WG cares about (and less about the larger issues of the RFC Series, longevity, archival issues, etc), that HAS been in the wheelhouse of the RSE. Further, having a group of folks who can provide reasonable input or feedback on the issues is seems prudent. The ISE in your example might not have direct experience with the issue of "approving a format blind people can't read", but when the RSE raises an objection and outlines the why, I'd expect stream managers to understand the argument for (or against). > > Yes. But what strikes me in ekr's line of argument, and also in mnot's comment elsewhere: > >>> As such, I remain unconvinced that the RFC Series is a special case that needs extraordinary processes or powers for a designated expert. > > is very bluntly an implication that "we" (for some value of "we" that seems to mainly comprise protocol engineers) know better than an experienced technical publisher about non-protocol-engineering aspects of technical publishing. I would like to continue tugging at this thread in the interest of collective clarity. What I'm trying to understand is the mental model that people on this list have of what "technical publishing" means in our context, and what "aspects of technical publishing" are most relevant to our needs. As I said here the other day, one perspective is that *mostly* what's happening in the RFC series is that we protocol engineers are publishing documentation for other technical folks (programmers, operators, technically-minded product managers and regulators, etc.). To my mind, in several respects this feels different from the kind of technical publishing involved in, say, physics or medicine journals, scholarly books, aircraft maintenance manuals, and professional magazines. Indeed, it seems much more similar to the ongoing series of technical proposals and documents produced in communities centered on, say, programming languages like Python [1] or Rust [2] - some of which are even called RFCs (and none of which involve contributions, as far as I know, from an "experienced technical publisher"). I realize that this very pragmatic perspective might seem to relegate the RFC series to mere documentation, but I don't see it as "mere" in any way - look at what we've built since April 7, 1969. So consider this to be one end of the spectrum or a very minimal specification for what we do. If we add more features to the spec, what further "aspects of technical publishing" need to be added? Peter [1] https://www.python.org/dev/peps/ [2] https://github.com/rust-lang/rfcs From nobody Tue Feb 9 15:41:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876323A0FF2 for ; Tue, 9 Feb 2021 15:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qqUl-0h31OS for ; Tue, 9 Feb 2021 15:41:50 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3403A0FF1 for ; Tue, 9 Feb 2021 15:41:50 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id u15so198383plf.1 for ; Tue, 09 Feb 2021 15:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HMN8uZexnvwWccosID3HI3cNGn8FFDLc/VKN0+M+zNc=; b=G3mKiHLk4RcpqQsrULGHbOpNdXQr3icJWDg/M/6NMKMyOc79D+pR9Y8/pG9kAUjMLT si6SJ9IjG5YfryYi8Ym3r5MgPoO3EP4DFAQxyoKdHry9qd/a4XQ/r/+oqYnZKONlBDu7 GTXNpW71mpKHQz5Pt9qPX60Yf4qCTSGltdYJDxJL7fwxvbwbJibyx5c6ARtY40pKU+ne 8PrzLuCeemjOk0o3zTpIny14cRV3n0wajFxGcVOU128QhN0TtNXiUDVZCvgf+T6rL5Xn WkCJl/mP/PXKx4IADEqws4YXDt7tfJ240qjoaJDLE3qAoLTdK8tXCAODNkTvH9lXVnss rUYw== 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=HMN8uZexnvwWccosID3HI3cNGn8FFDLc/VKN0+M+zNc=; b=HWm3yT2V73WcqWT1Jz8E0Y/3vhzvK4DHxWGJa0k2P/feeFudRlsi/flSMeYUlb+4Xf 0k7xa3cNyHL6fxlAhs24Dd+8cZkC57eofrvW77/BI1pzq0aTCivgZpDJQXs0UVFe3LAm vmgNNVJL1IUOvbv6jMPPE+59lndC+fBTrQ58OBGbLMQqXRyj07QEAQqUnnIOTEJ4i3Da fIGL+SyYA8wUW46/aGZQRcfDbuKI0++pZ8u5/CkKyxFvZfTKNR6funMa3XnRBpxrd6G2 VRHWqg7b6VqFmW8ii8nLi9y0fApsCe8vb39usU161xAiM1/vtyKpEzo8bSYnoQPDsWco TJGQ== X-Gm-Message-State: AOAM530TxV5jIBWDgE+KUs+r6eIMzlFqepV7wf6R8eWfQR+gGEwKR4cm U8zIN5SGebmTqjcESWdduoxL01TCSAMI2w== X-Google-Smtp-Source: ABdhPJyqn1ymjY/o2QM5ss3eMyS0XryfQLHVSjhrcoZOepdzgCJJHKUMGyEeH/WWSQShUHjt36NH6w== X-Received: by 2002:a17:902:cecc:b029:e1:268e:2286 with SMTP id d12-20020a170902ceccb02900e1268e2286mr293376plg.62.1612914109590; Tue, 09 Feb 2021 15:41:49 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id w83sm30001pfc.220.2021.02.09.15.41.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Feb 2021 15:41:48 -0800 (PST) To: Peter Saint-Andre Cc: rfced-future@iab.org References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> <2a1ffec1-7ac8-4605-8aa1-cd4fdbb25cf7@mozilla.com> From: Brian E Carpenter Message-ID: <86d2289f-2f10-b4e6-41db-862d382d0671@gmail.com> Date: Wed, 10 Feb 2021 12:41:44 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2a1ffec1-7ac8-4605-8aa1-cd4fdbb25cf7@mozilla.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 23:41:53 -0000 Peter, > If we add more features to the spec, what > further "aspects of technical publishing" need to be added? If I knew that, I'd be an expert in technical publishing. That's why (IMH= O) we need one, and profited greatly from having one for a number of year= s. We've collectively developed quite a strong dose of hubris, IMNSHO, and w= e don't know what we don't know. Regards Brian On 10-Feb-21 09:51, Peter Saint-Andre wrote: > [ no hats ] >=20 > On 2/9/21 12:34 PM, Brian E Carpenter wrote: >> On 10-Feb-21 06:10, Sarah Banks wrote: >>> Hi, >>> =C2=A0 =C2=A0Inline. >>> >>> >>>> >>>> >>>> >>>> The example I gave earlier applies: what if the WG decides to ap= prove a format that blind people can=E2=80=99t read? >>>> >>>> >>>> I think this example is quite clarifying, so I'm going to stop here.= While the question of whether a particular format is accessible requires= specialized expertise, the question of how accessible to make things is = a policy question of the kind we ordinarily leave to WGs. Why would (for = instance) the ISE have particular insight into this matter or particular = legitimacy to object? >>>> >>> >>> Because the ISE might happen to have that experience from other work = experiences. However, I would expect the RSE would have the purview here = to raise this issue, and/or object accordingly. One of the benefits here = would be that while the WG is generally focused on what the WG cares abou= t (and less about the larger issues of the RFC Series, longevity, archiva= l issues, etc), that HAS been in the wheelhouse of the RSE. Further, havi= ng a group of folks who can provide reasonable input or feedback on the i= ssues is seems prudent. The ISE in your example might not have direct exp= erience with the issue of "approving a format blind people can't read", b= ut when the RSE raises an objection and outlines the why, I'd expect stre= am managers to understand the argument for (or against). >> >> Yes. But what strikes me in ekr's line of argument, and also in mnot's= comment elsewhere: >> >>>> As such, I remain unconvinced that the RFC Series is a special case = that needs extraordinary processes or powers for a designated expert. >> >> is very bluntly an implication that "we" (for some value of "we" that = seems to mainly comprise protocol engineers) know better than an experien= ced technical publisher about non-protocol-engineering aspects of technic= al publishing. >=20 > I would like to continue tugging at this thread in the interest of > collective clarity. >=20 > What I'm trying to understand is the mental model that people on this > list have of what "technical publishing" means in our context, and what= > "aspects of technical publishing" are most relevant to our needs. >=20 > As I said here the other day, one perspective is that *mostly* what's > happening in the RFC series is that we protocol engineers are publishin= g > documentation for other technical folks (programmers, operators, > technically-minded product managers and regulators, etc.). >=20 > To my mind, in several respects this feels different from the kind of > technical publishing involved in, say, physics or medicine journals, > scholarly books, aircraft maintenance manuals, and professional > magazines. Indeed, it seems much more similar to the ongoing series of > technical proposals and documents produced in communities centered on, > say, programming languages like Python [1] or Rust [2] - some of which > are even called RFCs (and none of which involve contributions, as far a= s > I know, from an "experienced technical publisher"). I realize that this= > very pragmatic perspective might seem to relegate the RFC series to mer= e > documentation, but I don't see it as "mere" in any way - look at what > we've built since April 7, 1969. >=20 > So consider this to be one end of the spectrum or a very minimal > specification for what we do. If we add more features to the spec, what= > further "aspects of technical publishing" need to be added? >=20 > Peter >=20 > [1] https://www.python.org/dev/peps/ >=20 > [2] https://github.com/rust-lang/rfcs >=20 From nobody Tue Feb 9 15:52:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C91A3A1027 for ; Tue, 9 Feb 2021 15:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=baerPjoC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vb8PMKRP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8HgwB8o1i2a for ; Tue, 9 Feb 2021 15:52:19 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF3F3A1019 for ; Tue, 9 Feb 2021 15:52:19 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 025E55C00B4; Tue, 9 Feb 2021 18:52:18 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 09 Feb 2021 18:52:18 -0500 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=fm1; bh=a 6V3TEiJwel5/pzNHidMXfSt4Y+SzLwLHuCj/0v0j9Y=; b=baerPjoCPFzilaVII 6V/YvVrBUX60Q6kBk+QWFbtIA2Lq96c1u7NLcBhyr7SL9W6nOyyr7wcRmdrD0H6O PY6NwduUU6aQApO4toiTUlXg6+wM1qtNN8joq2OVBD6VpG5XdoPDxAcO5VO+7Gwc GUSf9XOuoKePVfVDTAy5Dj4byPzF5I5rCEHnqpdzHIC9enRDC+a15hzl4Y5XjNE0 055IVscTEerWylktEmpGb78n/0c5fKrf4QOyedyA/V7OT4871UYLdi9L1AzdSFW7 I/jlGYKZ5y7LVnRZORWc+aT2EsPr0givBQDsxo+qWWxHkOWrSLGbfCicn/NTxoA+ lq7zg== 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=a6V3TEiJwel5/pzNHidMXfSt4Y+SzLwLHuCj/0v0j 9Y=; b=vb8PMKRPXhqcWZDcqhGy66B5/hMwUu4yd6q9MkCQSHmvhxAXtUaZznTfA cB3mLoxFn9NaXSVsOFahRC1SIaHu3y7o0BOHIJYTo832rk55JlqDDmmqN1lqtxa0 cDVyOMFa8NiF/hpya8zjFa9QyuRN8qhkok7JFTSldMQGF5gX0DOfJcHOond5xUSO Ns6eS853mlrCY4jILkDXMeZQY+9FBOeIOgNqYp9+qzUl87K1KUdIDLjm9rMuQC6E pDuozcN2WTDXec/gSVYkOTkVHCBTuCZ/AEAqwJ6REegc1KnTSlML2lxZzZhXMRZo W6w8zi30TykaOUtDmbaHVtKdco7fA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrheeigdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhe dunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 4843C240064; Tue, 9 Feb 2021 18:52:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: Date: Wed, 10 Feb 2021 10:52:06 +1100 Cc: Sarah Banks , Eric Rescorla , rfced-future@iab.org, Eliot Lear , Brian Rosen Content-Transfer-Encoding: quoted-printable Message-Id: <350C3505-DBC4-4B02-B13C-8740BD131D49@mnot.net> References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 23:52:21 -0000 On 10 Feb 2021, at 6:34 am, Brian E Carpenter = wrote: >=20 > Yes. But what strikes me in ekr's line of argument, and also in mnot's = comment elsewhere: >=20 >>> As such, I remain unconvinced that the RFC Series is a special case = that needs extraordinary processes or powers for a designated expert. >=20 > is very bluntly an implication that "we" (for some value of "we" that = seems to mainly comprise protocol engineers) know better than an = experienced technical publisher about non-protocol-engineering aspects = of technical publishing. >=20 > We don't. And that implies that your perspective is that this person always = "know[s] better" than the community, on every issue that they care to = have an opinion about.=20 It also implies that the community is so obstinate as to ignore that = person's well-supported and informed arguments in WG discussion, ignore = the objections they make when a decision is made, and that the appeals = process is so weak that that person is overruled throughout its = application. It also implies that the folks on this thread who seem to = want to unconditionally support this person would also be ignored and = overruled throughout that process. Is there any example to date of an RFC Editor needing to exercise these = powers against this straw-man pig-headed community? Even with expert help that has extraordinary powers, there is no = guarantee that the right decisions will be made. What are you *really* = engineering for here? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Feb 9 15:55:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6903A102D for ; Tue, 9 Feb 2021 15:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 6gq3p7yLC35I for ; Tue, 9 Feb 2021 15:55:22 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AB23A1028 for ; Tue, 9 Feb 2021 15:55:21 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id m22so186091lfg.5 for ; Tue, 09 Feb 2021 15:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GplluLrWWdLyaxum2lAVKiCf45YjSk6zxPhMlqn87O0=; b=pK60+SQB3dcvY5QyTYTFdnnTvybEMqA9HSVoqanyulYBPYYsjlMWdzoffUhnNIeSsC S86w3pL5KpO1v53pJolq13k6ukRQyLQUWMCm5nzGVAqEGWsHOsfapck1iujRrh/XnGh4 v6Z9IerNJzZGVqNzQ2TL7Xp6DbSegPuUETv2BVL16S/YaYiRMaZGZuRSwkjEKKz81p4x h7NXeE8SERsyaL5qc1SzqluRuEKMLYbbzo+/YPvsno9UKdcXKBQBJNBLDR4bHNnie1nF 1OWO/TrO0tgoKlJCAMVK11tvB08X6S8btdNvfZMJGqIP1oOMwMJYAbnQvwkoRzAcIcch Ntbg== 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=GplluLrWWdLyaxum2lAVKiCf45YjSk6zxPhMlqn87O0=; b=i/jKZqPjKK+lUiTUyCmawfEX6SRgigOkI5a9dnX5ol5jsz88QxIM8sx2HZqclu0eM5 QkNqvMqm2XoAhEput9Q+g17WKb6uHsnmJ80UOVxqCwLvrBqHGRcXprjwZHo7prZAvIyN 4tgLJFT8HlmLVdFAGVyN+eQkXAgV1dkFfH07Tv62bFiOHv2JWgWcmLJWBwDj8lV+ecyL ktuK6oFcmE7r5DLDW0YuiWOxEI+8LcUaaUSHkgLisR2dWoR+QNK1RlN/U7+HOpg6xFYB KUY88kC3yAzF9M87oWOwmdU1yKwhhp4Trah6Z4OT3dcOTixOFghI4lh/0a4dZHYfjxVC nRCQ== X-Gm-Message-State: AOAM532B+OPGZJOjyPdE3qeV/e3HageRmW8lXNX+lSXdMMAjPuUOYjmz FYpHVoSMiDtvI2Pnt4wzcaUhWpR1Vq3xtJM/KbVoQw== X-Google-Smtp-Source: ABdhPJwa34lD/BjsGuA7HnrBMxzhfW8vzWQCKoxD95ONaXIlkR7pkt46kTM0md+gRxzMrKFWRukFyJLv3WLd1thOyoM= X-Received: by 2002:ac2:5086:: with SMTP id f6mr233676lfm.16.1612914920156; Tue, 09 Feb 2021 15:55:20 -0800 (PST) MIME-Version: 1.0 References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> In-Reply-To: From: Eric Rescorla Date: Tue, 9 Feb 2021 15:54:44 -0800 Message-ID: To: Brian E Carpenter Cc: Sarah Banks , rfced-future@iab.org, Mark Nottingham , Eliot Lear , Brian Rosen Content-Type: multipart/alternative; boundary="000000000000de80a105baf004ff" Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Feb 2021 23:55:24 -0000 --000000000000de80a105baf004ff Content-Type: text/plain; charset="UTF-8" On Tue, Feb 9, 2021 at 11:34 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Yes. But what strikes me in ekr's line of argument, and also in mnot's > comment elsewhere: > > >> As such, I remain unconvinced that the RFC Series is a special case > that needs extraordinary processes or powers for a designated expert. > > is very bluntly an implication that "we" (for some value of "we" that > seems to mainly comprise protocol engineers) know better than an > experienced technical publisher about non-protocol-engineering aspects of > technical publishing. > > We don't. > Well, that's not what I'm saying, at least. What I'm saying is that we (in this case the prospective members of the WG) are the group with the legitimacy to make decisions. That doesn't mean not consulting experts, but it means that the final decision making ought to rest with the community. This doesn't seem to me to be a particularly unusual notion. Here are two examples: - The IETF LLC engages a lawyer to advise it on legal matters, but ultimately makes the decisions with the lawyers advice (I think I have given this example before). - It's quite common in political systems to have departments staffed by career civil servants who have subject matter expertise but to ultimately accountable (typically headed) to political appointees who may or may not have subject matter expertise. My position is that it's the job of the community to take in expert input/advice, including, but not limited to that of the RSE/A, and balance it against other factors and ultimately come to a decision. -Ekr > Brian > > --000000000000de80a105baf004ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 9, 2021 at 11:34 AM Brian= E Carpenter <brian.e.carpenter@gmail.com> wrote:
Yes. But what strikes me in ekr's lin= e of argument, and also in mnot's comment elsewhere:

>> As such, I remain unconvinced that the RFC Series is a special cas= e that needs extraordinary processes or powers for a designated expert.

is very bluntly an implication that "we" (for some value of "= ;we" that seems to mainly comprise protocol engineers) know better tha= n an experienced technical publisher about non-protocol-engineering aspects= of technical publishing.

We don't.

Well, that's not what= I'm saying, at least. What I'm saying is that we (in this case the= prospective members of the WG) are the group with the legitimacy to make d= ecisions. That doesn't mean not consulting experts, but it means that t= he final decision making ought to rest with the community. This doesn't= seem to me to be a particularly unusual notion. Here are two examples:
=

- The IETF LLC engages a lawyer to advise it on l= egal matters, but ultimately makes the decisions with the lawyers advice (I= think I have given this example before).
- It's quite common= in political systems to have departments staffed by career civil servants = who have subject matter expertise but to ultimately accountable (typically = headed) to political appointees who may or may not have subject matter expe= rtise.

My position is that it's the job of the= community to take in expert input/advice, including, but not limited to th= at of the RSE/A, and balance it against other factors and ultimately come t= o a decision.

-Ekr


=C2=A0 =C2=A0Brian

--000000000000de80a105baf004ff-- From nobody Tue Feb 9 16:04:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBAC3A1043 for ; Tue, 9 Feb 2021 16:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 OW5MJokZ_rDR for ; Tue, 9 Feb 2021 16:04:49 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641803A1042 for ; Tue, 9 Feb 2021 16:04:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Db0PY0Mllz6G9vM; Tue, 9 Feb 2021 16:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612915489; bh=u9L/NoTMAOH1V3uPvFPItP/qs8o9j4GvAcLja4vMhqk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TXqeF/xqH3Y7etxL3oTexW1tvBeLnvt8L8HToTZCxOtEHE4y4g29wPiJ+uZ7FVAMl wm1px2M7LSsmR1kEbCC2yT7IDJQuPnAFXCmOu4mnxtO6a0Qf+fvFd5Yk5SLK66n1K/ zcelRNvIxnifGyRJ1QTMNmvuurGF+hDLbIN/ca/Y= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4Db0PX3yVnz6G7vj; Tue, 9 Feb 2021 16:04:48 -0800 (PST) To: Mark Nottingham Cc: rfced-future@iab.org References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> <350C3505-DBC4-4B02-B13C-8740BD131D49@mnot.net> From: "Joel M. Halpern" Message-ID: <841915a1-2702-dcd9-4619-5fdb585804f7@joelhalpern.com> Date: Tue, 9 Feb 2021 19:04:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <350C3505-DBC4-4B02-B13C-8740BD131D49@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Feb 2021 00:04:51 -0000 Mark, your quesiton of whether an RSE has needed to exercise such authority seems oddly formed since the very different operating structure probably renders the question historically meaningless. On the other hand, we do have evidence of cases where it took a forceful AD to get a working group to do the right things technically. Given that we have seen this in areas where we have real expertise, I find myself concluding that such need is more likely in a situation where the WG participants have less expertise. Yours, Joel On 2/9/2021 6:52 PM, Mark Nottingham wrote: > On 10 Feb 2021, at 6:34 am, Brian E Carpenter wrote: >> >> Yes. But what strikes me in ekr's line of argument, and also in mnot's comment elsewhere: >> >>>> As such, I remain unconvinced that the RFC Series is a special case that needs extraordinary processes or powers for a designated expert. >> >> is very bluntly an implication that "we" (for some value of "we" that seems to mainly comprise protocol engineers) know better than an experienced technical publisher about non-protocol-engineering aspects of technical publishing. >> >> We don't. > > And that implies that your perspective is that this person always "know[s] better" than the community, on every issue that they care to have an opinion about. > > It also implies that the community is so obstinate as to ignore that person's well-supported and informed arguments in WG discussion, ignore the objections they make when a decision is made, and that the appeals process is so weak that that person is overruled throughout its application. It also implies that the folks on this thread who seem to want to unconditionally support this person would also be ignored and overruled throughout that process. > > Is there any example to date of an RFC Editor needing to exercise these powers against this straw-man pig-headed community? > > Even with expert help that has extraordinary powers, there is no guarantee that the right decisions will be made. What are you *really* engineering for here? > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Tue Feb 9 16:11:04 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720293A1048 for ; Tue, 9 Feb 2021 16:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=T897oBNj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uWq4/e6J Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGRmvZl-igo9 for ; Tue, 9 Feb 2021 16:11:01 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994443A1045 for ; Tue, 9 Feb 2021 16:11:01 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AC3D55C0113; Tue, 9 Feb 2021 19:11:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 09 Feb 2021 19:11:00 -0500 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=fm1; bh=W HCY7b4BEpa7WfhmfBcOew/k5usiMcoOOIe6zwD1POE=; b=T897oBNjkhBKHTm1k s9XRW/zzgG1igr0wnIkcv+K/iowyzyxl1JXsawVdNTM6m0HJ2NXmnNe2FZlbNAG4 2mGRH2W2PvUkdfWpMYssmQcNlI2YJpTu1rQAvTuePJqQO9LbfjxcGXHhFVmGsm3i 0sTrqDogoCm9Fp9tD9+6jJLsGtJndnuF+cj+Q3QdJpQ6wi/RT6gzBCTzOtS95A5O TeOeAvdX3ZCQY6rVQjbqWiLsCyXlhk5LWHJ40beqEta1TMLCnZp04x8TXMnYAHua XHyi4QeKp8Oz/X6YCAYkqhGHeb+ilYzQ3ChAf+crwFE0FtLNrYVs9B1JoqqVbKbA jFurw== 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=WHCY7b4BEpa7WfhmfBcOew/k5usiMcoOOIe6zwD1P OE=; b=uWq4/e6J4vlg801ncFyQF7QFkRaoq7jImwtO0yb2rv/jr1eXfUk3vKb4u dWommUKdoyyJ7xvfHjdBIsarNcA67NZY8oGfteR0ULtTpENXMImgtjLjKViYWj76 R6PEpDjzm+OAkc52zrXZt2I4EG0UH5qUChpC/dmk1KzYyIWSsatu0itm4RrnVo5Y CIxCjAJ/XcMmWkKcDYVVLdZaYya1TuMDQDo+Je9aACKO4x86E3wQY+RIkoyn2KSq xrm+OnzSjo0BOXjO+rWwc8KudcZZNhtAyKev2sX8nU1vTCIJY3uuO8Q6iFd0LdU8 DRGpWHkr9smsQViRkKVNPcrzPQghg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrheeigddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeevffffhfduteevvefhueffieegtdeutd ehffeltefffedttdeggeejheeiueetteenucffohhmrghinhepmhhnohhtrdhnvghtnecu kfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 97B5824005E; Tue, 9 Feb 2021 19:10:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: <841915a1-2702-dcd9-4619-5fdb585804f7@joelhalpern.com> Date: Wed, 10 Feb 2021 11:10:55 +1100 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> <350C3505-DBC4-4B02-B13C-8740BD131D49@mnot.net> <841915a1-2702-dcd9-4619-5fdb585804f7@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Feb 2021 00:11:03 -0000 > On 10 Feb 2021, at 11:04 am, Joel M. Halpern = wrote: >=20 > Mark, your quesiton of whether an RSE has needed to exercise such = authority seems oddly formed since the very different operating = structure probably renders the question historically meaningless. I was asking if there's a basis in history for granting an RSA/E special = powers. We've had a person with those broad powers for a fair chunk of = time (in various specific forms); I think it's relevant to ask if = they've been used.=20 > On the other hand, we do have evidence of cases where it took a = forceful AD to get a working group to do the right things technically. = Given that we have seen this in areas where we have real expertise, I = find myself concluding that such need is more likely in a situation = where the WG participants have less expertise. That may be, and I'm not necessarily against this person having *any* = special consideration/weight in the process. However, if they have such = powers, there should be corresponding constraints on them -- just as = there are for an AD. And it needs to be more than 'the LLC decides = whether to renew the contract' -- that's too indirect. Cheers, >=20 > Yours, > Joel >=20 > On 2/9/2021 6:52 PM, Mark Nottingham wrote: >> On 10 Feb 2021, at 6:34 am, Brian E Carpenter = wrote: >>>=20 >>> Yes. But what strikes me in ekr's line of argument, and also in = mnot's comment elsewhere: >>>=20 >>>>> As such, I remain unconvinced that the RFC Series is a special = case that needs extraordinary processes or powers for a designated = expert. >>>=20 >>> is very bluntly an implication that "we" (for some value of "we" = that seems to mainly comprise protocol engineers) know better than an = experienced technical publisher about non-protocol-engineering aspects = of technical publishing. >>>=20 >>> We don't. >> And that implies that your perspective is that this person always = "know[s] better" than the community, on every issue that they care to = have an opinion about. >> It also implies that the community is so obstinate as to ignore that = person's well-supported and informed arguments in WG discussion, ignore = the objections they make when a decision is made, and that the appeals = process is so weak that that person is overruled throughout its = application. It also implies that the folks on this thread who seem to = want to unconditionally support this person would also be ignored and = overruled throughout that process. >> Is there any example to date of an RFC Editor needing to exercise = these powers against this straw-man pig-headed community? >> Even with expert help that has extraordinary powers, there is no = guarantee that the right decisions will be made. What are you *really* = engineering for here? >> Cheers, >> -- >> Mark Nottingham https://www.mnot.net/ -- Mark Nottingham https://www.mnot.net/ From nobody Tue Feb 9 17:02:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99893A10E9 for ; Tue, 9 Feb 2021 17:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ORkt06LEi9DG for ; Tue, 9 Feb 2021 17:02:22 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E723A10F5 for ; Tue, 9 Feb 2021 17:02:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Db1gy2bPPz6GM7w; Tue, 9 Feb 2021 17:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612918942; bh=sHVgc9GKHUKAq2T1sWA5a6zCfI44jyHb+9kdOw0MXmU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nlL1SJBTKEEF3uXyWVgoPrfNgMuoUWNIKZvP8xnKUkQSq4tkYvfjyfRb5u+7P7bsP /1J3Q0MnXhNnFNEMUkGrdngf3ICwrw6Jhv9AZev4ArisyDDmhPwq/yLka7o6eQ+QUR Bml/5JmwAtvVxcnXxQfzipydSn9eiAOOo+q0TQ2M= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4Db1gx564sz6G9nf; Tue, 9 Feb 2021 17:02:20 -0800 (PST) To: Eric Rescorla Cc: rfced-future@iab.org References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> From: "Joel M. Halpern" Message-ID: <4c52a888-625d-2add-c108-863802734abc@joelhalpern.com> Date: Tue, 9 Feb 2021 20:02:20 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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 approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Feb 2021 01:02:24 -0000 I think the analogy with the LLC's lawyer may well be misleading. If the LLC ignores the lawyer's advice when he is right, there are external forces which are likely to make the issue rather material. The forces at work in the RFC process are far more indirect. Hence the pressures on the WG to listen to the RSE are very different from the pressures on the LLC to listen to the lawyer. (The fact that we went further and put another lawyer on the LLC board itself can be argued to further this point.) Yours, Joel On 2/9/2021 6:54 PM, Eric Rescorla wrote: > > > On Tue, Feb 9, 2021 at 11:34 AM Brian E Carpenter > > wrote: > > Yes. But what strikes me in ekr's line of argument, and also in > mnot's comment elsewhere: > > >> As such, I remain unconvinced that the RFC Series is a special > case that needs extraordinary processes or powers for a designated > expert. > > is very bluntly an implication that "we" (for some value of "we" > that seems to mainly comprise protocol engineers) know better than > an experienced technical publisher about non-protocol-engineering > aspects of technical publishing. > > We don't. > > > Well, that's not what I'm saying, at least. What I'm saying is that we > (in this case the prospective members of the WG) are the group with the > legitimacy to make decisions. That doesn't mean not consulting experts, > but it means that the final decision making ought to rest with the > community. This doesn't seem to me to be a particularly unusual notion. > Here are two examples: > > - The IETF LLC engages a lawyer to advise it on legal matters, but > ultimately makes the decisions with the lawyers advice (I think I have > given this example before). > - It's quite common in political systems to have departments staffed by > career civil servants who have subject matter expertise but to > ultimately accountable (typically headed) to political appointees who > may or may not have subject matter expertise. > > My position is that it's the job of the community to take in expert > input/advice, including, but not limited to that of the RSE/A, and > balance it against other factors and ultimately come to a decision. > > -Ekr > > > >    Brian > > From nobody Tue Feb 9 17:28:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C59F3A1143 for ; Tue, 9 Feb 2021 17:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTsNitvh4AUQ for ; Tue, 9 Feb 2021 17:28:38 -0800 (PST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDE83A1141 for ; Tue, 9 Feb 2021 17:28:38 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id q72so204473pjq.2 for ; Tue, 09 Feb 2021 17:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=j3segI52fUfTVcFiOYTgu0mfoQ7+kW04bFOZepEYGIE=; b=jpgcfs6hnGgjFvWcuoQUh28W6I6XhT9jLiEceShb8Pueq2Zv6V7LNGCaJJIq+OIwI1 YpQyT7L6YqQyEuYiDapRYVBoFLm/SJEfewPCtEXtHuka5w/ZDfg2lQJpPNz8+9pU2bZ9 PnvUB2RcNbQi2vIcqIz4bz2zhYfwg0zvBRlaWz/qgdGlO7onBgPsHniOj3VoYfVwNamm VOzJvFB89lUJBFN6YjBzKbRc4HjccuJmjXj7iaplOlGdTJvN0BMQkArCaaMkOy/FrYUo yPSYkNHDLj/q2CLZNNSB5MKazshyXErit7awZJ4Vkx8j7GU76sa+5+6Ty60Oa7z0+N6W kldA== 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=j3segI52fUfTVcFiOYTgu0mfoQ7+kW04bFOZepEYGIE=; b=hVK0niyFObCbvLp9BqrR1eKLJuhIPn/OaF9nZzpswfYLk86z9H6NFjNm0KVAvzg/R+ qWgZE4yDQLAQdzznU1hitV2ze5QXgiLoDOJKJwXoieMFZ/ngoiiYPIqIxWh5jtBouQwK Y1mOkaaG+Anu/Or/PaDFUWnWeRRHdbFZRPF+/m6KaG8pN+lOj5eY3JHAAUdmSvF4+8+1 Mst4EFxrB41IfIrQWmg1dm1VrB3h/C6Spc/ENcIfJsbDgW2bh/DDUHzpcnTCC16Mipc7 enDeCcJTcLaYuADjl2uwOnyVw62eYKU7NoMxD0WEf6tovi9RNpbf3y+IE5mMyH15Kz+X G1Cg== X-Gm-Message-State: AOAM530IBYul8wq8X4jMaWrMAC6HBRvmjq7q4Ewhvft3y3EvFpdnrcEr qOxfBcFljXrav9F6l11Uhos= X-Google-Smtp-Source: ABdhPJydbtN67GYDPIALSvR+XUMW+KPLGWzSlKny714yfT0P8CNxNidGiL6I6VxmoteMBhuTWADzYQ== X-Received: by 2002:a17:90b:4c85:: with SMTP id my5mr668598pjb.225.1612920517644; Tue, 09 Feb 2021 17:28:37 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id j7sm151824pfh.147.2021.02.09.17.28.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Feb 2021 17:28:37 -0800 (PST) To: Eric Rescorla Cc: Sarah Banks , rfced-future@iab.org, Mark Nottingham , Eliot Lear , Brian Rosen References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> From: Brian E Carpenter Message-ID: <10f03895-1738-861a-f3ee-157af857d9c1@gmail.com> Date: Wed, 10 Feb 2021 14:28:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Feb 2021 01:28:40 -0000 On 10-Feb-21 12:54, Eric Rescorla wrote: >=20 >=20 > On Tue, Feb 9, 2021 at 11:34 AM Brian E Carpenter > wrote: >=20 > Yes. But what strikes me in ekr's line of argument, and also in mno= t's comment elsewhere: >=20 > >> As such, I remain unconvinced that the RFC Series is a special c= ase that needs extraordinary processes or powers for a designated expert.= >=20 > is very bluntly an implication that "we" (for some value of "we" th= at seems to mainly comprise protocol engineers) know better than an exper= ienced technical publisher about non-protocol-engineering aspects of tech= nical publishing. >=20 > We don't. >=20 >=20 > Well, that's not what I'm saying, at least. What I'm saying is that we = (in this case the prospective members of the WG) are the group with the l= egitimacy to make decisions. That doesn't mean not consulting experts, bu= t it means that the final decision making ought to rest with the communit= y. This doesn't seem to me to be a particularly unusual notion. Here are = two examples: >=20 > - The IETF LLC engages a lawyer to advise it on legal matters, but ulti= mately makes the decisions with the lawyers advice (I think I have given = this example before). > - It's quite common in political systems to have departments staffed by= career civil servants who have subject matter expertise but to ultimatel= y accountable (typically headed) to political appointees who may or may n= ot have subject matter expertise. >=20 > My position is that it's the job of the community to take in expert inp= ut/advice, including, but not limited to that of the RSE/A, and balance i= t against other factors and ultimately come to a decision. Yes, I find it hard to disagree with that position. I think what are real= ly talking about is the sanity-check level, where in the IETF we have qui= te a superstructure today: the formal review teams, the IETF Last Call pr= ocess, and the IESG review and DISCUSS process, which both you and I have= been part of in the past. What we're talking about is the equivalent superstructure for the RFC series' own documents, and specifically how th= e "lawyer-equivalent" role fits into that. I'm uncomfortable that the exp= ert's last chance to raise objections is (in effect) at the WG Last Call = stage. In the IESG analogy, there is further expert review during the app= roval process. I care about that, not so much about voting rules. Brian >=20 > -Ekr >=20 >=20 >=20 > =C2=A0 =C2=A0Brian >=20 From nobody Tue Feb 9 17:34:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75613A1149 for ; Tue, 9 Feb 2021 17:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=A4zpXZuQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wjrRiTeS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-gB297f8ZFS for ; Tue, 9 Feb 2021 17:34:03 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37733A1147 for ; Tue, 9 Feb 2021 17:34:02 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F3DC85C019D; Tue, 9 Feb 2021 20:34:01 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 09 Feb 2021 20:34:01 -0500 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=fm1; bh=W pukQIhkZZ1+P9xrrJtm9rNinZhj8mytTCSzkOGAYHs=; b=A4zpXZuQkEs4ukSjc HyrVV7xMfvsfdr/mIw26iWt17iVzuhqp4pVU1X1TTQjH2wvkgaS6+PxrlkNryUzp 0aMmTenZUqfjGNNQw/r6SxrB8jmpK/jZIVlGY161FjzCKTV7h4ImLHOV9clGozxm 37gjIVO66Ph5SXAG5BfF3hlZAAZJeDmLNPwtoITqtwuMoNCVUSbxaYUjZrssXTPn KIfPv+bsX6A7w2ctVUm+jPoTD/jMH6J24zJlYZaD8VIcsbvmD/OUy3eeO5liyCcj W9ldtN9SUQWkyGTSMc5O9gE1NbFQU0ltjbqsf8R6tj+VdoeInkF1MQwFfrBCXhv6 k5NWg== 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=WpukQIhkZZ1+P9xrrJtm9rNinZhj8mytTCSzkOGAY Hs=; b=wjrRiTeSAZrbqWtbs0UglJYJJArjNye5ZcMo0a0XPecGWiMGINyQY2mb2 yEDwvOdtB3u5WzfRBvrfBo21YNMzUoTaJDf3PpfL7iFDk4NUCiHw4ewAyhp5WcOd XsQFqRfQN3ftvdYpNONBW+b3sVXGb6Rk2R1VFj5Ngfn2oxNkBES+BzX7UppglPPZ g/A7BPLPuiCBM6MhbliL3ISL8l3nh7tfDkkJeY4j7uw41o9XIIYsoEAmBaceqjMW StWO8PB4uR481qfGb5Hk9/LqGcgrRlLSdobKEWOalMfeVgWYLlOkWQ9gyvv58zfj kiDrzF14JOIyldEZovH0R/JUWJjgA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrheeigdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhe dunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 8284C1080069; Tue, 9 Feb 2021 20:33:57 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: <10f03895-1738-861a-f3ee-157af857d9c1@gmail.com> Date: Wed, 10 Feb 2021 12:33:52 +1100 Cc: Eric Rescorla , Sarah Banks , rfced-future@iab.org, Eliot Lear , Brian Rosen Content-Transfer-Encoding: quoted-printable Message-Id: References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> <10f03895-1738-861a-f3ee-157af857d9c1@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Feb 2021 01:34:05 -0000 > On 10 Feb 2021, at 12:28 pm, Brian E Carpenter = wrote: >=20 > I'm uncomfortable that the expert's last chance to raise objections is = (in effect) at the WG Last Call stage. In the IESG analogy, there is = further expert review during the approval process. I care about that, = not so much about voting rules. I'd be very supportive of a notion that the expert's input gets = highlighted in all post-WG stages. I'd been assuming that it would be = included in their deliberations as a matter of course (as would all = objections / feedback), but calling it out seems appropriate, especially = since we're paying for that advice. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Feb 9 18:01:04 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF623A11AC for ; Tue, 9 Feb 2021 18:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETIb68TzidsM for ; Tue, 9 Feb 2021 18:01:00 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24C83A11A9 for ; Tue, 9 Feb 2021 18:01:00 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id e9so356057plh.3 for ; Tue, 09 Feb 2021 18:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ihwFNp4kabyahBBv8y5mJLnbaFP0DCDTm+K+LwTIxZ8=; b=En765rcRZM6fmhvmlz1yxvJkfefsWrkMJqs1chQTbf+x0gxjNmrOqLTcOdS+a2OID3 Kw61YRL307cVbtoVXPdc5Ej5AUl4LFcZWRDYO0V4NWnl7a8Bc/6Z9Jt9qj2BPdyJbf0R 3BuaVUNP/DDHFtemxN9bvct2PZn/mf/syhcIj0TSzE94uzRkEoC9Y9uXULHJYImDNb8Y p9VbYshR6LKZI715n8xzL8YJGNzVfSyxg/Avdr7pcGnBm9u//A4MFtfktycXq3kPhdl1 /kFayNIhq587btkwy2xjuPJ2Ww/rDS31R8Ds2tr1rUeD9wqV0SYnhmvKC7nI8/6hIZQr a2ow== 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=ihwFNp4kabyahBBv8y5mJLnbaFP0DCDTm+K+LwTIxZ8=; b=SX4yoZUNHtHuYAYksqk8nt2Fh2HiJ5N3l2ruGJ7Dnh5wPehtN7BzgdYtO2PY3ic4Ay zWn8ToyeTOwbaqId4KFwzCYV7e8ATw0RnVDki+8tHFC0nfc51jzgnw84W4FlswYI0ezB huChFljwyFYxX4UORv3QR5qCxKC589gttDaR1jx4KLVgwUAZWblIEsUni2U+B8rBUm8G HwdYS2qaFAWv8qyJGzAKWSaDPXQoSICyEvpbeiDV4KfuDl1vqSiqS0/hzBUaGJppeXzA RJW92udi2VOWTzxu9D1y0lKTpbTZYvQlSFT9/DBx+BwSbGQimb307Q/vCH59bIRqhOK3 +wBA== X-Gm-Message-State: AOAM532livCPxyTMPl5WqNLXX/lzZeTXNTXf7fNb8hXmYRoapLEZ5a1z WT/rt9fySMTYxFz74QL1W3vqsn9KraCiag== X-Google-Smtp-Source: ABdhPJyJHRcOPYqWw45xDrG5BRc7tThsp7tj6VM6qADknQL2SIH88ecwnoxk5TMLZLpabj9fnF/hCg== X-Received: by 2002:a17:90b:4d09:: with SMTP id mw9mr773462pjb.199.1612922459684; Tue, 09 Feb 2021 18:00:59 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id r12sm192704pfr.86.2021.02.09.18.00.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Feb 2021 18:00:59 -0800 (PST) To: rfced-future@iab.org References: <95991276-A36D-42CD-B37E-D6EE6B1F54AA@mnot.net> <6E9072F4-F5CC-4454-92EA-CC2C528A39DC@cisco.com> <127A8DB3-CFAD-4EB4-B77F-360615D90CAC@encrypted.net> <350C3505-DBC4-4B02-B13C-8740BD131D49@mnot.net> <841915a1-2702-dcd9-4619-5fdb585804f7@joelhalpern.com> From: Brian E Carpenter Message-ID: <6b8d344c-5fcd-d2df-9156-49dac44ca83a@gmail.com> Date: Wed, 10 Feb 2021 15:00:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] On approval bodies and EKR's text: QUESTIONS for you X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Feb 2021 02:01:04 -0000 On 10-Feb-21 13:10, Mark Nottingham wrote: > > >> On 10 Feb 2021, at 11:04 am, Joel M. Halpern wrote: >> >> Mark, your quesiton of whether an RSE has needed to exercise such authority seems oddly formed since the very different operating structure probably renders the question historically meaningless. > > I was asking if there's a basis in history for granting an RSA/E special powers. We've had a person with those broad powers for a fair chunk of time (in various specific forms); I think it's relevant to ask if they've been used. Since the clear split between the RSE and ISE functions, things have been a bit different and much clearer, I think. Before that split, the RSE (in the person of Jon Postel or Bob Braden) certainly took publish/don't publish decisions for non-IETF drafts, and published the style guide autonomously (or with a nominal OK from the IAB). Since the split, as far as I know, only the ISE has made publish/don't publish decisions, and the RSE plus the production team have updated the style guide, taken decisions about archival, and so on. I think it's fair to say that the style guide has never been a consensus document. That doesn't mean there was no consultation, but the decisions were autonomous. Another example: the RFC Series ISSN was obtained in 2008. That was essentially a decision between the then RSE and the IETF Trust (copyright holder for the RFC Series), in consultation with the then Editorial Board. There was advance notification to the IETF list, and a few days of discussion, but it certainly wasn't a community consensus. (Thread starting at https://mailarchive.ietf.org/arch/msg/ietf/PF0dHtc5KK_hqyXkrzxM755s9MI/) In the new regime we're discussing here, I assume the decision would have been taken by the WG and approved (or not) by the approval body. The opinion of a publishing expert would be an important part of the process. Brian > >> On the other hand, we do have evidence of cases where it took a forceful AD to get a working group to do the right things technically. Given that we have seen this in areas where we have real expertise, I find myself concluding that such need is more likely in a situation where the WG participants have less expertise. > > That may be, and I'm not necessarily against this person having *any* special consideration/weight in the process. However, if they have such powers, there should be corresponding constraints on them -- just as there are for an AD. And it needs to be more than 'the LLC decides whether to renew the contract' -- that's too indirect. > > Cheers, > > >> >> Yours, >> Joel >> >> On 2/9/2021 6:52 PM, Mark Nottingham wrote: >>> On 10 Feb 2021, at 6:34 am, Brian E Carpenter wrote: >>>> >>>> Yes. But what strikes me in ekr's line of argument, and also in mnot's comment elsewhere: >>>> >>>>>> As such, I remain unconvinced that the RFC Series is a special case that needs extraordinary processes or powers for a designated expert. >>>> >>>> is very bluntly an implication that "we" (for some value of "we" that seems to mainly comprise protocol engineers) know better than an experienced technical publisher about non-protocol-engineering aspects of technical publishing. >>>> >>>> We don't. >>> And that implies that your perspective is that this person always "know[s] better" than the community, on every issue that they care to have an opinion about. >>> It also implies that the community is so obstinate as to ignore that person's well-supported and informed arguments in WG discussion, ignore the objections they make when a decision is made, and that the appeals process is so weak that that person is overruled throughout its application. It also implies that the folks on this thread who seem to want to unconditionally support this person would also be ignored and overruled throughout that process. >>> Is there any example to date of an RFC Editor needing to exercise these powers against this straw-man pig-headed community? >>> Even with expert help that has extraordinary powers, there is no guarantee that the right decisions will be made. What are you *really* engineering for here? >>> Cheers, >>> -- >>> Mark Nottingham https://www.mnot.net/ > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Thu Feb 11 01:55:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F973A141E for ; Thu, 11 Feb 2021 01:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9zLgCc9aodL for ; Thu, 11 Feb 2021 01:54:57 -0800 (PST) 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 A95A33A141D for ; Thu, 11 Feb 2021 01:54:56 -0800 (PST) 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 11B9ss5T002101 for ; Thu, 11 Feb 2021 09:54:54 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 71F112204A for ; Thu, 11 Feb 2021 09:54:54 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 668F122042 for ; Thu, 11 Feb 2021 09:54:54 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.213.140]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11B9srVc011683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Feb 2021 09:54:54 GMT Reply-To: From: "Adrian Farrel" To: Date: Thu, 11 Feb 2021 09:54:52 -0000 Organization: Old Dog Consulting Message-ID: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: Adb/+5qcxraMUEj5SNyfvbgRj+pZcQ== Content-Language: en-gb X-Originating-IP: 87.112.213.140 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-25942.003 X-TM-AS-Result: No--4.066-10.0-31-10 X-imss-scan-details: No--4.066-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--4.066400-10.000000 X-TMASE-MatchedRID: VTZG8gdv4l5RBKsfa1kPYVUMLbLe58ONnHTi72HdJmaZfDRE1uqSggpk ft7mIBSq2DW6o5iEj7VIIsm0inIg3VyYD+e8/Tt9h4Ce12gzEFp4Qwz73Zn4eO2bjZi+EXNnC2f OQJTdIgVC0EtKHL9bQCHjpPXG7bnGkvCi/xG+O8VW1k0wh4Tk8Q73P4/aDCIFIFWQH/JudNibAx oOzIPjBZLDa/+keL1rwT1xtpbXvY01aLxhC4hUugXGi/7cli9jIfZjRfGTydgtferJ/d7AbyXi8 Z7hCx0oLhc3Vti1rQYjsWzGRrcysjN1VvnSogA6mOFnGEL0JOMeRZr2cxRELo+l4fZNSHjuEmMq xF2ZvUn+X6oM4Al4Qq7OHO+yrZO1JNdcnIl+MB9zc0yPz3arikYj0zDHPzJpU6RTRJK+hyY/J5S KnlHdbTwRWZefDaEpE7PJ/itq1qtiL/ws9tKSaUwK/QP9kPgMGIMg4+U4kbVhV46Pq4G069zLV4 GB7ftLF3l8kITIdS9M8RlysBFnVinem5QaDuuc3VYGKNZvmfv2v20RxLDyN4yW3GQHxHDTpusdi c0vwiDm0ie38aj4BnYcBFDJSHHZcOOsaM5kbD29NsL2xEmLy82SCraor2S5zb7gHAy19uQpQP60 tO0L4QbNK2rJ/fNFA/YE0wOW9A/S2CkXfoLSXlWeeIqHthMLfS0Ip2eEHny+qryzYw2E8AvgpsX ypsAMDMq3z/Y/gtUnRE+fI6etknt9TMGxvfBKpi0xp179c/W2x4rGsxdklvPJoYj7yQT0kXDyMm qWBfuwBrSwTmfrezDduZMXeo/BPHLd7rpW2OpBQ0AXBIlg5k3+9BzFCkVzNAW83zYDw/v1OlCIP xKfizngMRAgrdeEyfkWaeG5p9A= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 Feb 2021 09:54:59 -0000 It seems to me that we have reached a position where we are stuck between two positions which I shall express crudely: 1. The WG must be supreme and, while the approval group can express concerns and return things to the WG for further consideration, the WG must be allowed to have its way. 2. The approval group in the form of one of its "voting" members must be allowed to block output of the WG that it considers harmful to the series or to one of the streams in the series. These positions are accompanied by fears (valid or not) about how people and groups might operate, to force through ideas or to block them. Some are concerned that too many people will have the option to block work based on an overly wide perceived remit and overriding the will of the community. Others are concerned that the WG may become dominated by a clique of loud voices and that key opinions may be overridden in the operation of the "normal" IETF consensus process. There are probably other nuanced issues that we don't need to dig up. I don't believe we are likely to reach consensus to swing to align with either position 1 or 2 based on what I have seen in this discussion. So I'd like to make a proposal which is in the form of an escalation procedure based quite heavily on the processes used by the IESG when balloting on documents. It goes as follows: A. The WG last calls its work following the model of an IETF WG. It is assumed that all members of the approval group will participate in the WG, and particularly in the WG last call, in an attempt to uncover any of their concerns early, and to avoid late surprises. It is understood that, from time to time, a member of the approval group may find it impossible to participate in a particular discussion: they are encourage to send delegates. B. The "voting" members of the approval group review the work and ballot. They may ballot Yes, Block, No Position, Abstain, or Recuse. - Yes means "I support this work." A Yes ballot may be accompanied by comments indicating thoughts and issues that should be looked at, but are non-blocking. - Block means "I have a serious concern that needs to be resolved before this work can proceed." - No Position should only be used in exceptional cases such as illness or long vacation. Voting members are expected to try to present a different ballot position. - Abstain means "I have a serious concern, but recognise that it will not be resolved." - Recuse means "I am somehow so involved in this work that it would be improper for me to have a position." C. Work proceeds if: There is at least one "Yes" and no "Block" ballots. D. In the event of one or more Block ballots, the work cannot proceed to completion. There must be discussion in the WG between the members of the approval group who balloted "Block" and the WG, and the focus of the discussion must be on addressing the concerns and reaching consensus. E. All comments in Yes ballots must be returned to the WG and the WG must attempt to address them through the normal consensus process. F. In the event of there being exactly one Block ballot, and it being impossible to reach agreement between the WG and the member of the approval group who issued the ballot, the approval group will exercise an exception resolution process as follows: F1. The approval group will discuss the concern giving rise to the ballot and any proposed resolution from the WG F2. The approval group will vote on whether to sustain the Block or to release the work F3. The vote shall be by simple majority with the chair of the group holding a casting vote in the event of a tie. F4. If the Block is sustained, return to step D. F5. If the work is released, return to step C. I am sure that we can bike-shed the details of this. And, before we are done, we should do that and we should reach a process that we can all agree upon. But, in the mean time I am interested to know whether *something*similar* to this could address the concerns of both sides of the current debate. Thanks, Adrian From nobody Thu Feb 11 08:35:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833F13A1755 for ; Thu, 11 Feb 2021 08:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQeaHi7Ru05a for ; Thu, 11 Feb 2021 08:35:37 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4CE3A1756 for ; Thu, 11 Feb 2021 08:35:37 -0800 (PST) Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 11BGZXsS057044 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 11 Feb 2021 10:35:34 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1613061335; bh=VN1RGtdM8/3ynGXPyLg10zFsqo0lhAn0PCp6mFtUQ0c=; h=Subject:To:References:From:Date:In-Reply-To; b=nq/JxoB8rVbgMDPNWEKLkeyuTWEFq2oDk0npjgiw7YZr5qJqShhtDG7lbI1d2ini4 gWqkir+Sl65DMYga6ARGErLZzJKoTd6sQIH2TlV7fpirV0Ya+EaHHPUpn5KlwW5fX1 3fMDqg5ErZcihY0JwibBcO3qdhkFiLXbYTkjtnbU= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local To: adrian@olddog.co.uk, rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> From: Adam Roach Message-ID: Date: Thu, 11 Feb 2021 10:35:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 Feb 2021 16:35:42 -0000 On 2/11/21 03:54, Adrian Farrel wrote: > It seems to me that we have reached a position where we are stuck between > two positions which I shall express crudely: > > 1. The WG must be supreme and, while the approval group can express concerns > and return things to the WG for further consideration, the WG must be > allowed to have its way. > > 2. The approval group in the form of one of its "voting" members must be > allowed to block output of the WG that it considers harmful to the series or > to one of the streams in the series. > > These positions are accompanied by fears (valid or not) about how people and > groups might operate, to force through ideas or to block them. I like this framing, because it really throws into relief the core issue that I think is causing an impasse, even if it hasn't been brought forth explicitly: which group is more likely to be subject to capture by people who will make decisions that are subjectively bad for the series? A small, closed group, or a large open one? The calculus might change a bit one way or the other depending on whether the closed group is directly appointed, indirectly appointed, or comprised primarily of ex-officio members, but I think this question is really the elephant in the room that we need to address. /a From nobody Thu Feb 11 09:04:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B093A1794 for ; Thu, 11 Feb 2021 09:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv1-XvOFAKxN for ; Thu, 11 Feb 2021 09:04:40 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A643A1793 for ; Thu, 11 Feb 2021 09:04:39 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id p15so5700270ilq.8 for ; Thu, 11 Feb 2021 09:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tGfnOPmAQ7VPpHdfq8aUFwNdkdJoJ7D+TiZvgeJPoRg=; b=VGCeTbhZNNY2eFs3EdTyjxMYdPlUqb6sfblp7EoKONP50ydfEFQo6C0DpulDL19Ocw 5SYrfBLAqlAJBIsqiv8HlSjOil3RndMzQ/V4itzwpHZorvP8WRkWJ7mtOPxsFYzGiOB8 Rv0GOkogZ8/rgc/nw9ou6QrxXj0puoT87DfZxIJc9bb0FbMqlxI4b7zrBjoEP6fJrsDI ILa60q8cFvtsppetnJJYiy0JA1+sU802vMZnUy9ExYJARs6a+YN8j4br5ReVc7YZWTsN RyPaS5+lWUS7yUtQRH6giRnhINin+pcaPXtcDS8H6oCp0og+1ZPh6v/ffRzF86CPJFXn C4Jw== 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=tGfnOPmAQ7VPpHdfq8aUFwNdkdJoJ7D+TiZvgeJPoRg=; b=ApxP78Kg1Id1R7DvEHD+oDcDfac79WnYN8JeMHMw2tVljP9FIFDrRCAuyBahpxp5gz 9uwgnOc0ksLDzJaAy5JLqEfX3TryJBiHRQ4eJ+By+dn64VorG9Pkp5tbDpj2aJrp6qfd pzDK/nK4+Sk3k8HsPX8/Egm6oX1V6P+x9NoZ784KYkwdN9PHPyXUV0RmLRVJgTib3ud+ e7Ftufzpn1qQguJSEk1f2U361LmUOZYG2X+MKIyfkO9Js3kZJYH1MNd2iI3nlHNwIYzs SSqK6e0N8sRQW6HgheyhsH7zguRlEu2dgkO6Olmlq+ewXLk0BFQvRVkhnmin++Q2jC+O fdEg== X-Gm-Message-State: AOAM531wKCZ+a1yAl4VT4MZPep8SqOI/0+PhJCBrbpcTHVsLwbgvS6pg hyFGzXrzYSdwpuybikEfdwc5TQ== X-Google-Smtp-Source: ABdhPJxlD1sFuRj04aHkBCYDT0dzyv2e2qt5kH/TRw2zIWl2YqFmQUFu8mgAIEt7f1f24Il4NI0Azg== X-Received: by 2002:a05:6e02:1a89:: with SMTP id k9mr6579274ilv.68.1613063079238; Thu, 11 Feb 2021 09:04:39 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id f16sm2805053iob.16.2021.02.11.09.04.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 09:04:38 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B1E885E5-D368-4F62-8D16-8F938C259D9D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Thu, 11 Feb 2021 12:04:38 -0500 In-Reply-To: Cc: adrian@olddog.co.uk, rfced-future@iab.org To: Adam Roach References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 Feb 2021 17:04:43 -0000 --Apple-Mail=_B1E885E5-D368-4F62-8D16-8F938C259D9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Adam Where do you stand on his proposed resolution? > On Feb 11, 2021, at 11:35 AM, Adam Roach wrote: >=20 > On 2/11/21 03:54, Adrian Farrel wrote: >> It seems to me that we have reached a position where we are stuck = between >> two positions which I shall express crudely: >>=20 >> 1. The WG must be supreme and, while the approval group can express = concerns >> and return things to the WG for further consideration, the WG must be >> allowed to have its way. >>=20 >> 2. The approval group in the form of one of its "voting" members must = be >> allowed to block output of the WG that it considers harmful to the = series or >> to one of the streams in the series. >>=20 >> These positions are accompanied by fears (valid or not) about how = people and >> groups might operate, to force through ideas or to block them. >=20 >=20 > I like this framing, because it really throws into relief the core = issue that I think is causing an impasse, even if it hasn't been brought = forth explicitly: which group is more likely to be subject to capture by = people who will make decisions that are subjectively bad for the series? = A small, closed group, or a large open one? >=20 > The calculus might change a bit one way or the other depending on = whether the closed group is directly appointed, indirectly appointed, or = comprised primarily of ex-officio members, but I think this question is = really the elephant in the room that we need to address. >=20 > /a >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = --Apple-Mail=_B1E885E5-D368-4F62-8D16-8F938C259D9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Adam

Where = do you stand on his proposed resolution?

On Feb = 11, 2021, at 11:35 AM, Adam Roach <adam@nostrum.com> wrote:

On 2/11/21 03:54, Adrian Farrel wrote:
It = seems to me that we have reached a position where we are stuck = between
two positions which I shall express crudely:

1. The WG must be supreme and, while the = approval group can express concerns
and return things to = the WG for further consideration, the WG must be
allowed = to have its way.

2. The approval group in = the form of one of its "voting" members must be
allowed to = block output of the WG that it considers harmful to the series or
to one of the streams in the series.

These positions are accompanied by fears (valid or not) about = how people and
groups might operate, to force through = ideas or to block them.


I like this framing, because it = really throws into relief the core issue that I think is causing an = impasse, even if it hasn't been brought forth explicitly: which group is = more likely to be subject to capture by people who will make decisions = that are subjectively bad for the series? A small, closed group, or a = large open one?

The calculus might change a bit one way or the other = depending on whether the closed group is directly appointed, indirectly = appointed, or comprised primarily of ex-officio members, but I think = this question is really the elephant in the room that we need to = address.

/a

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

= --Apple-Mail=_B1E885E5-D368-4F62-8D16-8F938C259D9D-- From nobody Thu Feb 11 11:54:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA173A18BA for ; Thu, 11 Feb 2021 11:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi0SPcQWArIc for ; Thu, 11 Feb 2021 11:54:12 -0800 (PST) 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 5D8A03A18BE for ; Thu, 11 Feb 2021 11:54:12 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id z21so4663802pgj.4 for ; Thu, 11 Feb 2021 11:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=F/7FpFsYWm8xd1S6E73jZsU3EFDHINDbxlUQhveZJ2w=; b=RBqVk/TNcrki7qLLD5+8Qx8aXg+hXfSYVSa/OUnuoKQdrN62tfHUp1IH5FMgB8MMFO DYVRfuJDzgVxQde6MSI+03x4lninvHhWQe6xTIGdNcpHlCt8zBTY1yXHGpciWj2eDTdL AaGWsnxmZEpceBCdXDSXbrtQp4R8mSP50muCPOY9GBeAy3gqQ82K/1nAB2vuwcltlHYt 8RjlKTpPRqjj0E5BBQXx8N7/a0WBfQ+qRlkYvMp/7qVbWiN30lZurxISHqnGDzrSckbz hK2QilG6gS9zBKSuvA2gWYawmEIM62YLszYW/5wFlYMG/0L4BtiF1Uv3IQkBychZXi9z w0MA== 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=F/7FpFsYWm8xd1S6E73jZsU3EFDHINDbxlUQhveZJ2w=; b=bPQowIc7L9V7Zcm+2JtKJ9MFp27RbDeh/fXrv8j/kjYPK0O5gg5pxqOrNXB5ck5rWi aMubC4LeUWdr4ksTjD+neI8ruHKT1oM/m+mmqMLdK20P+LtgduhWYm+QFExqGlpa6yp1 zi4FTv0Bj4On6zUZMqVgRuQzp4WISoP+StrW8ZfwzCmIvy7Vg/jpyA+U95VNms0+BtoL 2L/i5jrCc9W9GYEX5wwH2kmo7yhTeTzkWuJWBu3L2RcSQ50tq16YdfHyNyRUFphjypkl lS3zKmEr4fvL6IZV6z64fDxOM+Rg6LFtYeYCKUn8kQT2xuhxLsbv7QvP3facdHIO/peR wGGQ== X-Gm-Message-State: AOAM532N/Na+KWWba0oGOUcVclxeNgljFXXuS5eyJUAyh5KfiYgYf1rz kpEJguaIKVl7wbsmq94R24EPcCkL4OOFvQ== X-Google-Smtp-Source: ABdhPJyJxouw1UNWZIJsD0bZJM6H9YkjttPNajHFLVNWtx5I2jDbfW/Ey9PkDrONvbvxDfLIHhE3Ew== X-Received: by 2002:a63:5c61:: with SMTP id n33mr9814315pgm.153.1613073250698; Thu, 11 Feb 2021 11:54:10 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id f3sm6278987pfe.25.2021.02.11.11.54.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 11:54:10 -0800 (PST) To: adrian@olddog.co.uk, rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> From: Brian E Carpenter Message-ID: <92e6b808-5de4-c6d9-6786-86ba03b9ce9a@gmail.com> Date: Fri, 12 Feb 2021 08:54:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 Feb 2021 19:54:14 -0000 > 1. The WG must be supreme No. That's the whole point of having an approval body. > I am sure that we can bike-shed the details of this. I'm pretty sure we shouldn't do that, which is why my proposal is much simpler and intentionally lacks details, but IMHO has exactly the same effect: *The approval body shall operate by consensus.* That's all. Just the dictionary definition of "consensus". How they reach consensus is their choice. If we must spell it out, Adrian's formulation is fine, although I'd prefer the traditional "Discuss" to "Block". Regards Brian C On 11-Feb-21 22:54, Adrian Farrel wrote: > It seems to me that we have reached a position where we are stuck between > two positions which I shall express crudely: > > 1. The WG must be supreme and, while the approval group can express concerns > and return things to the WG for further consideration, the WG must be > allowed to have its way. > > 2. The approval group in the form of one of its "voting" members must be > allowed to block output of the WG that it considers harmful to the series or > to one of the streams in the series. > > These positions are accompanied by fears (valid or not) about how people and > groups might operate, to force through ideas or to block them. Some are > concerned that too many people will have the option to block work based on > an overly wide perceived remit and overriding the will of the community. > Others are concerned that the WG may become dominated by a clique of loud > voices and that key opinions may be overridden in the operation of the > "normal" IETF consensus process. There are probably other nuanced issues > that we don't need to dig up. > > I don't believe we are likely to reach consensus to swing to align with > either position 1 or 2 based on what I have seen in this discussion. > > So I'd like to make a proposal which is in the form of an escalation > procedure based quite heavily on the processes used by the IESG when > balloting on documents. It goes as follows: > > A. The WG last calls its work following the model of an IETF WG. It is > assumed that all members of the approval group will participate in the WG, > and particularly in the WG last call, in an attempt to uncover any of their > concerns early, and to avoid late surprises. It is understood that, from > time to time, a member of the approval group may find it impossible to > participate in a particular discussion: they are encourage to send > delegates. > B. The "voting" members of the approval group review the work and ballot. > They may ballot Yes, Block, No Position, Abstain, or Recuse. > - Yes means "I support this work." A Yes ballot may be accompanied by > comments indicating thoughts and issues that should be looked at, but are > non-blocking. > - Block means "I have a serious concern that needs to be resolved before > this work can proceed." > - No Position should only be used in exceptional cases such as illness > or long vacation. Voting members are expected to try to present a different > ballot position. > - Abstain means "I have a serious concern, but recognise that it will > not be resolved." > - Recuse means "I am somehow so involved in this work that it would be > improper for me to have a position." > C. Work proceeds if: > There is at least one "Yes" and no "Block" ballots. > D. In the event of one or more Block ballots, the work cannot proceed to > completion. There must be discussion in the WG between the members of the > approval group who balloted "Block" and the WG, and the focus of the > discussion must be on addressing the concerns and reaching consensus. > E. All comments in Yes ballots must be returned to the WG and the WG must > attempt to address them through the normal consensus process. > F. In the event of there being exactly one Block ballot, and it being > impossible to reach agreement between the WG and the member of the approval > group who issued the ballot, the approval group will exercise an exception > resolution process as follows: > F1. The approval group will discuss the concern giving rise to the ballot > and any proposed resolution from the WG > F2. The approval group will vote on whether to sustain the Block or to > release the work > F3. The vote shall be by simple majority with the chair of the group holding > a casting vote in the event of a tie. > F4. If the Block is sustained, return to step D. > F5. If the work is released, return to step C. > > I am sure that we can bike-shed the details of this. And, before we are > done, we should do that and we should reach a process that we can all agree > upon. > > But, in the mean time I am interested to know whether *something*similar* to > this could address the concerns of both sides of the current debate. > > Thanks, > Adrian > > > > From nobody Thu Feb 11 12:05:58 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002613A18D1 for ; Thu, 11 Feb 2021 12:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xrjrmOm6rZI for ; Thu, 11 Feb 2021 12:05:55 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE7C3A18D0 for ; Thu, 11 Feb 2021 12:05:55 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id w19so6081230qki.13 for ; Thu, 11 Feb 2021 12:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=aybRkZCmy2kiX6upi37pQElob8XsCFzYSUE+jca22Xg=; b=bFMy4R2k9LwzswIeTX0IgHoXgjrueK8oLy4SZtHChjmvN4Ttn+J2ymG/UEEm4R68Xa BDr0rPKO0Kf2kPMi60FGT46mTnXcGel0bOJ66gt4ahDnzTVnZEdc3bk4rD1BJ9v8Ln0U WWn7jVseQ53tAmkBf4DD38B/rsbsJVaxvQa7EUZBIBmverkm9yEaqFnUpQgE9mq4SrtD dyHPZGirqbc7o1UDgCO3pficN4KSjOmbf6zN0oGHk3YJoAS0h+t/tHpRJma9xw1yTkLp JrpyfU956tThjY8pa35vCPTxhsX9wVTKNklC36Q1y0X002NH+EZpZcdV9aePkc+CwacO qhSw== 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=aybRkZCmy2kiX6upi37pQElob8XsCFzYSUE+jca22Xg=; b=koO0II1f31w/0ANkoyXuD6RLQ5cuZNlUsHsB8vvU8BN9T60oFzwn4D4FNWnUfzxtZP IvSHiERbRvS1c10Qj/aiK1j0XO6/LlUIIOXUP0NmFQ2Nkx7kApYEEKBo6GcI79SfoZOS xbMgDB88bJRz1YGwuCF6Djtl9I+9yYOR0l13DUs4swvlnvc4aWIpPj12WQ61Rm0hzhKS AmiA0txDYgU5C1Sg6nxDQjpOLYE9JxHKl+5YJ031R/SjImBFe3MZLbwWzzT5j7ZUOOUM jcOVOqiqMVNhZe8YaZYior5CAEJ8RgWT3KNB6JvOzk6+MTcmjlfSpryRGct9m2Z7t2Rc IR+A== X-Gm-Message-State: AOAM530+pMzoFOtJxg/rAiSDD8L1tr5R26tbWCbQ+qmQ1TJxS99eoCdk yaVhQtH/n36yk5ZL1NGN/A8Kpridgev7msIb X-Google-Smtp-Source: ABdhPJwa43WaFyKFnDJdMThY+YUQIQ5xXOxuV8WfokWbOTjM2051skXusoZpzr1IMSWnhiUtwLJ1DA== X-Received: by 2002:a05:620a:22b4:: with SMTP id p20mr10303740qkh.27.1613073953286; Thu, 11 Feb 2021 12:05:53 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id j13sm4522509qkk.118.2021.02.11.12.05.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Feb 2021 12:05:52 -0800 (PST) To: rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> From: Michael StJohns Message-ID: Date: Thu, 11 Feb 2021 15:05:50 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 Feb 2021 20:05:57 -0000 On 2/11/2021 11:35 AM, Adam Roach wrote: > I like this framing, because it really throws into relief the core > issue that I think is causing an impasse, even if it hasn't been > brought forth explicitly: which group is more likely to be subject to > capture by people who will make decisions that are subjectively bad > for the series? A small, closed group, or a large open one? > > The calculus might change a bit one way or the other depending on > whether the closed group is directly appointed, indirectly appointed, > or comprised primarily of ex-officio members, but I think this > question is really the elephant in the room that we need to address. Adam - I've seen many times over my years with the IETF where a large group has been captured by a smaller group and made decisions that could be argued to be bad along at least one axis or another.  In fact, that was one of the reasons that I've been from time to time urging that the CFRG become a WG instead. I don't think there's a strong argument that a random small group of self-selected experts is better than a community selected group picked using the criteria of specific expertise.   In fact, the selection of the IESG is exactly that.  Or would you argue that your selection as AD was flawed and you should have been replaced by a self-selected group claiming expertise in ART? *sigh* Mike From nobody Thu Feb 11 15:22:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86213A0E0F for ; Thu, 11 Feb 2021 15:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Bob7O7Yj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CAbb3lsP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb2W6S7Aline for ; Thu, 11 Feb 2021 15:22:21 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897FE3A0E0D for ; Thu, 11 Feb 2021 15:22:21 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5FE7A5C00D9 for ; Thu, 11 Feb 2021 18:22:20 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Thu, 11 Feb 2021 18:22:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=2ccxEgobSUBkjhBz7o4vEkLAdI0SYc8 xpqHIr8esuvg=; b=Bob7O7Yjv8zC8eZj4x5D6KSghk8ICG2FgGu0lmb2IWiHGF6 SCERuwW3IaHKniPHwrchX5LgYbdoNjS5B+/XIVIMgmfrtSilcLd/Vm5fsLAoYoxU mwOyvevFbA8Q3TEfZhc1zuP2UjhsTtZBktGjLfpmEp02RKtjwcGUrpHpb96r5o94 0sotgWqh4tQzbJKLwefQk4SDIv9wLrulF4Gpqj4aOqTCcrOtrJJyxht0BT2BfLPa 3P5o/MQPhRbXAGGhFN74y5ZLrG93sF+If266KpMtxpjHSuGAn87Ml0alKzRnSEC6 y8DstcXsN4+fXdISdnfAXC4miZa7QCG5jmH+KkQ== 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=2ccxEg obSUBkjhBz7o4vEkLAdI0SYc8xpqHIr8esuvg=; b=CAbb3lsPI6UVJpeuxcoyzT HIdrVAagRPnr19F8amsRH1J6DkVu1xsMp++b0Lno/QhbLl0o7q0OdZheA9+k4lEV UVsuYKK+MzM5zwouX4XhFLJy5JgTmstZfdGcJnGAfWTkl33PCJq8ZD/8BjERvQFY ZJTsywmTrW2IN/xMdRJgclmxdUly+PrMlxeW/MCcsKmhp3QCm4x4KnRkkUbB7apm fZjiWZZjNtFK+l59tb7Mt6LiWMv/XD49rDmI5mPKkA5jK86F51oOB/+dHtaJxvIk 5XFig/YWqY/16UDgv8jaHGjkKOGjUzkD6HAJxJQndZBO+l9rtkZME8ZbMxLlF1/Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledriedtgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepteejheeftedvudduvdevve etkefghfefvedugeeugeekjeejvdfhveeukeejgfdtnecuffhomhgrihhnpehirggsrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh htsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 959414E0081; Thu, 11 Feb 2021 18:22:19 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <091700f0-d579-4a6d-ab13-02fbea8a7f51@www.fastmail.com> In-Reply-To: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> Date: Fri, 12 Feb 2021 10:22:00 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 Feb 2021 23:22:24 -0000 I think that this assessment is close enough to how things are going. I might have said that it wasn't "fears" on my own part, in the perhaps deluded view that my objection was more principled. That is, I want no individual to have the power to overwhelm the process in any direction, whether that be stagnation or toward their personal goals. But I don't think the exact reason matter much. The formulation of the process seems fine. With a bunch of quibbles: * I think that Brian's consensus thing is how things will work in practice, but we need a backstop and this is reasonable. * I would note that the Abstain/No Position/Recuse distinctions are not process relevant and so likely only serve to enable posturing, which might not be helpful (I've seen abstention in the IESG used this way and I believe it to be unhealthy), but that's a minor niggle. * I don't think that the chair acting as tie-breaker is a good idea. This group doesn't need a privileged role like that (and they might not even need a chair given the likely size). I think that overturning a blocking position should take more people voting to overturn than voting to sustain. For a group of size 4, that means 3 out of 4 and I think that's entirely appropriate. I would enhance this with: * We need an explicit process for public comment periods for proposals before approval can occur. There probably needs to be a fixed duration for that comment period and then a time limit on when approvals are completed. These might be fairly generous given the non-urgent nature of the work, but I think that we can't allow unbounded time. * I would add that the request for approval of a document should come with a report that details dissent in the working group and that any individual can have their dissent position explicitly included in that report in their own words. I am thinking here specifically about RSA/E, because this seems to be particularly important. * I would add that any block position needs to come with a clear statement about the reasons for it. We might want to develop guidelines for what is and isn't valid reasons for that. I like that this explicitly includes discussion of that position, but I think that discussion needs a concrete starting point. There are obviously many failure modes that can be invented where the approvals body and WG end up at loggerheads and this all breaks down. As we've noted before, invoking a higher authority might be necessary, but that needs to be very carefully constrained. We've a history of relying on appeals without invoking them in this organization, which I think is a fine tradition to continue. On Thu, Feb 11, 2021, at 20:54, Adrian Farrel wrote: > It seems to me that we have reached a position where we are stuck between > two positions which I shall express crudely: > > 1. The WG must be supreme and, while the approval group can express concerns > and return things to the WG for further consideration, the WG must be > allowed to have its way. > > 2. The approval group in the form of one of its "voting" members must be > allowed to block output of the WG that it considers harmful to the series or > to one of the streams in the series. > > These positions are accompanied by fears (valid or not) about how people and > groups might operate, to force through ideas or to block them. Some are > concerned that too many people will have the option to block work based on > an overly wide perceived remit and overriding the will of the community. > Others are concerned that the WG may become dominated by a clique of loud > voices and that key opinions may be overridden in the operation of the > "normal" IETF consensus process. There are probably other nuanced issues > that we don't need to dig up. > > I don't believe we are likely to reach consensus to swing to align with > either position 1 or 2 based on what I have seen in this discussion. > > So I'd like to make a proposal which is in the form of an escalation > procedure based quite heavily on the processes used by the IESG when > balloting on documents. It goes as follows: > > A. The WG last calls its work following the model of an IETF WG. It is > assumed that all members of the approval group will participate in the WG, > and particularly in the WG last call, in an attempt to uncover any of their > concerns early, and to avoid late surprises. It is understood that, from > time to time, a member of the approval group may find it impossible to > participate in a particular discussion: they are encourage to send > delegates. > B. The "voting" members of the approval group review the work and ballot. > They may ballot Yes, Block, No Position, Abstain, or Recuse. > - Yes means "I support this work." A Yes ballot may be accompanied by > comments indicating thoughts and issues that should be looked at, but are > non-blocking. > - Block means "I have a serious concern that needs to be resolved before > this work can proceed." > - No Position should only be used in exceptional cases such as illness > or long vacation. Voting members are expected to try to present a different > ballot position. > - Abstain means "I have a serious concern, but recognise that it will > not be resolved." > - Recuse means "I am somehow so involved in this work that it would be > improper for me to have a position." > C. Work proceeds if: > There is at least one "Yes" and no "Block" ballots. > D. In the event of one or more Block ballots, the work cannot proceed to > completion. There must be discussion in the WG between the members of the > approval group who balloted "Block" and the WG, and the focus of the > discussion must be on addressing the concerns and reaching consensus. > E. All comments in Yes ballots must be returned to the WG and the WG must > attempt to address them through the normal consensus process. > F. In the event of there being exactly one Block ballot, and it being > impossible to reach agreement between the WG and the member of the approval > group who issued the ballot, the approval group will exercise an exception > resolution process as follows: > F1. The approval group will discuss the concern giving rise to the ballot > and any proposed resolution from the WG > F2. The approval group will vote on whether to sustain the Block or to > release the work > F3. The vote shall be by simple majority with the chair of the group holding > a casting vote in the event of a tie. > F4. If the Block is sustained, return to step D. > F5. If the work is released, return to step C. > > I am sure that we can bike-shed the details of this. And, before we are > done, we should do that and we should reach a process that we can all agree > upon. > > But, in the mean time I am interested to know whether *something*similar* to > this could address the concerns of both sides of the current debate. > > Thanks, > Adrian > > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > From nobody Thu Feb 11 16:03:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8813A0E72 for ; Thu, 11 Feb 2021 16:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOvGmVPEZR3T for ; Thu, 11 Feb 2021 16:03:21 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C94C3A0E70 for ; Thu, 11 Feb 2021 16:03:21 -0800 (PST) Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 11C03EKA014215 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 11 Feb 2021 18:03:15 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1613088196; bh=s7EYItuoF+nzhe34WybNf+kAnRlcfEb26MxnuuvChJQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=RHxLbVud0GOB3pKUs63FF51JCZHwuDxZiO4Opb3nSTje60rb34lvZe046zwHaX2yq LC7Bj9+nFo3Z/qqo6WNtOWZct6ICxoozuIs5iGx4GnwK+gAXJdJhQMyDbzPnuQhOJC CwjhgNyr8/Cz47l5JkdsvAoQHln7bwHufavglvxg= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local To: Brian Rosen Cc: adrian@olddog.co.uk, rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> From: Adam Roach Message-ID: <5f0d2ac6-e70f-a509-d0aa-077d27c5b680@nostrum.com> Date: Thu, 11 Feb 2021 18:03:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FF1866C7FECE9D24B724D977" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 Feb 2021 00:03:25 -0000 This is a multi-part message in MIME format. --------------FF1866C7FECE9D24B724D977 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I could live with something of this general shape, although it's certainly not my top choice. Process notwithstanding, this proposal is fundamentally position #2 with "one of" replaced by "a simple majority of," which still falls back to the capture question. The whole proposal would be made significantly more palatable if we had an appeals process that allowed for outcome based on substance rather than process, but I recognize that this runs into a sticky conversation about which body receives the appeal. /a On 2/11/21 11:04, Brian Rosen wrote: > Adam > > Where do you stand on his proposed resolution? > >> On Feb 11, 2021, at 11:35 AM, Adam Roach > > wrote: >> >> On 2/11/21 03:54, Adrian Farrel wrote: >>> It seems to me that we have reached a position where we are stuck >>> between >>> two positions which I shall express crudely: >>> >>> 1. The WG must be supreme and, while the approval group can express >>> concerns >>> and return things to the WG for further consideration, the WG must be >>> allowed to have its way. >>> >>> 2. The approval group in the form of one of its "voting" members must be >>> allowed to block output of the WG that it considers harmful to the >>> series or >>> to one of the streams in the series. >>> >>> These positions are accompanied by fears (valid or not) about how >>> people and >>> groups might operate, to force through ideas or to block them. >> >> >> I like this framing, because it really throws into relief the core >> issue that I think is causing an impasse, even if it hasn't been >> brought forth explicitly: which group is more likely to be subject to >> capture by people who will make decisions that are subjectively bad >> for the series? A small, closed group, or a large open one? >> >> The calculus might change a bit one way or the other depending on >> whether the closed group is directly appointed, indirectly appointed, >> or comprised primarily of ex-officio members, but I think this >> question is really the elephant in the room that we need to address. >> >> /a >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > --------------FF1866C7FECE9D24B724D977 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I could live with something of this general shape, although it's certainly not my top choice.

Process notwithstanding, this proposal is fundamentally position #2 with "one of" replaced by "a simple majority of," which still falls back to the capture question. The whole proposal would be made significantly more palatable if we had an appeals process that allowed for outcome based on substance rather than process, but I recognize that this runs into a sticky conversation about which body receives the appeal.

/a

On 2/11/21 11:04, Brian Rosen wrote:
Adam

Where do you stand on his proposed resolution?

On Feb 11, 2021, at 11:35 AM, Adam Roach <adam@nostrum.com> wrote:

On 2/11/21 03:54, Adrian Farrel wrote:
It seems to me that we have reached a position where we are stuck between
two positions which I shall express crudely:

1. The WG must be supreme and, while the approval group can express concerns
and return things to the WG for further consideration, the WG must be
allowed to have its way.

2. The approval group in the form of one of its "voting" members must be
allowed to block output of the WG that it considers harmful to the series or
to one of the streams in the series.

These positions are accompanied by fears (valid or not) about how people and
groups might operate, to force through ideas or to block them.


I like this framing, because it really throws into relief the core issue that I think is causing an impasse, even if it hasn't been brought forth explicitly: which group is more likely to be subject to capture by people who will make decisions that are subjectively bad for the series? A small, closed group, or a large open one?

The calculus might change a bit one way or the other depending on whether the closed group is directly appointed, indirectly appointed, or comprised primarily of ex-officio members, but I think this question is really the elephant in the room that we need to address.

/a

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


--------------FF1866C7FECE9D24B724D977-- From nobody Thu Feb 11 16:04:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEC73A0E7A for ; Thu, 11 Feb 2021 16:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvzcjlzdHCUe for ; Thu, 11 Feb 2021 16:04:07 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA10E3A0E73 for ; Thu, 11 Feb 2021 16:04:07 -0800 (PST) Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 11C0443d014525 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 11 Feb 2021 18:04:05 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1613088246; bh=fvaLT/eMovrfs+egwJxl9Z/+7ctiYt6o2dayF5xDqkM=; h=Subject:To:References:From:Date:In-Reply-To; b=W/azawGZJiDg8JKhrqKNSjw2u6dcgQrokoSN7WGHS6pUaESxOU1w9UE1hCkeRmLRy jGYP+yfq9JoHHgXkd6ry9evxGm1pTSFV3k6RitOgSC4lWkkicZdJ2fjciWeOKp9zzL rS0882/iEg6VDn0b3qfnZx3RTADMROGJFnGaL8+A= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local To: Michael StJohns , rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> From: Adam Roach Message-ID: <81097945-65b2-6651-6093-0ac55d9ca436@nostrum.com> Date: Thu, 11 Feb 2021 18:03:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.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] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 Feb 2021 00:04:12 -0000 On 2/11/21 14:05, Michael StJohns wrote: > Or would you argue that your selection as AD was flawed and you should > have been replaced by a self-selected group claiming expertise in ART? To be fair, this characterization effectively matches the facts on the ground; see, e.g., https://www6.ietf.org/iesg/appeal/response-to-klensin-2008-06-13.txt The closer we can hew to this model where the approving body has very little power in the face of strong community sentiment, the closer we come to finding a compromise between the two positions Adrian lays out. /a From nobody Thu Feb 11 16:13:45 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A723A0E8E for ; Thu, 11 Feb 2021 16:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=dOLTAoSq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JG23Nkk3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fUvvbrTLM_j for ; Thu, 11 Feb 2021 16:13:42 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C433A0E9F for ; Thu, 11 Feb 2021 16:13:42 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 38B81ACF; Thu, 11 Feb 2021 19:13:41 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 11 Feb 2021 19:13:41 -0500 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=fm1; bh=0 3pGKCwo8MTCquVTomPrzuoNGopRTf/EWajKuG6rMCY=; b=dOLTAoSqLZt859Klr PoX7gfeVVU99txsrExh0bHEOWkprDUXECxus+JTlUFUZ2nxjV9Yq+rHMrtbmV6BN LIoX6OU13jIFQpxJNC4zr9jB2DnQIaie3oYQfoJhTZfsZtJDk6v2ibxQjxTc7HaV UFf/c+b8ZUGToD20iS2F0ILG6P/ifwAT1wEgD6KVcqTIg8j5LTuMLac4zvnrecNv FeI61MtPRpcaiQwdIAI8vzHA6QMSQYf8lci6+ReajET0sLY7pebGa+YnQzwicRlq aD9ivcIKNCXD6Bq3jcqOiIHiR5ynTUJXmxb1rAZ7SDeZXItaQACn2xaAdKKolMyR fbAJA== 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=03pGKCwo8MTCquVTomPrzuoNGopRTf/EWajKuG6rM CY=; b=JG23Nkk3uxpUTG8Ioug7CThYrmFbrLXfjgSgeVUnuQaJ9XQWkbUmqvfLK w0wiypDOb5iMIRP9dNPnI2ONZZcYd+7d7B3yB14JzzGiYCXZokUiGCeuHM6uSS3x 4F9V5HPsDpsZynsF75LqxFrjjwBg9jnvFVuy6Rg2x57QshT9J0Oac4b1nf1EaGCv EpijnXzziD1opz7qdslaMomIuuBjCiEEqsB/skZ8QbsyuKndD09J8/phpuJnqpQe 1N5Ikl3zYNG0MfEMnOKG17XzSE+zFsuK62nm7dNEG+z56DweS/CRA1+pgbKBrJCq 9HEyEb9wYx9n3ES9Rd1YYS9nOaW1g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledriedtgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepuedtkefhtdfggfejjeegkeevheefhffguefgheefgfegkefhiedtgeduvedufeei necuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrud ejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 03347240064; Thu, 11 Feb 2021 19:13:36 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: <5f0d2ac6-e70f-a509-d0aa-077d27c5b680@nostrum.com> Date: Fri, 12 Feb 2021 11:13:32 +1100 Cc: Brian Rosen , rfced-future@iab.org, adrian@olddog.co.uk Content-Transfer-Encoding: quoted-printable Message-Id: References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <5f0d2ac6-e70f-a509-d0aa-077d27c5b680@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 Feb 2021 00:13:44 -0000 I'm roughly in the same boat; there are some details that need = bikeshedding^H^H^Hrefinement, but I could live with it. I agree that we need to figure out something for appeals; in general, = multiple layers of approval/appeal increases confidence in the work, and = it's something we should figure out, even if finding the stuckee is = hard. Cheers, > On 12 Feb 2021, at 11:03 am, Adam Roach wrote: >=20 > I could live with something of this general shape, although it's = certainly not my top choice. >=20 > Process notwithstanding, this proposal is fundamentally position #2 = with "one of" replaced by "a simple majority of," which still falls back = to the capture question. The whole proposal would be made significantly = more palatable if we had an appeals process that allowed for outcome = based on substance rather than process, but I recognize that this runs = into a sticky conversation about which body receives the appeal. >=20 > /a >=20 > On 2/11/21 11:04, Brian Rosen wrote: >> Adam >>=20 >> Where do you stand on his proposed resolution? >>=20 >>> On Feb 11, 2021, at 11:35 AM, Adam Roach wrote: >>>=20 >>> On 2/11/21 03:54, Adrian Farrel wrote: >>>> It seems to me that we have reached a position where we are stuck = between >>>> two positions which I shall express crudely: >>>>=20 >>>> 1. The WG must be supreme and, while the approval group can express = concerns >>>> and return things to the WG for further consideration, the WG must = be >>>> allowed to have its way. >>>>=20 >>>> 2. The approval group in the form of one of its "voting" members = must be >>>> allowed to block output of the WG that it considers harmful to the = series or >>>> to one of the streams in the series. >>>>=20 >>>> These positions are accompanied by fears (valid or not) about how = people and >>>> groups might operate, to force through ideas or to block them. >>>=20 >>>=20 >>> I like this framing, because it really throws into relief the core = issue that I think is causing an impasse, even if it hasn't been brought = forth explicitly: which group is more likely to be subject to capture by = people who will make decisions that are subjectively bad for the series? = A small, closed group, or a large open one? >>>=20 >>> The calculus might change a bit one way or the other depending on = whether the closed group is directly appointed, indirectly appointed, or = comprised primarily of ex-officio members, but I think this question is = really the elephant in the room that we need to address. >>>=20 >>> /a >>>=20 >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >>=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Thu Feb 11 23:20:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7048F3A1376 for ; Thu, 11 Feb 2021 23:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.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 X_5Og_fiWI18 for ; Thu, 11 Feb 2021 23:20:15 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400112.outbound.protection.outlook.com [40.107.140.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDDB3A1377 for ; Thu, 11 Feb 2021 23:20:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IN8Dt4nSQIfnHIqBi+Eje1rmb5Et5zXaT0XyMFCsnr3eldXm7HsuCQselHrL+qIMHX2m7c7sPOuuKFzbRaMobSlct9LQfxwYSABtb0kzIdmSdU0XPTgpOZHmkOhpzEnl8eUwfVCr8vzIbJLKwJ5ilVu2OkzMAPNlO9D1UEoIG4L/hLDyF8vsI9Hu6jhnruiHAJ1oTK+xfFa23ZhcTa+Csrc0VX/PJHcagm/3DNsG/K51zr4bSpNCFXWCyka3N5Zmo4+CYefCRfI2jGbMagBj4dab5r4V4sZxQRHhN5gXS+97iyfmaY4hi9lDjQjDwhRJJqTbSX8Kx50FG8UBJcBJlg== 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=23UlFwPxic7RNl9GLzeIFVOKY607q9rg+GW693oM08w=; b=T79uRJlPAw1Yy8b8L83ugG4NKTr9wkThXCtyxvsPvEQYnaw+CSYNpLp9/GYIg4c2WUnz4FuGI4mbMMuFki+Oz92k02Esr8fQXTq/GADNnhm6LqwLGC7m2kuYZRlpI4aRFqyLie6KrI4LKw+XPDY0y26rW3Zp8yHcLBVPpHiJ+SGIxuY23yo5WPyPaNoXPY13qgKjK/v1i4aCt/s5b44MwJmya5jKWCVP8nTLXwRvAZIx8XXija1rUvcdGbPogGjuZ7PmuexyRO2w4rW0Ie1kG3nreJMJzbBtIHoAmGgd0t06Zu+EwleoyWB8HPTLQPYYSGCof043JZJOAMPKMY/6Ug== 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=23UlFwPxic7RNl9GLzeIFVOKY607q9rg+GW693oM08w=; b=SKTpCj8FPcNOIldtt8poGINmzL3kpr/szMpTJn9L4QoFJ5WwAI4PbQij5jhG2Ax+FMA64gMNscThzX77c9zUZjM646erimcOgeZCyYcmn/Z2vXMq313gA6qQAjy45fTA2QuzPLNnBOMLhmeWPHmp07JbMMOO6VsytUHyXnlhGKQ= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB5708.jpnprd01.prod.outlook.com (2603:1096:404:8058::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.26; Fri, 12 Feb 2021 07:20:10 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f%7]) with mapi id 15.20.3846.026; Fri, 12 Feb 2021 07:20:10 +0000 To: adrian@olddog.co.uk, rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <696c4d2f-3755-c219-663c-6e0addb062c3@it.aoyama.ac.jp> Date: Fri, 12 Feb 2021 16:20:09 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.83] X-ClientProxiedBy: TYAPR01CA0107.jpnprd01.prod.outlook.com (2603:1096:404:2a::23) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.11.2] (133.2.210.83) by TYAPR01CA0107.jpnprd01.prod.outlook.com (2603:1096:404:2a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25 via Frontend Transport; Fri, 12 Feb 2021 07:20:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f7d79b70-e3f8-4546-e0dc-08d8cf26a1ef X-MS-TrafficTypeDiagnostic: TYAPR01MB5708: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dFvAFTf/ZtTnQUpjMYQFXDzhiz41/JhRbDpM3cdATZyP17u+uGs/iI4MyeUSYfwjFPpwiFudou/tqpUipfbAJMAEKMcWBaEfn3VrYkkZhP+k5Adf0X2zkhzLozjUb2UynhT0pWhezxjA2Uuybazg5MJGhAyShxAYGtFAI412r9dVCXWzel8TaEkIm9kGHJ8hRgkbL8cSXjnzIBgbN6rstZWAd9BY7YgEdZ48YX8WMqsNHjIlKv8VkinawlRzKPMH+z4BU77dZIeiRJNTbQZ8B/nTc1FgBnVHFSQwzM2Ms0DOnz2BgTqCB6n4Zf/c6wJQHu++/RJXKktnQOlPQjrP/m/UPtSbyZy58cyDeK0K9n0HRmlQopcGupL+rZviwdoAweeNZdowADjfGv/HpCUTRTUD6Fj2sBnKZ0ZIwQHMLrx361XYFZb+6yvi6TQ5VF2rC3UViTYplSU11xjMsl6/CO9bR+It2Rvw3F9Atk179CMsuaO7ceZnmADn4BCO8eEXZcEnUdItEO55qRh9yv8yjOYck8BaI46DEACxBOEug+pIeVO46nh2NUdEPuHXiBTIIY5Qz5hvLb52hUz1dx4+AAGy1jDErKvg7i599G9QKiQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(396003)(136003)(376002)(39850400004)(186003)(53546011)(16526019)(6486002)(26005)(2616005)(31696002)(83380400001)(956004)(31686004)(36916002)(52116002)(66946007)(66476007)(66556008)(8676002)(786003)(5660300002)(316002)(16576012)(8936002)(86362001)(2906002)(478600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?UjJ2S3d0RmZjYzl0cWZRYTQ1RElvSk9CSk5GYmZPSTVXdTllTERBVmU2cUNJ?= =?utf-8?B?L2FqZlNIZ2ZHYlU1OFlKYnNiZFN4cXh2QTBueCtybExUNDdoSG81elFLMUhv?= =?utf-8?B?WHZpdUNVY2ZELzlyczhZUnR6S0dlNzF3OVRGM2czL1R4R2lGOWNMSlRRcXkr?= =?utf-8?B?bnFPc08vZVZVNXhDZjRKWE82NEVYQjFRbUVuSmxxaUl2U0MvYTJ0RVRudkR5?= =?utf-8?B?NFlOa2pFTk00azU1ejM4TWdJbmJTTUVyTEZJNHQ3VjRxOVdEZU52SldqQWd1?= =?utf-8?B?T2EvVXlQRHNxQXpOQUh5L3VGTE9naU1tUDJBUVBCL2xGcW1JZmV6OXBCYU9v?= =?utf-8?B?T3JwRDRHWWRSbDgrNEJIalJ0Y1ljTFpCcHljbUQ2NFNibWNOem1hcFkxclg3?= =?utf-8?B?ZEFQNW1jSTdLZlkrMkx5MHdSVTZKamdMbE1rdzZmTG1ISm1DM1h5YThrcGFv?= =?utf-8?B?VEgzZmF6Qm5YWGJ6VGdhZGQ4V0YvWW12U1czYjhrZDdXSnBVVDVwSWVlZ0Fl?= =?utf-8?B?bkdxMXVZZlZmOXhVZW5MVDAvT0t5ZTJjY3QvdHFydko5cUVsWVY1QmlvTWFM?= =?utf-8?B?LzdwNGdzaFpPSVlobkZ5REhZbXE4YWpZM0FKOGdXQVZxSmZQSFFISDBrN1ov?= =?utf-8?B?VzNwTWVnbWFuWCtVTGxZSnFzM3d1ZHFQQ0hwZG5jaEo0eXM5NW1ucHh6NTNS?= =?utf-8?B?Uk5pOWI0QzVnaGM3UjVPUlhCYkdRSTJXTU4yWmpWYTF3aitoNWE1ZCtGbmt6?= =?utf-8?B?SjU5OU1YT29CdXEreTdSdlNTR0FYVkUyWTFXVmFpc2hXQVNqRkMvTUxxOFpu?= =?utf-8?B?WlVaREdablRTTkV4UkpQSWh4am1MK2s0TXBkS3Joc1p0UFJUdy9mZHh2OHVu?= =?utf-8?B?cEFSNzRkREhSZS9lRGppeVQxdmhTSHdqdmJvMDdldXg1VlR0b1NQVTg1Qmt3?= =?utf-8?B?OVN2T2N6TkN1dXlWUWZZRnd2bXVZOEI0YlF1SVIwZmVidUNyYUtFblRXNXVD?= =?utf-8?B?b3FnaCs1d2p1YmEzUTJlYzBQcHorZ1laWnI4K2dVT0E2cmJ6azdtQmdQR3FY?= =?utf-8?B?OHNqczVlaXBUNm9tUyttRjFGU21HZ1lKYzRDbkh5TEZaVVVlRmJTYTFFMkZp?= =?utf-8?B?Y1FUUWJjSXRrVlVmYXJDNUVsVENERWlOUERhd2hTakExSUhNcmlQTGxTZXFn?= =?utf-8?B?RVEzS0hGNVI5cVZoLzNMYWZnTUNGR2dnSVowL0t4NTdRblBTR2hrQm9HN0Za?= =?utf-8?B?MkVzTTh1ekppTnFWUnY3U05rakQrb3BXTi9ZNUZiZWYxL21YNmpKNTZkaUhH?= =?utf-8?B?OE9VUitNYlh6cmlBZjVndWg3cThvUHlnbUtkQjBucU9ydVRqS1hPZ2NUT1Jj?= =?utf-8?B?MFZtcU9PM3dvdEJZZzJPeEREaG05eGg0Z0RzR25DSTljL0lET0lRZHZqck45?= =?utf-8?B?ckFGdEVLNjZYVk5uM054NnljQWNVMHZZVDNxYkJNckhQYVNoSnk1dnhhNjMz?= =?utf-8?B?SzhUd2lNaXk0dGdXMnhaSGdnUEJFRkpJMldGM0ZJQzJMdFJ5UEdCOVhYQ1FV?= =?utf-8?B?eFc2M0kweGJGK0J5eWl6K1M0dVhmV2lCTnJWRDZxWXVhWkc4MHpzVFBPdEZS?= =?utf-8?B?dmEwajZ2SGs4eXZaQWR5eFZCSERkZ0wrZndDYnA0ODhOUXVpMEtOaHk0VmFl?= =?utf-8?B?ejJhRjI2eFFlTFRTQXFNdGxLQ0tFbmpMSXJMTVVZd2NUYzROT2RQOHoxZGxW?= =?utf-8?Q?3+ijrpzUcdUhsQvO7LZ3wFM2Cdepe+EmLjI9uIN?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: f7d79b70-e3f8-4546-e0dc-08d8cf26a1ef X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2021 07:20:10.6748 (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: cnj3clq7Lfd8o3mitivXeumQLBqdlIRo3DNd59DFn/Ki/q42u59IX+V+ObUiuS41WwDLGg5qtFG7cdaDQeqTlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB5708 Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 Feb 2021 07:20:18 -0000 In general, I agree with the direction the discussion is taking. However, I have a concern about a point below. On 11/02/2021 18:54, Adrian Farrel wrote: > A. The WG last calls its work following the model of an IETF WG. It is > assumed that all members of the approval group will participate in the WG, > and particularly in the WG last call, in an attempt to uncover any of their > concerns early, and to avoid late surprises. It is understood that, from > time to time, a member of the approval group may find it impossible to > participate in a particular discussion: they are encourage to send > delegates. > B. The "voting" members of the approval group review the work and ballot. > They may ballot Yes, Block, No Position, Abstain, or Recuse. > - Yes means "I support this work." A Yes ballot may be accompanied by > comments indicating thoughts and issues that should be looked at, but are > non-blocking. > - Block means "I have a serious concern that needs to be resolved before > this work can proceed." > - No Position should only be used in exceptional cases such as illness > or long vacation. Voting members are expected to try to present a different > ballot position. > - Abstain means "I have a serious concern, but recognise that it will > not be resolved." > - Recuse means "I am somehow so involved in this work that it would be > improper for me to have a position." > C. Work proceeds if: > There is at least one "Yes" and no "Block" ballots. This is the point where I have my doubts. As far as I understand, on the IESG, a lot of No Objection ballots are tolerated because of the wide range of topics the IESG deals with and the large number of drafts. In my imagination, RFC-related decisions should be supported by something closer to consensus than just a single member being fully in on a proposal. The number of proposals should also not be that high, so that every member should easily be able to form a well-founded position on every proposal. Also, at least in the case of stream managers, illness or long vacations should be handled by having a (temporary) replacement for the stream manager position, which would extend to the position on the approval group. Regards, Martin. > D. In the event of one or more Block ballots, the work cannot proceed to > completion. There must be discussion in the WG between the members of the > approval group who balloted "Block" and the WG, and the focus of the > discussion must be on addressing the concerns and reaching consensus. > E. All comments in Yes ballots must be returned to the WG and the WG must > attempt to address them through the normal consensus process. > F. In the event of there being exactly one Block ballot, and it being > impossible to reach agreement between the WG and the member of the approval > group who issued the ballot, the approval group will exercise an exception > resolution process as follows: > F1. The approval group will discuss the concern giving rise to the ballot > and any proposed resolution from the WG > F2. The approval group will vote on whether to sustain the Block or to > release the work > F3. The vote shall be by simple majority with the chair of the group holding > a casting vote in the event of a tie. > F4. If the Block is sustained, return to step D. > F5. If the work is released, return to step C. > > I am sure that we can bike-shed the details of this. And, before we are > done, we should do that and we should reach a process that we can all agree > upon. > > But, in the mean time I am interested to know whether *something*similar* to > this could address the concerns of both sides of the current debate. > > Thanks, > Adrian From nobody Fri Feb 12 02:25:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CA33A1521 for ; Fri, 12 Feb 2021 02:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY8UNvzgD4mA for ; Fri, 12 Feb 2021 02:25:34 -0800 (PST) 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 539543A1520 for ; Fri, 12 Feb 2021 02:25:33 -0800 (PST) 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 11CAPU5Z031225; Fri, 12 Feb 2021 10:25:30 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C272E22042; Fri, 12 Feb 2021 10:25:30 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id B63A122044; Fri, 12 Feb 2021 10:25:30 +0000 (GMT) Received: from LAPTOPK7AS653V (80.98.162.213.dyn.plus.net [213.162.98.80] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11CAPTGq021523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Feb 2021 10:25:30 GMT Reply-To: From: "Adrian Farrel" To: "=?utf-8?Q?'Martin_J._D=C3=BCrst'?=" , References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <696c4d2f-3755-c219-663c-6e0addb062c3@it.aoyama.ac.jp> In-Reply-To: <696c4d2f-3755-c219-663c-6e0addb062c3@it.aoyama.ac.jp> Date: Fri, 12 Feb 2021 10:25:29 -0000 Organization: Old Dog Consulting Message-ID: <014a01d70129$637fb640$2a7f22c0$@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: AQFC9jKhHxSLiwTnuH2Y4NU4l8GOMgGh80Itq29U/FA= Content-Language: en-gb X-Originating-IP: 213.162.98.80 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-25942.003 X-TM-AS-Result: No--9.067-10.0-31-10 X-imss-scan-details: No--9.067-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--9.067200-10.000000 X-TMASE-MatchedRID: DuKherWvI/vxIbpQ8BhdbDZoNXJMbH+n5PYstWAKH2o2KXiB7g5P0wYz GYtVtarBW8UnJEwvwRH9oNvYJlI5/tfOfGcoM5ITj0drvddoWESiWMoE6tSLsC62hjZS0WoYFBQ /QCFoaHH8JBu81Iq1v8Jle2FZW4E6qkQi8MSvbgS84C/3iwAgxOvWkvu/824/ZRL+gCLSlhcRKc /cnVC2pzwBkJ8YQNFkR8Ta/YEUuqe+f4AWV7koYlldxqSi5bOJfYrr1p9yfCqnRvssirgAK4+04 hOwZfJRBmyRelNSJCx6N6DnPW7WvNyR6c3G65kmlRdhw/BBzad+S5m2/8VLmhZggOIN5f2+kBoD l/NowCYJvEJEb9kbDXNZYXop6xMzPNpwvL0sv+jJ/bVh4iw9hm0TAJ1EuNBmYr1+1qQjF1kJcuX R+WTrTgzg2awlUpqNrBYbn0pgK6KjBBH+lBIdBYeAntdoMxBauiR977BIMuUELMPQNzyJSz9xCE x7KAJu7E4zV6A8rsxvLPLblyY/MHBtk6relg0lJrUxoq6hvw/DvsJEJ3LgvKRLyh9jv2CMpusdi c0vwiCqKc4MHOV0jGdVAQMsDwD6wAswe0QGYTk8H8cjm4LSleAeEI3tbHhVazloiUOYcKzFOmM0 K6dTllF3VfkwgwhjGcDnTMg90jtaoFFRAKWvJo61Z+HJnvsOfS0Ip2eEHnzUHQeTVDUrIlNkM6v OVn5wdB0ntd9Tzp7iRhduhvElsm3DH6nl/HrnQd7axTzIGeIaY+/QdoinAeHbkXYcfxKFdZfcWk xQLJu1XcZ5s+OaTGGS6S+7sY5Y0euAyjA9EON7b8lIt67/NZXhOiEIQxNB9HmAsM11v0u45mjKI IYY3xiCad9aBKWfm9p/RC99TJ5Lhb8xGEnVfg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 Feb 2021 10:25:39 -0000 Hi Martin, Top post. It was a straw man, not a firm position. My thinking was that "no position" should not be a common event. But = there will always be corner cases. Not that the IESG has "no objection" and "no ballot made". I would say = that "no objection" should not exist: say yes or no, but don't say = nothing. However, the "no position" is needed just in case circumstances = intervene. A -----Original Message----- From: Martin J. D=C3=BCrst =20 Sent: 12 February 2021 07:20 To: adrian@olddog.co.uk; rfced-future@iab.org Subject: Re: [Rfced-future] Non-approval resolution In general, I agree with the direction the discussion is taking.=20 However, I have a concern about a point below. On 11/02/2021 18:54, Adrian Farrel wrote: > A. The WG last calls its work following the model of an IETF WG. It is > assumed that all members of the approval group will participate in the = WG, > and particularly in the WG last call, in an attempt to uncover any of = their > concerns early, and to avoid late surprises. It is understood that, = from > time to time, a member of the approval group may find it impossible to > participate in a particular discussion: they are encourage to send > delegates. > B. The "voting" members of the approval group review the work and = ballot. > They may ballot Yes, Block, No Position, Abstain, or Recuse. > - Yes means "I support this work." A Yes ballot may be = accompanied by > comments indicating thoughts and issues that should be looked at, but = are > non-blocking. > - Block means "I have a serious concern that needs to be resolved = before > this work can proceed." > - No Position should only be used in exceptional cases such as = illness > or long vacation. Voting members are expected to try to present a = different > ballot position. > - Abstain means "I have a serious concern, but recognise that it = will > not be resolved." > - Recuse means "I am somehow so involved in this work that it = would be > improper for me to have a position." > C. Work proceeds if: > There is at least one "Yes" and no "Block" ballots. This is the point where I have my doubts. As far as I understand, on the = IESG, a lot of No Objection ballots are tolerated because of the wide=20 range of topics the IESG deals with and the large number of drafts. In=20 my imagination, RFC-related decisions should be supported by something=20 closer to consensus than just a single member being fully in on a=20 proposal. The number of proposals should also not be that high, so that=20 every member should easily be able to form a well-founded position on=20 every proposal. Also, at least in the case of stream managers, illness=20 or long vacations should be handled by having a (temporary) replacement=20 for the stream manager position, which would extend to the position on=20 the approval group. Regards, Martin. > D. In the event of one or more Block ballots, the work cannot proceed = to > completion. There must be discussion in the WG between the members of = the > approval group who balloted "Block" and the WG, and the focus of the > discussion must be on addressing the concerns and reaching consensus. > E. All comments in Yes ballots must be returned to the WG and the WG = must > attempt to address them through the normal consensus process. > F. In the event of there being exactly one Block ballot, and it being > impossible to reach agreement between the WG and the member of the = approval > group who issued the ballot, the approval group will exercise an = exception > resolution process as follows: > F1. The approval group will discuss the concern giving rise to the = ballot > and any proposed resolution from the WG > F2. The approval group will vote on whether to sustain the Block or to > release the work > F3. The vote shall be by simple majority with the chair of the group = holding > a casting vote in the event of a tie. > F4. If the Block is sustained, return to step D. > F5. If the work is released, return to step C. >=20 > I am sure that we can bike-shed the details of this. And, before we = are > done, we should do that and we should reach a process that we can all = agree > upon. >=20 > But, in the mean time I am interested to know whether = *something*similar* to > this could address the concerns of both sides of the current debate. >=20 > Thanks, > Adrian From nobody Fri Feb 12 16:37:05 2021 Return-Path: X-Original-To: rfced-future@iab.org Delivered-To: rfced-future@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A383A1210; Fri, 12 Feb 2021 16:33:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: The IAB , rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317640971.31337.3831067814878926668@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:29 -0800 Archived-At: Subject: [Rfced-future] rfcefdp - Requested session has been scheduled for IETF 110 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:38 -0000 Dear Eliot Lear, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rfcefdp Session 1 (2:00 requested) Tuesday, 9 March 2021, Session I 1300-1500 Room Name: Room 2 size: 502 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/rfcefdp.ics Request Information: --------------------------------------------------------- Working Group Name: RFC Editor Future Development Area Name: Internet Architecture Board Session Requester: Eliot Lear Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: rum dispatch stir sipcore emu opsawg anima People who must be present: Brian Rosen Eliot Lear Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Feb 13 14:05:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F62C3A1031 for ; Sat, 13 Feb 2021 14:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=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 uFMM4TitZz63 for ; Sat, 13 Feb 2021 14:05:15 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B390A3A102C for ; Sat, 13 Feb 2021 14:05:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7A3A8300BD0 for ; Sat, 13 Feb 2021 17:05:12 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hLcTJ-fAIiFK for ; Sat, 13 Feb 2021 17:05:10 -0500 (EST) Received: from [192.168.1.159] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 5DF2B300AA6; Sat, 13 Feb 2021 17:05:10 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> Date: Sat, 13 Feb 2021 17:05:11 -0500 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <26C52797-60A7-475F-A795-32E782F93A97@vigilsec.com> References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 Feb 2021 22:05:18 -0000 Adrian: I am largely in favor of this approach, assuming that this description = is after some form of community Last Call. Russ > On Feb 11, 2021, at 4:54 AM, Adrian Farrel = wrote: >=20 > It seems to me that we have reached a position where we are stuck = between > two positions which I shall express crudely: >=20 > 1. The WG must be supreme and, while the approval group can express = concerns > and return things to the WG for further consideration, the WG must be > allowed to have its way. >=20 > 2. The approval group in the form of one of its "voting" members must = be > allowed to block output of the WG that it considers harmful to the = series or > to one of the streams in the series. >=20 > These positions are accompanied by fears (valid or not) about how = people and > groups might operate, to force through ideas or to block them. Some = are > concerned that too many people will have the option to block work = based on > an overly wide perceived remit and overriding the will of the = community. > Others are concerned that the WG may become dominated by a clique of = loud > voices and that key opinions may be overridden in the operation of the > "normal" IETF consensus process. There are probably other nuanced = issues > that we don't need to dig up. >=20 > I don't believe we are likely to reach consensus to swing to align = with > either position 1 or 2 based on what I have seen in this discussion. >=20 > So I'd like to make a proposal which is in the form of an escalation > procedure based quite heavily on the processes used by the IESG when > balloting on documents. It goes as follows: >=20 > A. The WG last calls its work following the model of an IETF WG. It is > assumed that all members of the approval group will participate in the = WG, > and particularly in the WG last call, in an attempt to uncover any of = their > concerns early, and to avoid late surprises. It is understood that, = from > time to time, a member of the approval group may find it impossible to > participate in a particular discussion: they are encourage to send > delegates. > B. The "voting" members of the approval group review the work and = ballot. > They may ballot Yes, Block, No Position, Abstain, or Recuse. > - Yes means "I support this work." A Yes ballot may be accompanied = by > comments indicating thoughts and issues that should be looked at, but = are > non-blocking.=20 > - Block means "I have a serious concern that needs to be resolved = before > this work can proceed." > - No Position should only be used in exceptional cases such as = illness > or long vacation. Voting members are expected to try to present a = different > ballot position. > - Abstain means "I have a serious concern, but recognise that it = will > not be resolved." > - Recuse means "I am somehow so involved in this work that it would = be > improper for me to have a position." > C. Work proceeds if: > There is at least one "Yes" and no "Block" ballots. > D. In the event of one or more Block ballots, the work cannot proceed = to > completion. There must be discussion in the WG between the members of = the > approval group who balloted "Block" and the WG, and the focus of the > discussion must be on addressing the concerns and reaching consensus. > E. All comments in Yes ballots must be returned to the WG and the WG = must > attempt to address them through the normal consensus process. > F. In the event of there being exactly one Block ballot, and it being > impossible to reach agreement between the WG and the member of the = approval > group who issued the ballot, the approval group will exercise an = exception > resolution process as follows: > F1. The approval group will discuss the concern giving rise to the = ballot > and any proposed resolution from the WG > F2. The approval group will vote on whether to sustain the Block or to > release the work > F3. The vote shall be by simple majority with the chair of the group = holding > a casting vote in the event of a tie. > F4. If the Block is sustained, return to step D. > F5. If the work is released, return to step C. >=20 > I am sure that we can bike-shed the details of this. And, before we = are > done, we should do that and we should reach a process that we can all = agree > upon. >=20 > But, in the mean time I am interested to know whether = *something*similar* to > this could address the concerns of both sides of the current debate. >=20 > Thanks, > Adrian >=20 >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Sat Feb 13 14:19:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F693A104C for ; Sat, 13 Feb 2021 14:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFDlPNyf6NNG for ; Sat, 13 Feb 2021 14:19:20 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642243A104B for ; Sat, 13 Feb 2021 14:19:20 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id o21so2412738qtr.3 for ; Sat, 13 Feb 2021 14:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=/+qOKR5Id0UP4xMvCsuKVcxw5gvZwFS0GSnPfX3Lvig=; b=wMpTRGrEyEb75afIMhZk3Tvq1/fDTQNtQo82WXhn3MxDieQ6MHNsyyilQ1KDlt9dXE 9gckYLUfD/18qEn+E48/nusPPCWEGKSoZdRl/gahcDfigviCUd+2HQFiBUcXUfYLAclU w5UWh/kiM7DmZE4oUHDmng/NNZbacEPEoGx8BtH0ww5YIKLkwj1rRkH5hVa2VC5/l5nN wqa5pUONBqabD3bcXWSpUvEwXPfDmPLYiY7kJcE6NzTBf9m3Z02yy2+Ersq86ciX+vfb wWHscOcZHMdiH1YT/d7RxrnTZIUZzxohsj0ypnqoafar1qDA95seINPtNpaJ/VhHDiQX 9hTA== 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=/+qOKR5Id0UP4xMvCsuKVcxw5gvZwFS0GSnPfX3Lvig=; b=DJe8bW+EKAyMtMgUUqM5/T7eVTaOFjmDtcQSBv9c7VVLzF07VvVl6JXSjgnRoPdFtL g6J8ms2EDST5YPDiPh+KVq9retLqWHKAM0dyu7tO33YZaQQQU7DiLgB4g/6nYdTdJQWN TnPkiprUM3MuPJYJO6H5Pveu9voozexgwF9Caq+wjo0HKMyPUN2xWUV6Z5/Qy+MvrvxO CSzd1sfH468RqlaA6pi1IoGvCuLYH+ODU1sOdT+qGdYpBfb0/6N2EgX7857QqEFC4WER 1w1QLvudRSMcDvvML7/kPKVVJnmMn/0Rq//UB6WYR3WZFMo80OuLE8pcOQNCIQC+TYY5 cnYA== X-Gm-Message-State: AOAM53159P+20G/oY7HhPs3hYU5uLZ9LHrx9mVys3+bB5n8OJS2pNmZ/ LfgESB4/AKOxRIlkH4rET1plrDvRMinBJL11 X-Google-Smtp-Source: ABdhPJwRK9t+V0g8/odj0996DonjJS6448zFYCbkxJgI5dK0CD93uQxtkGldtOeB65iw9wkJwQdnNQ== X-Received: by 2002:aed:2644:: with SMTP id z62mr2985938qtc.72.1613254758917; Sat, 13 Feb 2021 14:19:18 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id t128sm9026977qka.46.2021.02.13.14.19.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Feb 2021 14:19:18 -0800 (PST) To: rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> From: Michael StJohns Message-ID: Date: Sat, 13 Feb 2021 17:19:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <059b01d7005b$f25241e0$d6f6c5a0$@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] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 Feb 2021 22:19:22 -0000 On 2/11/2021 4:54 AM, Adrian Farrel wrote: > It seems to me that we have reached a position where we are stuck between > two positions which I shall express crudely: > > 1. The WG must be supreme and, while the approval group can express concerns > and return things to the WG for further consideration, the WG must be > allowed to have its way. > > 2. The approval group in the form of one of its "voting" members must be > allowed to block output of the WG that it considers harmful to the series or > to one of the streams in the series. I think I'm in this last position.  But I think this needs to be a default of "fails without approval" rather than "proceeds without a block".  Unlike most other documents approved through the IETF system, a document in this stream has the possibility of screwing up the entire system of documents and hence a bit more care should be taken and a bit more approval should be needed before the document becomes the law of the land (IETF). > B. The "voting" members of the approval group review the work and ballot. > They may ballot Yes, Block, No Position, Abstain, or Recuse. > - Yes means "I support this work." A Yes ballot may be accompanied by > comments indicating thoughts and issues that should be looked at, but are > non-blocking. > - Block means "I have a serious concern that needs to be resolved before > this work can proceed." > - No Position should only be used in exceptional cases such as illness > or long vacation. Voting members are expected to try to present a different > ballot position. > - Abstain means "I have a serious concern, but recognise that it will > not be resolved." > - Recuse means "I am somehow so involved in this work that it would be > improper for me to have a position." > C. Work proceeds if: > There is at least one "Yes" and no "Block" ballots. I would delete "Abstain"  as not being a possible position.  I'd change "Block" to "No".   Members of the approval group are expected to review and have a position on all documents.  A "serious concern" with the document has to translate to a "No". I'd change C to "There is at least a majority of "Yes" votes and no more than one "No". Alternately, I'd allow a Block on a first vote and have that cause the approval body to enter into a one month delay on a final vote regardless of the number of Yes votes.  The WG or other submitter may chose at that point to withdraw the document from consideration for final approval to address any comments. I'd also strongly suggest that the WG MUST engage with the approving body prior to submission of the documents to ensure that not only are the WG desires met, but that the needs of the Streams are considered. Mike From nobody Sat Feb 13 14:27:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7FE3A105D for ; Sat, 13 Feb 2021 14:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO9XfmRV-vn4 for ; Sat, 13 Feb 2021 14:27:01 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABA13A1183 for ; Sat, 13 Feb 2021 14:26:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7CDA4300BD6 for ; Sat, 13 Feb 2021 17:26:48 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id a8KfJPZOnRPY for ; Sat, 13 Feb 2021 17:26:46 -0500 (EST) Received: from [192.168.1.159] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D227D300AA6; Sat, 13 Feb 2021 17:26:46 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Sat, 13 Feb 2021 17:26:48 -0500 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> To: Mike StJohns X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 Feb 2021 22:27:07 -0000 > On Feb 13, 2021, at 5:19 PM, Michael StJohns = wrote: >=20 > On 2/11/2021 4:54 AM, Adrian Farrel wrote: >> It seems to me that we have reached a position where we are stuck = between >> two positions which I shall express crudely: >>=20 >> 1. The WG must be supreme and, while the approval group can express = concerns >> and return things to the WG for further consideration, the WG must be >> allowed to have its way. >=20 >>=20 >> 2. The approval group in the form of one of its "voting" members must = be >> allowed to block output of the WG that it considers harmful to the = series or >> to one of the streams in the series. >=20 > I think I'm in this last position. But I think this needs to be a = default of "fails without approval" rather than "proceeds without a = block". Unlike most other documents approved through the IETF system, a = document in this stream has the possibility of screwing up the entire = system of documents and hence a bit more care should be taken and a bit = more approval should be needed before the document becomes the law of = the land (IETF). >=20 >=20 >> B. The "voting" members of the approval group review the work and = ballot. >> They may ballot Yes, Block, No Position, Abstain, or Recuse. >> - Yes means "I support this work." A Yes ballot may be = accompanied by >> comments indicating thoughts and issues that should be looked at, but = are >> non-blocking. >> - Block means "I have a serious concern that needs to be resolved = before >> this work can proceed." >> - No Position should only be used in exceptional cases such as = illness >> or long vacation. Voting members are expected to try to present a = different >> ballot position. >> - Abstain means "I have a serious concern, but recognise that it = will >> not be resolved." >> - Recuse means "I am somehow so involved in this work that it = would be >> improper for me to have a position." >> C. Work proceeds if: >> There is at least one "Yes" and no "Block" ballots. >=20 > I would delete "Abstain" as not being a possible position. I'd = change "Block" to "No". Members of the approval group are expected to = review and have a position on all documents. A "serious concern" with = the document has to translate to a "No". I think that Adrian picked these words based on my message. My message = was based on the ballot positions used by the IESG for charters. I think that "Block" has a connotation that further discussion is = welcome. On the other hand, "No" sounds too final. Russ From nobody Sat Feb 13 14:38:30 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688203A1084 for ; Sat, 13 Feb 2021 14:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3dRKhLDC8qx for ; Sat, 13 Feb 2021 14:38:26 -0800 (PST) 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 DC9393A1082 for ; Sat, 13 Feb 2021 14:38:25 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11DMcLdQ012407; Sat, 13 Feb 2021 22:38:21 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AFC3D2203B; Sat, 13 Feb 2021 22:38:21 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 9AE392203A; Sat, 13 Feb 2021 22:38:21 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.170.249]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11DMcKYL002885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Feb 2021 22:38:21 GMT Reply-To: From: "Adrian Farrel" To: "'Russ Housley'" Cc: References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <26C52797-60A7-475F-A795-32E782F93A97@vigilsec.com> In-Reply-To: <26C52797-60A7-475F-A795-32E782F93A97@vigilsec.com> Date: Sat, 13 Feb 2021 22:38:21 -0000 Organization: Old Dog Consulting Message-ID: <036001d70258$ef2f21a0$cd8d64e0$@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: AQFC9jKhHxSLiwTnuH2Y4NU4l8GOMgKe1qgmq2nLinA= Content-Language: en-gb X-Originating-IP: 87.112.170.249 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-25942.003 X-TM-AS-Result: No--11.935-10.0-31-10 X-imss-scan-details: No--11.935-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--11.935300-10.000000 X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbI61Z+HJnvsOoae+ev6zOlLqKNrFGduhxgFf gVTicugFDcbrI/fqzrQ0wzctYPMXOZhob9ur4dhcC4s/hE51YdVR3sGN+j7mNF5PUvqfnLYm2Uw BLM8az1TuDsvNWRKjrOr5+SrRXePNyxt1RBilwYk9k+RrKgLy2EPIlAqA4/DEy5JfHvVu9IuQtG nRkAKQMQjkg9bEPgqHnERuJUJiceNJJDuM6qazTvZvT2zYoYOwi+TAnPnbtthOz8YOQHnBeQOa5 6IXd1fmrxCwyzKoFWqpkYbxnLHZfW6rU5KSKOvUKUnZzo2UQD14Qwz73Zn4eO2bjZi+EXNnC2fO QJTdIgVC0EtKHL9bQCHjpPXG7bnGkvCi/xG+O8VW1k0wh4Tk8cGcvcBoab2jTql5sUV3fW5CIyK eBKUqgjUWiGs9AsvRJkAyRNZc6CiZxQ0LLmG+fyxg5qs3xzgfrXkuON8pnlFYyjK5TMgMNDRif7 JSrYOqRToGmkNUJwZB8C5LRz8z4CldXBfCiub0vr18zqZRJhIAaovTveFt1WmycYYiBYyZDUadX 8VcWfCE/kw+C0nA5uSOkVbqE3osY93BF3BQDx5OHhVJB+QhXLuM0remZ3UjYjNWMNi9SZqw0FFG deCd9m8X2hD8HnjIEzL9rCc3Ml4qEgEVlPNK9tMJkd+MUUHPvzsnmt00i6R+weGD7YUgC3r7hje GiWblMVjD/bD58+5/fS0YpxL5/MALMHtEBmE5PB/HI5uC0pXgHhCN7Wx4VWs5aIlDmHCsxTpjNC unU5ZRd1X5MIMIYxnA50zIPdI7WqBRUQClryaeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1d934/rDAK3zhG2qikEpQGUP0CaNyMsfWupYyrJSNwDM7MplH1SjVnWImEqqtWILKM6fDfO/ Yrxl X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 Feb 2021 22:38:28 -0000 Thanks Russ, all, for comments. Eliot has asked me to try to synthesise the comments received so far = into a refined write-up in time for Thursday's meeting. No doubt I'll manage this somehow (possibly forgoing something or other = =F0=9F=98=89) Adrian -----Original Message----- From: Russ Housley =20 Sent: 13 February 2021 22:05 To: Adrian Farrel Cc: rfced-future@iab.org Subject: Re: [Rfced-future] Non-approval resolution Adrian: I am largely in favor of this approach, assuming that this description = is after some form of community Last Call. Russ > On Feb 11, 2021, at 4:54 AM, Adrian Farrel = wrote: >=20 > It seems to me that we have reached a position where we are stuck = between > two positions which I shall express crudely: >=20 > 1. The WG must be supreme and, while the approval group can express = concerns > and return things to the WG for further consideration, the WG must be > allowed to have its way. >=20 > 2. The approval group in the form of one of its "voting" members must = be > allowed to block output of the WG that it considers harmful to the = series or > to one of the streams in the series. >=20 > These positions are accompanied by fears (valid or not) about how = people and > groups might operate, to force through ideas or to block them. Some = are > concerned that too many people will have the option to block work = based on > an overly wide perceived remit and overriding the will of the = community. > Others are concerned that the WG may become dominated by a clique of = loud > voices and that key opinions may be overridden in the operation of the > "normal" IETF consensus process. There are probably other nuanced = issues > that we don't need to dig up. >=20 > I don't believe we are likely to reach consensus to swing to align = with > either position 1 or 2 based on what I have seen in this discussion. >=20 > So I'd like to make a proposal which is in the form of an escalation > procedure based quite heavily on the processes used by the IESG when > balloting on documents. It goes as follows: >=20 > A. The WG last calls its work following the model of an IETF WG. It is > assumed that all members of the approval group will participate in the = WG, > and particularly in the WG last call, in an attempt to uncover any of = their > concerns early, and to avoid late surprises. It is understood that, = from > time to time, a member of the approval group may find it impossible to > participate in a particular discussion: they are encourage to send > delegates. > B. The "voting" members of the approval group review the work and = ballot. > They may ballot Yes, Block, No Position, Abstain, or Recuse. > - Yes means "I support this work." A Yes ballot may be accompanied = by > comments indicating thoughts and issues that should be looked at, but = are > non-blocking.=20 > - Block means "I have a serious concern that needs to be resolved = before > this work can proceed." > - No Position should only be used in exceptional cases such as = illness > or long vacation. Voting members are expected to try to present a = different > ballot position. > - Abstain means "I have a serious concern, but recognise that it = will > not be resolved." > - Recuse means "I am somehow so involved in this work that it would = be > improper for me to have a position." > C. Work proceeds if: > There is at least one "Yes" and no "Block" ballots. > D. In the event of one or more Block ballots, the work cannot proceed = to > completion. There must be discussion in the WG between the members of = the > approval group who balloted "Block" and the WG, and the focus of the > discussion must be on addressing the concerns and reaching consensus. > E. All comments in Yes ballots must be returned to the WG and the WG = must > attempt to address them through the normal consensus process. > F. In the event of there being exactly one Block ballot, and it being > impossible to reach agreement between the WG and the member of the = approval > group who issued the ballot, the approval group will exercise an = exception > resolution process as follows: > F1. The approval group will discuss the concern giving rise to the = ballot > and any proposed resolution from the WG > F2. The approval group will vote on whether to sustain the Block or to > release the work > F3. The vote shall be by simple majority with the chair of the group = holding > a casting vote in the event of a tie. > F4. If the Block is sustained, return to step D. > F5. If the work is released, return to step C. >=20 > I am sure that we can bike-shed the details of this. And, before we = are > done, we should do that and we should reach a process that we can all = agree > upon. >=20 > But, in the mean time I am interested to know whether = *something*similar* to > this could address the concerns of both sides of the current debate. >=20 > Thanks, > Adrian >=20 >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Sat Feb 13 14:53:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D14E3A10C7 for ; Sat, 13 Feb 2021 14:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcG8QZo6M2zP for ; Sat, 13 Feb 2021 14:53:13 -0800 (PST) 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 7FDCC3A10C0 for ; Sat, 13 Feb 2021 14:53:13 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id b14so3279780qkk.0 for ; Sat, 13 Feb 2021 14:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=mcPdRQ9HyQhxRDawMS2wikcyzt0k2ky3N+0xbQPBROw=; b=xycn1EkPSf8SMO+F9jhYKh5+Gn2/JsP3oc3MshMsYsLm9WAg3BSzAHdZ+fH+5yTuEr 0Z4AWqg0sA/NoYuCyKG3HEmzsuEiI1Xz8CGxc7VieLPjCwPeLMdQhFxfCr45B69soAr+ yQqH+yKRlvFH5Nq1BjzjwkVMIW6enRGeFM/yXerOLSOzfKfpNPWCcp8XRTrLZUDYPSL2 w1CtIiBz02zLZSCYpkaysuAP/nmL6pDLDTQanzoFfu38CAWeMTXDZ2sqmuIuDQ9U3W+d NZRtWbjvEcdP6ketxOs7f9u8FKegHGagxWXjeNukI9xq3s21cAmlJw0DLNrdoW7W57hF y0gA== 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=mcPdRQ9HyQhxRDawMS2wikcyzt0k2ky3N+0xbQPBROw=; b=tiMkSIWjBaj3h8utjgF9IzOJjDjj4TaB0HcnMb+Zy2Cv+FwjiPOxDjvRadpO1dn8Kr tBL8/2bbEVmJlSuhodA27kBglQKq0a1uCqxLw1iLjbM0h5gHY7LD8Vrc09HC/c2Pbzc5 6NQaL33sYnpV6mTpbiHK5yn/bzWuam6b6LhVPdKTTHbrgN2wHegxxtnTmcPHjGU6S8xF NCcARMVT4kHw1vY0UFfBAreQMz+tK67DqALNwP7xmHHdmoPSthb6VO9yxjyW8K720Q59 tCT4vJgb5uT+C26Nw9YbgDx9F0dlaylvROu5ZFTG/bpwpM1zzIaJVJQ/J8JmSK9SkS/A ES8w== X-Gm-Message-State: AOAM532nYbqEiQxY0uIb3Kk4+HrxpFFAm66zcUrNEpaMLwlw5QdZ5JXw 4BsdGRpa2PW5R7OcunG6i/GEIZHvEL1Hkafc X-Google-Smtp-Source: ABdhPJxjQzLhMrRDM6XvIUbpuPa9nH8ZoIpm9cTovyFBOv94Y3iXbumb+7Xpw1fv+jTxS0ZD/CaZOA== X-Received: by 2002:a37:4b49:: with SMTP id y70mr8796679qka.228.1613256787023; Sat, 13 Feb 2021 14:53:07 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id 18sm7980234qtw.70.2021.02.13.14.53.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Feb 2021 14:53:06 -0800 (PST) To: Russ Housley Cc: rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> From: Michael StJohns Message-ID: <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> Date: Sat, 13 Feb 2021 17:53:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 Feb 2021 22:53:20 -0000 On 2/13/2021 5:26 PM, Russ Housley wrote: > I think that "Block" has a connotation that further discussion is welcome. On the other hand, "No" sounds too final. > Agree. But unlike the rest of the IETF style document processes, this group is dealing with a) a very small document set, and b) a very focused document set and c) a requirement to involve the approval body in the formation of such documents.  If a document makes it to the approval body without resolving the approval body comment(s), I'd suggest that discussion has already completed and that the person voting "no" is acknowledging that process. Mike From nobody Tue Feb 16 06:19:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A7B3A0D58 for ; Tue, 16 Feb 2021 06:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mcH-08_qNQ65 for ; Tue, 16 Feb 2021 06:19:25 -0800 (PST) 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 4B1033A0A3D for ; Tue, 16 Feb 2021 06:19:25 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 951AE2788B; Tue, 16 Feb 2021 06:19:23 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: Russ Housley , rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> Date: Tue, 16 Feb 2021 06:19:23 -0800 In-Reply-To: <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> (Michael StJohns's message of "Sat, 13 Feb 2021 17:53:05 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 14:19:26 -0000 Michael StJohns writes: > If a document makes it to the approval body without resolving the > approval body comment(s), I'd suggest that discussion has already > completed and that the person voting "no" is acknowledging that > process. So, in your view "no" is really a "never". IE, it's too late to discuss further because the discussion has already concluded and there is never anything beyond this voting point? IE, this is the last step in the decision making process? -- Wes Hardaker USC/ISI From nobody Tue Feb 16 07:43:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE943A07E6 for ; Tue, 16 Feb 2021 07:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 YXC-jsONUKJR for ; Tue, 16 Feb 2021 07:43:52 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684BE3A0786 for ; Tue, 16 Feb 2021 07:43:51 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11GFhnvG017314 for ; Tue, 16 Feb 2021 15:43:49 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B103022042 for ; Tue, 16 Feb 2021 15:43:49 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 9A3D822040 for ; Tue, 16 Feb 2021 15:43:49 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.200]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11GFhdEF013937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 16 Feb 2021 15:43:48 GMT Reply-To: From: "Adrian Farrel" To: Date: Tue, 16 Feb 2021 15:43:39 -0000 Organization: Old Dog Consulting Message-ID: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdcEend2jO63euAzSFuSAQubSLPG9Q== Content-Language: en-gb X-Originating-IP: 195.166.134.200 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-25942.003 X-TM-AS-Result: No--7.777-10.0-31-10 X-imss-scan-details: No--7.777-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--7.777000-10.000000 X-TMASE-MatchedRID: plY+lOywO/sOwAmmWH5kBEI4eS9mV4/sLjmiN0TsUBbLkl8e9W70i4w0 ZuabowBJByiKMiu8hxQPsMiSITv1VUYHUwS2/Lf1Lyz9QvAyHjoQw535+M4bTiuGKh4AkqKVOv5 xGAHttYqcEY9nUXU52+8AhpH2qqaS83gviLOxr+Rn3ejPjd19ca15LjjfKZ5RFujNgNeS9UBWNq wl1FguifGeXyqYAyTw0NCqOuZrDkj+LMBubZglGZaX2JWUPLy8mkdAU3usvKuCm0ktRXpIXRDIw 7HM/OWFYSRElaqsSEzcp84GAHRlYSMl1hCOZZHt/sUSFaCjTLyUOCxPuT+1PjGQt2RbsLmqun/n V2uWnO0srFyss2eexlKKhJzxP81Taouz65/8ri0sIMJqMNlanTsY2/UEG7fkS8QrgUwl2irsh1c sNX6njBMbIiVA+EZDNd5AH8/Ww6/rhraMUXTqiq2h350vYYtlu4zSt6ZndSM4XREg9Ki10ye8PS PebEZnY7fzidZZ4h2WRdg0HF7GTfK8P5YL7dF6sgYw1+LBrk3HKik02lpsOVNtD3nNFtZWxxGnm YpyTg9Mo9LRIVyOWZRNDYlhDNjbSDSYtjcE/IcsWKt1qrD4oQmtOibiW9/Iyjef3ni3BDYH4S+q Yy5HORCQS9hpZrG1N8qpMl2zzQVpDQtBbxfhCu69enT+tBuZmiIRKybdHSw9phCcpYL3wQDgUEs YRr3q4vM1YF6AJbZcLc3sLtjOt9CpCFLDTHZU3QfwsVk0UbtuRXh7bFKB7lB0FH0z1ijaQNfMJa 96MXnlkjWwhPX2SVPFygDSdsZSS4W/MRhJ1X4= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 15:43:55 -0000 Hi, As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H persuaded me to take a second pass trying to factor in some of the comments on the list. I can't promise that I have captured *exactly* what everyone said, especially as some of the opinions were conflicting. What I have done is try to move the text towards something that might be a compromise between the positions. FWIW, I went back to the "Discuss" position because it carries some implication that we are all going to try to get together and resolve this. I also tried to cut some of the waffle. I do tend to waffle. There are two open points. I'd humbly suggest that the people who raised these issues might try to throw some text at a solution. 1. At point C there is the concept of a "community last call". This was raised by Martin and Russ, and I suggest that they put forward a proposal. The challenge might be to find a way to identify and reach the "community" (it's easy in the IETF, but very hard for "the world"). 2. At point J there is the concept of "an appeal" in the case of Discusses being unreconcilable. This was raised by Adam and Mark. The challenge, as they noted, is working out to whom one appeals. Hope this is useful (which is, after all, the only point). Adrian ==== Decision-making procedures A. Development Cycle The WG is expected to show its work to the approval group and attempt to be aware of issues that the approval group might be concerned about. The members of the approval group are expected to pay attention to the work of the WG and speak up when they have concerns. The intention is early discovery of issues and avoidance of late surprises. B. WG last call The WG last calls its work following the model of an IETF WG. It is assumed that all members of the approval group will participate the WG last call, in an attempt to expose any of their concerns that still remain, and to reach agreement. C. Community last call / public comment It is unclear whether this step (corresponding to IETF last call) exists and how it would be operated. Further discussion needed per Martin and Russ. D. Participation by members of the approval group As noted in steps A and B, participation in WG work by members of the approval group is expected. It is understood that, from time to time, a member of the approval group may find it impossible to participate in a particular discussion: in this case, they are encourage to send delegates. E. Discussion by the approval group The approval group shall discuss the output of the WG. Such discussion is to take place normally within 2 weeks of the WG making a request. The 2 week period may be stretched by holidays or IETF meetings, but the WG must be notified if this is the case. All comments and concerns shall be documented to the WG which may take them into consideration. F. Approval by the approval group The voting members of the approval group shall formally ballot by the end of the discussion period in E. Each voting member may ballot one of: - Yes: Means "I support this work." A Yes ballot may be accompanied by comments indicating thoughts and issues that should be looked at, but are non-blocking. - Discuss: Means "I have a serious concern that I would like to Discuss before this work can proceed." Voting members are expected to actively engage in resolving their Discuss positions. - No Position: Only used in exceptional cases such as illness or long vacation. Voting members are expected to try to present a different ballot position. - Abstain: Means "I have a serious concern, but recognise that it will not be resolved." An Abstain ballot is a way for a voting member to get out of the way of progress even though it worries them. The existence of an Abstain ballot does not imply the work is flawed, but indicates a genuinely irreconcilable difference of opinion. - Recuse: Means "It would be improper for me to have a position." For example, if the proposal was to remunerate the voting member. G. Reasons for a Discuss The approval group shall maintain a list of reasons for a Discuss ballot. A Discuss that does not conform to one of these reasons shall not be valid, and must be re-balloted. An initial draft of this list is as follows: - The proposal would cause significant harm to one of the streams - The proposal would cause significant harm to the series - The proposal would cause inconvenience to a group of consumers, the benefit of the change does not outweigh the cost of the inconvenience, and that inconvenience could be overcome by using a different approach G. Work proceeds if... At the end of the discussion period (point E) or at any later time, there is at least one "Yes" and no "Discuss" ballot. That is, work fails to proceed unless it has approval. H. Resolution of Discusses A voting member who ballots Discuss shall explain their concerns to the WG and shall engage in discussions attempting to resolve the concerns and arrive at a compromise or other agreement. When such agreement is reached, the voting member should transition their ballot to a "Yes". A voting member may transition their ballot to an "Abstain" at any time, although all parties are encouraged to attempt to reach agreement. I. Single Discuss resolution In the event of there being exactly one Discuss ballot, and there being no timely progress to agreement between the WG and the member of the approval group who issued the ballot, the WG may request that the approval group exercise an exception resolution process as follows: - The approval group will discuss the concern giving rise to the ballot and any proposed resolution from the WG - The approval group shall attempt to reach consensus on whether to sustain the Discuss or to release the work, but failing that shall vote with a simple majority determining the outcome - If the Discuss is sustained, return to step H - If the work is released, the Discuss ballot shall be changed to an Abstain and the work shall progress J. Appeals In the event that more than one Discuss cannot be resolved or that a single Discuss is sustained by the approval group, there is a right of appeal. The details of this need to be worked out per Adam and Mark. From nobody Tue Feb 16 08:44:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEA03A0ADD for ; Tue, 16 Feb 2021 08:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cjHzLpfkx6dW for ; Tue, 16 Feb 2021 08:44:21 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7E73A0CA2 for ; Tue, 16 Feb 2021 08:44:09 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id m22so16866309lfg.5 for ; Tue, 16 Feb 2021 08:44:09 -0800 (PST) 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=yjCqfVQ3hcW+J1Zxcgl4K/kRUp4Lm9jnaIXg99wodQ0=; b=xdLBeG8atvK+tUNtWHVHm/xlyZ9wQ6Zx4aQw+97fsu3MsLeeZCVm0CbE4FXhuEIJg5 W/CZctUXnRbSPj7l19G+W/JmHu+0fw0w1RqZ6nIWxIMEvNZEWubj68gnd0aZCLrgkgZD /O+sxGWKKulCWaa5wfzygGk8dz48MPFJFuap1V8UNn1Bkr3UTzEB4uFlErUrCVrst3tF i0Qu2PaKD1We4DeNIYMwgerIcqCOfJq1w5ranc0LhgWqG4NfICz6ZkkDtSIgTn0RWnT4 lBrXzl26yRGarUsIM77SI/TPOex3FQx0kyxE4RlurgMf5GtpPGqUjcw8yo97gMZVELcb hOJA== 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=yjCqfVQ3hcW+J1Zxcgl4K/kRUp4Lm9jnaIXg99wodQ0=; b=lbfx+NMT+hfOCIM5h26GFbl/5hjBzAtdsDBrpSHPQLvF8OSADaFz6zME8FeZaQa/IM oGuL0PLZpvn9EVrWq3eiKhb2e+T3lnVltVdJTI/BBU5g6KGuyqncPc2Gaz2fgTfpBnTX EdHW5uhrAQLJT7VmYw9xIW0sH5Ko/saDa8t3RMnw8kl1jRcFoJ3lA5MK2ewBpGfa/JpF b3vg0XQh5oMx9LvNSFQYcpdz46GGtzf+Ph5AY1TYmHgK+PFwUTQRI5XzvTGDiFfQY7Xx KlqjjGzN6TEY27kWGkRb4/YXotIuEOvb6SxFoU51s1JUXxjFxy0ZB7plW7mdTp61Dm5/ 8mTA== X-Gm-Message-State: AOAM531RfBUNowZgfMR1xO5pzkERukwupj39HebPTctITsC/Gh2bgZAx j/f1UpO3vUz3c0l/7ay+3DAV+b8jm74v+QiY3P7DZcYIDTnNCw== X-Google-Smtp-Source: ABdhPJwnmAkJLKSx8vfMqvjuV51yVGAwDd8oaj0Uxn3yux5dH36ST3S1TSnyr7MIQ5Q9/rBy9TlAkGuQj5sopXYrExc= X-Received: by 2002:a05:6512:21c8:: with SMTP id d8mr11741427lft.557.1613493846842; Tue, 16 Feb 2021 08:44:06 -0800 (PST) MIME-Version: 1.0 References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> In-Reply-To: From: "StJohns, Michael" Date: Tue, 16 Feb 2021 11:43:56 -0500 Message-ID: To: Wes Hardaker Cc: Russ Housley , rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000096c00505bb76cff8" Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 16:44:23 -0000 --00000000000096c00505bb76cff8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 16, 2021 at 09:19 Wes Hardaker wrote: > Michael StJohns writes: > > > If a document makes it to the approval body without resolving the > > approval body comment(s), I'd suggest that discussion has already > > completed and that the person voting "no" is acknowledging that > > process. > > So, in your view "no" is really a "never". IE, it's too late to discuss > further because the discussion has already concluded and there is never > anything beyond this voting point? IE, this is the last step in the > decision making process? > -- > Wes Hardaker > USC/ISI > No. What I said in the other thread was: - Do people agree that any objections must be returned to the WG for discussion? I don't know what that actually does. Rejected documents (not originating in the approval body) that don't get approved are in the state that all non approved documents end up in and the WG or authors can take whatever actions they want including revising and resubmitting. I'd say instead that rejections from the approval body need a cover letter of some sort similar to how feedback works in the other streams and leave it at that. Rather than have the approval body process devolve into an adjunct of the WG process, I=E2=80=99d like there to be a clean separation between the two= . This also makes clear the two roles for the members of the approval body in both participating in the crafting of the document sin the WG and the decision process in the approval body. Later, mike --00000000000096c00505bb76cff8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 16, 2021 at 09:19 Wes Hardaker <wjhns1@hardakers.net> wrote:
Michael StJohns <msj@nthpermutation.com> writes:
> If a document makes it to the approval body without resolving the
> approval body comment(s), I'd suggest that discussion has already<= br> > completed and that the person voting "no" is acknowledging t= hat
> process.

So, in your view "no" is really a "never".=C2=A0 IE, it= 's too late to discuss
further because the discussion has already concluded and there is never
anything beyond this voting point?=C2=A0 IE, this is the last step in the decision making process?
--
Wes Hardaker
USC/ISI

No.= =C2=A0 What I said in the other thread was: =C2=A0
<= br>
    =
  • Do people agree that any objections must be re= turned to the WG for discussion?

I don't know w= hat that actually does.=C2=A0=C2=A0 Rejected documents (not originating in = the approval body) that don't get approved are in the state that all no= n approved documents end up in and the WG or authors can take whatever acti= ons they want including revising and resubmitting.=C2=A0 I'd say instea= d that rejections from the approval body need a cover letter of some sort s= imilar to how feedback works in the other streams and leave it at that.

=
Rather than have the approval body process devolve = into an adjunct of the WG process, I=E2=80=99d like there to be a clean sep= aration between the two.=C2=A0 This also makes clear the two roles for the = members of the approval body in both participating in the crafting of the d= ocument sin the WG and the decision process in the approval body.

Later, mike



--00000000000096c00505bb76cff8-- From nobody Tue Feb 16 08:59:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0E3A0BB3 for ; Tue, 16 Feb 2021 08:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF84QJqlLXXJ for ; Tue, 16 Feb 2021 08:59:42 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726153A0BDE for ; Tue, 16 Feb 2021 08:55:48 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11GGtg7R020001; Tue, 16 Feb 2021 16:55:42 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AC97C2204C; Tue, 16 Feb 2021 16:55:42 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 8E80E22046; Tue, 16 Feb 2021 16:55:42 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.200]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11GGtTvL006331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Feb 2021 16:55:41 GMT Reply-To: From: "Adrian Farrel" To: "'StJohns, Michael'" , "'Wes Hardaker'" Cc: , "'Russ Housley'" References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> In-Reply-To: Date: Tue, 16 Feb 2021 16:55:27 -0000 Organization: Old Dog Consulting Message-ID: <02ce01d70484$8e917310$abb45930$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CF_01D70484.8E923660" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFC9jKhHxSLiwTnuH2Y4NU4l8GOMgHlRdJNAfO4zmMB81HmLQH+2PZQAlgUn6erMgIm8A== Content-Language: en-gb X-Originating-IP: 195.166.134.200 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-25942.003 X-TM-AS-Result: No--24.559-10.0-31-10 X-imss-scan-details: No--24.559-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--24.559000-10.000000 X-TMASE-MatchedRID: B0+RG8xpjtTxIbpQ8BhdbMOYvqsF7ngCgkMXwPojuxfoA4t6iwgWjBAD U0md7t141LxsgLeQ5yj1yEkjh0q8iDuSyjwPyEwFHmtCXih7f9P4P7Nt1jwSKeRAMktxwsnyi7e t6e7ljTB60FCjuld9b/N4/Kc9b0bXzmRmmnTk3UEIs18ZTh19+PHoOMMtqjdO3unRG7yMq8WwZF Qe8mbnQ7sxN65mQUEF94kC+QgebwiFVWNH9lUU9WeLTmaxFK6ApWOBfK9L1z9Em2z04jGoEylKc sKM4Cvm8BDZgLo4o4vHFK+jBXQAnIx79FVL8Qb2KaMQ6tw7oDJ+CWCcHScOE40jIdnB7VAWkOqT J462iya12hnxAYmLkH6Y7p2uT2jxOqtHDb5Jdoq6iJsmkdGsWd9WrDP4LKdpnSgPkvDdtOgSpKY PHUJnSomZnwWWIBq/vy1D537721d4azimUe6PlGQYj6+BFPEwGfESeH6pl4ZHpEd1UrzmFdo4FZ oSpQ8YI4R8SjGpwQxUIeWBPbgx+xZUo/YA5GJaNmg1ckxsf6cSwak5eNXy+6EBi7RBcbi8vE8Ad WlKaiuV34ly4gf0KbGmPLUrS0N++KuH5yWJFSMxoyhWa19A5JKLNrbpy/A0TL7UowoFRPrxQS6s szEOmhMEJIAtVEvGryXKyzGJAO9ZXfkVrnVU0XlIk1mB0VxP/3x8h/jAheVj45SARuR9Kq5gSOX /YANP3c7SY8eZSi4oYj2veQH+qNVd2gBzAHvNPNFSp45HGjDVWJXkRYrtO5soi2XrUn/JlR1cT9 YafQVKWdTfwsJjy9CpCFLDTHZUSVdy2uiYUWJFGCd0S0NCsm9/xCkJe4YotrUVhbPWszjvpubIt sq2gNs/8ON75NFD66XHIc5w+gc= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 16:59:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CF_01D70484.8E923660 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mike, I tried to capture something along these lines in my 2nd cut. =20 That is: * Approval body people should participate in the WG and WGLC * The reasons for a Discuss must be clearly stated and communicated to = the WG * A discusser must attempt to resolve the issue in discussion with the = WG =20 Wordsmithing is welcome. =20 A =20 From: Rfced-future On Behalf Of StJohns, = Michael Sent: 16 February 2021 16:44 To: Wes Hardaker Cc: rfced-future@iab.org; Russ Housley Subject: Re: [Rfced-future] Non-approval resolution =20 =20 =20 On Tue, Feb 16, 2021 at 09:19 Wes Hardaker > wrote: Michael StJohns = > writes: > If a document makes it to the approval body without resolving the > approval body comment(s), I'd suggest that discussion has already > completed and that the person voting "no" is acknowledging that > process. So, in your view "no" is really a "never". IE, it's too late to discuss further because the discussion has already concluded and there is never anything beyond this voting point? IE, this is the last step in the decision making process? --=20 Wes Hardaker USC/ISI =20 No. What I said in the other thread was: =20 =20 * Do people agree that any objections must be returned to the WG for = discussion? I don't know what that actually does. Rejected documents (not = originating in the approval body) that don't get approved are in the = state that all non approved documents end up in and the WG or authors = can take whatever actions they want including revising and resubmitting. = I'd say instead that rejections from the approval body need a cover = letter of some sort similar to how feedback works in the other streams = and leave it at that. Rather than have the approval body process devolve into an adjunct of = the WG process, I=E2=80=99d like there to be a clean separation between = the two. This also makes clear the two roles for the members of the = approval body in both participating in the crafting of the document sin = the WG and the decision process in the approval body. =20 Later, mike =20 =20 =20 ------=_NextPart_000_02CF_01D70484.8E923660 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Mike, I tried to capture something = along these lines in my 2nd cut.

 

That = is:

  • Approval body people = should participate in the WG and WGLC
  • The reasons for a = Discuss must be clearly stated and communicated to the = WG
  • A discusser must attempt to resolve = the issue in discussion with the WG

 

Wordsmithing is = welcome.

 

A

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of StJohns, = Michael
Sent: 16 February 2021 16:44
To: Wes = Hardaker <wjhns1@hardakers.net>
Cc: = rfced-future@iab.org; Russ Housley = <housley@vigilsec.com>
Subject: Re: [Rfced-future] = Non-approval resolution

 

 

 

On = Tue, Feb 16, 2021 at 09:19 Wes Hardaker <wjhns1@hardakers.net> = wrote:

Michael = StJohns <msj@nthpermutation.com> writes:

> If = a document makes it to the approval body without resolving the
> = approval body comment(s), I'd suggest that discussion has = already
> completed and that the person voting "no" is = acknowledging that
> process.

So, in your view = "no" is really a "never".  IE, it's too late to = discuss
further because the discussion has already concluded and = there is never
anything beyond this voting point?  IE, this is = the last step in the
decision making process?
--
Wes = Hardaker
USC/ISI

 

No.  What I said in the other thread was: =  

 

  • Do people agree that any objections must be = returned to the WG for = discussion?

I don't know what that actually = does.   Rejected documents (not originating in the approval = body) that don't get approved are in the state that all non approved = documents end up in and the WG or authors can take whatever actions they = want including revising and resubmitting.  I'd say instead that = rejections from the approval body need a cover letter of some sort = similar to how feedback works in the other streams and leave it at = that.

Rather than = have the approval body process devolve into an adjunct of the WG = process, I=E2=80=99d like there to be a clean separation between the = two.  This also makes clear the two roles for the members of the = approval body in both participating in the crafting of the document sin = the WG and the decision process in the approval = body.

 

Later, mike

 

 

 

------=_NextPart_000_02CF_01D70484.8E923660-- From nobody Tue Feb 16 10:43:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF433A0E1F for ; Tue, 16 Feb 2021 10:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 oO9V57-oQGZQ for ; Tue, 16 Feb 2021 10:43:15 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E66C3A0E1D for ; Tue, 16 Feb 2021 10:43:14 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id h16so7736269qth.11 for ; Tue, 16 Feb 2021 10:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=BBKWn39/fbAEkN7VEgiifOVWL28LU5AoQjaOTjzS0x4=; b=zMrJf+3NEzusKeKezbvRoIbBcncr2hw61S7hyUtrsso4XDCrBF0hV2ZNrUp9l1L1pC kMTQQY87BXKed5npG8JgaiDpZo+8bweevrWyd83FJH/Ad81wZRP0vrhBGvEt4H+Nqc6Q mPpGW7gXlL7yRvqYue1bJ9KyJ3bf5/iPyVj8kfdBuVWlOldoHfg4/PsV6uty7FGkzKEQ klv9CtfjiR2teZr/xXZOKCLCcI/ZqHhodEerlq/2x7DKDpMXApfKzKQawu63PrPuo0ma qqkGwC6mUPJcKZ5toAbgAbUnqmQ+IANIbQYV6vQpkdDg2RIAg+13l0eMcsuBZINzjYAN EASw== 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=BBKWn39/fbAEkN7VEgiifOVWL28LU5AoQjaOTjzS0x4=; b=MQo6ZVDr4MpIAQdsgzRdcQrieGspX0IXWlPffBXT+AYftkEZsOXRdCcofhUAqSxadN OPaufV3P4TbWhCuA/d6ZX+2lFLbxg4KfYYQ6S25HnjwoXithpNoMzspDPCx2bZIcMKlR 2kZZzyXfwctBhCFGMcfVaISSdElVaZ8xTtz/UJrI8DslcyJG9ZL4HARMwxn7a2eelGs7 D1AUGTvqAMZ2/179HxVJqZOeIeuTMIg6k05/9R8KjsDfesi/rALKpid2wwd1OTbB0Tpu 6weqnykt5tck/x7EqhUqf21o84s/vrLnk0CYOeZn5hxqH8TA4n3n2iO9BAHh+dVg/mTf 7trA== X-Gm-Message-State: AOAM532ULg19Kts3fF6u8N5oensxx+3z7c8HpQagrUWTzdblprIshwE/ sGOxzm8HNOM7DzB/5p7R8+XDOQ== X-Google-Smtp-Source: ABdhPJzF7dU3dSV0NhOF9C0ib+4hDoE/rjWYrDsZTrtJqVY8XCdu9TyH2xrhMtk8XsUUlpj/xyLwEA== X-Received: by 2002:a05:622a:44d:: with SMTP id o13mr20059810qtx.378.1613500993797; Tue, 16 Feb 2021 10:43:13 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id h9sm1407993qke.121.2021.02.16.10.43.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Feb 2021 10:43:13 -0800 (PST) To: adrian@olddog.co.uk, 'Wes Hardaker' Cc: rfced-future@iab.org, 'Russ Housley' References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> From: Michael StJohns Message-ID: Date: Tue, 16 Feb 2021 13:43:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <02ce01d70484$8e917310$abb45930$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------AB80A8D6A45F92A86571E137" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 18:43:17 -0000 This is a multi-part message in MIME format. --------------AB80A8D6A45F92A86571E137 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/16/2021 11:55 AM, Adrian Farrel wrote: > > Mike, I tried to capture something along these lines in my 2^nd cut. > > That is: > > * Approval body people should participate in the WG and WGLC > * The reasons for a Discuss must be clearly stated and communicated > to the WG > * A discusser must attempt to resolve the issue in discussion with > the WG > I think the above is reasonable as far as it goes - but I'd really suggest there is no "Discuss" vote - just a "No" vote.   An approval body member who has issues should have tried to address them in the WG.  When the document is submitted to the AB, if such issues remain, the AB member can either vote Yes maybe indicating in the minutes that these issues remain unaddressed, but they won't block on them, or No.  If there are sufficient No votes (or insufficient Yes votes), then the fact that the issue(s) remain unresolved gets conveyed with the rejection.  The WG can either try again or abandon the documents. Unlike the IETF model where the IESG as a whole has little initial input into the documents, that can't be the case here if we expect to have a functioning RFC system. The AB members MUST be involved in the WG activities.  Because of that difference, the IESG discuss model really does not fit the RFC model. > Wordsmithing is welcome. > > A > > *From:*Rfced-future *On Behalf Of > *StJohns, Michael > *Sent:* 16 February 2021 16:44 > *To:* Wes Hardaker > *Cc:* rfced-future@iab.org; Russ Housley > *Subject:* Re: [Rfced-future] Non-approval resolution > > On Tue, Feb 16, 2021 at 09:19 Wes Hardaker > wrote: > > Michael StJohns > writes: > > > If a document makes it to the approval body without resolving the > > approval body comment(s), I'd suggest that discussion has already > > completed and that the person voting "no" is acknowledging that > > process. > > So, in your view "no" is really a "never".  IE, it's too late to > discuss > further because the discussion has already concluded and there is > never > anything beyond this voting point?  IE, this is the last step in the > decision making process? > -- > Wes Hardaker > USC/ISI > > No.  What I said in the other thread was: > > * Do people agree that any objections must be returned to the WG > for discussion? > > I don't know what that actually does.   Rejected documents (not > originating in the approval body) that don't get approved are in the > state that all non approved documents end up in and the WG or authors > can take whatever actions they want including revising and > resubmitting.  I'd say instead that rejections from the approval body > need a cover letter of some sort similar to how feedback works in the > other streams and leave it at that. > > Rather than have the approval body process devolve into an adjunct of > the WG process, I’d like there to be a clean separation between the > two.  This also makes clear the two roles for the members of the > approval body in both participating in the crafting of the document > sin the WG and the decision process in the approval body. > > Later, mike > --------------AB80A8D6A45F92A86571E137 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/16/2021 11:55 AM, Adrian Farrel wrote:

Mike, I tried to capture something along these lines in my 2nd cut.

 

That is:

  • Approval body people should participate in the WG and WGLC
  • The reasons for a Discuss must be clearly stated and communicated to the WG
  • A discusser must attempt to resolve the issue in discussion with the WG


I think the above is reasonable as far as it goes - but I'd really suggest there is no "Discuss" vote - just a "No" vote.   An approval body member who has issues should have tried to address them in the WG.  When the document is submitted to the AB, if such issues remain, the AB member can either vote Yes maybe indicating in the minutes that these issues remain unaddressed, but they won't block on them, or No.  If there are sufficient No votes (or  insufficient Yes votes), then the fact that the issue(s) remain unresolved gets conveyed with the rejection.  The WG can either try again or abandon the documents.

Unlike the IETF model where the IESG as a whole has little initial input into the documents, that can't be the case here if we expect to have a functioning RFC system. The AB members MUST be involved in the WG activities.  Because of that difference, the IESG discuss model really does not fit the RFC model.


 

Wordsmithing is welcome.

 

A

 

From: Rfced-future <rfced-future-bounces@iab.org> On Behalf Of StJohns, Michael
Sent: 16 February 2021 16:44
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: rfced-future@iab.org; Russ Housley <housley@vigilsec.com>
Subject: Re: [Rfced-future] Non-approval resolution

 

 

 

On Tue, Feb 16, 2021 at 09:19 Wes Hardaker <wjhns1@hardakers.net> wrote:

Michael StJohns <msj@nthpermutation.com> writes:

> If a document makes it to the approval body without resolving the
> approval body comment(s), I'd suggest that discussion has already
> completed and that the person voting "no" is acknowledging that
> process.

So, in your view "no" is really a "never".  IE, it's too late to discuss
further because the discussion has already concluded and there is never
anything beyond this voting point?  IE, this is the last step in the
decision making process?
--
Wes Hardaker
USC/ISI

 

No.  What I said in the other thread was:  

 

  • Do people agree that any objections must be returned to the WG for discussion?

I don't know what that actually does.   Rejected documents (not originating in the approval body) that don't get approved are in the state that all non approved documents end up in and the WG or authors can take whatever actions they want including revising and resubmitting.  I'd say instead that rejections from the approval body need a cover letter of some sort similar to how feedback works in the other streams and leave it at that.

Rather than have the approval body process devolve into an adjunct of the WG process, I’d like there to be a clean separation between the two.  This also makes clear the two roles for the members of the approval body in both participating in the crafting of the document sin the WG and the decision process in the approval body.

 

Later, mike

 

 

 


--------------AB80A8D6A45F92A86571E137-- From nobody Tue Feb 16 10:52:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED873A0E34 for ; Tue, 16 Feb 2021 10:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N8e-dWls7do for ; Tue, 16 Feb 2021 10:52:18 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9A13A0E32 for ; Tue, 16 Feb 2021 10:52:18 -0800 (PST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 2AB4168203E; Tue, 16 Feb 2021 13:52:17 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Scott Bradner In-Reply-To: Date: Tue, 16 Feb 2021 13:52:16 -0500 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> To: Michael StJohns X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 18:52:21 -0000 what about non WG documents? (e.g., individual submissions)=20 Scott > On Feb 16, 2021, at 1:43 PM, Michael StJohns = wrote: >=20 > On 2/16/2021 11:55 AM, Adrian Farrel wrote: >> Mike, I tried to capture something along these lines in my 2nd cut. >>=20 >> =20 >>=20 >> That is: >>=20 >> =E2=80=A2 Approval body people should participate in the WG and = WGLC >> =E2=80=A2 The reasons for a Discuss must be clearly stated and = communicated to the WG >> =E2=80=A2 A discusser must attempt to resolve the issue in = discussion with the WG >=20 >=20 > I think the above is reasonable as far as it goes - but I'd really = suggest there is no "Discuss" vote - just a "No" vote. An approval = body member who has issues should have tried to address them in the WG. = When the document is submitted to the AB, if such issues remain, the AB = member can either vote Yes maybe indicating in the minutes that these = issues remain unaddressed, but they won't block on them, or No. If = there are sufficient No votes (or insufficient Yes votes), then the = fact that the issue(s) remain unresolved gets conveyed with the = rejection. The WG can either try again or abandon the documents. >=20 > Unlike the IETF model where the IESG as a whole has little initial = input into the documents, that can't be the case here if we expect to = have a functioning RFC system. The AB members MUST be involved in the WG = activities. Because of that difference, the IESG discuss model really = does not fit the RFC model. >=20 >=20 >=20 >> =20 >>=20 >> Wordsmithing is welcome. >>=20 >> =20 >>=20 >> A >>=20 >> =20 >>=20 >> From: Rfced-future On Behalf Of = StJohns, Michael >> Sent: 16 February 2021 16:44 >> To: Wes Hardaker >> Cc: rfced-future@iab.org; Russ Housley >> Subject: Re: [Rfced-future] Non-approval resolution >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Tue, Feb 16, 2021 at 09:19 Wes Hardaker = wrote: >>=20 >> Michael StJohns writes: >>=20 >> > If a document makes it to the approval body without resolving the >> > approval body comment(s), I'd suggest that discussion has already >> > completed and that the person voting "no" is acknowledging that >> > process. >>=20 >> So, in your view "no" is really a "never". IE, it's too late to = discuss >> further because the discussion has already concluded and there is = never >> anything beyond this voting point? IE, this is the last step in the >> decision making process? >> --=20 >> Wes Hardaker >> USC/ISI >>=20 >> =20 >>=20 >> No. What I said in the other thread was: =20 >>=20 >> =20 >>=20 >> =E2=80=A2 Do people agree that any objections must be returned = to the WG for discussion? >> I don't know what that actually does. Rejected documents (not = originating in the approval body) that don't get approved are in the = state that all non approved documents end up in and the WG or authors = can take whatever actions they want including revising and resubmitting. = I'd say instead that rejections from the approval body need a cover = letter of some sort similar to how feedback works in the other streams = and leave it at that. >>=20 >> Rather than have the approval body process devolve into an adjunct of = the WG process, I=E2=80=99d like there to be a clean separation between = the two. This also makes clear the two roles for the members of the = approval body in both participating in the crafting of the document sin = the WG and the decision process in the approval body. >>=20 >> =20 >>=20 >> Later, mike >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Feb 16 11:04:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A96E3A0E4C for ; Tue, 16 Feb 2021 11:04:18 -0800 (PST) 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 YT5r6C3G20fs for ; Tue, 16 Feb 2021 11:04:15 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBD03A0E3B for ; Tue, 16 Feb 2021 11:04:13 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11GJ47Oc008371; Tue, 16 Feb 2021 19:04:07 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 892AE2203D; Tue, 16 Feb 2021 19:04:07 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 71BC82203C; Tue, 16 Feb 2021 19:04:07 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.200]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11GJ45oA001693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Feb 2021 19:04:06 GMT Reply-To: From: "Adrian Farrel" To: "'Michael StJohns'" , "'Wes Hardaker'" Cc: , "'Russ Housley'" References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> In-Reply-To: Date: Tue, 16 Feb 2021 19:04:04 -0000 Organization: Old Dog Consulting Message-ID: <031b01d70496$7f264920$7d72db60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_031C_01D70496.7F2781A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFC9jKhHxSLiwTnuH2Y4NU4l8GOMgHlRdJNAfO4zmMB81HmLQH+2PZQAlgUn6cBIGntLgGD84D0qxz/PFA= Content-Language: en-gb X-Originating-IP: 195.166.134.200 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-25942.003 X-TM-AS-Result: No--15.149-10.0-31-10 X-imss-scan-details: No--15.149-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--15.148800-10.000000 X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbI61Z+HJnvsOpWOBfK9L1z9XXbZeMl1WD3ng dHUORlYL7xLJm73AMlSdiEw2m/81b0dJ6BpskzTLqjZ865FPtpoj56rvFVgJ7Gz50Qgrr06PaZL X9qrZPKIAKkI9yCanYwpmVeR0pkrdZKCyFRIOMWUZ9MKxHrUy4THxTmKQiP7iuhHIEUdjiTHkYB DLwsbmZ1+xqm1+8gA1VaG0Xl3juCv87Z5ei5jPEFkxnoxnQfVSStGAgmKqWuUINpIFnbd6mntcS BXe4RfNx2BzlZpGzx5XyJfIqosReURV7C9ojOZ15Qo03mEdwAHg02I3oyGU8L142xO28EPeDUad X8VcWfD+jcLt5fUKob04our2MsXR8ZTibkDR5X2h16VXdExyzgvxMaV6x4s8JlAnHnaswGlPnXZ 9u2IhHdc7Ay/DJk3NNUCIiMoGGlesRgqDQj9gp/jQkA7rdCuFdscokGT+O49Em2z04jGoEylKcs KM4Cvm8BDZgLo4o4sygWhEWCrRtwS+Xc7cwjX6+ACG5oWJ7tKeutXlSdRVjUamD+dkC4n9iW9Kh QDG5stjGAilamgi/wfA/nMs0uTJR1vveBQPCRcrCLswi3Npja6IBbSnfz+3CwWRLqiC/UqfcdLZ s76StsJ++jdSAUUkfsjPhd+fS5HUsV22aJ5sToDcpVWyPxAMqAn+yHbzwCeWyPi+tKraPMg1IeY uXGyOnIB/iADzv69RgM2MVcov0wV0DOIpze3pcaD+wPaBYtZKRaXN2yYjHk/cRvj5stP6fUKi99 DpPHhKkAU17gNQnuGzdbsR7OPYyAzYZQWW+9qeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg1KMqIeOstifOMB0shqXhHro7NYXgHKUTvKwpIgJ9gqohmMthcwvFFv3UYLEZvNwd2WRxJ7p CWCK X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 19:04:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_031C_01D70496.7F2781A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable OK, thanks Mike. =20 I=E2=80=99m not going to debate, but I just wanted to say what was = underlying my thinking. It seemed to me that everything you say about getting discussion done in = the WG and early seems good. However, I didn=E2=80=99t want to just draw = a line at that point when the strength of view of the approval group = member might not have been clear, and the discussions in the WG should = (possibly) not be predicated on a persons opinion being so powerful.=20 The whole point, I hope, is that everything can be a discussion with it = being understood that each approval group member has a position that = they are bound to defend. =20 Anyway, onwards to other people=E2=80=99s voices. =20 Adrian =20 From: Michael StJohns =20 Sent: 16 February 2021 18:43 To: adrian@olddog.co.uk; 'Wes Hardaker' Cc: rfced-future@iab.org; 'Russ Housley' Subject: Re: [Rfced-future] Non-approval resolution =20 On 2/16/2021 11:55 AM, Adrian Farrel wrote: Mike, I tried to capture something along these lines in my 2nd cut. =20 That is: 1. Approval body people should participate in the WG and WGLC 2. The reasons for a Discuss must be clearly stated and communicated to = the WG 3. A discusser must attempt to resolve the issue in discussion with the = WG =20 I think the above is reasonable as far as it goes - but I'd really = suggest there is no "Discuss" vote - just a "No" vote. An approval = body member who has issues should have tried to address them in the WG. = When the document is submitted to the AB, if such issues remain, the AB = member can either vote Yes maybe indicating in the minutes that these = issues remain unaddressed, but they won't block on them, or No. If = there are sufficient No votes (or insufficient Yes votes), then the = fact that the issue(s) remain unresolved gets conveyed with the = rejection. The WG can either try again or abandon the documents. Unlike the IETF model where the IESG as a whole has little initial input = into the documents, that can't be the case here if we expect to have a = functioning RFC system. The AB members MUST be involved in the WG = activities. Because of that difference, the IESG discuss model really = does not fit the RFC model. =20 =20 Wordsmithing is welcome. =20 A =20 From: Rfced-future = On Behalf Of StJohns, Michael Sent: 16 February 2021 16:44 To: Wes Hardaker Cc: rfced-future@iab.org ; Russ Housley = Subject: Re: [Rfced-future] Non-approval resolution =20 =20 =20 On Tue, Feb 16, 2021 at 09:19 Wes Hardaker > wrote: Michael StJohns = > writes: > If a document makes it to the approval body without resolving the > approval body comment(s), I'd suggest that discussion has already > completed and that the person voting "no" is acknowledging that > process. So, in your view "no" is really a "never". IE, it's too late to discuss further because the discussion has already concluded and there is never anything beyond this voting point? IE, this is the last step in the decision making process? --=20 Wes Hardaker USC/ISI =20 No. What I said in the other thread was: =20 =20 1. Do people agree that any objections must be returned to the WG for = discussion? I don't know what that actually does. Rejected documents (not = originating in the approval body) that don't get approved are in the = state that all non approved documents end up in and the WG or authors = can take whatever actions they want including revising and resubmitting. = I'd say instead that rejections from the approval body need a cover = letter of some sort similar to how feedback works in the other streams = and leave it at that. Rather than have the approval body process devolve into an adjunct of = the WG process, I=E2=80=99d like there to be a clean separation between = the two. This also makes clear the two roles for the members of the = approval body in both participating in the crafting of the document sin = the WG and the decision process in the approval body. =20 Later, mike =20 =20 =20 =20 ------=_NextPart_000_031C_01D70496.7F2781A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

OK, thanks = Mike.

 

I=E2=80=99m = not going to debate, but I just wanted to say what was underlying my = thinking.

It seemed to me that everything you = say about getting discussion done in the WG and early seems good. = However, I didn=E2=80=99t want to just draw a line at that point when = the strength of view of the approval group member might not have been = clear, and the discussions in the WG should (possibly) not be predicated = on a persons opinion being so powerful.

The whole = point, I hope, is that everything can be a discussion with it being = understood that each approval group member has a position that they are = bound to defend.

 

Anyway, = onwards to other people=E2=80=99s voices.

 

Adrian

 

From: Michael StJohns = <msj@nthpermutation.com>
Sent: 16 February 2021 = 18:43
To: adrian@olddog.co.uk; 'Wes Hardaker' = <wjhns1@hardakers.net>
Cc: rfced-future@iab.org; 'Russ = Housley' <housley@vigilsec.com>
Subject: Re: = [Rfced-future] Non-approval = resolution

 

On = 2/16/2021 11:55 AM, Adrian Farrel wrote:

Mike, I = tried to capture something along these lines in my 2nd = cut.

 

That = is:

  1. Approval body people should = participate in the WG and WGLC
  2. The reasons for a = Discuss must be clearly stated and communicated to the = WG
  3. A discusser must attempt to resolve = the issue in discussion with the = WG

 

I = think the above is reasonable as far as it goes - but I'd really suggest = there is no "Discuss" vote - just a "No" = vote.   An approval body member who has issues should have = tried to address them in the WG.  When the document is submitted to = the AB, if such issues remain, the AB member can either vote Yes maybe = indicating in the minutes that these issues remain unaddressed, but they = won't block on them, or No.  If there are sufficient No votes = (or  insufficient Yes votes), then the fact that the issue(s) = remain unresolved gets conveyed with the rejection.  The WG can = either try again or abandon the documents.

Unlike the = IETF model where the IESG as a whole has little initial input into the = documents, that can't be the case here if we expect to have a = functioning RFC system. The AB members MUST be involved in the WG = activities.  Because of that difference, the IESG discuss model = really does not fit the RFC = model.

 

 

Wordsmithing is = welcome.

 

A

 

From: Rfced-future <rfced-future-bounces@iab= .org> On Behalf Of StJohns, Michael
Sent: 16 = February 2021 16:44
To: Wes Hardaker <wjhns1@hardakers.net>
= Cc: rfced-future@iab.org; Russ = Housley <housley@vigilsec.com>
= Subject: Re: [Rfced-future] Non-approval = resolution

 

 

 

On = Tue, Feb 16, 2021 at 09:19 Wes Hardaker <wjhns1@hardakers.net> = wrote:

Michael StJohns <msj@nthpermutation.com> writes:

> If = a document makes it to the approval body without resolving the
> = approval body comment(s), I'd suggest that discussion has = already
> completed and that the person voting "no" is = acknowledging that
> process.

So, in your view = "no" is really a "never".  IE, it's too late to = discuss
further because the discussion has already concluded and = there is never
anything beyond this voting point?  IE, this is = the last step in the
decision making process?
--
Wes = Hardaker
USC/ISI

 

No.  What I said in the other thread was: =  

 

  1. Do people agree that any objections must be = returned to the WG for = discussion?

I don't know what that actually = does.   Rejected documents (not originating in the approval = body) that don't get approved are in the state that all non approved = documents end up in and the WG or authors can take whatever actions they = want including revising and resubmitting.  I'd say instead that = rejections from the approval body need a cover letter of some sort = similar to how feedback works in the other streams and leave it at = that.

Rather than = have the approval body process devolve into an adjunct of the WG = process, I=E2=80=99d like there to be a clean separation between the = two.  This also makes clear the two roles for the members of the = approval body in both participating in the crafting of the document sin = the WG and the decision process in the approval = body.

 

Later, mike

 

 

 

 <= /o:p>

------=_NextPart_000_031C_01D70496.7F2781A0-- From nobody Tue Feb 16 11:10:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B953A0E77 for ; Tue, 16 Feb 2021 11:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POz6vHOwtXLx for ; Tue, 16 Feb 2021 11:10:16 -0800 (PST) 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 CCF933A0E76 for ; Tue, 16 Feb 2021 11:10:15 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id x14so10500804qkm.2 for ; Tue, 16 Feb 2021 11:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=xm53/WviJEHlvQVl8xIdUtz4ne2rfTy24S2X01IYEk0=; b=jxegrDXykr6V/168t71e4q0GHfexM/ytIwN2RvSuJaAQUTeW/byr4ABat1TtBh45sL fAKl35NBIxJ1uwgDNNlgm0MGBvd7xAXmACs3l8FB5xo4As2EU89XqxE+UFZtHd/NyiSI Fu21/zc6VODNcY0Ye+MSHttPG3Q6yNdgNfMEwiTOmtsxeu72SXDAI6ZBPLED//KZz+MZ Vc56FQAOTXVJHlxf5B6da+es5DUowjMhJSrub0+p5fvq5Hjv62ih2iKnxVaSwUkv5OJ7 M40d+gBgTGbiAw6v0dSSPjIkcZLHCp97vFnL5jNMtZk9ODlgTlljjXmPWpoxZrqECxGu xrYQ== 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=xm53/WviJEHlvQVl8xIdUtz4ne2rfTy24S2X01IYEk0=; b=hZ8wL20Kyol20B3l2sv97A3L/jLY1tU/FWMzdncRCxnFE/CDAnGxrbwEyLtiycKtUl IYUEQxePrf4XZ8XLoQhrxuydnvCIbeGt00VCd1Lz+TAbySEux3EZonlirvHDQvPtnk9l qv6RoOpyQ/Pw3PMfufdRLxJXas2qBTYDZXnTi+TZdC6guewlBxrpnRHsqR77WFGx++Pc Q5YdZjLECVLVoQlf0Bup5wttZiN1kXguhfWOJgn+aiUoFIcTgTsJYIsJA7vdmcSGs5Gt 5L7TH0kYZtU1VmjgRsrIxLLRuLQBdFaIe7hexSuAK7OdY9XqDt5prP5w9Yq+c9eBs47D 0bPQ== X-Gm-Message-State: AOAM532z4v/ZdAWmJLDEDy8ioHleugROb2L/sDURC9fClGtJ4UaruoaU FZiekGtphkGBlGo71GHReXV7XqXDVNgaeUm2 X-Google-Smtp-Source: ABdhPJz4zGnRkg6QezMD1Q5SEL0TwdwAyLQJV4sCY/sC1SvUs5KLcUbQKsRgziqgtQ8fYXZBs/8lyQ== X-Received: by 2002:a37:4ed1:: with SMTP id c200mr7455135qkb.55.1613502613936; Tue, 16 Feb 2021 11:10:13 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id k187sm15173654qkc.74.2021.02.16.11.10.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Feb 2021 11:10:13 -0800 (PST) To: Scott Bradner Cc: rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> From: Michael StJohns Message-ID: Date: Tue, 16 Feb 2021 14:10:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 19:10:18 -0000 On 2/16/2021 1:52 PM, Scott Bradner wrote: > what about non WG documents? (e.g., individual submissions) > > Scott Good catch.  The AB needs to have some sort of buy in for individual submissions which suggests that at least the general scope of the IS needs to be discussed with the AB near the beginning of the document process.    I think the approval process remains the same, but there needs to be a flavor of an adoption process - e.g. some AB member has to sponsor the document prior to it being submitted for approval and that AB member would be responsible for working with the author(s) to deal with probable AB pushbacks. Mike > >> On Feb 16, 2021, at 1:43 PM, Michael StJohns wrote: >> >> On 2/16/2021 11:55 AM, Adrian Farrel wrote: >>> Mike, I tried to capture something along these lines in my 2nd cut. >>> >>> >>> >>> That is: >>> >>> • Approval body people should participate in the WG and WGLC >>> • The reasons for a Discuss must be clearly stated and communicated to the WG >>> • A discusser must attempt to resolve the issue in discussion with the WG >> >> I think the above is reasonable as far as it goes - but I'd really suggest there is no "Discuss" vote - just a "No" vote. An approval body member who has issues should have tried to address them in the WG. When the document is submitted to the AB, if such issues remain, the AB member can either vote Yes maybe indicating in the minutes that these issues remain unaddressed, but they won't block on them, or No. If there are sufficient No votes (or insufficient Yes votes), then the fact that the issue(s) remain unresolved gets conveyed with the rejection. The WG can either try again or abandon the documents. >> >> Unlike the IETF model where the IESG as a whole has little initial input into the documents, that can't be the case here if we expect to have a functioning RFC system. The AB members MUST be involved in the WG activities. Because of that difference, the IESG discuss model really does not fit the RFC model. >> >> >> >>> >>> >>> Wordsmithing is welcome. >>> >>> >>> >>> A >>> >>> >>> >>> From: Rfced-future On Behalf Of StJohns, Michael >>> Sent: 16 February 2021 16:44 >>> To: Wes Hardaker >>> Cc: rfced-future@iab.org; Russ Housley >>> Subject: Re: [Rfced-future] Non-approval resolution >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Feb 16, 2021 at 09:19 Wes Hardaker wrote: >>> >>> Michael StJohns writes: >>> >>>> If a document makes it to the approval body without resolving the >>>> approval body comment(s), I'd suggest that discussion has already >>>> completed and that the person voting "no" is acknowledging that >>>> process. >>> So, in your view "no" is really a "never". IE, it's too late to discuss >>> further because the discussion has already concluded and there is never >>> anything beyond this voting point? IE, this is the last step in the >>> decision making process? >>> -- >>> Wes Hardaker >>> USC/ISI >>> >>> >>> >>> No. What I said in the other thread was: >>> >>> >>> >>> • Do people agree that any objections must be returned to the WG for discussion? >>> I don't know what that actually does. Rejected documents (not originating in the approval body) that don't get approved are in the state that all non approved documents end up in and the WG or authors can take whatever actions they want including revising and resubmitting. I'd say instead that rejections from the approval body need a cover letter of some sort similar to how feedback works in the other streams and leave it at that. >>> >>> Rather than have the approval body process devolve into an adjunct of the WG process, I’d like there to be a clean separation between the two. This also makes clear the two roles for the members of the approval body in both participating in the crafting of the document sin the WG and the decision process in the approval body. >>> >>> >>> >>> Later, mike >>> >>> >>> >>> >>> >>> >>> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Feb 16 11:18:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1FC3A0FED for ; Tue, 16 Feb 2021 11:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 4_Ky_opa9fiu for ; Tue, 16 Feb 2021 11:18:46 -0800 (PST) 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 DDE993A0F01 for ; Tue, 16 Feb 2021 11:18:45 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id t18so5169947qvn.8 for ; Tue, 16 Feb 2021 11:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=oTVwoekU2QMlVpsIqohg6Ax80lYcM8qmQcWdY2FwH0I=; b=vXYVW2snkVlwrHPV/7xqpNM2jqCPxdfqAYmheqGOSd30d/esFjprw3naWZjZ65nqwj MIRTeImbrap/TU5xctO/DfTmmauP+wrmqBBq/s1AVll9esaIPJjdXVBU4pyqt3qn/+/3 sPYts0uQ0VNthzexk8Ln0dbFpcnCv+i65Vq9YSimb23uzjuer/sWjH1qTkBUDqN8OLe9 Nr7xUHrkQAY2bIVFUlAyInckJFBFCrDa6tUWrb9bJFOLmWTgEr7NCHmJNPHQ9h0B5Z3K fTUuC9V/SxVI225yWTDUqtYo2+VyWu3kNOcetBkw7mN6udsB2xVR24jUiFavbdHZJmtV JCQA== 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=oTVwoekU2QMlVpsIqohg6Ax80lYcM8qmQcWdY2FwH0I=; b=C6RzPRXBPXxH4QSd8OdGcGvz5XG1HKjabzhY9U+LTQa6j7igtCpyJIADuyi80H4FuP aIa9ydHzHEzWxhu37f2c5AKSg8SmFBtPUk1gP4zVsR5ciOzd6Bu6x+jryMJ7xCSGvADh osx5wlZmZZ00myqEai1HFqY3ieVubd3Evz6SQwhfl4Qk4gHRKlWzmcJuYX/H7MdMdO+Y 5z0J5ni8Q+sCgGx8VaquMXBWPBRmfXvDRcQMRUMqWroOMnx3WgxakQ2d92pkiN6P50Jn qkLlUdtUAcGkV6iICgizx5/SmcL0iKWUd1IT+5DWa9ZdqZcCSuXVK7VmKrajdg5G5cWR IKWg== X-Gm-Message-State: AOAM53045jtu++lBd+qneSIbYLCh5f6556GbtXEJq50dpWpio0zb3ifM xSKuT2o7BNEN0NKSHECwSED8mg== X-Google-Smtp-Source: ABdhPJzdN4heXk/oEyQeIfYDCV2GO8jxtM80UAgLpXAWN4lEnU3WNTOM+S+GzKweLBqwtibi3dYVdg== X-Received: by 2002:a0c:cd0c:: with SMTP id b12mr16991497qvm.10.1613503124579; Tue, 16 Feb 2021 11:18:44 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id s129sm15285876qkh.37.2021.02.16.11.18.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Feb 2021 11:18:44 -0800 (PST) To: adrian@olddog.co.uk, 'Wes Hardaker' Cc: rfced-future@iab.org, 'Russ Housley' References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> <031b01d70496$7f264920$7d72db60$@olddog.co.uk> From: Michael StJohns Message-ID: Date: Tue, 16 Feb 2021 14:18:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <031b01d70496$7f264920$7d72db60$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------34C3E96F18C2F2555104D658" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 19:18:50 -0000 This is a multi-part message in MIME format. --------------34C3E96F18C2F2555104D658 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/16/2021 2:04 PM, Adrian Farrel wrote: > > OK, thanks Mike. > > I’m not going to debate, but I just wanted to say what was underlying > my thinking. > Not really a debate - but just trying to capture the AB member's dual roles as both approvers and being involved in the formation of the documents.  I'm not against discussion - just trying to make the point that the "DISCUSS" vote in the IESG means something like "I haven't seen this before and something looks wonky, can you explain this to my satisfaction?" and that there should never be a case where a document reaches the approval process where an AB member "hasn't seen this before". I.e., before the document reaches the approval phase in the AB, it's gone through a) consensus discussions and revisions, and b) WG last call.  AB issues with the document should be resolved before the document is sent to the AB (in other words, in the WG or during WG last call) and the AB sends out (if it should?) a c) community last call. Mike > It seemed to me that everything you say about getting discussion done > in the WG and early seems good. However, I didn’t want to just draw a > line at that point when the strength of view of the approval group > member might not have been clear, and the discussions in the WG should > (possibly) not be predicated on a persons opinion being so powerful. > > The whole point, I hope, is that everything can be a discussion with > it being understood that each approval group member has a position > that they are bound to defend. > > Anyway, onwards to other people’s voices. > > Adrian > > *From:*Michael StJohns > *Sent:* 16 February 2021 18:43 > *To:* adrian@olddog.co.uk; 'Wes Hardaker' > *Cc:* rfced-future@iab.org; 'Russ Housley' > *Subject:* Re: [Rfced-future] Non-approval resolution > > On 2/16/2021 11:55 AM, Adrian Farrel wrote: > > Mike, I tried to capture something along these lines in my 2^nd cut. > > That is: > > 1. Approval body people should participate in the WG and WGLC > 2. The reasons for a Discuss must be clearly stated and > communicated to the WG > 3. A discusser must attempt to resolve the issue in discussion > with the WG > > I think the above is reasonable as far as it goes - but I'd really > suggest there is no "Discuss" vote - just a "No" vote.   An approval > body member who has issues should have tried to address them in the > WG.  When the document is submitted to the AB, if such issues remain, > the AB member can either vote Yes maybe indicating in the minutes that > these issues remain unaddressed, but they won't block on them, or No.  > If there are sufficient No votes (or  insufficient Yes votes), then > the fact that the issue(s) remain unresolved gets conveyed with the > rejection.  The WG can either try again or abandon the documents. > > Unlike the IETF model where the IESG as a whole has little initial > input into the documents, that can't be the case here if we expect to > have a functioning RFC system. The AB members MUST be involved in the > WG activities.  Because of that difference, the IESG discuss model > really does not fit the RFC model. > > Wordsmithing is welcome. > > A > > *From:*Rfced-future > *On Behalf Of *StJohns, Michael > *Sent:* 16 February 2021 16:44 > *To:* Wes Hardaker > > *Cc:* rfced-future@iab.org ; Russ > Housley > *Subject:* Re: [Rfced-future] Non-approval resolution > > On Tue, Feb 16, 2021 at 09:19 Wes Hardaker > wrote: > > Michael StJohns > writes: > > > If a document makes it to the approval body without > resolving the > > approval body comment(s), I'd suggest that discussion has > already > > completed and that the person voting "no" is acknowledging that > > process. > > So, in your view "no" is really a "never".  IE, it's too late > to discuss > further because the discussion has already concluded and there > is never > anything beyond this voting point?  IE, this is the last step > in the > decision making process? > -- > Wes Hardaker > USC/ISI > > No.  What I said in the other thread was: > > 1. Do people agree that any objections must be returned to > the WG for discussion? > > I don't know what that actually does.   Rejected documents (not > originating in the approval body) that don't get approved are in > the state that all non approved documents end up in and the WG or > authors can take whatever actions they want including revising and > resubmitting.  I'd say instead that rejections from the approval > body need a cover letter of some sort similar to how feedback > works in the other streams and leave it at that. > > Rather than have the approval body process devolve into an adjunct > of the WG process, I’d like there to be a clean separation between > the two.  This also makes clear the two roles for the members of > the approval body in both participating in the crafting of the > document sin the WG and the decision process in the approval body. > > Later, mike > --------------34C3E96F18C2F2555104D658 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/16/2021 2:04 PM, Adrian Farrel wrote:

OK, thanks Mike.

 

I’m not going to debate, but I just wanted to say what was underlying my thinking.

Not really a debate - but just trying to capture the AB member's dual roles as both approvers and being involved in the formation of the documents.  I'm not against discussion - just trying to make the point that the "DISCUSS" vote in the IESG means something like "I haven't seen this before and something looks wonky, can you explain this to my satisfaction?" and that there should never be a case where a document reaches the approval process where an AB member "hasn't seen this before". 

I.e., before the document reaches the approval phase in the AB, it's gone through a) consensus discussions and revisions, and b) WG last call.  AB issues with the document should be resolved before the document is sent to the AB (in other words, in the WG or during WG last call) and the AB sends out (if it should?) a c) community last call.

Mike


It seemed to me that everything you say about getting discussion done in the WG and early seems good. However, I didn’t want to just draw a line at that point when the strength of view of the approval group member might not have been clear, and the discussions in the WG should (possibly) not be predicated on a persons opinion being so powerful.

The whole point, I hope, is that everything can be a discussion with it being understood that each approval group member has a position that they are bound to defend.

 

Anyway, onwards to other people’s voices.

 

Adrian

 

From: Michael StJohns <msj@nthpermutation.com>
Sent: 16 February 2021 18:43
To: adrian@olddog.co.uk; 'Wes Hardaker' <wjhns1@hardakers.net>
Cc: rfced-future@iab.org; 'Russ Housley' <housley@vigilsec.com>
Subject: Re: [Rfced-future] Non-approval resolution

 

On 2/16/2021 11:55 AM, Adrian Farrel wrote:

Mike, I tried to capture something along these lines in my 2nd cut.

 

That is:

  1. Approval body people should participate in the WG and WGLC
  2. The reasons for a Discuss must be clearly stated and communicated to the WG
  3. A discusser must attempt to resolve the issue in discussion with the WG

 

I think the above is reasonable as far as it goes - but I'd really suggest there is no "Discuss" vote - just a "No" vote.   An approval body member who has issues should have tried to address them in the WG.  When the document is submitted to the AB, if such issues remain, the AB member can either vote Yes maybe indicating in the minutes that these issues remain unaddressed, but they won't block on them, or No.  If there are sufficient No votes (or  insufficient Yes votes), then the fact that the issue(s) remain unresolved gets conveyed with the rejection.  The WG can either try again or abandon the documents.

Unlike the IETF model where the IESG as a whole has little initial input into the documents, that can't be the case here if we expect to have a functioning RFC system. The AB members MUST be involved in the WG activities.  Because of that difference, the IESG discuss model really does not fit the RFC model.

 

 

Wordsmithing is welcome.

 

A

 

From: Rfced-future <rfced-future-bounces@iab.org> On Behalf Of StJohns, Michael
Sent: 16 February 2021 16:44
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: rfced-future@iab.org; Russ Housley <housley@vigilsec.com>
Subject: Re: [Rfced-future] Non-approval resolution

 

 

 

On Tue, Feb 16, 2021 at 09:19 Wes Hardaker <wjhns1@hardakers.net> wrote:

Michael StJohns <msj@nthpermutation.com> writes:

> If a document makes it to the approval body without resolving the
> approval body comment(s), I'd suggest that discussion has already
> completed and that the person voting "no" is acknowledging that
> process.

So, in your view "no" is really a "never".  IE, it's too late to discuss
further because the discussion has already concluded and there is never
anything beyond this voting point?  IE, this is the last step in the
decision making process?
--
Wes Hardaker
USC/ISI

 

No.  What I said in the other thread was:  

 

  1. Do people agree that any objections must be returned to the WG for discussion?

I don't know what that actually does.   Rejected documents (not originating in the approval body) that don't get approved are in the state that all non approved documents end up in and the WG or authors can take whatever actions they want including revising and resubmitting.  I'd say instead that rejections from the approval body need a cover letter of some sort similar to how feedback works in the other streams and leave it at that.

Rather than have the approval body process devolve into an adjunct of the WG process, I’d like there to be a clean separation between the two.  This also makes clear the two roles for the members of the approval body in both participating in the crafting of the document sin the WG and the decision process in the approval body.

 

Later, mike

 

 

 

 


--------------34C3E96F18C2F2555104D658-- From nobody Tue Feb 16 13:54:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387423A1181 for ; Tue, 16 Feb 2021 13:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMG_KAJ-UpNC for ; Tue, 16 Feb 2021 13:54:08 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FCB3A118C for ; Tue, 16 Feb 2021 13:54:07 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id gx20so209865pjb.1 for ; Tue, 16 Feb 2021 13:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RQIudMq5+bNPdLLlOLe1ylb4bj8AF5w06wVvBJd9cHE=; b=aMDWmEWN4L61OYUVa7tqKSUDSEfipJGX6DTsRXKmKyfv3EiZjpiV51gdJk98ly41m5 BXMzxuyTBow0I9Ws5cmm+iEqPXtKJYRRbEQJO633kCuG8h0lukxf6ZECaUiSrKJQaiec BWzQlKNCTx+LhzbsvGiH1FyNQ3YjxuM9efV6x3bpvKlQzVAFqqvcWmZsbq20nffz8p4s fMl6vPL7xyel4GEo2ULUvoqe6POiFtwW5gbjaenOiztssdJkuJC0luC4cuaAjHsqQnRS vyQY6xtDzWCNUAcnyTdsKiIqw823wovmwzVE/wrduI6wzmaRJNHhTCeodXGZxRc5KExW Di4w== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=RQIudMq5+bNPdLLlOLe1ylb4bj8AF5w06wVvBJd9cHE=; b=aFI9Z5KP4eOQDKXfg4ZgISgpDYWzlavCKHAR5fqq1TzyHD8sCzhjr3BMkGZdKiQRY+ ueVyT2MoaBBtZ2cu7k0w/ivxwjBA5aLp9lxy5gbGn+R2pdvtSSpPprBLp/ajIT6NHWwd jKT2qcHrQB5iYPqG+2nELbeiLvDKwy52l1Xj9iKUXgpWPeshVI/Xje/0cmKY/xE73yjq ANoDpuolcCo3CE569ZOC5f3mgOfQ2FiLT5ReXXDntNA7iclvt8bQI8UfTwPDZAUdxiPT caHOx1D00cIovBJBdsfE2kxrAc6jp/HgobbW2duvc9kjyWcPYyyFmFxURGVpEQFjsFRQ ziWw== X-Gm-Message-State: AOAM532LDakAn9aycuJVsCojWvZ7w06XBaWv6vHcH8HBOgjdgmJwiA9K BqWcltZvw8BpR18KI6dEjiJSeSziMmK3dA== X-Google-Smtp-Source: ABdhPJwhwfHJIAFyxBpImYG2G6cQ1F4AKIoOYR4qlgrv7agklD/of6lFHP/ZqLcRsBhtBx2+chzPsA== X-Received: by 2002:a17:903:3109:b029:e2:86d3:bec with SMTP id w9-20020a1709033109b02900e286d30becmr21836763plc.49.1613512447040; Tue, 16 Feb 2021 13:54:07 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id v1sm3556622pjh.29.2021.02.16.13.54.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Feb 2021 13:54:06 -0800 (PST) To: Michael StJohns , Scott Bradner Cc: rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <32548527-c428-8a04-6fed-b7e6adee3e60@gmail.com> Date: Wed, 17 Feb 2021 10:54:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 21:54:09 -0000 On 17-Feb-21 08:10, Michael StJohns wrote: > On 2/16/2021 1:52 PM, Scott Bradner wrote: >> what about non WG documents? (e.g., individual submissions) >> >> Scott >=20 > Good catch.=C2=A0 The AB needs to have some sort of buy in for individu= al=20 > submissions which suggests that at least the general scope of the IS=20 > needs to be discussed with the AB near the beginning of the document=20 > process.=C2=A0=C2=A0=C2=A0 I think the approval process remains the sam= e, but there=20 > needs to be a flavor of an adoption process - e.g. some AB member has t= o=20 > sponsor the document prior to it being submitted for approval and that = > AB member would be responsible for working with the author(s) to deal=20 > with probable AB pushbacks. It's a good catch, but I'm inclined to a different answer: just say no. I'm not seeing why we need a bypass in this case. We need the bypass in the IETF for topics that simply don't need the overhead of a WG; in this case we already *have* a WG. If somebody believes, for example, that all RFCs should be translated into Elbonian, I think it is necessary and sufficient to tell them to take it to the working group. Brian From nobody Tue Feb 16 14:02:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B403A1198 for ; Tue, 16 Feb 2021 14:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8RcE--79Xwk for ; Tue, 16 Feb 2021 14:02:06 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68ADC3A1193 for ; Tue, 16 Feb 2021 14:02:06 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id v10so8196065qtq.7 for ; Tue, 16 Feb 2021 14:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=xbxjEXYYBFoybZKPuCCHfE0DsNLGJPVLO6/N6YO/O84=; b=gTMNgnVOOKzTELpi6DFUsfoBtjTN9JsXi7wsUze0ozwCnnBVX8mrLoJ8vQRgo/YpLL W960PEU0n6dTAwoDEfga2yuvl+RUxCFQr74jMGhAWH1DJZcqXW0Soj7jrbOzSO4eM20E UxpNneukwc5qoEwr6JLI8+Z3Ulo8hF3ciwFD4l7/XrodNI9uK5fAM/0uSW6IrJRCgOZq SMlCKdfc1PwKb+4/S5HfR5XyGDyGfR3YYXS8W0MhlreOMQUMU1ER0mjWWOqk9w+NfoZf jPZesgh/5uaohlk5taJrhk1o3pQ+RbE4IPVWkpXdcDR3lyjcPATRdd6xWepDSpvd43O2 LxmQ== 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=xbxjEXYYBFoybZKPuCCHfE0DsNLGJPVLO6/N6YO/O84=; b=dhfUKj1tCzTsqAbr3koTWhEfh5Zr/d4qA5n//K5Iq43kilIp6gXqZuWh1ZNf8KDRk9 A54SsczBZipCTojGC4IO9YopiCtqbYXd8skIHElZD5YYy9Uv4hN1OMTQYwzzvU/uHCWR FHSrDc60ZohEP9Q+q8cnVTGvmAkffcr0bspjzjtd/ZzcdeqNvLzBHzX2RIw/DPaT09MS LL7AVhdWzqUVFX41xsz4o39I9ZUfYJkTnTdtGqE8lO8+WlS7ckGY4TcXsmKwKGOmoeeo QVjE9dMYUjsp1/GMnqgZ5uZAAD4+MpzGGyuicHaFpLcSc4DjYw4eHLnhoQamwYTvGdw0 6R0Q== X-Gm-Message-State: AOAM531jn2Oqur9emelE3SzYeO/OA71iHT2JDmS6HlsQY2C2hDGVBc/w OPG1fchgFEd8p8WvBTDNMXNqqU2q9kTc3uoF X-Google-Smtp-Source: ABdhPJzthXmpmqqJ2ZUMLsJACr7HcCgmTiGbprPV8d5ojJeFmE3IOOJMzsKRxWOTi+HSldERZwNLZg== X-Received: by 2002:aed:20a8:: with SMTP id 37mr21399868qtb.362.1613512924881; Tue, 16 Feb 2021 14:02:04 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id t71sm191823qka.86.2021.02.16.14.02.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Feb 2021 14:02:04 -0800 (PST) To: Brian E Carpenter , Scott Bradner Cc: rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> <32548527-c428-8a04-6fed-b7e6adee3e60@gmail.com> From: Michael StJohns Message-ID: <723efbc1-ad5a-afc4-cd92-233627ba8e43@nthpermutation.com> Date: Tue, 16 Feb 2021 17:02:01 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <32548527-c428-8a04-6fed-b7e6adee3e60@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] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 22:02:08 -0000 On 2/16/2021 4:54 PM, Brian E Carpenter wrote: > On 17-Feb-21 08:10, Michael StJohns wrote: >> On 2/16/2021 1:52 PM, Scott Bradner wrote: >>> what about non WG documents? (e.g., individual submissions) >>> >>> Scott >> Good catch.  The AB needs to have some sort of buy in for individual >> submissions which suggests that at least the general scope of the IS >> needs to be discussed with the AB near the beginning of the document >> process.    I think the approval process remains the same, but there >> needs to be a flavor of an adoption process - e.g. some AB member has to >> sponsor the document prior to it being submitted for approval and that >> AB member would be responsible for working with the author(s) to deal >> with probable AB pushbacks. > It's a good catch, but I'm inclined to a different answer: just say no. > I'm not seeing why we need a bypass in this case. We need the bypass > in the IETF for topics that simply don't need the overhead of a WG; in > this case we already *have* a WG. > > If somebody believes, for example, that all RFCs should be translated > into Elbonian, I think it is necessary and sufficient to tell them to > take it to the working group. > > Brian > Probably not.  I actually think there will be a few of these - maybe originated by the RPC or by a hired XML expert for example. I may be wrong, but the WG is probably the wrong path for some documents. If someone proposed Elbonian, I'd suggest that the AB probably wouldn't approve it if they were anywhere near sane regardless of whether this was an IC or a WG sponsored document. Later, Mike From nobody Tue Feb 16 14:02:30 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAE13A1199 for ; Tue, 16 Feb 2021 14:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.1 X-Spam-Level: X-Spam-Status: No, score=-7.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, 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 22qbnj-xyxu7 for ; Tue, 16 Feb 2021 14:02:26 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B075F3A1198 for ; Tue, 16 Feb 2021 14:02:26 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id m2so7155332pgq.5 for ; Tue, 16 Feb 2021 14:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Vuixj1tIT9RugTO7zv2nXAb8Wv+O/lYwzqJbBARPJKA=; b=KXJWxZMtvuKSQ8yw3eFQOZX7voqKg+Zdqw3G3VJwsP07Uq02URslb6jwcsHYlmjUy3 zxJPxfktiMkhstevkKCXWfe+jjJwd56wRGt/JPMPyHu26+vS/VXZ5gfvtbeGN4pDw8Nb u0sSEVnXOc/ygrzIo1WuvPE1WKzBsV6U2d0eaICLR0e0yxyB6LlbGE7Uh15WYVZwkQPF wXGBM5rIGOMQ+WKjXu5fFdKJXHgUiGoa95hFpu9uY4AM3VPt6vECgHBdUB6XkRTx908j SvffOeYPz8qSwyplpO/9v1IEn/JzvsWbwN+dtteU8cdFkVqOb3Z604vpi+1SieASraMN 6WJA== 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=Vuixj1tIT9RugTO7zv2nXAb8Wv+O/lYwzqJbBARPJKA=; b=jgD+ZxEa9I+akHKvUTHguuZ4WSxQJY5iUA4dGzxMmxDWXn5q/r9RPVG7S4OhismZ7d dJcp0Pbg/lkfmVBv5W5NJ0uzYUlEsu3xFIBSNktBAupZ2qeAvbPWbpZa/z55W39Ogkmm T2SY58xdd0k6kKBIVPS/oLplrCNIVsiB8rHHNcJP96dNwkSe+s6pz3Q8fVA/LTyruZTo FYYLA6F0RMVu7N/evy530IsdNhkoKnpAse0SGG30n8D9OOO/llXRafFTtoqjmO+C36by TpFqKsbmuK5dwSeNo8FL3KdG9vURIdPfJd4LOK+E0RCiojCLGKG0gLVgjniFqFcC3aYT 2xcw== X-Gm-Message-State: AOAM533Rx/VmACbB4ndCUun+UP8/qZMN8Uxpv8Af8F9gSyzp+XEjLsQn gjuyywR5Vvr67dgmWlhA/5mHiiXu1k5cXA== X-Google-Smtp-Source: ABdhPJy7f3TVud+S+hVIQH1Dos6+MUkT5JjPSynJQQUs/jdFFjotSLECZJUf1lrKw9Gjl2Qbe+0NwA== X-Received: by 2002:a63:d20a:: with SMTP id a10mr19524659pgg.451.1613512944796; Tue, 16 Feb 2021 14:02:24 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id t77sm23345050pfc.119.2021.02.16.14.02.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Feb 2021 14:02:24 -0800 (PST) To: adrian@olddog.co.uk, rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> From: Brian E Carpenter Message-ID: <0a39cebb-75e1-c0a1-9d30-2d4956ba929a@gmail.com> Date: Wed, 17 Feb 2021 11:02:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 22:02:29 -0000 I'm going to say simply yes, good enough to go forward. Especially, yes to "Discuss" rather than either "Block" or "No". Discussion is the goal. One one point: > C. Community last call / public comment > It is unclear whether this step (corresponding to IETF last call) exists and > how it would be operated. Further discussion needed per Martin and Russ. I'd say we're asking for trouble if we don't have a public comment period. That could be done via a web form to limit trolling etc. And the RSA/E (or somebody else) needs to be responsible for outreach. Regards Brian C On 17-Feb-21 04:43, Adrian Farrel wrote: > Hi, > > As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H persuaded me > to take a second pass trying to factor in some of the comments on the list. > > I can't promise that I have captured *exactly* what everyone said, > especially as some of the opinions were conflicting. What I have done is try > to move the text towards something that might be a compromise between the > positions. FWIW, I went back to the "Discuss" position because it carries > some implication that we are all going to try to get together and resolve > this. > > I also tried to cut some of the waffle. I do tend to waffle. > > There are two open points. I'd humbly suggest that the people who raised > these issues might try to throw some text at a solution. > > 1. At point C there is the concept of a "community last call". This was > raised by Martin and Russ, and I suggest that they put forward a proposal. > The challenge might be to find a way to identify and reach the "community" > (it's easy in the IETF, but very hard for "the world"). > > 2. At point J there is the concept of "an appeal" in the case of Discusses > being unreconcilable. This was raised by Adam and Mark. The challenge, as > they noted, is working out to whom one appeals. > > Hope this is useful (which is, after all, the only point). > > Adrian > > ==== > > Decision-making procedures > > A. Development Cycle > The WG is expected to show its work to the approval group and attempt to be > aware of issues that the approval group might be concerned about. > The members of the approval group are expected to pay attention to the work > of the WG and speak up when they have concerns. > The intention is early discovery of issues and avoidance of late surprises. > > B. WG last call > The WG last calls its work following the model of an IETF WG. It is assumed > that all members of the approval group will participate the WG last call, in > an attempt to expose any of their concerns that still remain, and to reach > agreement. > > C. Community last call / public comment > It is unclear whether this step (corresponding to IETF last call) exists and > how it would be operated. Further discussion needed per Martin and Russ. > > D. Participation by members of the approval group > As noted in steps A and B, participation in WG work by members of the > approval group is expected. > It is understood that, from time to time, a member of the approval group may > find it impossible to participate in a particular discussion: in this case, > they are encourage to send delegates. > > E. Discussion by the approval group > The approval group shall discuss the output of the WG. > Such discussion is to take place normally within 2 weeks of the WG making a > request. > The 2 week period may be stretched by holidays or IETF meetings, but the WG > must be notified if this is the case. > All comments and concerns shall be documented to the WG which may take them > into consideration. > > F. Approval by the approval group > The voting members of the approval group shall formally ballot by the end of > the discussion period in E. > Each voting member may ballot one of: > - Yes: Means "I support this work." A Yes ballot may be accompanied by > comments indicating thoughts and issues that should be looked at, but are > non-blocking. > - Discuss: Means "I have a serious concern that I would like to Discuss > before this work can proceed." Voting members are expected to actively > engage in resolving their Discuss positions. > - No Position: Only used in exceptional cases such as illness or long > vacation. Voting members are expected to try to present a different ballot > position. > - Abstain: Means "I have a serious concern, but recognise that it will not > be resolved." An Abstain ballot is a way for a voting member to get out of > the way of progress even though it worries them. The existence of an Abstain > ballot does not imply the work is flawed, but indicates a genuinely > irreconcilable difference of opinion. > - Recuse: Means "It would be improper for me to have a position." For > example, if the proposal was to remunerate the voting member. > > G. Reasons for a Discuss > The approval group shall maintain a list of reasons for a Discuss ballot. A > Discuss that does not conform to one of these reasons shall not be valid, > and must be re-balloted. > An initial draft of this list is as follows: > - The proposal would cause significant harm to one of the streams > - The proposal would cause significant harm to the series > - The proposal would cause inconvenience to a group of consumers, the > benefit of the change does not outweigh the cost of the inconvenience, and > that inconvenience could be overcome by using a different approach > > G. Work proceeds if... > At the end of the discussion period (point E) or at any later time, there is > at least one "Yes" and no "Discuss" ballot. That is, work fails to proceed > unless it has approval. > > H. Resolution of Discusses > A voting member who ballots Discuss shall explain their concerns to the WG > and shall engage in discussions attempting to resolve the concerns and > arrive at a compromise or other agreement. > When such agreement is reached, the voting member should transition their > ballot to a "Yes". > A voting member may transition their ballot to an "Abstain" at any time, > although all parties are encouraged to attempt to reach agreement. > > I. Single Discuss resolution > In the event of there being exactly one Discuss ballot, and there being no > timely progress to agreement between the WG and the member of the approval > group who issued the ballot, the WG may request that the approval group > exercise an exception resolution process as follows: > - The approval group will discuss the concern giving rise to the ballot and > any proposed resolution from the WG > - The approval group shall attempt to reach consensus on whether to sustain > the Discuss or to release the work, but failing that shall vote with a > simple majority determining the outcome > - If the Discuss is sustained, return to step H > - If the work is released, the Discuss ballot shall be changed to an Abstain > and the work shall progress > > J. Appeals > In the event that more than one Discuss cannot be resolved or that a single > Discuss is sustained by the approval group, there is a right of appeal. > The details of this need to be worked out per Adam and Mark. > > > From nobody Tue Feb 16 14:55:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9A93A1244 for ; Tue, 16 Feb 2021 14:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-egeJoBKwWo for ; Tue, 16 Feb 2021 14:54:56 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCBB3A1241 for ; Tue, 16 Feb 2021 14:54:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CCF63300B8B for ; Tue, 16 Feb 2021 17:54:53 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IX88r5LA50xI for ; Tue, 16 Feb 2021 17:54:52 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 99979300AE8; Tue, 16 Feb 2021 17:54:52 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <723efbc1-ad5a-afc4-cd92-233627ba8e43@nthpermutation.com> Date: Tue, 16 Feb 2021 17:54:54 -0500 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <0F412141-5EC9-420B-8DA5-4E3D92A13A22@vigilsec.com> References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> <32548527-c428-8a04-6fed-b7e6adee3e60@gmail.com> <723efbc1-ad5a-afc4-cd92-233627ba8e43@nthpermutation.com> To: Mike StJohns X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 22:55:11 -0000 > On Feb 16, 2021, at 5:02 PM, Michael StJohns = wrote: >=20 > On 2/16/2021 4:54 PM, Brian E Carpenter wrote: >> On 17-Feb-21 08:10, Michael StJohns wrote: >>> On 2/16/2021 1:52 PM, Scott Bradner wrote: >>>> what about non WG documents? (e.g., individual submissions) >>>>=20 >>>> Scott >>> Good catch. The AB needs to have some sort of buy in for individual >>> submissions which suggests that at least the general scope of the IS >>> needs to be discussed with the AB near the beginning of the document >>> process. I think the approval process remains the same, but there >>> needs to be a flavor of an adoption process - e.g. some AB member = has to >>> sponsor the document prior to it being submitted for approval and = that >>> AB member would be responsible for working with the author(s) to = deal >>> with probable AB pushbacks. >> It's a good catch, but I'm inclined to a different answer: just say = no. >> I'm not seeing why we need a bypass in this case. We need the bypass >> in the IETF for topics that simply don't need the overhead of a WG; = in >> this case we already *have* a WG. >>=20 >> If somebody believes, for example, that all RFCs should be translated >> into Elbonian, I think it is necessary and sufficient to tell them to >> take it to the working group. >>=20 >> Brian >>=20 > Probably not. I actually think there will be a few of these - maybe = originated by the RPC or by a hired XML expert for example. I may be = wrong, but the WG is probably the wrong path for some documents. Just because that is the source of the document, I see no reason that = the WG cannot adopt and review them before they get approved. Russ From nobody Tue Feb 16 14:58:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD193A1254 for ; Tue, 16 Feb 2021 14:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn0zEkmh7fpd for ; Tue, 16 Feb 2021 14:58:12 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F3B3A1251 for ; Tue, 16 Feb 2021 14:58:11 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id m22so18543381lfg.5 for ; Tue, 16 Feb 2021 14:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U7chtlnq4H/8kaPc9O4iRS+zjZ7Xh9b4Z+bok4W953I=; b=miL9xXppa1rsIRr4Di7CPPOZqXihL5P/qWiEthz7+5nvqXfSD1sEQjGH0lP/r4qT8v 6HiYv2+HRfJI8Erf4k17064RbBl3hS5rcF4eHKEiKGf8RVUV9d+Ezyjl6GCAfLC9Q7+d ywOArGI/oUTnElrTqnqGwwDUzD1cHhf2KPxtl7QQ1EC3zzmwhwROEFzI44MxU6gpl2wU oslUNGWjhIpWXmUu49/D5QD2iTvnqR6uiN0EqFcBMdhXRsJJeJoanB4+iSnvRGJyEM9z Fpn7A4ue6kHSrT/OX1NqNuesUjd3rneehmywvUfRQ4Mlst6FiCqAfJ93ZrYHLhLS46aP VJ3A== 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=U7chtlnq4H/8kaPc9O4iRS+zjZ7Xh9b4Z+bok4W953I=; b=LWDMyB/HdCFUWG1UIeaZMeWXPY0ziBJZrp5QaCD6Rr8pgVxw2XJQWwmL080CwkT0De 62dxfjXzgsxmBwa+wBPtUal6K7adY2ub4pWmsmgzinLw/PuJmt+ABJot2Zl3jstSV9jx JmIWDbe1dtL8VUDBa4rwoDt2iSyVtHu5EL+wicNmT+uwVZ16qXzmU7MkIJX+ZtvHCs0u b3kfUEhmq3fAeYoDLuV2EDgpI3jAXe7izyryAfPYVNkn0RdS3FALTxMeRuf31hd1saPy 7vfhyBoyjMpjRSuxWvv93vm+ZjHbyGqG4hqZ0T43CAOr8EFdYUsvB+V70kutcRnjD+om NbWA== X-Gm-Message-State: AOAM5335vi8IW7Gk13k6SUmVBZeeaWdsP8x4i/VpozmOaNc3/UX8MmCY S+5f0W6x74OSRBbwTg8D6dXQ5iHGA5SGuBXMu4pVRA== X-Google-Smtp-Source: ABdhPJyJLglT+mEdd1M7WbNGJFzd6qHyC7fnBFbzI//SSmLaQtpMkdY9G4/yCSCfsIe8mWFpBp9FKVQMOPCm4q/p7ug= X-Received: by 2002:a05:6512:11e8:: with SMTP id p8mr13189240lfs.579.1613516289857; Tue, 16 Feb 2021 14:58:09 -0800 (PST) MIME-Version: 1.0 References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> <32548527-c428-8a04-6fed-b7e6adee3e60@gmail.com> In-Reply-To: <32548527-c428-8a04-6fed-b7e6adee3e60@gmail.com> From: Eric Rescorla Date: Tue, 16 Feb 2021 14:57:33 -0800 Message-ID: To: Brian E Carpenter Cc: Michael StJohns , Scott Bradner , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000004beba605bb7c09a6" Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 22:58:14 -0000 --0000000000004beba605bb7c09a6 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 16, 2021 at 1:54 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 17-Feb-21 08:10, Michael StJohns wrote: > > On 2/16/2021 1:52 PM, Scott Bradner wrote: > >> what about non WG documents? (e.g., individual submissions) > >> > >> Scott > > > > Good catch. The AB needs to have some sort of buy in for individual > > submissions which suggests that at least the general scope of the IS > > needs to be discussed with the AB near the beginning of the document > > process. I think the approval process remains the same, but there > > needs to be a flavor of an adoption process - e.g. some AB member has to > > sponsor the document prior to it being submitted for approval and that > > AB member would be responsible for working with the author(s) to deal > > with probable AB pushbacks. > > It's a good catch, but I'm inclined to a different answer: just say no. > I'm not seeing why we need a bypass in this case. We need the bypass > in the IETF for topics that simply don't need the overhead of a WG; in > this case we already *have* a WG. > > If somebody believes, for example, that all RFCs should be translated > into Elbonian, I think it is necessary and sufficient to tell them to > take it to the working group. > I agree. In my experience individual submissions often don't get the level of scrutiny one might like, and given that we have a standing WG, if you can't persuade that WG, that's a pretty good sign that the idea shouldn't proceed. -Ekr > Brian > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000004beba605bb7c09a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 16, 2021 at 1:54 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
On 17-Feb-21 08:10, Michael StJohns wrote:
> On 2/16/2021 1:52 PM, Scott Bradner wrote:
>> what about non WG documents?=C2=A0 (e.g., individual submissions)<= br> >>
>> Scott
>
> Good catch.=C2=A0 The AB needs to have some sort of buy in for individ= ual
> submissions which suggests that at least the general scope of the IS <= br> > needs to be discussed with the AB near the beginning of the document <= br> > process.=C2=A0=C2=A0=C2=A0 I think the approval process remains the sa= me, but there
> needs to be a flavor of an adoption process - e.g. some AB member has = to
> sponsor the document prior to it being submitted for approval and that=
> AB member would be responsible for working with the author(s) to deal =
> with probable AB pushbacks.

It's a good catch, but I'm inclined to a different answer: just say= no.
I'm not seeing why we need a bypass in this case. We need the bypass in the IETF for topics that simply don't need the overhead of a WG; in<= br> this case we already *have* a WG.

If somebody believes, for example, that all RFCs should be translated
into Elbonian, I think it is necessary and sufficient to tell them to
take it to the working group.

I agree. = In my experience individual submissions often don't get the level of sc= rutiny one might like, and given that we have a standing WG, if you can'= ;t persuade that WG, that's a pretty good sign that the idea shouldn= 9;t proceed.

-Ekr


=C2=A0 =C2=A0 Brian

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000004beba605bb7c09a6-- From nobody Tue Feb 16 15:24:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3E93A12A9 for ; Tue, 16 Feb 2021 15:24:23 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byeFio0BzHGm for ; Tue, 16 Feb 2021 15:24:22 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400120.outbound.protection.outlook.com [40.107.140.120]) (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 D12F93A1289 for ; Tue, 16 Feb 2021 15:24:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XovjS3VhJHY/cTJf8Mr5Em6q44Lzy4F7tu8ZF46lLXt+YyZJBEu0ZeRUyBLg2NA9k758QFjGDtPYG71BSw2hHa5T540KHfUxWxfKQqZ47g7u87EfW6VLBweWhzFnGYb0e8p/D7ZR0iu/+rJrrRgox/vb9mR8QMY1Vdbrt67WQGF6wVdTOxD/Q+qUYt1DbM17ugoPNwOHj4ApN0YaHzo8g4zv6JXlha9s7hsCEDfHarVTCD+jxqJ8H+y/UCVNHRojZPzAtt099sVFBLx5DkUZmsPbhpctWUtat4B349M14eYxJ3/WD4BEyfhhYmMUC3xk3aFO8gFRUQQ/M7KzIiNcLw== 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=DFUMNLB5G8hPCxlpgQx9JI2P4YVFhd9aimKMYGYM/xk=; b=KL6k+E1d8e0wVh1SMiwWGpu1/Eto2lfwdzqzpni7O4xLp9q0iVDuAEJYeoESp+i2RCeN3qczjuaEBZDZbMo42jj2iL3eCdBID8CzJFYqZ6fMMcW+/oQyIwF096D3w81GqSS/RtlP9hjMS0gcJKyRGjZsmAU2Lr0Uqq3rtEXLtdw2q79x7dVN1LDW9HUNMzfHu92TY9w112tSjzL7Igp0aPaA83nz5RiH32ou3RkGzjUnL8rL1VauQLRjCmPsdDApgReYYIk9OLvFquX3YzmTLi9g/3MMZhWYsE9hOOPKVpAupDFaY7Cf4I4puKgMAml0wKj2Zs7temtgUFA+kvKvwA== 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=DFUMNLB5G8hPCxlpgQx9JI2P4YVFhd9aimKMYGYM/xk=; b=GMebf+DCFgronulzleet9Hz+MCiTnr7kC49swktbpTSb78eqQLNl8E1lRQnTue5OEkURYWwGPIlANj6Cxv8fA81+MmX0uoT4+xtjzRKsFOIE5Ls9EgUXDr7L8M4Wu3LaKBVDOHaHSb8xjjVA6I09nJl4cfQIOH/Bl5vgPw6gHVM= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB5948.jpnprd01.prod.outlook.com (2603:1096:404:8055::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.26; Tue, 16 Feb 2021 23:24:19 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f%7]) with mapi id 15.20.3868.027; Tue, 16 Feb 2021 23:24:19 +0000 To: Russ Housley , Mike StJohns Cc: rfced-future@iab.org References: <059b01d7005b$f25241e0$d6f6c5a0$@olddog.co.uk> <68bcb19e-1834-0bdd-3a0b-9ddff8e37761@nthpermutation.com> <02ce01d70484$8e917310$abb45930$@olddog.co.uk> <32548527-c428-8a04-6fed-b7e6adee3e60@gmail.com> <723efbc1-ad5a-afc4-cd92-233627ba8e43@nthpermutation.com> <0F412141-5EC9-420B-8DA5-4E3D92A13A22@vigilsec.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <96ad84d3-2fb8-d622-21a8-1314ca479c81@it.aoyama.ac.jp> Date: Wed, 17 Feb 2021 08:24:16 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <0F412141-5EC9-420B-8DA5-4E3D92A13A22@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [223.217.46.174] X-ClientProxiedBy: TY1PR01CA0195.jpnprd01.prod.outlook.com (2603:1096:403::25) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.7] (223.217.46.174) by TY1PR01CA0195.jpnprd01.prod.outlook.com (2603:1096:403::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Tue, 16 Feb 2021 23:24:19 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9824b779-3917-4a89-5c28-08d8d2d1fc1e X-MS-TrafficTypeDiagnostic: TYAPR01MB5948: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xd47foqQ87+mlQZ6jq4f1YJG7mK20wXDZ2hCiY8LzlH2poCefC63WI+ertEpSMDePQ69e+49WSbjtN6xFpkOFR3eP4UDAXa4lpcl55I8IBUvCBMoklRWXwNqdlwYySwvzEpgqhsceGPs4m6vCspeA5A3VzcQak8GT1jAMNFpHxldyyqhwcXmefRUdx/7ygWhNJ5Py6In8Qx913lDzXYqG6dNUa/HnnlL36aw/xb+oVejC4LYgCZOguET1deRgZe9/totn15IngH9iIOD0MNc7cGogwBTIfVsTxa7x+vGq2t2VFkyMODs7444+RhvkXSpx4owx9Lafs2dcBTMnjb+sG63O5/Zlp5u9qbmbNLlhB2wCI7JNYRqQFShlDi5bLQJy484lJRDVXfPIIiX1FFBjKfLFUNbxsaHkJair7efxYjLdrtD/4vOned9ZwuEwmDze0ntVj5meWkypROExuRThQXWPBIG2BWAnegsBX4a1MrBWU9OF/4pq5n0SZUTeSB+EgPfo9nWy+llwXUYVl8hofw6ebMfRjFp5P+8nmgzXWHmuECHFatJAwNFCq2uYeyI5m2OnJsj9xz7ctDGfAI0Lb2DE70aTC0O/WdZa+DEJjo= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(376002)(39840400004)(396003)(366004)(478600001)(2616005)(16526019)(4326008)(8676002)(186003)(6486002)(8936002)(316002)(31686004)(31696002)(110136005)(786003)(52116002)(5660300002)(2906002)(6666004)(956004)(66946007)(26005)(86362001)(66556008)(66476007)(53546011)(36916002)(16576012)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?R1N2clZKamhTMmZyc0p0bGZUbkFRZlFLbS90V3pCakJMN2dTMkd1UlNJamxX?= =?utf-8?B?UWZjL0tKR0xrY081UFFFNzFid1Rqa1NWajlTdEVyRUhGTThNa0U2YklkZUhX?= =?utf-8?B?VEZGNk9FQlZEcVNNNGFzRFRldFQzUUVONU4rZGZJMSsxNUtRd2REQXpENDBM?= =?utf-8?B?WDErV0cwZENrdWVnckJQTWVqNm1HU0hkMUtpV1E1amxYeEFLVFpZc1VtT1Jv?= =?utf-8?B?M1dPZ1k0UTZ2cmNHOUJNN0x2R21YRnErN2VQaXdMeDZ1NEdtdHRRNWtuM0ta?= =?utf-8?B?ZGpKYlZmaUFkdXkrMjE3TFRTbW9KRDZzSmdrTjBZUUVlSnZYS0N1VVB0RGV2?= =?utf-8?B?TzZ2SWRHMTBHdzRNSHBITmh2WGlFZ25kRFZvVlZtNVJSZEdBM1dHZk5waXRx?= =?utf-8?B?cnpIVDVtejFPN09NWkFIczJZS2RRS1kzSFlGSTFmOXNWT3lsMzhRVlVlS2V5?= =?utf-8?B?OUE2N3g2b3NoV2dDSlNBUXREY2Vrblk0K25samcwSXJhTDBRQWJsUFVqWXBr?= =?utf-8?B?SUNFV3ZEU0xhQjVCOHU5STY1VC9CTGZ3SmE1UUJMeEp0OTBEaDFGVDhja3pi?= =?utf-8?B?WjUyY2JoanV4eFR1SXY3RTFRMEN5OXVVSmVqR2FKVzE4elEvVWhRSGNra3ZP?= =?utf-8?B?d2JoM3lrTGdjYkhhd3AyWU5wdDJSbmREL3JBVVhrQy9IZEt2VFNBbFROM3dj?= =?utf-8?B?SFRIcDl5ZURzUTcrNnVwcXFhQXUxMkJ6RzFRZG42OERyZHJjaG05ejdLeGov?= =?utf-8?B?R1NVWnVyTmtGdmFSaFgwOXM4TE9SM0xJRTFQekRyNytLK1NDR3JXQnU1S2Iz?= =?utf-8?B?K0RSWEZPaGNJamROY1FLcGZJYytlNkwya0pPdU83ZUVlUmtlc3Y5NEZWNWVW?= =?utf-8?B?eDJ2aW9xZERqMTJydDJFNU05cExPQ2NHT2E4VzNpbCtUTUhoMW9vQ2h6ZW1N?= =?utf-8?B?TWJtcWJwR3lxOE9wenZ5MXdCT0RuYjU1UkFpZDV2VUZrbXNGZjhZaHdLMFVH?= =?utf-8?B?WmlUZWVBdldsMzE5cmdIU3FWY2F0V3o5bmdPdjFrSkRBQUtxRDNtWm9WMEhu?= =?utf-8?B?OVRTeFVyZjNFWWZNS25IbmEvTXlQZnE2N0tIdHA0Mkg5THkzZUU2Rm1IVW4z?= =?utf-8?B?RUY2b0VWbTFsT3JZa3dCcjM4MC96RW9vTEdmVWoyaXR1L3pIcjFkUk9MM3Jo?= =?utf-8?B?ZVkrKzRxbjZHVDVEZlBMaHN1ZURhMTB1S2FpaVpkZ3k4ZC9mbDhzbms5TDUz?= =?utf-8?B?UHFiSExHVEs2Y1VIaVJKZmFrZ3Z0eXVROU1qMlo3RmJ3VSszVzNmT2dPSkV3?= =?utf-8?B?OTJXY1hOZ3BtZGVZZjlkWVdTdmtmOWpmVjR4eG5sd1VXeStBemc4RExEYzZD?= =?utf-8?B?NHA4RG8rY2JwOUtjRDhTalowYkNEYUVqZEgwZmFDekpleTd6UFVYMVpqMjBn?= =?utf-8?B?TklvZVN4UWcyU1ZIMERhV0ZqNURyVm51SzV3US9FbUNjeHZOZnJPK0p4L0R1?= =?utf-8?B?UTNKYlVHSDNZWWl2WVc1NEdZY0tQdGJEQ1pGaStrTGFEeDlleVVVVFFwMy9W?= =?utf-8?B?bUJyR2RjYnNOZlZTbUFWMStjZ3JOVzN6UDAxL252NVJnY3NvazZKd2RTeC9W?= =?utf-8?B?NnVYTVJyVk1LSi9qN1BaL2VFRTRhTWVGRThMbkorODF2VklvSFBkZ01nTUpm?= =?utf-8?B?RS9lY0NKNXBYanJaQm05N3dkSjY2WW5nTFNnS1cxZDJKWGJmNlkrNVBMZ0Uy?= =?utf-8?Q?04epGeYlh1SNKPGI3p6+FiqPPzAktO8XWPag/kZ?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 9824b779-3917-4a89-5c28-08d8d2d1fc1e X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2021 23:24:19.4463 (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: WLRzqqZSLLIpEX6yRaF29NSijWOrGNYtFaLfCCw+s5UU35w5kr8uEumHF3Vr+msTFaXBKmtnwFHNmdw5lwP3fg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB5948 Archived-At: Subject: Re: [Rfced-future] Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 23:24:24 -0000 On 17/02/2021 07:54, Russ Housley wrote: > > >> On Feb 16, 2021, at 5:02 PM, Michael StJohns wrote: >> >> On 2/16/2021 4:54 PM, Brian E Carpenter wrote: >>> On 17-Feb-21 08:10, Michael StJohns wrote: >>>> On 2/16/2021 1:52 PM, Scott Bradner wrote: >>>>> what about non WG documents? (e.g., individual submissions) >>>>> >>>>> Scott >>>> Good catch. The AB needs to have some sort of buy in for individual >>>> submissions which suggests that at least the general scope of the IS >>>> needs to be discussed with the AB near the beginning of the document >>>> process. I think the approval process remains the same, but there >>>> needs to be a flavor of an adoption process - e.g. some AB member has to >>>> sponsor the document prior to it being submitted for approval and that >>>> AB member would be responsible for working with the author(s) to deal >>>> with probable AB pushbacks. >>> It's a good catch, but I'm inclined to a different answer: just say no. >>> I'm not seeing why we need a bypass in this case. We need the bypass >>> in the IETF for topics that simply don't need the overhead of a WG; in >>> this case we already *have* a WG. >>> >>> If somebody believes, for example, that all RFCs should be translated >>> into Elbonian, I think it is necessary and sufficient to tell them to >>> take it to the working group. >>> >>> Brian >>> >> Probably not. I actually think there will be a few of these - maybe originated by the RPC or by a hired XML expert for example. I may be wrong, but the WG is probably the wrong path for some documents. > > Just because that is the source of the document, I see no reason that the WG cannot adopt and review them before they get approved. Yes. And the process in the WG could (and should) be very short and light if it's a document from the RPC or an XML expert that nobody disagrees with, or that is just published for the record, without by itself changing anything in the publication process. Regards, Martin. From nobody Tue Feb 16 15:30:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30583A12BA for ; Tue, 16 Feb 2021 15:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=PsKlKOqd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H+K1OG1e Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVQII_7USwUY for ; Tue, 16 Feb 2021 15:30:48 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1D23A12B9 for ; Tue, 16 Feb 2021 15:30:48 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A8E575C012A for ; Tue, 16 Feb 2021 18:30:47 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 16 Feb 2021 18:30:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=dEKW42xinBQpKxqjmgf5Xx+coNw7HF7 a82tAZzRMbXU=; b=PsKlKOqdJZq0dd5tdAPgp6Jom81A45IvYKH+d00D7ot8NhQ LcT/d/pE2G+cC+pupXWW5Hj828dozq6MRHwPE+OklKoOEAaocWcjcwZDdu+xHH5z XfFZstyqj3WG7C9E8wSqb1FtLXCHV3JyUKpfw3nAL7dxlTretA76MgFk4y6aZwbh rYk8LjHOwpVxzktuIM4K0X3B7g0iHmcsHxRFnUMo975MQW/9C/CJCDh9YqkNxAS7 6PmfErtkgJ1K66U2HigRHEwE65k7fXYqRFjE6Y8Kc1zVDptoSnXAM/W4BFQmk0BJ JxDLKgO/WuUeira+hjXsh/7u74WbhjqUEBKgBdw== 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=dEKW42 xinBQpKxqjmgf5Xx+coNw7HF7a82tAZzRMbXU=; b=H+K1OG1eASQBCZBSgMsboX du0e9x7OPKzjKV0UDyQQXZ8Uw9Gh5yopqgXDrH1hU3eTP43Twest0gHbyXJIPTZP 7k0GBGU5lZBRfgi91tKqV6OSv3lMfCPVJlTEaK6ZXrGon3yTxwAeATSE/6ymMOsy u7zZ2kPtS/W1LRoxXWnjMMtOoluYJoHI17X2qbnOCYaR7eeL/k/nfhLL1rOEduPm TLtYVr3xZf+fTmm7lfC8oRAIrP4Vfl+/sAM2h54UNoFU9PaWro/E7GR/d/crRz1e tLiKrjBARhQ+6tFRr8vgC5y/hIsWa3IgKgn8QYpB6Hx0mjqaLe2izUkbVk0ZAShw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrjedugddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepteejheeftedvudduvdevve etkefghfefvedugeeugeekjeejvdfhveeukeejgfdtnecuffhomhgrihhnpehirggsrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh htsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 649184E0080; Tue, 16 Feb 2021 18:30:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <8857e559-0f9b-4590-96ae-2d1373129bb1@www.fastmail.com> In-Reply-To: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> Date: Wed, 17 Feb 2021 10:30:08 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Feb 2021 23:30:51 -0000 I think that this is good. The community last call process I had imagined was simple: an email is sent to a number of venues asking for input, with a 2-4 week period allowed as circumstances dictate. This is not the internal check that the WG performs, but one that deliberately seeks input from a broader audience. Feedback from this stage is intended to inform AB decisions, but it also might cause the WG to retract their request for approval (which would allow them to address a concern without forcing a vote). As a starting point, I would suggest that we simply document that a list of email addresses to which the announcement/request be sent. It might be seeded with rfc-interest@ and then added to as requested. I expect that last-call@ would be a good candidate and iab@ might be. The IRTF/IRSG and ISEB might also have their own preferences, but I'm not familiar enough with those to say. It might also be of interest to other groups like IEEE, ITU-T, and so forth. My suggestion is that all we need to document is that the AB maintain the list and that they accept all reasonable requests to be added. Nit: There are two G's. On Wed, Feb 17, 2021, at 02:43, Adrian Farrel wrote: > Hi, > > As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H persuaded me > to take a second pass trying to factor in some of the comments on the list. > > I can't promise that I have captured *exactly* what everyone said, > especially as some of the opinions were conflicting. What I have done is try > to move the text towards something that might be a compromise between the > positions. FWIW, I went back to the "Discuss" position because it carries > some implication that we are all going to try to get together and resolve > this. > > I also tried to cut some of the waffle. I do tend to waffle. > > There are two open points. I'd humbly suggest that the people who raised > these issues might try to throw some text at a solution. > > 1. At point C there is the concept of a "community last call". This was > raised by Martin and Russ, and I suggest that they put forward a proposal. > The challenge might be to find a way to identify and reach the "community" > (it's easy in the IETF, but very hard for "the world"). > > 2. At point J there is the concept of "an appeal" in the case of Discusses > being unreconcilable. This was raised by Adam and Mark. The challenge, as > they noted, is working out to whom one appeals. > > Hope this is useful (which is, after all, the only point). > > Adrian > > ==== > > Decision-making procedures > > A. Development Cycle > The WG is expected to show its work to the approval group and attempt to be > aware of issues that the approval group might be concerned about. > The members of the approval group are expected to pay attention to the work > of the WG and speak up when they have concerns. > The intention is early discovery of issues and avoidance of late surprises. > > B. WG last call > The WG last calls its work following the model of an IETF WG. It is assumed > that all members of the approval group will participate the WG last call, in > an attempt to expose any of their concerns that still remain, and to reach > agreement. > > C. Community last call / public comment > It is unclear whether this step (corresponding to IETF last call) exists and > how it would be operated. Further discussion needed per Martin and Russ. > > D. Participation by members of the approval group > As noted in steps A and B, participation in WG work by members of the > approval group is expected. > It is understood that, from time to time, a member of the approval group may > find it impossible to participate in a particular discussion: in this case, > they are encourage to send delegates. > > E. Discussion by the approval group > The approval group shall discuss the output of the WG. > Such discussion is to take place normally within 2 weeks of the WG making a > request. > The 2 week period may be stretched by holidays or IETF meetings, but the WG > must be notified if this is the case. > All comments and concerns shall be documented to the WG which may take them > into consideration. > > F. Approval by the approval group > The voting members of the approval group shall formally ballot by the end of > the discussion period in E. > Each voting member may ballot one of: > - Yes: Means "I support this work." A Yes ballot may be accompanied by > comments indicating thoughts and issues that should be looked at, but are > non-blocking. > - Discuss: Means "I have a serious concern that I would like to Discuss > before this work can proceed." Voting members are expected to actively > engage in resolving their Discuss positions. > - No Position: Only used in exceptional cases such as illness or long > vacation. Voting members are expected to try to present a different ballot > position. > - Abstain: Means "I have a serious concern, but recognise that it will not > be resolved." An Abstain ballot is a way for a voting member to get out of > the way of progress even though it worries them. The existence of an Abstain > ballot does not imply the work is flawed, but indicates a genuinely > irreconcilable difference of opinion. > - Recuse: Means "It would be improper for me to have a position." For > example, if the proposal was to remunerate the voting member. > > G. Reasons for a Discuss > The approval group shall maintain a list of reasons for a Discuss ballot. A > Discuss that does not conform to one of these reasons shall not be valid, > and must be re-balloted. > An initial draft of this list is as follows: > - The proposal would cause significant harm to one of the streams > - The proposal would cause significant harm to the series > - The proposal would cause inconvenience to a group of consumers, the > benefit of the change does not outweigh the cost of the inconvenience, and > that inconvenience could be overcome by using a different approach > > G. Work proceeds if... > At the end of the discussion period (point E) or at any later time, there is > at least one "Yes" and no "Discuss" ballot. That is, work fails to proceed > unless it has approval. > > H. Resolution of Discusses > A voting member who ballots Discuss shall explain their concerns to the WG > and shall engage in discussions attempting to resolve the concerns and > arrive at a compromise or other agreement. > When such agreement is reached, the voting member should transition their > ballot to a "Yes". > A voting member may transition their ballot to an "Abstain" at any time, > although all parties are encouraged to attempt to reach agreement. > > I. Single Discuss resolution > In the event of there being exactly one Discuss ballot, and there being no > timely progress to agreement between the WG and the member of the approval > group who issued the ballot, the WG may request that the approval group > exercise an exception resolution process as follows: > - The approval group will discuss the concern giving rise to the ballot and > any proposed resolution from the WG > - The approval group shall attempt to reach consensus on whether to sustain > the Discuss or to release the work, but failing that shall vote with a > simple majority determining the outcome > - If the Discuss is sustained, return to step H > - If the work is released, the Discuss ballot shall be changed to an Abstain > and the work shall progress > > J. Appeals > In the event that more than one Discuss cannot be resolved or that a single > Discuss is sustained by the approval group, there is a right of appeal. > The details of this need to be worked out per Adam and Mark. > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > From nobody Tue Feb 16 16:03:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573B83A131C for ; Tue, 16 Feb 2021 16:03:38 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hlhpU0wQss0 for ; Tue, 16 Feb 2021 16:03:36 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320101.outbound.protection.outlook.com [40.107.132.101]) (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 1C8B33A1319 for ; Tue, 16 Feb 2021 16:03:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k3R1AK50k21KsPL8lEKYPxW/nUcCTYWr0yxELPN6ObCGsl5rmCIEHEJC9CX5R8CXLgaVdDgaGYpfSmh6VWG8k2kkrBlLzoTz7fSFcNrahrT/XdSCU8ZP01kIZTAK3v6fr7zr+CcI4dK4WTIvhGaRHlhDZZ3USVIg/NfYLKPLpAMFFUJw8KOQaBc4p9+7aT2O39CidN+P27vC8WV2lrugY3JEgUKvXR1unVr80qWukgfp6T4wi5s2wXKkr+13NV5E5JqFbjIo034g9q+HebD/CDWVXATAy1+/wLqKleaVlL0lf48GDUZTSq4NL0ALiDALLIfh7gu045qjT6TviWHZjQ== 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=Zot2uUEqrm1g2/ViENMvb7tjffJF8w4Q6yqaM54Ezp8=; b=BMvrb5FOlhpPuDorBMag9Z3gdxybJe+kx9N7FzOjdXudEJLxaKgUf9qUriImEh7f8A0LHySiGLIJ3V2XO7wYZub8hJpSX9KLF1YM1KTHffDEZPH+cCFg1yua5QEX6xXoGJ5f7pgOB97wHFFciOLUg193XYX5gpc+zrlm0e76GC2k5IQr6pAJFVzzbyF+bvcD+j40L5PoQ6VDNesSO8qmOuXjiTtwTBkuAY0R7s4Ek3G///FVMtFvXiSnnYZMD+HPci5W3nDcv3pSdBCIxAyQND4U+7AqPp8157FQ2VHtZPZhEwcXm/ec7/eaYLr5pqaa+mRQYXxSzhqWW0R9YIQOWQ== 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=Zot2uUEqrm1g2/ViENMvb7tjffJF8w4Q6yqaM54Ezp8=; b=N206lDAf3DjcRciKJZK/+Ui4gX6XyUa7Yt2shJ4J7vg9fr1mgEuxn7eo0HhJhIBCS0Jyyzi352kPKuLAiOFmBCY1c0Z1t/0GvaeFjc0KC5HmCLfjJ2vvpSXdmGOpOyFljl6hSROrH/RUsgRSko0UNAxOu1t4jNCjWBeq8Qs75XU= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB3851.jpnprd01.prod.outlook.com (2603:1096:404:d4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.29; Wed, 17 Feb 2021 00:03:29 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f%7]) with mapi id 15.20.3868.027; Wed, 17 Feb 2021 00:03:29 +0000 To: Martin Thomson , rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <8857e559-0f9b-4590-96ae-2d1373129bb1@www.fastmail.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Wed, 17 Feb 2021 09:03:26 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <8857e559-0f9b-4590-96ae-2d1373129bb1@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [223.217.46.174] X-ClientProxiedBy: TYCPR01CA0107.jpnprd01.prod.outlook.com (2603:1096:405:4::23) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.7] (223.217.46.174) by TYCPR01CA0107.jpnprd01.prod.outlook.com (2603:1096:405:4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Wed, 17 Feb 2021 00:03:29 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9e299755-9ae6-4939-8c96-08d8d2d774ec X-MS-TrafficTypeDiagnostic: TY2PR01MB3851: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: aU6bRQ6o//fjbWXdG+DiteMJlcdeNiItpHIU+mP8Jz/BmePCo9yIdLctg4d33POzKF3TYoYTR5tv9Y7vxeMHzROPPYXR8DUnrDshuOOgw205LUfwYPSN/zu+0QlWxRfu3aDSYCaBtum3F0azMUCsNHt78LajguqaHI/AyE4jyFtqizbA2lhvl4Iyx7pboviKaKEwDgrZ4sBMSSKmi1NrasCu8NYVJpzECx5jPJZhz4JTCE82JQ0yjRmBQqucpQtDB/9EVn3KA3VzI/bxv3vDywkFERlCqyY5oaOPo+ozlkizOwgKyAFPN+ZCTZPLF13dcKy0WmTqOWJHm1mxpded7RKAyQSkRGT2slCYtrQyYP5moIU03TXH2ctFdxcQzCh12lXS4HAtS5x5ah1UA2LZDFRgzchzDceoiuKwNQvEIXFn7yyGHDeDzyWLASj4k5U9MfclOYuo7RywoUcNnQ4f4EhJbXzEnyfHlFYueKoQLYs0OyaKkozWRLNifgjRolWtjuKOw12Huvy8T0+lx+qYkrPAVmlt47egwkLwwaSGeVJKl1ufVK/kioyWIovL2hg6NZDLppsAX1fhbl1EflsQeVKM9dnAoEJMYTvl+h6B68c/OHXFXqDKpzgE3Hi+9iRq1rh1nZBV8ZTyu9kjs4FD5JqXT4xjbHkdUdOu+/V6Trgy6B75oINECyyu1teNl2th X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(396003)(366004)(39840400004)(376002)(2616005)(966005)(36916002)(956004)(5660300002)(83380400001)(6486002)(52116002)(66556008)(6666004)(66946007)(316002)(53546011)(16526019)(786003)(8936002)(66476007)(16576012)(26005)(86362001)(478600001)(186003)(2906002)(8676002)(31686004)(31696002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?aEl6djNLemR3ZkdGMkpvSVlUVDNIblhuWXpHd25zKzRCVTJJOVkxU1grMlFY?= =?utf-8?B?RHlLUTVPV3hrbmhBdnBIZ2NNSUEwajRQS2w0NjVza3N0Tk5xcFhySVdzS2ds?= =?utf-8?B?Q0trL0pPdXROUUsrUGpEdEJnSnhMMWJMdytDVkdRNzlYekY1TEVUN0R3cXgv?= =?utf-8?B?L1ozYjJtWWlGSXZmNnhpYjhmaDR1STJFNEF6YU9yMGlJelh1eENoQ1k3T2FF?= =?utf-8?B?OGtaQ1hwWTRSemcra1VmM0hKTERVTStaa3l4ZWt6TjVacmx2TUlwUWQwSWtp?= =?utf-8?B?SjJRZGxvdHVJeE1qVTRUNCtLd1F1dTdVNFB4UjJ2Nk9MaDE1Y2krQXhoOUlp?= =?utf-8?B?cUU0M3ZtZFZHTXJqa0RlcHdrdTA1dElLdEN0d0lBMG12cmtNR0NLTmI5TWlH?= =?utf-8?B?eUN3UHI1aWpOWmtsS0xuWE4rblFXamFIa09JS2V6dkxDRVVUazZSRVVxcEVN?= =?utf-8?B?VXc4R25qY3kzeVRiU08vUzlPaGZGbFg0NVVSWVRBb0ZIMUNJZDJWRWdYazh3?= =?utf-8?B?WjNOamZRekNWcXVkTG1Rc0NKNkVYTmZMVm0ycnp6T2FFZzNzcnRhOWFmRHpX?= =?utf-8?B?ZzFPZ2tSYXVsMTU4dUxVVGlCK2g0N0g3V3VSOVJXZUU2bjU1NXM2c09xbWlO?= =?utf-8?B?aHJBOE5vSmI4N3d2dWlKYW5VTDkrUjJWZnlmMVZMT1NIeXlZVGxGMXdCVjZG?= =?utf-8?B?aEFnbkVXRjM5ZXN3V3ZtZE8xQStUcHk3ak1xUWNKL1UyMzU3clU5VE1ORGVq?= =?utf-8?B?eVY3djlQdEJHWEtyWVVoTXl3bmw2KzcxdGZUVEN6bjVUdnRIdHBrUjBZajIr?= =?utf-8?B?TmovTnBKQjdWVUlDVUJkdWlxTkJqRk4rMU9rbFNvcTRNMlRlaHZzYXh2RHhI?= =?utf-8?B?R0JDbXpFZ3ZSRTRyWDl0RElqOUhuQVQwWm5HTzVJWEtEVTF4czEyeUI1UHd1?= =?utf-8?B?SlN4WmpvbXQyMXZCS0h2MDZtNHAvVjA3Ykd6bXdVaUZhbWlCOVZ1QW8zNXFN?= =?utf-8?B?M0JUd1JseTl6ZzMxWmpQVnB0aFdsSEFobjNzek5nVEkzTFhsWGdZeFo1UHdt?= =?utf-8?B?SjU5QlppSysxK1Q1U3JIUWNlVTRXblBVMDJqMWVJalVNa2NYajFnTGU2U2pp?= =?utf-8?B?MTdpZUYxdm5ab1NwdlB5NVdScHJ3dXppeHRxOWttNHZ5QlJqVk9JVzN0Y3Z2?= =?utf-8?B?YktIeExzOTZwM1FvOThYU0dzZ3JzYlcrZmU2ZmVycU0wTU1WM0tOcFpINmtC?= =?utf-8?B?UzFFL2p0YTh3WUtLTmZYSnVtbVhYbHhWTldyM2hneW91MSthS2hhckFYUmpv?= =?utf-8?B?N1ErdG9KQ2o1anViNEc2YXVmbHhuVkhtVm5XWGFlWCtQN2VkdWp3dEFodXlQ?= =?utf-8?B?TVo2NnJJSW9IUnc3aWVqMWRRYTR4aHdXOExHRVNxa2xIZWVMenlSZUs3OVRU?= =?utf-8?B?TTdJQXdDY0FONGhtOTNuM3JyK3d6Z3ovTTVhSDhpMFprcEFEOVFtdG9JV0Yw?= =?utf-8?B?Z3o4N245bVNLbzBqRWFTbmNaTXdCbkVRdEdzSldQR0g0Q2UrT0xKMWNVSlU5?= =?utf-8?B?YzVCTUkvUGJCYmlVL0VZVlkyWkpIbW0ydG9DYVRPTVBTQndQNzNkTDNOMGk0?= =?utf-8?B?K0s3dENVZGkxZUo4TDMyNm51Z2lKMzN0TGpLTDU5VVF1Z1NkRDVaZXREcXM4?= =?utf-8?B?NFd4MFA0Mlk5SWdoSGFsNlViUFhsRGtJUnJPL2ZwMCtJTEFtWEd5cEZYNHh0?= =?utf-8?Q?L4Z5jHLoaYfJHQCTzkDPTFPy3oHl6emzahRTq7m?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 9e299755-9ae6-4939-8c96-08d8d2d774ec X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2021 00:03:29.5650 (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: YuTCA6u1AcQ94XOIWVatm7/4/S4ILfI2DesbeuY9c3mA0KG+DBaUIOj4dkxsY+l6FTCo+zW2kzjNOb4atRyblg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB3851 Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 00:03:38 -0000 On 17/02/2021 08:30, Martin Thomson wrote: > I think that this is good. > > The community last call process I had imagined was simple: an email is sent to a number of venues asking for input, with a 2-4 week period allowed as circumstances dictate. This is not the internal check that the WG performs, but one that deliberately seeks input from a broader audience. Feedback from this stage is intended to inform AB decisions, but it also might cause the WG to retract their request for approval (which would allow them to address a concern without forcing a vote). > > As a starting point, I would suggest that we simply document that a list of email addresses to which the announcement/request be sent. It might be seeded with rfc-interest@ and then added to as requested. I expect that last-call@ would be a good candidate and iab@ might be. The IRTF/IRSG and ISEB might also have their own preferences, but I'm not familiar enough with those to say. It might also be of interest to other groups like IEEE, ITU-T, and so forth. My suggestion is that all we need to document is that the AB maintain the list and that they accept all reasonable requests to be added. Not much to add. Putting a notice on the top page of https://www.rfc-editor.org/ (and a few other notorious pages) also should be considered. In addition, I think the above list and locations should also be used for a heads-up when starting some serious work. As an example, when working on the RFC XML format version N, don't just send a note when you think you are done (at last call), but send a message that invites interested parties when you're starting. Regards, Martin. From nobody Tue Feb 16 19:34:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84233A0C37 for ; Tue, 16 Feb 2021 19:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 PIHz9K8JjR9x for ; Tue, 16 Feb 2021 19:34:25 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe9d::711]) (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 90AA53A0BF7 for ; Tue, 16 Feb 2021 19:34:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ToTHjlJPvx0DAMRx0IHbUzz1QKKgoZtFb5vwMhDvTgD2Tab0K2hH9ne0Hgige8qY4GibEQYbQeClFnsBlBt1YWgGwLCs3579tlpdO36ZT1bW6t55ZlPK2yA2B38mlOjTLlFFF2V5UVvxJGyldNisPKOxdWNGB2BgVwamc+XT804uTgzGaOvt7/yyxYdUpyl+x5TFfddqMS3ySAj8uex+pgYUX73fDV3KcnuqbdOW0uEGlg0GapKkNNKsx/ZxNDOx4jbTpfAxIUdRJTz/xGlzwKc16RWHL8g6kXCviAIxAEJ3e+jZ86ypRIhMdm0ijf/46I8KtT904OdRtqTgSACb7g== 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=JQXwYu+5xzXNLSqlAh87aGoJjsST46090jm8DmWZbxg=; b=gAqPAQx+gG7MdeM4ABY6Rf3026tvI8AVPT1PR5wifhOfmfSkeTejZeBJ13+P9i2FnHR9EWWUiVLHXT0vrktqynOqVjtQXWlmYQB3ZKMv27U0YdY6rG5BgbUWfs0/69mHC3wDT36G0T2OIRFhu0eDEPDXaKCm6xVsBzsziLT8dNRGJolUL8s2NP93QSuXkFkdgerOjAkpdeqC4yu5V8NqDO/XPkg/lr4SPPRzmUO6aAuMyr8JGGYdIucPgdm9XIQT3+lDjMGVtMl3ZE44CZ6szhC1Yvw+pi9l9vlQVnmpHfG7qAi1S/fKmQO7UGx4ayUS23sucnnSHw3nDBhdYfjx5A== 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=JQXwYu+5xzXNLSqlAh87aGoJjsST46090jm8DmWZbxg=; b=lkeeqN2ETBQ2DviVfFcE2JB9juapJtCCnWiG4JaYRRiaTwqQOl4dFlb+OBkVjovcnVzUWvVxDqRrEf7vJvt6dwj4NO469XHR8YuhJV1zN2su1UPA26NzRiMaY/LdcbJTKuA59EeLkPcSFYF3xPWymVbyF/N890LRTXwjJoGdEBA= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYCPR01MB5757.jpnprd01.prod.outlook.com (2603:1096:400:46::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27; Wed, 17 Feb 2021 03:34:17 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f%7]) with mapi id 15.20.3868.027; Wed, 17 Feb 2021 03:34:17 +0000 To: rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Wed, 17 Feb 2021 12:34:14 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [223.217.46.174] X-ClientProxiedBy: TYWPR01CA0009.jpnprd01.prod.outlook.com (2603:1096:400:a9::14) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.7] (223.217.46.174) by TYWPR01CA0009.jpnprd01.prod.outlook.com (2603:1096:400:a9::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Wed, 17 Feb 2021 03:34:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3b05380d-a619-481f-47ae-08d8d2f4e747 X-MS-TrafficTypeDiagnostic: TYCPR01MB5757: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TuunUYeU/Hna8KjfUOl98oVnPh22QPWANtsxbzsoO6iCJbCmgwbO08TxNiYRTggUSS6cq5Y7XmS0M8qwuV2yMD02x9kUXMv86nJAjQsW9+LDcHa58fMruotlQsi3/u58Fma5zKiN9nxAlUuRIku03DHCRc+YNK7siEqz6/ef+zrNwh7UAsALB9jkwvCdZ3vOIQTXI4KpT2r6MG9TFCOu5MED96Ng4sVjkBAKFC+wr9lvsu7db7w00MDb83QYWA6bjDvtzjow5vOH2IrnQLv9P585qWMqOFSS5x3mff6h+4Ww5JF1IQhYP2mFQTn0bFoSE62OtD+eJ4Qq13jYzntqhhcUwIdOtJJ2Nfm+fFaYeSeMbD+8zRcvTH6sTb8xzlBrJPgJVTqCJvCmX75sA6E2SDXqvpvMjLBzNmeLnbtJT/SVBvwEXkyS9Gr4bsMccqpAhnu3ZAckoSqPXyjhWb02/xL+mtM4tJp5J3enV2ApBcZCc5EBwf9o51cukC1UhsWTVGH4Fk7AvLxEPKFR2zGjt3rSXumHOq24xtLien6dpj35hM1HkMvX88pPESIXt9j7oXIWKIdwhCQvXL5OheTQjol7iKBAz/nA2+y21KuoCsE= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(136003)(39850400004)(396003)(6486002)(86362001)(478600001)(53546011)(6916009)(2906002)(31696002)(83380400001)(36916002)(52116002)(66556008)(956004)(5660300002)(8676002)(8936002)(31686004)(26005)(2616005)(16576012)(786003)(66476007)(16526019)(186003)(316002)(66946007)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?WG5lbWMvczlCbE9idXN2c2Q1N1dINjVJNElqbkZ5dW9LVzB4MVNwTEZ6YnNp?= =?utf-8?B?V3d1Slh1R0x5NFFrZnN2bWNxZVRmeXBZMFZWY1d3ZVF5Kys3N3Y5czdPYUkx?= =?utf-8?B?RW5UdXBpbUppSEhrN2xmeU5Wc3RoN3pZdDJySnFWbW1rdEtBYjIybFdUMDY2?= =?utf-8?B?K1lsQk10dUI2T2ZnWVkwV1ZESXNicEtzdXM1TFQrdEFqSTdhaXgyVHlsVWds?= =?utf-8?B?Y0ZFanJlSUdjNUVuUTdGTWw2bzZJMjE2OWNLZHg0K0JtZW16VENvYitKcE9h?= =?utf-8?B?VDVJR3ZpSFFmWjQ5ZUpmaC9jakdDQTRDOFdDcVRqRkwrUkVmQjl0aU55clV3?= =?utf-8?B?RkxaeTlrdDlqZzVvWjJ6SllMMUhhdEtoMjRjQzZHNVUvejZJOWZnWURCSTV5?= =?utf-8?B?T21YcmZnbUhCaHh5OU96WTFrYWRaaHlvbE1wRnh0YUZZOXorN0p5ZnF0TEcz?= =?utf-8?B?a1dMWFZmMEJ0OGVOMjRTWjhobUtJYWZWc3k4MW83T3doOEJPL1JvU0pWejhr?= =?utf-8?B?YTBDWExoWDlYVUQyM3hTYkRHNlRyb2pPTUJFd080YitGSTlNWlFYOGp3cGtQ?= =?utf-8?B?aHp6aXFmMmxpQjVaN0Zhc25lb2pMQ2wzSU1NSUxUUTV1c3NUNml4OXV3dFhF?= =?utf-8?B?RlhsREpGSHk4VWVrV0hYYzFnbTdrS293YXNBRHlZYXBUNTJZRHhCSng0WFN0?= =?utf-8?B?Vm9BNmR2eUwwNXFma1JyaVBTblFWU2tTdGM3NTduWFdqZTU2cTF3ZWMwWGdv?= =?utf-8?B?NENob3VTdjhyYVZEcnJNVjlETTdBVXg3VkN6bTN3aFU5cnJTTzdjT3VWUzVr?= =?utf-8?B?a0oxY01lMUNBRHJVMCtaTWdjVS9CbFQ4Zld2SFdUdTEwY0JwWHpBdVg1bmY0?= =?utf-8?B?bGwzWDlSbHNRUGZaOStKOGc1REhOUFBIUHhWUXg5dFdFZnBTZ1NwTCtjM09S?= =?utf-8?B?SXdwSzJycERxaHpOcjJ5cHZzK1hJdzQyR3hYUjNKZE84aGN6Z2hnOVVZenkr?= =?utf-8?B?RzdzQWpVa1g5YkoxU1pWTTRTTmM5S0ZWUThZUFlkVlBnZHFrSmRoK3U2S2Ra?= =?utf-8?B?aUxiWVUzRis4WGh6NCs5VEF0SndkWUVVQXhjbmVQK2RHNXAyZDRsMy8rczYr?= =?utf-8?B?U2lIUC9JcThFSnAvYVV4Y2R2K1dFQ2VhUTVDcVd2LzZkc1Y1a0o0Z09CVXZt?= =?utf-8?B?V1FDUEdLc2VDYTNabmtIM2dQT09LS21aa1VLd0RhZ2pwRXB3M0tNRjFQYzZZ?= =?utf-8?B?bjhTa09CMnoyTWtqdTZEakQwYWtySXNKd0gvdjRrNUM1b1c5NlNqZ1pVRUdD?= =?utf-8?B?blljc3kzYm9IVVNTcXZQc0pDdnU1dm1OT1d6YlRObVpxVjVHejA4eWZQKzBj?= =?utf-8?B?a3ljQWdqM3dTWWN3M3M5bTFjVmFWbzRiT2ZiWkFVSVg1NUpzTUd3YUlQY0d2?= =?utf-8?B?U1cvbFhBLzYxTjBiTjZ6ZFBUOHdYcENOV1dxaXduTkRSVFhkakYrVGRBNm15?= =?utf-8?B?SjhTd2hRZXREWUlZcDA0T3RRNDV3aG1OUjRLNjhpeWcyVFJEYUVEQzFMR212?= =?utf-8?B?dzBGVnJqRThZazFsM0htdkRZRllvYTNQaVhwUTJuaENFak1QcGRCM2F1SEx0?= =?utf-8?B?N2pQVjdSd3oyNWpRUXIrUjlBYnc4Um1GM2N6VnhYcC9vb2xHb3FrR0ZFOUxp?= =?utf-8?B?K1BxMEtNUjBkRnBGTVkzYXZUSjJZSXZ3UEh0VWF4bHpWWHBLK2tCTXhZb3Ru?= =?utf-8?Q?OuUk0GgDY84zRKry5tk71HWmtRCH5Y46hIN+nG3?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 3b05380d-a619-481f-47ae-08d8d2f4e747 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2021 03:34:16.9983 (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: oM55blrdMh8ejLwcCAF0780gNM2albwCY8xOaCwnwxu8qxOgHml95C9CASor7QMxsIzx6hF/UyNNK4QC6aO6cg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB5757 Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 03:34:28 -0000 On 17/02/2021 00:43, Adrian Farrel wrote: > Hi, > > As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H persuaded me > to take a second pass trying to factor in some of the comments on the list. > > I can't promise that I have captured *exactly* what everyone said, > especially as some of the opinions were conflicting. What I have done is try > to move the text towards something that might be a compromise between the > positions. FWIW, I went back to the "Discuss" position because it carries > some implication that we are all going to try to get together and resolve > this. Looks good to me, except for two points: - You still have the approval threshold at 1 YES. As others also have said, this is not appropriate for the topics at hand. The 'abstain' should probably also go. (second point G, with some influence on point F) (In the IESG, it's okay that a draft be approved essentially on the responsibility of a single AD; it should never happen that we have something RFC-related approved and later, one AB member gets blamed for some outcome because all the others can say: I didn't vote yes on this on.) - Point G mentions consumers, but producers aren't mentioned anywhere. While it is fair to expect that we need more care to make sure we look out for the needs of consumers, I think producers should also be mentioned, at the very least for completeness. Regards, Martin. > I also tried to cut some of the waffle. I do tend to waffle. > > There are two open points. I'd humbly suggest that the people who raised > these issues might try to throw some text at a solution. > > 1. At point C there is the concept of a "community last call". This was > raised by Martin and Russ, and I suggest that they put forward a proposal. > The challenge might be to find a way to identify and reach the "community" > (it's easy in the IETF, but very hard for "the world"). > > 2. At point J there is the concept of "an appeal" in the case of Discusses > being unreconcilable. This was raised by Adam and Mark. The challenge, as > they noted, is working out to whom one appeals. > > Hope this is useful (which is, after all, the only point). > > Adrian > > ==== > > Decision-making procedures > > A. Development Cycle > F. Approval by the approval group > The voting members of the approval group shall formally ballot by the end of > the discussion period in E. > Each voting member may ballot one of: > - Yes: Means "I support this work." A Yes ballot may be accompanied by > comments indicating thoughts and issues that should be looked at, but are > non-blocking. > - Discuss: Means "I have a serious concern that I would like to Discuss > before this work can proceed." Voting members are expected to actively > engage in resolving their Discuss positions. > - No Position: Only used in exceptional cases such as illness or long > vacation. Voting members are expected to try to present a different ballot > position. > - Abstain: Means "I have a serious concern, but recognise that it will not > be resolved." An Abstain ballot is a way for a voting member to get out of > the way of progress even though it worries them. The existence of an Abstain > ballot does not imply the work is flawed, but indicates a genuinely > irreconcilable difference of opinion. > - Recuse: Means "It would be improper for me to have a position." For > example, if the proposal was to remunerate the voting member. > > G. Reasons for a Discuss > The approval group shall maintain a list of reasons for a Discuss ballot. A > Discuss that does not conform to one of these reasons shall not be valid, > and must be re-balloted. > An initial draft of this list is as follows: > - The proposal would cause significant harm to one of the streams > - The proposal would cause significant harm to the series > - The proposal would cause inconvenience to a group of consumers, the > benefit of the change does not outweigh the cost of the inconvenience, and > that inconvenience could be overcome by using a different approach > > G. Work proceeds if... > At the end of the discussion period (point E) or at any later time, there is > at least one "Yes" and no "Discuss" ballot. That is, work fails to proceed > unless it has approval. From nobody Tue Feb 16 22:21:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782553A1572 for ; Tue, 16 Feb 2021 22:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_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=j3L3t+yK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZNivqE9h Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cvd3H_Nf3IG for ; Tue, 16 Feb 2021 22:21:00 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C423A1570 for ; Tue, 16 Feb 2021 22:21:00 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id D10EDB12; Wed, 17 Feb 2021 01:20:58 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 17 Feb 2021 01:20:59 -0500 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=J SHQqkfqGOBYy4rp1Csp1ziYfuqhCWX2lff6B+rw8zI=; b=j3L3t+yKHm8IRc10F 8pSr2ZjjGs7RbgfGafw+CK4rFlB6fc2KLg3u3xC+8bsynryLlPcyNCSZN5+PjCI+ TNPVV8QvjBeuRwYBziR71LzAfQ+4Uc1NeEy5BNPFno1tUsy4OiZAmXwI/gEYYuAf MTtqxWcRGRRRcGQZ59GZlvGfcuIzLN3A+oifFKw8sSLHTF/fE5QNgE62iqET1CKE cDceT2v6zVOKc0Hftm/KYwfwZSEi+iZgpDbOeVWNju2PXXvneGQC9Fxx/rUaU5EC S6jWah7+JtXgZruoM2c0MFRVqTmh1GKNxKWbKP99NQqY6eCylweRrGfszLzsvRaq V0Ycg== 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=JSHQqkfqGOBYy4rp1Csp1ziYfuqhCWX2lff6B+rw8 zI=; b=ZNivqE9hAHSY+8hOp2jsq0/bTgEPYTXGuk4YqBZAUB7b1HRoxjhSfWTdL gbyIV6zlDAi5EKV9ApabDzO2GHqg+151nmMIVj2SdAhuR4grMK8ku6vOXX6CNr3U Xdn4pEb6x7EIOi5v5805srh4zySMcBxKOucetoAtu2spWh47a8JUQBBafYGHrOSl f1iQvvzibpgw0Sy2l4eGVIW0GEvi24Kh5s85A0WXb8EUdwukwovu0XCeNTUHG2OW MM0VkSdXWOwOJexUXxulJQh6p4DeGT0nh2/8/SFg9PJxNSlY5g2ZCwbM/7rAGdxQ Xn/BP4Z/WPIngsR5yOG1ZXyC/N9Mw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrjedugdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepuedtkefhtdfggfejjeegkeevheefhffguefgheefgfegkefhiedtgeduvedufeei necuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrud ejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 4C2A8108005C; Wed, 17 Feb 2021 01:20:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> Date: Wed, 17 Feb 2021 17:20:52 +1100 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 06:21:04 -0000 This looks good. Regarding appeals -- perhaps we could make progress by listing possible = destinations for appeals and their positive/negative aspects. To get us started: * The IESG -- not a good idea; only the IETF. Already represented on the = approval group. * The IAB -- Better than IESG in that it has a broader/long-term = function, but also represented on the approval group. * Internet Society BoT (or Chair) -- has appropriate scope / distance; = relationship to Series is a bit fuzzy? Any other candidates? Cheers, > On 17 Feb 2021, at 2:43 am, Adrian Farrel wrote: >=20 > Hi, >=20 > As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H = persuaded me > to take a second pass trying to factor in some of the comments on the = list. >=20 > I can't promise that I have captured *exactly* what everyone said, > especially as some of the opinions were conflicting. What I have done = is try > to move the text towards something that might be a compromise between = the > positions. FWIW, I went back to the "Discuss" position because it = carries > some implication that we are all going to try to get together and = resolve > this. >=20 > I also tried to cut some of the waffle. I do tend to waffle. >=20 > There are two open points. I'd humbly suggest that the people who = raised > these issues might try to throw some text at a solution.=20 >=20 > 1. At point C there is the concept of a "community last call". This = was > raised by Martin and Russ, and I suggest that they put forward a = proposal. > The challenge might be to find a way to identify and reach the = "community" > (it's easy in the IETF, but very hard for "the world"). >=20 > 2. At point J there is the concept of "an appeal" in the case of = Discusses > being unreconcilable. This was raised by Adam and Mark. The challenge, = as > they noted, is working out to whom one appeals. >=20 > Hope this is useful (which is, after all, the only point). >=20 > Adrian >=20 > =3D=3D=3D=3D >=20 > Decision-making procedures >=20 > A. Development Cycle > The WG is expected to show its work to the approval group and attempt = to be > aware of issues that the approval group might be concerned about. > The members of the approval group are expected to pay attention to the = work > of the WG and speak up when they have concerns. > The intention is early discovery of issues and avoidance of late = surprises. >=20 > B. WG last call > The WG last calls its work following the model of an IETF WG. It is = assumed > that all members of the approval group will participate the WG last = call, in > an attempt to expose any of their concerns that still remain, and to = reach > agreement.=20 >=20 > C. Community last call / public comment > It is unclear whether this step (corresponding to IETF last call) = exists and > how it would be operated. Further discussion needed per Martin and = Russ. >=20 > D. Participation by members of the approval group > As noted in steps A and B, participation in WG work by members of the > approval group is expected. > It is understood that, from time to time, a member of the approval = group may > find it impossible to participate in a particular discussion: in this = case, > they are encourage to send delegates. >=20 > E. Discussion by the approval group > The approval group shall discuss the output of the WG.=20 > Such discussion is to take place normally within 2 weeks of the WG = making a > request. > The 2 week period may be stretched by holidays or IETF meetings, but = the WG > must be notified if this is the case. > All comments and concerns shall be documented to the WG which may take = them > into consideration. >=20 > F. Approval by the approval group > The voting members of the approval group shall formally ballot by the = end of > the discussion period in E. > Each voting member may ballot one of: > - Yes: Means "I support this work." A Yes ballot may be accompanied by > comments indicating thoughts and issues that should be looked at, but = are > non-blocking.=20 > - Discuss: Means "I have a serious concern that I would like to = Discuss > before this work can proceed." Voting members are expected to actively > engage in resolving their Discuss positions. > - No Position: Only used in exceptional cases such as illness or long > vacation. Voting members are expected to try to present a different = ballot > position. > - Abstain: Means "I have a serious concern, but recognise that it will = not > be resolved." An Abstain ballot is a way for a voting member to get = out of > the way of progress even though it worries them. The existence of an = Abstain > ballot does not imply the work is flawed, but indicates a genuinely > irreconcilable difference of opinion. > - Recuse: Means "It would be improper for me to have a position." For > example, if the proposal was to remunerate the voting member. >=20 > G. Reasons for a Discuss > The approval group shall maintain a list of reasons for a Discuss = ballot. A > Discuss that does not conform to one of these reasons shall not be = valid, > and must be re-balloted. > An initial draft of this list is as follows: > - The proposal would cause significant harm to one of the streams > - The proposal would cause significant harm to the series > - The proposal would cause inconvenience to a group of consumers, the > benefit of the change does not outweigh the cost of the inconvenience, = and > that inconvenience could be overcome by using a different approach >=20 > G. Work proceeds if... > At the end of the discussion period (point E) or at any later time, = there is > at least one "Yes" and no "Discuss" ballot. That is, work fails to = proceed > unless it has approval. >=20 > H. Resolution of Discusses > A voting member who ballots Discuss shall explain their concerns to = the WG > and shall engage in discussions attempting to resolve the concerns and > arrive at a compromise or other agreement. > When such agreement is reached, the voting member should transition = their > ballot to a "Yes". > A voting member may transition their ballot to an "Abstain" at any = time, > although all parties are encouraged to attempt to reach agreement. >=20 > I. Single Discuss resolution > In the event of there being exactly one Discuss ballot, and there = being no > timely progress to agreement between the WG and the member of the = approval > group who issued the ballot, the WG may request that the approval = group > exercise an exception resolution process as follows: > - The approval group will discuss the concern giving rise to the = ballot and > any proposed resolution from the WG > - The approval group shall attempt to reach consensus on whether to = sustain > the Discuss or to release the work, but failing that shall vote with a > simple majority determining the outcome > - If the Discuss is sustained, return to step H > - If the work is released, the Discuss ballot shall be changed to an = Abstain > and the work shall progress >=20 > J. Appeals > In the event that more than one Discuss cannot be resolved or that a = single > Discuss is sustained by the approval group, there is a right of = appeal. > The details of this need to be worked out per Adam and Mark. >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Wed Feb 17 02:41:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A513A18FC for ; Wed, 17 Feb 2021 02:40:59 -0800 (PST) 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, MAY_BE_FORGED=0.001, 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 4MgLZ6EtHCn3 for ; Wed, 17 Feb 2021 02:40:57 -0800 (PST) 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 0CD9E3A18F8 for ; Wed, 17 Feb 2021 02:40:55 -0800 (PST) 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 11HAerFD030009; Wed, 17 Feb 2021 10:40:53 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E442122042; Wed, 17 Feb 2021 10:40:52 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id CEAD02203D; Wed, 17 Feb 2021 10:40:52 +0000 (GMT) Received: from LAPTOPK7AS653V (201.128.51.84.dyn.plus.net [84.51.128.201] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11HAepYH019723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2021 10:40:52 GMT Reply-To: From: "Adrian Farrel" To: "=?utf-8?Q?'Martin_J._D=C3=BCrst'?=" Cc: References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> In-Reply-To: Date: Wed, 17 Feb 2021 10:40:49 -0000 Organization: Old Dog Consulting Message-ID: <042201d70519$5c357ed0$14a07c70$@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: AQK73sepUntFs9GH4jshSIa9TmihyQE+F2VxqIh/CXA= Content-Language: en-gb X-Originating-IP: 84.51.128.201 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-25942.003 X-TM-AS-Result: No--3.901-10.0-31-10 X-imss-scan-details: No--3.901-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--3.901100-10.000000 X-TMASE-MatchedRID: C/snMIRQLS3xIbpQ8BhdbI61Z+HJnvsO+IfriO3cV8QslLE3tqWy1SqU 3RD+dVC4VaIdEZADYEKS8yMbHOfs/8X6zzMWVMJEwRTopFgZxh1UENBIMyKD0aq9wgXVNwtgGX8 vQkpi2nTwyolo7bSb/I95LIBsUqtjsdQ7HAphoqcsYOarN8c4H5YJh9GtGmRL/uymSAhGxLI/NI bqEKEJc983zSpNdAFaT6gd6TkwVI9N3GWDKhOOSCmjEOrcO6AyF8lNgsbZcW8jIzpupoCXKyvz6 n8ktwf/Fmc+ovluyClB3kjok4mOG2bQIxHg2fnbN61IK1p5WeE23HKB4DzLVgg2kgWdt3qaB1hN UA6Ub5lqPHxwQVHLd9ruX7WP3EtsiJO+wNSDs1/urlEZNxNW1zsY2/UEG7fkhOKxyaUqiJkcWCM kF6w0fXKvkc1THn/IgmX8YLR+pAA1Dk8i7XDkjnpRh12Siy9rMaTXeoefvJybKItl61J/yY3BZj 4qY5QbDMq3z/Y/gtUnRE+fI6etkh68STJXiHfKsw1nuR2XRuq2VS+wtYhY7YdAYaICnu+g6y+5q XtA3lJAdX6Or9ZohlTwHCfnGpOXxDDEgMuEKQOICwHQhEG/BOh6vUQky8b7LLR5nF3ltXgVUhlu C41uNBWJz0qF3xvHJIWB1QP6/JM= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 10:40:59 -0000 Thanks Martin, Again, I'm not in the business of fighting for the rights of straw men. = They are unionised and can stand up for themselves (provided they have = access to a broomstick). But just to explain my thinking... > Looks good to me, except for two points: > > - You still have the approval threshold at 1 YES. As others also have > said, this is not appropriate for the topics at hand. I wonder what the benefit of setting the threshold higher is. It would probably be benign to set it higher given the commentary on "no = position" and "abstain" since the absence of a Discuss is otherwise a = Yes. But I don't see what we get by setting it higher. Perhaps I missed = something. > The 'abstain' should probably also go. > (second point G, with some influence on point F) > (In the IESG, it's okay that a draft be approved essentially on the > responsibility of a single AD; it should never happen that we have > something RFC-related approved and later, one AB member gets blamed > for some outcome because all the others can say: I didn't vote > yes on this on.) So many points =F0=9F=98=8A - It may be popular in Western democracies to blame the people who voted = for X, but we all know that the people who didn't vote are equally to = blame. So I don't hold with this "blame" thing, and I don't think I've = seen it on the IESG ever. - The IESG does not approve stuff on the responsibility of a single AD. = Just not how it works. - That the IESG doesn't have many Yes ballots is a distressing but = irrelevant issue in this context. - None of this is the point of an Abstain. I see two chief reasons: - If the WG decides to have a proposal where the ISE is paid per RFC, = I would expect the ISE to object at first and then move to an Abstain. It would be = highly inappropriate to ballot Yes on the proposal. - If a voting member feels "in their gut" that a proposal is a bad = idea and can't be convinced otherwise, they may still realise (either through = discussion or through the single Discuss resolution procedure) that they should not block = the proposal. It would be odd for them to say Yes in this situation. What else = can they do to "get out of the way"? > - Point G mentions consumers, but producers aren't mentioned anywhere. > While it is fair to expect that we need more care to make sure we = look > out for the needs of consumers, I think producers should also be > mentioned, at the very least for completeness. No objection to calling out "producers". In my mind a producer is also a = consumer. Adrian=20 From nobody Wed Feb 17 03:02:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CE93A1920 for ; Wed, 17 Feb 2021 03:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OhyZnV1b0vqR for ; Wed, 17 Feb 2021 03:02:23 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400090.outbound.protection.outlook.com [40.107.140.90]) (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 C66353A191D for ; Wed, 17 Feb 2021 03:02:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c2jp2l6RWLfjXLHU98p57LJRuPBpVqt3H373+OQO92Qal5YerU09/LxhC2TghH2UGbS4+BxQ/2FPQn5CGdI2RKNluxcFmzdrWXBBk0WwjkV+UlWK+jTS+ddLlAhArkDVzjI89rUi5Yodkpe+nzKQ7XZz0jyvuVmv3ZiprDH6uBRTchy6Ha1NsVKkeml/Ps7QEjmuX1hIM4nbRa1vKIQV3rjDesr7iwVJ21/gZDS+jTzAzBiL+IkLXrUOPNGWca595ShgPSyQjpaj20fFevuHIdKGg5x7yo5GxS3nNyJntjm9xbFu9HO1yCn9/9CsZ2eDVit/CS/zML07S+NYphUB9w== 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=Cg9psiTpHNw4QBATepIas/+hyYnYYqQ56GVaVqMLo3E=; b=I+HmZPIiCHA1VZFCvoLdjm7B3O5E0IGVkggVDvaOgZTIGNpWvukee1szo40VHwG6kvQJwlihpFJsF4dqhckMy1tlX/YhxWscBcqoyCMyJtAhsslxd+RPQYUMab5meeT3urUnEe0RkQnoDyietANPskWp0eALVuusk/NYJth8r0as3rIDuLcvP9jEM39JmROL8+YfFKc6a4gD78lqK07aJ7QY/1RFfmpqnPiVxjscwRE2k/ECWYvH96x4O6tV1j8IY1feetZIw8Ku6dvinTGviYf/dCNj0BbpwGfX53tn3SWoWsyAqUJN3yovJXEj7g2J+EEF22he3FbVH5msBMBd1w== 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=Cg9psiTpHNw4QBATepIas/+hyYnYYqQ56GVaVqMLo3E=; b=RzFyLCp5MrIckaYpP/ve1PTH1zWQGlp9xK2WaS6HWoDXkHckoUNaDsQwL93l1H+UeQ12zFoTgij92l7mlOJs/CeM2xl35RLKbumkhxPsrCdCsmhPsSJsBY0BppSa5NXHtbPxxTbMngvvv9yO52xTkuFYx7AwfJU5zNqyhbkzuP0= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB3951.jpnprd01.prod.outlook.com (2603:1096:404:c9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.31; Wed, 17 Feb 2021 11:02:20 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f%7]) with mapi id 15.20.3868.027; Wed, 17 Feb 2021 11:02:20 +0000 To: adrian@olddog.co.uk Cc: rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <042201d70519$5c357ed0$14a07c70$@olddog.co.uk> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <22a12842-2882-899a-d103-9375b5b8d40f@it.aoyama.ac.jp> Date: Wed, 17 Feb 2021 20:02:16 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <042201d70519$5c357ed0$14a07c70$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [223.217.46.174] X-ClientProxiedBy: TYCPR01CA0079.jpnprd01.prod.outlook.com (2603:1096:405:3::19) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.7] (223.217.46.174) by TYCPR01CA0079.jpnprd01.prod.outlook.com (2603:1096:405:3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Wed, 17 Feb 2021 11:02:20 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d0b60862-3992-4ff9-eff6-08d8d3337f0a X-MS-TrafficTypeDiagnostic: TYAPR01MB3951: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KrW9OA5GG88dI4bOohUMo65Se/RchpZZuyoyLuUDjXQanOlYb3tnperakHj2jxT94zoiCA3fLai6hqdQHq3R+pXK04BRltVb6M03BLxqoW5tEhI78WD7yR/Pgqu0HFRmoten7ul5KrC34iCVMTA5baYfI2dqB5M41cViLGPfIyXLww5XKV5ToJKV3ZdRUFd8u14fsPUQW9EmXxPbmPOOdzNFlmot646/h86IKQpLS9xtIq6+bdmV9H/gG1+Oede7XlLvD9HSxgtPMNDqQdC+59ll7yXlkvY1/QcXmPst6tGaGFq8kh49hViO8g8AL5JQM6NywqFuqj91U5Q5LbKwCl+KnIQ0sRCm/CmmmMUp/uHBPl+rQycewn/MyTkfhiuhIxXnzOT62xevKcOhrYpQIKmSeBH819aE+D3lvYpyiq2XMimzHwSn4Zjb8bCZGepKDIqif1CDhBIT29HiyefhTXJ3nRavtrZWoXP8wrpbKhom9hCxm7W9f3joXaHYxiBCI+zBdVZFacFsbQ3gJ7qVQwxNhNxRTgboqvTG1aVZcHSHOqTlWiT+Kaf5HXKYiWxiAgPCz+0V4OokHkWV7QaWRQrI93KEx8fPygFXmrgPUUM= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(39850400004)(376002)(366004)(83380400001)(16576012)(6486002)(786003)(6916009)(478600001)(86362001)(8676002)(31686004)(26005)(316002)(4326008)(53546011)(186003)(8936002)(52116002)(66946007)(66476007)(2906002)(66556008)(2616005)(31696002)(956004)(36916002)(5660300002)(6666004)(16526019)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ekNFQTI4MUlNM2o5VmdqZjZNK3JlL284cEhTajFMbzNrYUhYQVNFNmh6em5v?= =?utf-8?B?NTlyVFQ2cDBMVEwrMXIzaXpXUUY2NTd5Y2Vzaml6U3M0eDA4T1BpMmc5Z1Q3?= =?utf-8?B?VXpZVWpnbnZvL2k5VHhmaFNhRWVnWStPT3V4RVkxSUkzYjFITk0vbDkvMDd1?= =?utf-8?B?U2tNSUdMRUdkNWRnM2NBR3FiSk13UVFDc2dUaG5qWGwvYUNHSUxtbHlKeUpM?= =?utf-8?B?dms5WmllMzk4NStoRDN3cm82b3paOU1CdHlBa080VGdjV0FibkkxV2kzL2Z6?= =?utf-8?B?dkg1em5WUDRnTVY1N3JRMXpWS3Z5RXR6UkNvWUQxRGpuLzRPOWtXeXFkZlli?= =?utf-8?B?ZnFxMVVHTU00T2Y2S2pGNXVZL0kvTmJ2ZGxDZTVERTJXN2szV0hPY3NEZVpP?= =?utf-8?B?L3F2SXdVWXJhTzhTS2MxQ2tsbmJmUEVxclliei9BTXlhWHBKeFhTOGlkM1hR?= =?utf-8?B?ZjMrdnA4MFNQOFhZRG51dVRsb1VIL1Y5MGlIUVl5SThIVW5mZEo1aTJNSGhW?= =?utf-8?B?Z0JnY3NmemJISGxGMTQvWUE0OFVnWHNNbDBUa2kvTUJBNjgzMkd5ZVFIbmFU?= =?utf-8?B?N1RqMDAyb3FJakVoWUd3b2FWbm9Cd08xZnpxVzFyem9iRnY0bFcxUldFaEdk?= =?utf-8?B?V2p1bmpKeHdnUG5KcXZ4bGpNc3RMWFRYWnNDcW43V1RvZHFPREFnanVTRnVW?= =?utf-8?B?ZW8yMmtKbmZ3RDlvQ3lkcXFRQzVFYVc2SmZFdUJlRmdlbkRPdzVtOHFMN1pJ?= =?utf-8?B?dDlPdysxQ05nV1ltLzZHQ3hOUlVCVUhUQVJLL0QvTmtKSHJlMDhtTXFza053?= =?utf-8?B?VUxacWwrVVYvTVVVdXlRZ0hwWHBtclFkaWkrN1BXRzBMeGlpUDJxVEdaUGho?= =?utf-8?B?c1NjaHJCMzdzaGJqZDVBS3JHdi80ditsdlprdXlMd1YyWFF1OUUwQ1g4VjZh?= =?utf-8?B?ZUdtNUtTTmlZYS84REQvaDZKR25ZMXhpN0tEL2dmR2c3a0RCS0o1SVlYSTU2?= =?utf-8?B?RmhIWkY3MlZSQ0xwT3lqeFBEN01maWN2dDNua05QRlB4R1hhc1NhOVN3SmhB?= =?utf-8?B?RkRQUkExa3dnYURoK3E0UDBwL2tPWFNQNmthN1FQL0RZRWxwRysxSUQwWmlu?= =?utf-8?B?K0NKQllkdGxxUi9qbVRRbWc4c21rekFtT2twK2M0cDJLby9DRjE4TUd3RGNs?= =?utf-8?B?YXVRVk5EUFdJdHlyOGVlR045TjluekVkQ0FkYXd0enRBbmpEKzYvdi9EeEc0?= =?utf-8?B?dWliOWkzR3gzSG16NW9qZ1VrbUdzNWRMZDFnNUZ3UlMvbFJJcjJZY0ozTTRs?= =?utf-8?B?Y2VQZ3J5TWtuUGJSeUF1UnZuYlNicXVEcnZVUW5FZTA2RlZ6QlllM0ZzK0RV?= =?utf-8?B?VlFZaHhiMzZxL0QvNHZvUlZ3VlRSM1V0RVJoVVpMYXhDVjZOb0MwMEQrWmxR?= =?utf-8?B?YjVDYnlIZERGREtxcFVVa0wxWS9SVlJDTEd0dHk5RHVORmQwSDhSZGN0V2Jz?= =?utf-8?B?ZHh4VlNiYnlFSi9lNk1ybkt1c1Z2WHFIMnA3V3pzSVppdFp0R2RLSWhsWmhS?= =?utf-8?B?OFVpNmtaamNKb3RtcmNUV0ZvN2ZybElaQmVOSjVmOHZqNnU5NGg5cnFoOTJJ?= =?utf-8?B?SGR0Y0NHbDJZNURvblNPR0tnUUlPU0pIZkI4VjFxalVCQUdKNTZUREJYWTF4?= =?utf-8?B?QmQ5LzF2NDFqUVloRFpHYTk2TVFlK3hDZldLb2lGYzVnS3daZnFMVmhMS3F2?= =?utf-8?Q?Y12Kq32738hi9nnQ66xwTvpQX48vKicJYZnOsil?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: d0b60862-3992-4ff9-eff6-08d8d3337f0a X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2021 11:02:20.2535 (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: xnLvG1k1FWISh3WsMO9ppVDbUFtEXVimh6gIV+i/N4naSQEM1w/xg1bWLTdFqBIrDIhB0t6RDoDR4fCRjm8hrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3951 Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 11:02:24 -0000 Hello Adrian, Many thanks for your detailed answer. On 17/02/2021 19:40, Adrian Farrel wrote: > Thanks Martin, > > Again, I'm not in the business of fighting for the rights of straw men. They are unionised and can stand up for themselves (provided they have access to a broomstick). > > But just to explain my thinking... > >> Looks good to me, except for two points: >> >> - You still have the approval threshold at 1 YES. As others also have >> said, this is not appropriate for the topics at hand. > > I wonder what the benefit of setting the threshold higher is. > It would probably be benign to set it higher given the commentary on "no position" and "abstain" since the absence of a Discuss is otherwise a Yes. > But I don't see what we get by setting it higher. Perhaps I missed something. I still feel that changing RFC-related stuff with one Yes and the rest (four or five or even more) of the responsible board in one way or another not really engaged is just somehow fundamentally wrong. More details below. >> The 'abstain' should probably also go. >> (second point G, with some influence on point F) >> (In the IESG, it's okay that a draft be approved essentially on the >> responsibility of a single AD; it should never happen that we have >> something RFC-related approved and later, one AB member gets blamed >> for some outcome because all the others can say: I didn't vote >> yes on this on.) > > So many points 😊 > > - It may be popular in Western democracies to blame the people who voted for X, but we all know that the people who didn't vote are equally to blame. So I don't hold with this "blame" thing, and I don't think I've seen it on the IESG ever. Good to know. Was maybe the wrong way for me to explain my doubts. > - The IESG does not approve stuff on the responsibility of a single AD. Just not how it works. > > - That the IESG doesn't have many Yes ballots is a distressing but irrelevant issue in this context. > > - None of this is the point of an Abstain. I see two chief reasons: > - If the WG decides to have a proposal where the ISE is paid per RFC, I would expect > the ISE to object at first and then move to an Abstain. It would be highly inappropriate > to ballot Yes on the proposal. I think that cases such as this a) should be quite infrequent even among the already rather low expected number of overall documents, b) would better be handled by general abstention rules for which we don't really need a special category, and c) shouldn't happen to the extent that there's only one member left who can say YES (i.e. in cases like the above, I would find it doubly important that the board members not affected by the pay change would all or at least in a strong majority approve of the proposal). > - If a voting member feels "in their gut" that a proposal is a bad idea and can't be > convinced otherwise, they may still realise (either through discussion or through > the single Discuss resolution procedure) that they should not block the proposal. > It would be odd for them to say Yes in this situation. What else can they do to > "get out of the way"? I'm fine with this, as long as this is e.g. a single member, or a small minority if the number of members is higher. But if n-1 members have to get out of their way so that the single YES vote can move things forward, then for me, there's something fundamentally wrong. >> - Point G mentions consumers, but producers aren't mentioned anywhere. >> While it is fair to expect that we need more care to make sure we look >> out for the needs of consumers, I think producers should also be >> mentioned, at the very least for completeness. > > No objection to calling out "producers". In my mind a producer is also a consumer. Of course producers are also consumers. But we need to look out for their needs *as producers*, too, not only as consumers. Regards, Martin. > Adrian > From nobody Wed Feb 17 07:53:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DC23A1AF5 for ; Wed, 17 Feb 2021 07:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLjqnb-6MIZB for ; Wed, 17 Feb 2021 07:53:52 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5120D3A1B1D for ; Wed, 17 Feb 2021 07:53:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 87947300B8B for ; Wed, 17 Feb 2021 10:53:49 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pKICeQvEClnS for ; Wed, 17 Feb 2021 10:53:47 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 2ECE8300AEA; Wed, 17 Feb 2021 10:53:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> Date: Wed, 17 Feb 2021 10:53:48 -0500 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 15:53:55 -0000 The IAB charter (RFC 2850) makes me think that the IAB should handle = appeals. The ISOC BoT could be a second level for non-technical = concerns. Russ > On Feb 17, 2021, at 1:20 AM, Mark Nottingham wrote: >=20 > This looks good. >=20 > Regarding appeals -- perhaps we could make progress by listing = possible destinations for appeals and their positive/negative aspects. >=20 > To get us started: >=20 > * The IESG -- not a good idea; only the IETF. Already represented on = the approval group. > * The IAB -- Better than IESG in that it has a broader/long-term = function, but also represented on the approval group. > * Internet Society BoT (or Chair) -- has appropriate scope / distance; = relationship to Series is a bit fuzzy? >=20 > Any other candidates? >=20 > Cheers, >=20 >=20 >> On 17 Feb 2021, at 2:43 am, Adrian Farrel = wrote: >>=20 >> Hi, >>=20 >> As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H = persuaded me >> to take a second pass trying to factor in some of the comments on the = list. >>=20 >> I can't promise that I have captured *exactly* what everyone said, >> especially as some of the opinions were conflicting. What I have done = is try >> to move the text towards something that might be a compromise between = the >> positions. FWIW, I went back to the "Discuss" position because it = carries >> some implication that we are all going to try to get together and = resolve >> this. >>=20 >> I also tried to cut some of the waffle. I do tend to waffle. >>=20 >> There are two open points. I'd humbly suggest that the people who = raised >> these issues might try to throw some text at a solution.=20 >>=20 >> 1. At point C there is the concept of a "community last call". This = was >> raised by Martin and Russ, and I suggest that they put forward a = proposal. >> The challenge might be to find a way to identify and reach the = "community" >> (it's easy in the IETF, but very hard for "the world"). >>=20 >> 2. At point J there is the concept of "an appeal" in the case of = Discusses >> being unreconcilable. This was raised by Adam and Mark. The = challenge, as >> they noted, is working out to whom one appeals. >>=20 >> Hope this is useful (which is, after all, the only point). >>=20 >> Adrian >>=20 >> =3D=3D=3D=3D >>=20 >> Decision-making procedures >>=20 >> A. Development Cycle >> The WG is expected to show its work to the approval group and attempt = to be >> aware of issues that the approval group might be concerned about. >> The members of the approval group are expected to pay attention to = the work >> of the WG and speak up when they have concerns. >> The intention is early discovery of issues and avoidance of late = surprises. >>=20 >> B. WG last call >> The WG last calls its work following the model of an IETF WG. It is = assumed >> that all members of the approval group will participate the WG last = call, in >> an attempt to expose any of their concerns that still remain, and to = reach >> agreement.=20 >>=20 >> C. Community last call / public comment >> It is unclear whether this step (corresponding to IETF last call) = exists and >> how it would be operated. Further discussion needed per Martin and = Russ. >>=20 >> D. Participation by members of the approval group >> As noted in steps A and B, participation in WG work by members of the >> approval group is expected. >> It is understood that, from time to time, a member of the approval = group may >> find it impossible to participate in a particular discussion: in this = case, >> they are encourage to send delegates. >>=20 >> E. Discussion by the approval group >> The approval group shall discuss the output of the WG.=20 >> Such discussion is to take place normally within 2 weeks of the WG = making a >> request. >> The 2 week period may be stretched by holidays or IETF meetings, but = the WG >> must be notified if this is the case. >> All comments and concerns shall be documented to the WG which may = take them >> into consideration. >>=20 >> F. Approval by the approval group >> The voting members of the approval group shall formally ballot by the = end of >> the discussion period in E. >> Each voting member may ballot one of: >> - Yes: Means "I support this work." A Yes ballot may be accompanied = by >> comments indicating thoughts and issues that should be looked at, but = are >> non-blocking.=20 >> - Discuss: Means "I have a serious concern that I would like to = Discuss >> before this work can proceed." Voting members are expected to = actively >> engage in resolving their Discuss positions. >> - No Position: Only used in exceptional cases such as illness or long >> vacation. Voting members are expected to try to present a different = ballot >> position. >> - Abstain: Means "I have a serious concern, but recognise that it = will not >> be resolved." An Abstain ballot is a way for a voting member to get = out of >> the way of progress even though it worries them. The existence of an = Abstain >> ballot does not imply the work is flawed, but indicates a genuinely >> irreconcilable difference of opinion. >> - Recuse: Means "It would be improper for me to have a position." For >> example, if the proposal was to remunerate the voting member. >>=20 >> G. Reasons for a Discuss >> The approval group shall maintain a list of reasons for a Discuss = ballot. A >> Discuss that does not conform to one of these reasons shall not be = valid, >> and must be re-balloted. >> An initial draft of this list is as follows: >> - The proposal would cause significant harm to one of the streams >> - The proposal would cause significant harm to the series >> - The proposal would cause inconvenience to a group of consumers, the >> benefit of the change does not outweigh the cost of the = inconvenience, and >> that inconvenience could be overcome by using a different approach >>=20 >> G. Work proceeds if... >> At the end of the discussion period (point E) or at any later time, = there is >> at least one "Yes" and no "Discuss" ballot. That is, work fails to = proceed >> unless it has approval. >>=20 >> H. Resolution of Discusses >> A voting member who ballots Discuss shall explain their concerns to = the WG >> and shall engage in discussions attempting to resolve the concerns = and >> arrive at a compromise or other agreement. >> When such agreement is reached, the voting member should transition = their >> ballot to a "Yes". >> A voting member may transition their ballot to an "Abstain" at any = time, >> although all parties are encouraged to attempt to reach agreement. >>=20 >> I. Single Discuss resolution >> In the event of there being exactly one Discuss ballot, and there = being no >> timely progress to agreement between the WG and the member of the = approval >> group who issued the ballot, the WG may request that the approval = group >> exercise an exception resolution process as follows: >> - The approval group will discuss the concern giving rise to the = ballot and >> any proposed resolution from the WG >> - The approval group shall attempt to reach consensus on whether to = sustain >> the Discuss or to release the work, but failing that shall vote with = a >> simple majority determining the outcome >> - If the Discuss is sustained, return to step H >> - If the work is released, the Discuss ballot shall be changed to an = Abstain >> and the work shall progress >>=20 >> J. Appeals >> In the event that more than one Discuss cannot be resolved or that a = single >> Discuss is sustained by the approval group, there is a right of = appeal. >> The details of this need to be worked out per Adam and Mark. >>=20 >>=20 >>=20 >> --=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 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Feb 17 08:28:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE443A1B57 for ; Wed, 17 Feb 2021 08:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoAfiN8mSXPB for ; Wed, 17 Feb 2021 08:28:49 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B88F3A0C2A for ; Wed, 17 Feb 2021 08:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9911; q=dns/txt; s=iport; t=1613579329; x=1614788929; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Uc0v+MQwyp2ndReltgIDIJptkRxlZrVSZHIdPO/LxoU=; b=cjJ4VRmtflC597vQhWjq1BgCwIcVdaP8SPrD81q9rARkfxfAFIlWxJK2 lgy9uo3mDFxxkRaKt3BVLciCSOnBkRHRwWG1tODyEqOnKP2fmkZKHe6BQ 6QnKequDttALm2x6cT+ZVffqQErT6Nxj/8ao+o786kxEmJMWmZ42UF1Cc E=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BSAADlQi1gjBbLJq1YChoBAQEBAQEBAQEBAwEBAQESA?= =?us-ascii?q?QEBAQICAQEBAYIPgXyBJVYBJxIxhEGJBIhOA5xHBAcBAQEKAwEBHQsMBAEBh?= =?us-ascii?q?E0CggwmOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBhjoNhkQBAQEDAQEBI?= =?us-ascii?q?UQHBAcFCwsYKgICJzAGExQHggVLAYJmIA+vQ3aBMoVYhHsKBoE4gVOLbUKCA?= =?us-ascii?q?oERJwwQglc+gl0BgTODQzSCKwSBZloGAWcXLBAUDQE5AjQPKwERByMqGimHZ?= =?us-ascii?q?oNPhFIOjDycSoMFgy2BOpEHhiADH6MxjjWjTkaDcwIEBgUCFoFrIYFZMxoIG?= =?us-ascii?q?xU7KgGCPj4SGQ2OKw0JgQEBDYcXO4VGQAMvNwIGAQkBAQMJizVeAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,184,1610409600"; d="asc'?scan'208";a="33459702" 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; 17 Feb 2021 16:28:44 +0000 Received: from ams3-vpn-dhcp722.cisco.com (ams3-vpn-dhcp722.cisco.com [10.61.66.210]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 11HGSh7X025390 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2021 16:28:44 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_005A7402-DF73-45AF-8764-9CA81DF918FB"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 17 Feb 2021 17:28:43 +0100 In-Reply-To: Cc: Mark Nottingham , rfced-future@iab.org To: Russ Housley References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.66.210, ams3-vpn-dhcp722.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 16:28:51 -0000 --Apple-Mail=_005A7402-DF73-45AF-8764-9CA81DF918FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Well, that=E2=80=99s a question: What is the likely nature of the appeal? If it is a question of whether = or not the DISCUSSes are permitted, that seems pretty close to = technical. Will this change harm the series? Will this change harm the = stream? Who gets to second guess on that? Anyone? Or are we talking = about process appeals a=E2=80=99la were A-G properly followed? Eliot > On 17 Feb 2021, at 16:53, Russ Housley wrote: >=20 > The IAB charter (RFC 2850) makes me think that the IAB should handle = appeals. The ISOC BoT could be a second level for non-technical = concerns. >=20 > Russ >=20 >=20 >> On Feb 17, 2021, at 1:20 AM, Mark Nottingham wrote: >>=20 >> This looks good. >>=20 >> Regarding appeals -- perhaps we could make progress by listing = possible destinations for appeals and their positive/negative aspects. >>=20 >> To get us started: >>=20 >> * The IESG -- not a good idea; only the IETF. Already represented on = the approval group. >> * The IAB -- Better than IESG in that it has a broader/long-term = function, but also represented on the approval group. >> * Internet Society BoT (or Chair) -- has appropriate scope / = distance; relationship to Series is a bit fuzzy? >>=20 >> Any other candidates? >>=20 >> Cheers, >>=20 >>=20 >>> On 17 Feb 2021, at 2:43 am, Adrian Farrel = wrote: >>>=20 >>> Hi, >>>=20 >>> As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H = persuaded me >>> to take a second pass trying to factor in some of the comments on = the list. >>>=20 >>> I can't promise that I have captured *exactly* what everyone said, >>> especially as some of the opinions were conflicting. What I have = done is try >>> to move the text towards something that might be a compromise = between the >>> positions. FWIW, I went back to the "Discuss" position because it = carries >>> some implication that we are all going to try to get together and = resolve >>> this. >>>=20 >>> I also tried to cut some of the waffle. I do tend to waffle. >>>=20 >>> There are two open points. I'd humbly suggest that the people who = raised >>> these issues might try to throw some text at a solution. >>>=20 >>> 1. At point C there is the concept of a "community last call". This = was >>> raised by Martin and Russ, and I suggest that they put forward a = proposal. >>> The challenge might be to find a way to identify and reach the = "community" >>> (it's easy in the IETF, but very hard for "the world"). >>>=20 >>> 2. At point J there is the concept of "an appeal" in the case of = Discusses >>> being unreconcilable. This was raised by Adam and Mark. The = challenge, as >>> they noted, is working out to whom one appeals. >>>=20 >>> Hope this is useful (which is, after all, the only point). >>>=20 >>> Adrian >>>=20 >>> =3D=3D=3D=3D >>>=20 >>> Decision-making procedures >>>=20 >>> A. Development Cycle >>> The WG is expected to show its work to the approval group and = attempt to be >>> aware of issues that the approval group might be concerned about. >>> The members of the approval group are expected to pay attention to = the work >>> of the WG and speak up when they have concerns. >>> The intention is early discovery of issues and avoidance of late = surprises. >>>=20 >>> B. WG last call >>> The WG last calls its work following the model of an IETF WG. It is = assumed >>> that all members of the approval group will participate the WG last = call, in >>> an attempt to expose any of their concerns that still remain, and to = reach >>> agreement. >>>=20 >>> C. Community last call / public comment >>> It is unclear whether this step (corresponding to IETF last call) = exists and >>> how it would be operated. Further discussion needed per Martin and = Russ. >>>=20 >>> D. Participation by members of the approval group >>> As noted in steps A and B, participation in WG work by members of = the >>> approval group is expected. >>> It is understood that, from time to time, a member of the approval = group may >>> find it impossible to participate in a particular discussion: in = this case, >>> they are encourage to send delegates. >>>=20 >>> E. Discussion by the approval group >>> The approval group shall discuss the output of the WG. >>> Such discussion is to take place normally within 2 weeks of the WG = making a >>> request. >>> The 2 week period may be stretched by holidays or IETF meetings, but = the WG >>> must be notified if this is the case. >>> All comments and concerns shall be documented to the WG which may = take them >>> into consideration. >>>=20 >>> F. Approval by the approval group >>> The voting members of the approval group shall formally ballot by = the end of >>> the discussion period in E. >>> Each voting member may ballot one of: >>> - Yes: Means "I support this work." A Yes ballot may be accompanied = by >>> comments indicating thoughts and issues that should be looked at, = but are >>> non-blocking. >>> - Discuss: Means "I have a serious concern that I would like to = Discuss >>> before this work can proceed." Voting members are expected to = actively >>> engage in resolving their Discuss positions. >>> - No Position: Only used in exceptional cases such as illness or = long >>> vacation. Voting members are expected to try to present a different = ballot >>> position. >>> - Abstain: Means "I have a serious concern, but recognise that it = will not >>> be resolved." An Abstain ballot is a way for a voting member to get = out of >>> the way of progress even though it worries them. The existence of an = Abstain >>> ballot does not imply the work is flawed, but indicates a genuinely >>> irreconcilable difference of opinion. >>> - Recuse: Means "It would be improper for me to have a position." = For >>> example, if the proposal was to remunerate the voting member. >>>=20 >>> G. Reasons for a Discuss >>> The approval group shall maintain a list of reasons for a Discuss = ballot. A >>> Discuss that does not conform to one of these reasons shall not be = valid, >>> and must be re-balloted. >>> An initial draft of this list is as follows: >>> - The proposal would cause significant harm to one of the streams >>> - The proposal would cause significant harm to the series >>> - The proposal would cause inconvenience to a group of consumers, = the >>> benefit of the change does not outweigh the cost of the = inconvenience, and >>> that inconvenience could be overcome by using a different approach >>>=20 >>> G. Work proceeds if... >>> At the end of the discussion period (point E) or at any later time, = there is >>> at least one "Yes" and no "Discuss" ballot. That is, work fails to = proceed >>> unless it has approval. >>>=20 >>> H. Resolution of Discusses >>> A voting member who ballots Discuss shall explain their concerns to = the WG >>> and shall engage in discussions attempting to resolve the concerns = and >>> arrive at a compromise or other agreement. >>> When such agreement is reached, the voting member should transition = their >>> ballot to a "Yes". >>> A voting member may transition their ballot to an "Abstain" at any = time, >>> although all parties are encouraged to attempt to reach agreement. >>>=20 >>> I. Single Discuss resolution >>> In the event of there being exactly one Discuss ballot, and there = being no >>> timely progress to agreement between the WG and the member of the = approval >>> group who issued the ballot, the WG may request that the approval = group >>> exercise an exception resolution process as follows: >>> - The approval group will discuss the concern giving rise to the = ballot and >>> any proposed resolution from the WG >>> - The approval group shall attempt to reach consensus on whether to = sustain >>> the Discuss or to release the work, but failing that shall vote with = a >>> simple majority determining the outcome >>> - If the Discuss is sustained, return to step H >>> - If the work is released, the Discuss ballot shall be changed to an = Abstain >>> and the work shall progress >>>=20 >>> J. Appeals >>> In the event that more than one Discuss cannot be resolved or that a = single >>> Discuss is sustained by the approval group, there is a right of = appeal. >>> The details of this need to be worked out per Adam and Mark. >>>=20 >>>=20 >>>=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 >> -- >> 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 --Apple-Mail=_005A7402-DF73-45AF-8764-9CA81DF918FB 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAtRDsACgkQh7ZrRtnS ejOvgwf/REB2xVnUF+JmNdt7re+0Xe5B4kIKpVEToiS8JGb2KkcIS/VbR5EvO/QI RfwsYedixiSb3AUilqHm3HtT+qTnCq6UIQrPpN8d40dHs4UfFlygpe036is7jusk hGyhBiO5HszOcox2xg+4xoCfFlwumYzOXdhIMguyMM64Wl4gRvaEiPPLF90NR8nA LcPgwlBau09y+NyvcSQdgj+vFzqC9QBRPOiE3raNxhWa/z3+6G43AAfDoB+VSwNg +GoPaXTo968t5RIm1s/Hxo13vkObvqquhRQaNT+64d0SJV5eifqSlcl9NrDUmQnf hdvKOYXlINjMMOWfyKdytVgEf7Kt3A== =8g1T -----END PGP SIGNATURE----- --Apple-Mail=_005A7402-DF73-45AF-8764-9CA81DF918FB-- From nobody Wed Feb 17 08:35:22 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508383A1B6B for ; Wed, 17 Feb 2021 08:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR5m3l4IKwDN for ; Wed, 17 Feb 2021 08:35:20 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81BE3A1B6E for ; Wed, 17 Feb 2021 08:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1645; q=dns/txt; s=iport; t=1613579719; x=1614789319; h=from:mime-version:subject:message-id:date:to; bh=i5ZwRM3eXaM4fcTOt7pOOqfkMU3R2pIeW6S4ioO/zmE=; b=X/gcqr9XG7x7dytdTbdG4b5UU0GcqFGDajvRc7rH997iy8XUsSsWQndL 8NXb8N58Z31PW03odNJyMjR4wouKGU+qjusFMLf9y248K91tb98ZxRFhP 3cA7MEw7SLxdBMy+CvMixCmLwzl7fE9x7XkafKzFws6h5ObT/Q7ByEZHs k=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0D9BAACRS1g/xbLJq1iHgEBCxIMggQLg3cBJxKEcokEo?= =?us-ascii?q?x2BfAQHAQEBCgMBATQEAQGGWyY2Bw4CAwEBAQMCAwEBAQEFAQEBAgEGBHGFb?= =?us-ascii?q?oZugTMCg10BgwahGo4cdoEyikgQgTiBU4wvggKBOByIIIJJNIIrBIUSTJ1on?= =?us-ascii?q?EqDBYMtgTqXJwMfgx+gErFrXoNzAgQGBQIWgVsCMYFXMxoIGxVlAYI/PRIZD?= =?us-ascii?q?ZxoQANmAgYBCQEBAwmMEwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,184,1610409600"; d="asc'?scan'208";a="31088204" 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; 17 Feb 2021 16:35:15 +0000 Received: from ams3-vpn-dhcp722.cisco.com (ams3-vpn-dhcp722.cisco.com [10.61.66.210]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 11HGZFXA027250 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 17 Feb 2021 16:35:15 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_F8FA1AAC-8B41-4A4E-90C6-F536381BD374"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <5FC62D6B-0A6D-4DFB-A07F-704D23452397@cisco.com> Date: Wed, 17 Feb 2021 17:35:14 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.66.210, ams3-vpn-dhcp722.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Tomorrow's agenda X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 16:35:21 -0000 --Apple-Mail=_F8FA1AAC-8B41-4A4E-90C6-F536381BD374 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, As a co-chair, I=E2=80=99m really encouraged by the response to = Adrian=E2=80=99s proposal. Thanks to Adrian and to everyone for finding = common ground. Seems to me that he has pretty much written our agenda = for us. My proposal is that we discuss his proposal and see if we can = fill in the gaps a bit. I also think there=E2=80=99s an open question hanging out there about = the role of the RSE in all of this. My suggestion is that we keep that = in context as we go through this. For us to succeed, there is still a = need for people to show give and take on all sides. But I am hopeful we = will find yet more common ground in discussions. Eliot --Apple-Mail=_F8FA1AAC-8B41-4A4E-90C6-F536381BD374 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAtRcIACgkQh7ZrRtnS ejPIwgf/ZI/4DOYWgAVLVogwkhtWuF0usCauJZeNw4UPKxYTyWSzkkbsqfbuQpXB 3yAyX3tvFCccR0lhbrqWtlSHc9U9PlgQk95CTnES3NF9xo7YYpwbFSMO9CFKNNCl ER+3tK2G2TyAphrcvkxeqfuHDozgwJgs9r4RgyKRou9IAFeWp35PUGIMCoWs59k7 u+REoK030sgA73lj0GwKT53j13p7DAsc1j1T0nbK4xxfVEXOU7Rb0trDaBeGZci3 XgITzq10lw8+C5w81rY/V5e+V5XfMvJzt0cP6vY+U3+h/sDYw428UVn6QJ0rQw8u hKjCWOhWA0+TyBlIyrmPbXygDJbISQ== =uzkv -----END PGP SIGNATURE----- --Apple-Mail=_F8FA1AAC-8B41-4A4E-90C6-F536381BD374-- From nobody Wed Feb 17 11:47:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6C3A0E65 for ; Wed, 17 Feb 2021 11:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p5uhWYlqybU for ; Wed, 17 Feb 2021 11:47:46 -0800 (PST) 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 F23293A1CE8 for ; Wed, 17 Feb 2021 11:47:45 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id b8so7969994plh.12 for ; Wed, 17 Feb 2021 11:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=foOxuzHd3glQYeIWJDyD431ElU3280NGwvFooi/XEHo=; b=ZzNm7SeDfVl7IyUUCygbawTYottofzNgdzltcL51H0dHUD+glIEZIke9rDY2+cDUpT ONxJOtHZr2RT+mPJw75G78no6WaDbtJLUo62TQjYF2A0gsJoTwXk3wGDMeoEbiOytWeq reQ4xxySStTF4QSwd4IU5Vx1GOk31+cofKBRVgeJCZq754Rw0rMIZh/7SgNqdquuYt7B 1l8tQxmmsLbidD2ptC0Js7Kd5Y+SlhSIzdA+pmNxmNrE2wGw4wAiQH6BkxlychyIGRL0 aWoLiBZkugdl2brBUdSJtZ0RnhcOlF1Ant3muD6ZGRon5DIEwjUmwUgs4O48SuCagAus hQEQ== 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=foOxuzHd3glQYeIWJDyD431ElU3280NGwvFooi/XEHo=; b=N68d0JK1EBNALw7fiMLnQTRrL7VE6/0almfaK9EwN8kSr3ZfzI4jjNqvn5QwQTtZj/ 9UFp0RRb0Rc4OmnTu/DFH9hQvROj2zqnb3QeAjtXZVSQ1SQ7mmy0SJEFrTEyXlZoEqZd SXeL7YyR1LxFboykb8In4xJ3Ww1/ElPk/mzhsYyx4ni/n/qWXU8EgpoP6A1U+vUUGX7o qBBetPr5cNPn4q2oKv8AOWy+SktRuL4MDURZXlQeFWP62s9idmG4EkvpagafXqoYG9cT oypume3nD5sBlCK2JavVnsht/WMbIs4Z85Qx1McgfjPe8BKKt9RkcIoq6uhUzlGTryyl d1wQ== X-Gm-Message-State: AOAM530dog2AsQxFdpngm6slWyu37AIGY+skgHkIsA5kOPn+FtIWTzPV LtgSPCm4YL2yPAHWqAS2TZceKqwDPwib9Q== X-Google-Smtp-Source: ABdhPJyDWa4PxsctFhQuo5LJEEdRJWVyB8HLyyBrWybBM7rN7f2zGnitW6r02OP/uYh2yb2zI1DFhg== X-Received: by 2002:a17:90a:bd84:: with SMTP id z4mr381598pjr.179.1613591264675; Wed, 17 Feb 2021 11:47:44 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id fz24sm2995529pjb.35.2021.02.17.11.47.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2021 11:47:44 -0800 (PST) To: rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> From: Brian E Carpenter Message-ID: Date: Thu, 18 Feb 2021 08:47:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 19:47:48 -0000 On 18-Feb-21 05:28, Eliot Lear wrote: > Well, that=E2=80=99s a question: >=20 > What is the likely nature of the appeal? If it is a question of whethe= r or not the DISCUSSes are permitted, that seems pretty close to technica= l. Will this change harm the series? Will this change harm the stream? = Who gets to second guess on that? Anyone? Or are we talking about proc= ess appeals a=E2=80=99la were A-G properly followed? In the IETF process, the IAB's appeal role is limited by: "is final with respect to the question of whether or not the [Internet standards] procedures have been followed and with respect to all questions of technical merit." and the ISOC Board's role is limited by: "only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open [Internet Standards] Process." It seems to me we could wordsmith equivalent limits for this case, basically by removing the words in brackets, as long as the IAB and ISOC Board's roles are carefully limited. (I also believe that at the end of all this, the IAB Charter will need a little tweak, but that can be left aside for now.) Regards Brian C >=20 > Eliot >=20 >=20 >> On 17 Feb 2021, at 16:53, Russ Housley wrote: >> >> The IAB charter (RFC 2850) makes me think that the IAB should handle a= ppeals. The ISOC BoT could be a second level for non-technical concerns.= >> >> Russ >> >> >>> On Feb 17, 2021, at 1:20 AM, Mark Nottingham wrote: >>> >>> This looks good. >>> >>> Regarding appeals -- perhaps we could make progress by listing possib= le destinations for appeals and their positive/negative aspects. >>> >>> To get us started: >>> >>> * The IESG -- not a good idea; only the IETF. Already represented on = the approval group. >>> * The IAB -- Better than IESG in that it has a broader/long-term func= tion, but also represented on the approval group. >>> * Internet Society BoT (or Chair) -- has appropriate scope / distance= ; relationship to Series is a bit fuzzy? >>> >>> Any other candidates? >>> >>> Cheers, >>> >>> >>>> On 17 Feb 2021, at 2:43 am, Adrian Farrel wrot= e: >>>> >>>> Hi, >>>> >>>> As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H persua= ded me >>>> to take a second pass trying to factor in some of the comments on th= e list. >>>> >>>> I can't promise that I have captured *exactly* what everyone said, >>>> especially as some of the opinions were conflicting. What I have don= e is try >>>> to move the text towards something that might be a compromise betwee= n the >>>> positions. FWIW, I went back to the "Discuss" position because it ca= rries >>>> some implication that we are all going to try to get together and re= solve >>>> this. >>>> >>>> I also tried to cut some of the waffle. I do tend to waffle. >>>> >>>> There are two open points. I'd humbly suggest that the people who ra= ised >>>> these issues might try to throw some text at a solution. >>>> >>>> 1. At point C there is the concept of a "community last call". This = was >>>> raised by Martin and Russ, and I suggest that they put forward a pro= posal. >>>> The challenge might be to find a way to identify and reach the "comm= unity" >>>> (it's easy in the IETF, but very hard for "the world"). >>>> >>>> 2. At point J there is the concept of "an appeal" in the case of Dis= cusses >>>> being unreconcilable. This was raised by Adam and Mark. The challeng= e, as >>>> they noted, is working out to whom one appeals. >>>> >>>> Hope this is useful (which is, after all, the only point). >>>> >>>> Adrian >>>> >>>> =3D=3D=3D=3D >>>> >>>> Decision-making procedures >>>> >>>> A. Development Cycle >>>> The WG is expected to show its work to the approval group and attemp= t to be >>>> aware of issues that the approval group might be concerned about. >>>> The members of the approval group are expected to pay attention to t= he work >>>> of the WG and speak up when they have concerns. >>>> The intention is early discovery of issues and avoidance of late sur= prises. >>>> >>>> B. WG last call >>>> The WG last calls its work following the model of an IETF WG. It is = assumed >>>> that all members of the approval group will participate the WG last = call, in >>>> an attempt to expose any of their concerns that still remain, and to= reach >>>> agreement. >>>> >>>> C. Community last call / public comment >>>> It is unclear whether this step (corresponding to IETF last call) ex= ists and >>>> how it would be operated. Further discussion needed per Martin and R= uss. >>>> >>>> D. Participation by members of the approval group >>>> As noted in steps A and B, participation in WG work by members of th= e >>>> approval group is expected. >>>> It is understood that, from time to time, a member of the approval g= roup may >>>> find it impossible to participate in a particular discussion: in thi= s case, >>>> they are encourage to send delegates. >>>> >>>> E. Discussion by the approval group >>>> The approval group shall discuss the output of the WG. >>>> Such discussion is to take place normally within 2 weeks of the WG m= aking a >>>> request. >>>> The 2 week period may be stretched by holidays or IETF meetings, but= the WG >>>> must be notified if this is the case. >>>> All comments and concerns shall be documented to the WG which may ta= ke them >>>> into consideration. >>>> >>>> F. Approval by the approval group >>>> The voting members of the approval group shall formally ballot by th= e end of >>>> the discussion period in E. >>>> Each voting member may ballot one of: >>>> - Yes: Means "I support this work." A Yes ballot may be accompanied = by >>>> comments indicating thoughts and issues that should be looked at, bu= t are >>>> non-blocking. >>>> - Discuss: Means "I have a serious concern that I would like to Disc= uss >>>> before this work can proceed." Voting members are expected to active= ly >>>> engage in resolving their Discuss positions. >>>> - No Position: Only used in exceptional cases such as illness or lon= g >>>> vacation. Voting members are expected to try to present a different = ballot >>>> position. >>>> - Abstain: Means "I have a serious concern, but recognise that it wi= ll not >>>> be resolved." An Abstain ballot is a way for a voting member to get = out of >>>> the way of progress even though it worries them. The existence of an= Abstain >>>> ballot does not imply the work is flawed, but indicates a genuinely >>>> irreconcilable difference of opinion. >>>> - Recuse: Means "It would be improper for me to have a position." Fo= r >>>> example, if the proposal was to remunerate the voting member. >>>> >>>> G. Reasons for a Discuss >>>> The approval group shall maintain a list of reasons for a Discuss ba= llot. A >>>> Discuss that does not conform to one of these reasons shall not be v= alid, >>>> and must be re-balloted. >>>> An initial draft of this list is as follows: >>>> - The proposal would cause significant harm to one of the streams >>>> - The proposal would cause significant harm to the series >>>> - The proposal would cause inconvenience to a group of consumers, th= e >>>> benefit of the change does not outweigh the cost of the inconvenienc= e, and >>>> that inconvenience could be overcome by using a different approach >>>> >>>> G. Work proceeds if... >>>> At the end of the discussion period (point E) or at any later time, = there is >>>> at least one "Yes" and no "Discuss" ballot. That is, work fails to p= roceed >>>> unless it has approval. >>>> >>>> H. Resolution of Discusses >>>> A voting member who ballots Discuss shall explain their concerns to = the WG >>>> and shall engage in discussions attempting to resolve the concerns a= nd >>>> arrive at a compromise or other agreement. >>>> When such agreement is reached, the voting member should transition = their >>>> ballot to a "Yes". >>>> A voting member may transition their ballot to an "Abstain" at any t= ime, >>>> although all parties are encouraged to attempt to reach agreement. >>>> >>>> I. Single Discuss resolution >>>> In the event of there being exactly one Discuss ballot, and there be= ing no >>>> timely progress to agreement between the WG and the member of the ap= proval >>>> group who issued the ballot, the WG may request that the approval gr= oup >>>> exercise an exception resolution process as follows: >>>> - The approval group will discuss the concern giving rise to the bal= lot and >>>> any proposed resolution from the WG >>>> - The approval group shall attempt to reach consensus on whether to = sustain >>>> the Discuss or to release the work, but failing that shall vote with= a >>>> simple majority determining the outcome >>>> - If the Discuss is sustained, return to step H >>>> - If the work is released, the Discuss ballot shall be changed to an= Abstain >>>> and the work shall progress >>>> >>>> J. Appeals >>>> In the event that more than one Discuss cannot be resolved or that a= single >>>> Discuss is sustained by the approval group, there is a right of appe= al. >>>> The details of this need to be worked out per Adam and Mark. >>>> >>>> >>>> >>>> -- >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Wed Feb 17 12:43:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E633A1D27 for ; Wed, 17 Feb 2021 12:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arZAQF020Hon for ; Wed, 17 Feb 2021 12:43:33 -0800 (PST) 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 B365F3A1E03 for ; Wed, 17 Feb 2021 12:43:23 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id e9so6965746qvy.3 for ; Wed, 17 Feb 2021 12:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=sz2IW/BbeywpRcExpm5JTBqXX/WKQIeXoJPo9ITxosY=; b=F4+d1BZ0kKTASLByUc6o9w62VoBQG3wxfCvZvDdPlX7v5DKK2VEmNJAj8hfMHICpao 5euu2zbyt9uz0lvbDWEaX2tRhf9dvPQue1X6/aQ1RFFgOwb89yY8IUgdxGTjjDvefgSo f4slPxDuLRQ+vGVRgIbitZNzyLUTn6JnJescAakrJkv+fy0TFwSJ+6OIMU7wU3tpnxVz YS97Xl7hn6JqbCJh6xHj6zgc96T2eNMvNteXpU+afSXYMNnnqn4zDIDUvLhzoxPjcf4P WIXhu4XXNAMTlqcLW0dek/gbRV1Rt0sb51HmqPgW2v+pL6Xe+8JZ8N5uAuJ3FPc6gdct E+/w== 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=sz2IW/BbeywpRcExpm5JTBqXX/WKQIeXoJPo9ITxosY=; b=PdqRns3IZ3zT+eBEo94EJfFqboL2eC5MwV5M1lKfF4jrukKh580IdL2JoLuK2L+gXj YjWw57sxu/ZymQfOeSWP6YWVA4YJlV43VdfcBlFlPeTiOoTt4xUdDc1WGjBt1mSiSnTn Aj5YucJkMLs0XONN2GokPtSODMP1E/wbvWIzYJEHgSpVDVQr6jwwz/KnV67oPvtWYRHP um49wvZO+kAoMDRhJ2gVkz62bff69ogFihpcb8bvo6yLjkxMenKE92IeD8LcDBGE0ETA HW1q0HssjlgP0L5zIonjhv2Bnh0fRHbiS7K6Reos//i5cm723VNDjzRzLrZl+duV4e55 vTtA== X-Gm-Message-State: AOAM533raHyFNr2qlPGbPLQfXJlRxebBz4lmz9J5eN8RyCX5JlH/4JiF YBOvwnZDUUJJGnOnU4rN3JFa0UDg6FXdN1ty X-Google-Smtp-Source: ABdhPJwC+WNF+IEU09NBcAnvx6slOhGyjVQdm6hytIkcHU8MuwwpL04V75zP5uD6z+DLmyo9vycJzA== X-Received: by 2002:a05:6214:9b2:: with SMTP id du18mr912298qvb.15.1613594601810; Wed, 17 Feb 2021 12:43:21 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id s130sm2498922qka.10.2021.02.17.12.43.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Feb 2021 12:43:21 -0800 (PST) To: rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> From: Michael StJohns Message-ID: <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> Date: Wed, 17 Feb 2021 15:43:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 20:43:35 -0000 On 2/17/2021 11:28 AM, Eliot Lear wrote: > Well, that’s a question: > > What is the likely nature of the appeal? If it is a question of whether or not the DISCUSSes are permitted, that seems pretty close to technical. Will this change harm the series? Will this change harm the stream? Who gets to second guess on that? Anyone? Or are we talking about process appeals a’la were A-G properly followed? > > Eliot > Very good question.  We do need to avoid a turtles all the way down type of problem though. Maybe we do this slightly differently - have the bodies that send the AB members be able to override the vote of their AB member(s) through a majority vote of their own?  That would cover 4 of the votes on the AB. The request to override would take the form of an appeal and each body would use its own procedures to discuss the request and then vote.  The RSE wouldn't get a vote, but any Nomcom selected members would (Nomcom does not direct their vote).   Majority of those voting (including the directed votes by the sending bodies) will override the decision no matter how bad it might be for the series. Mostly, I think there's not going to be a lot of output where a traditional appeal makes sense which makes the normal "who resolves the appeals" process kind of an iffy fit. Mike From nobody Wed Feb 17 14:01:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE69A3A1DA2 for ; Wed, 17 Feb 2021 14:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=hnLsR+9G; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nKMSdim7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMWHSCSoyhz2 for ; Wed, 17 Feb 2021 14:01:16 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9BC3A136A for ; Wed, 17 Feb 2021 14:01:16 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E77647DC for ; Wed, 17 Feb 2021 17:01:15 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 17 Feb 2021 17:01:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=3GsbW UsSIbcHF6uw2qx/6/40lFjPCvgAQ4Q1TUjLoWI=; b=hnLsR+9GGpAjw9H0jNxQH nd0XmUL9iNWSbSUizfhgElmIYGr5PWlfF3H9pU4MbQMIpsVBAA576w1EfjZ4EWvE rYBDLmFjs0tgSljLyJA7DpkwTpiuocA9edag/8VS/NFhIyxkX6XS/nTfpTkhWNXm yQZo+K7BegHvEPaWOen5qwiXawzBm4K9GuEzpsXZdYptycfY/aKlkHcJPaPUrfP3 djof9KNjEuOcfosWVLihmQVv7IoVjgwbToCJ5RJgbQ5LfANWEqsZJZDSBOnKTf5w oV2MeD7s7S3F8zgwo7Mmq4avtLtSDSB2P9nsMb59p0iBowxzYxLIjieY1rFXUXI5 Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=3GsbWUsSIbcHF6uw2qx/6/40lFjPCvgAQ4Q1TUjLo WI=; b=nKMSdim7++FQ0rrKMPkSVvY0YegUjh4S/fl+A7iew952VZ3jV5b5EK1jm WE4pjdsCVoAREZTVq6/D0ndyrY5McoTWBa95x+ENLUebYk9yPF7MDFPzDZuzViuD 7d/IY1QTDfV8lGXVoq04IBpBOjolijp/6CyIgCUdQRNDx5zj4Dbk50MUq1BSd4Co wpoWqEByLwZc5Ls815u5i6OCwKlcmr7z0Rygu/ahjOLDu8dalyxMk20nnwMMd0a1 oKzAsayY4NE6sJLro1212xtmFekxYuLUg/BLtRRRPHbE9rB+Dz6z22EcPuwNUav2 zYVJoc31X3A3uWpTPymr63+Am0p3g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrjedvgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfejueduieffledtge elheejvdettdejudduhefggeefgfekgfeuieetgefftddtnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD0494E0080; Wed, 17 Feb 2021 17:01:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <648d55f2-9cbe-4565-9939-22c61a90c63e@www.fastmail.com> In-Reply-To: <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> Date: Thu, 18 Feb 2021 09:00:55 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 22:01:19 -0000 On Thu, Feb 18, 2021, at 07:43, Michael StJohns wrote: > Maybe we do this slightly differently - have the bodies that send the = AB=20 > members be able to override the vote of their AB member(s) through a=20= > majority vote of their own?=C2=A0=20 So if I think that the IESG representative represented incorrectly, I co= uld take that up with the IESG? That sounds like it could work. There = isn't similar recourse for the ISE, but I think that is entirely consist= ent with the nature of that position. From nobody Wed Feb 17 15:48:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD543A1E3F for ; Wed, 17 Feb 2021 15:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Z4vQeNwDq8 for ; Wed, 17 Feb 2021 15:48:27 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA14D3A1E3D for ; Wed, 17 Feb 2021 15:48:26 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id z11so1116021lfb.9 for ; Wed, 17 Feb 2021 15:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZBkRlFFMS8InfdTfLwfSqxyaQUikOL9+T+9Vcf/7PKA=; b=sZE/jg4BACcmy4LBP7v3M3vVSMzS+BT5y8KUvdqOMkmgSyOkzCe6JyOEApcmCtqnW3 RErehuS/DTM/HqNOzMlIrKInmcKR9G7sZhupXF1a4zkup4HxtIBBQxWOkyEi6T4Aby3Z pSiyCpq62cfmxBZSfMjpCS/lzlXHe4OLgwDRAHsvmKBrujWo4FhXJL+Fzi5K2FlG8N4t FZmKfTCaKFdjlWIezW2GVP7z9Wvz+JgjnNbUqgAiSFY2i+rFchtNe3wXjB+aHeRPbNEL 9N9UEpZvrmwM3u/VfUQoTzugEr44OyjVYFfqK+X9TZYNWIErUdHg2Sv3wgQkMFIwKvtA mkJw== 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=ZBkRlFFMS8InfdTfLwfSqxyaQUikOL9+T+9Vcf/7PKA=; b=o8zwCN3EGA272BM1rlM1l2ojn9iTar7L5RbVjleEvs6LO4wp7zrTBVZylUjOthWWXy yLS+LWeIh3mBLDo5WXbDptc0d81E3W56qhNSh8S1PPlVknaqdAZ4AdaIcOlWWUaE7gvS LDdW4CURLFX1tTZtkxGUjaPk0YauWp/g6vWNaE3OACqQRG3E054Rhd9Jr+vEM8xGypLQ NtnNbsyjShDT7mk9oAyse9AdQvoYUIsiKfP0yHKEtW99rbj32DLz8sbwlzCLIcPSyo/Z UCsq39vFo1mGtKfUFaPknHmn0LZ9uUdZELtFOoPR9FAFBjhyxE3T7P4Z9etd6rHNOtMW eg5g== X-Gm-Message-State: AOAM530XNkHxCTiOMjKoUneczQtq6K7wsHh4qcXjJdWxje56XGggGh5T 6f7N5J6cGj6ZqSAHOfyd5KHGIpiVRTyFBhopwg2LxA== X-Google-Smtp-Source: ABdhPJwCOEHd0IK3ExK+Fq4jIuCgx1jkfdLUMclQEygBSRAemEepq08c8x71M89J1b51kKwZYO6agOmghNQgu0q2SFQ= X-Received: by 2002:a19:c306:: with SMTP id t6mr799901lff.113.1613605704778; Wed, 17 Feb 2021 15:48:24 -0800 (PST) MIME-Version: 1.0 References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> In-Reply-To: From: Eric Rescorla Date: Wed, 17 Feb 2021 15:47:48 -0800 Message-ID: To: Russ Housley Cc: Mark Nottingham , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000d7559005bb90dad2" Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 23:48:30 -0000 --000000000000d7559005bb90dad2 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 17, 2021 at 7:54 AM Russ Housley wrote: > The IAB charter (RFC 2850) makes me think that the IAB should handle > appeals. The ISOC BoT could be a second level for non-technical concerns. > This seems right to me as well. -Ekr > Russ > > > > On Feb 17, 2021, at 1:20 AM, Mark Nottingham wrote: > > > > This looks good. > > > > Regarding appeals -- perhaps we could make progress by listing possible > destinations for appeals and their positive/negative aspects. > > > > To get us started: > > > > * The IESG -- not a good idea; only the IETF. Already represented on the > approval group. > > * The IAB -- Better than IESG in that it has a broader/long-term > function, but also represented on the approval group. > > * Internet Society BoT (or Chair) -- has appropriate scope / distance; > relationship to Series is a bit fuzzy? > > > > Any other candidates? > > > > Cheers, > > > > > >> On 17 Feb 2021, at 2:43 am, Adrian Farrel wrote: > >> > >> Hi, > >> > >> As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H persuaded > me > >> to take a second pass trying to factor in some of the comments on the > list. > >> > >> I can't promise that I have captured *exactly* what everyone said, > >> especially as some of the opinions were conflicting. What I have done > is try > >> to move the text towards something that might be a compromise between > the > >> positions. FWIW, I went back to the "Discuss" position because it > carries > >> some implication that we are all going to try to get together and > resolve > >> this. > >> > >> I also tried to cut some of the waffle. I do tend to waffle. > >> > >> There are two open points. I'd humbly suggest that the people who raised > >> these issues might try to throw some text at a solution. > >> > >> 1. At point C there is the concept of a "community last call". This was > >> raised by Martin and Russ, and I suggest that they put forward a > proposal. > >> The challenge might be to find a way to identify and reach the > "community" > >> (it's easy in the IETF, but very hard for "the world"). > >> > >> 2. At point J there is the concept of "an appeal" in the case of > Discusses > >> being unreconcilable. This was raised by Adam and Mark. The challenge, > as > >> they noted, is working out to whom one appeals. > >> > >> Hope this is useful (which is, after all, the only point). > >> > >> Adrian > >> > >> ==== > >> > >> Decision-making procedures > >> > >> A. Development Cycle > >> The WG is expected to show its work to the approval group and attempt > to be > >> aware of issues that the approval group might be concerned about. > >> The members of the approval group are expected to pay attention to the > work > >> of the WG and speak up when they have concerns. > >> The intention is early discovery of issues and avoidance of late > surprises. > >> > >> B. WG last call > >> The WG last calls its work following the model of an IETF WG. It is > assumed > >> that all members of the approval group will participate the WG last > call, in > >> an attempt to expose any of their concerns that still remain, and to > reach > >> agreement. > >> > >> C. Community last call / public comment > >> It is unclear whether this step (corresponding to IETF last call) > exists and > >> how it would be operated. Further discussion needed per Martin and Russ. > >> > >> D. Participation by members of the approval group > >> As noted in steps A and B, participation in WG work by members of the > >> approval group is expected. > >> It is understood that, from time to time, a member of the approval > group may > >> find it impossible to participate in a particular discussion: in this > case, > >> they are encourage to send delegates. > >> > >> E. Discussion by the approval group > >> The approval group shall discuss the output of the WG. > >> Such discussion is to take place normally within 2 weeks of the WG > making a > >> request. > >> The 2 week period may be stretched by holidays or IETF meetings, but > the WG > >> must be notified if this is the case. > >> All comments and concerns shall be documented to the WG which may take > them > >> into consideration. > >> > >> F. Approval by the approval group > >> The voting members of the approval group shall formally ballot by the > end of > >> the discussion period in E. > >> Each voting member may ballot one of: > >> - Yes: Means "I support this work." A Yes ballot may be accompanied by > >> comments indicating thoughts and issues that should be looked at, but > are > >> non-blocking. > >> - Discuss: Means "I have a serious concern that I would like to Discuss > >> before this work can proceed." Voting members are expected to actively > >> engage in resolving their Discuss positions. > >> - No Position: Only used in exceptional cases such as illness or long > >> vacation. Voting members are expected to try to present a different > ballot > >> position. > >> - Abstain: Means "I have a serious concern, but recognise that it will > not > >> be resolved." An Abstain ballot is a way for a voting member to get out > of > >> the way of progress even though it worries them. The existence of an > Abstain > >> ballot does not imply the work is flawed, but indicates a genuinely > >> irreconcilable difference of opinion. > >> - Recuse: Means "It would be improper for me to have a position." For > >> example, if the proposal was to remunerate the voting member. > >> > >> G. Reasons for a Discuss > >> The approval group shall maintain a list of reasons for a Discuss > ballot. A > >> Discuss that does not conform to one of these reasons shall not be > valid, > >> and must be re-balloted. > >> An initial draft of this list is as follows: > >> - The proposal would cause significant harm to one of the streams > >> - The proposal would cause significant harm to the series > >> - The proposal would cause inconvenience to a group of consumers, the > >> benefit of the change does not outweigh the cost of the inconvenience, > and > >> that inconvenience could be overcome by using a different approach > >> > >> G. Work proceeds if... > >> At the end of the discussion period (point E) or at any later time, > there is > >> at least one "Yes" and no "Discuss" ballot. That is, work fails to > proceed > >> unless it has approval. > >> > >> H. Resolution of Discusses > >> A voting member who ballots Discuss shall explain their concerns to the > WG > >> and shall engage in discussions attempting to resolve the concerns and > >> arrive at a compromise or other agreement. > >> When such agreement is reached, the voting member should transition > their > >> ballot to a "Yes". > >> A voting member may transition their ballot to an "Abstain" at any time, > >> although all parties are encouraged to attempt to reach agreement. > >> > >> I. Single Discuss resolution > >> In the event of there being exactly one Discuss ballot, and there being > no > >> timely progress to agreement between the WG and the member of the > approval > >> group who issued the ballot, the WG may request that the approval group > >> exercise an exception resolution process as follows: > >> - The approval group will discuss the concern giving rise to the ballot > and > >> any proposed resolution from the WG > >> - The approval group shall attempt to reach consensus on whether to > sustain > >> the Discuss or to release the work, but failing that shall vote with a > >> simple majority determining the outcome > >> - If the Discuss is sustained, return to step H > >> - If the work is released, the Discuss ballot shall be changed to an > Abstain > >> and the work shall progress > >> > >> J. Appeals > >> In the event that more than one Discuss cannot be resolved or that a > single > >> Discuss is sustained by the approval group, there is a right of appeal. > >> The details of this need to be worked out per Adam and Mark. > >> > >> > >> > >> -- > >> Rfced-future mailing list > >> Rfced-future@iab.org > >> https://www.iab.org/mailman/listinfo/rfced-future > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000d7559005bb90dad2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 17, 2021 at 7:54 AM Russ = Housley <housley@vigilsec.com> wrote:
The= IAB charter (RFC 2850) makes me think that the IAB should handle appeals.= =C2=A0 The ISOC BoT could be a second level for non-technical concerns.
=



Russ


> On Feb 17, 2021, at 1:20 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
> This looks good.
>
> Regarding appeals -- perhaps we could make progress by listing possibl= e destinations for appeals and their positive/negative aspects.
>
> To get us started:
>
> * The IESG -- not a good idea; only the IETF. Already represented on t= he approval group.
> * The IAB -- Better than IESG in that it has a broader/long-term funct= ion, but also represented on the approval group.
> * Internet Society BoT (or Chair) -- has appropriate scope / distance;= relationship to Series is a bit fuzzy?
>
> Any other candidates?
>
> Cheers,
>
>
>> On 17 Feb 2021, at 2:43 am, Adrian Farrel <adrian@olddog.co.uk> wrote:
>>
>> Hi,
>>
>> As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H = persuaded me
>> to take a second pass trying to factor in some of the comments on = the list.
>>
>> I can't promise that I have captured *exactly* what everyone s= aid,
>> especially as some of the opinions were conflicting. What I have d= one is try
>> to move the text towards something that might be a compromise betw= een the
>> positions. FWIW, I went back to the "Discuss" position b= ecause it carries
>> some implication that we are all going to try to get together and = resolve
>> this.
>>
>> I also tried to cut some of the waffle. I do tend to waffle.
>>
>> There are two open points. I'd humbly suggest that the people = who raised
>> these issues might try to throw some text at a solution.
>>
>> 1. At point C there is the concept of a "community last call&= quot;. This was
>> raised by Martin and Russ, and I suggest that they put forward a p= roposal.
>> The challenge might be to find a way to identify and reach the &qu= ot;community"
>> (it's easy in the IETF, but very hard for "the world"= ;).
>>
>> 2. At point J there is the concept of "an appeal" in the= case of Discusses
>> being unreconcilable. This was raised by Adam and Mark. The challe= nge, as
>> they noted, is working out to whom one appeals.
>>
>> Hope this is useful (which is, after all, the only point).
>>
>> Adrian
>>
>> =3D=3D=3D=3D
>>
>> Decision-making procedures
>>
>> A. Development Cycle
>> The WG is expected to show its work to the approval group and atte= mpt to be
>> aware of issues that the approval group might be concerned about.<= br> >> The members of the approval group are expected to pay attention to= the work
>> of the WG and speak up when they have concerns.
>> The intention is early discovery of issues and avoidance of late s= urprises.
>>
>> B. WG last call
>> The WG last calls its work following the model of an IETF WG. It i= s assumed
>> that all members of the approval group will participate the WG las= t call, in
>> an attempt to expose any of their concerns that still remain, and = to reach
>> agreement.
>>
>> C. Community last call / public comment
>> It is unclear whether this step (corresponding to IETF last call) = exists and
>> how it would be operated. Further discussion needed per Martin and= Russ.
>>
>> D. Participation by members of the approval group
>> As noted in steps A and B, participation in WG work by members of = the
>> approval group is expected.
>> It is understood that, from time to time, a member of the approval= group may
>> find it impossible to participate in a particular discussion: in t= his case,
>> they are encourage to send delegates.
>>
>> E. Discussion by the approval group
>> The approval group shall discuss the output of the WG.
>> Such discussion is to take place normally within 2 weeks of the WG= making a
>> request.
>> The 2 week period may be stretched by holidays or IETF meetings, b= ut the WG
>> must be notified if this is the case.
>> All comments and concerns shall be documented to the WG which may = take them
>> into consideration.
>>
>> F. Approval by the approval group
>> The voting members of the approval group shall formally ballot by = the end of
>> the discussion period in E.
>> Each voting member may ballot one of:
>> - Yes: Means "I support this work." A Yes ballot may be = accompanied by
>> comments indicating thoughts and issues that should be looked at, = but are
>> non-blocking.
>> - Discuss: Means "I have a serious concern that I would like = to Discuss
>> before this work can proceed." Voting members are expected to= actively
>> engage in resolving their Discuss positions.
>> - No Position: Only used in exceptional cases such as illness or l= ong
>> vacation. Voting members are expected to try to present a differen= t ballot
>> position.
>> - Abstain: Means "I have a serious concern, but recognise tha= t it will not
>> be resolved." An Abstain ballot is a way for a voting member = to get out of
>> the way of progress even though it worries them. The existence of = an Abstain
>> ballot does not imply the work is flawed, but indicates a genuinel= y
>> irreconcilable difference of opinion.
>> - Recuse: Means "It would be improper for me to have a positi= on." For
>> example, if the proposal was to remunerate the voting member.
>>
>> G. Reasons for a Discuss
>> The approval group shall maintain a list of reasons for a Discuss = ballot. A
>> Discuss that does not conform to one of these reasons shall not be= valid,
>> and must be re-balloted.
>> An initial draft of this list is as follows:
>> - The proposal would cause significant harm to one of the streams<= br> >> - The proposal would cause significant harm to the series
>> - The proposal would cause inconvenience to a group of consumers, = the
>> benefit of the change does not outweigh the cost of the inconvenie= nce, and
>> that inconvenience could be overcome by using a different approach=
>>
>> G. Work proceeds if...
>> At the end of the discussion period (point E) or at any later time= , there is
>> at least one "Yes" and no "Discuss" ballot. Th= at is, work fails to proceed
>> unless it has approval.
>>
>> H. Resolution of Discusses
>> A voting member who ballots Discuss shall explain their concerns t= o the WG
>> and shall engage in discussions attempting to resolve the concerns= and
>> arrive at a compromise or other agreement.
>> When such agreement is reached, the voting member should transitio= n their
>> ballot to a "Yes".
>> A voting member may transition their ballot to an "Abstain&qu= ot; at any time,
>> although all parties are encouraged to attempt to reach agreement.=
>>
>> I. Single Discuss resolution
>> In the event of there being exactly one Discuss ballot, and there = being no
>> timely progress to agreement between the WG and the member of the = approval
>> group who issued the ballot, the WG may request that the approval = group
>> exercise an exception resolution process as follows:
>> - The approval group will discuss the concern giving rise to the b= allot and
>> any proposed resolution from the WG
>> - The approval group shall attempt to reach consensus on whether t= o sustain
>> the Discuss or to release the work, but failing that shall vote wi= th a
>> simple majority determining the outcome
>> - If the Discuss is sustained, return to step H
>> - If the work is released, the Discuss ballot shall be changed to = an Abstain
>> and the work shall progress
>>
>> J. Appeals
>> In the event that more than one Discuss cannot be resolved or that= a single
>> Discuss is sustained by the approval group, there is a right of ap= peal.
>> The details of this need to be worked out per Adam and Mark.
>>
>>
>>
>> --
>> Rfced-future mailing list
>> Rfced-fu= ture@iab.org
>> https://www.iab.org/mailman/listinfo/rfce= d-future
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>
> --
> Rfced-future mailing list
> Rfced-future= @iab.org
> https://www.iab.org/mailman/listinfo/rfced-fut= ure

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000d7559005bb90dad2-- From nobody Thu Feb 18 11:03:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E150F3A15B2 for ; Thu, 18 Feb 2021 11:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7ZMhAiG6M5L for ; Thu, 18 Feb 2021 11:03:23 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A553A15AB for ; Thu, 18 Feb 2021 11:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1107; q=dns/txt; s=iport; t=1613675002; x=1614884602; h=from:mime-version:subject:message-id:date:to; bh=iVEz82ZDhdcEgavoBUCIlTDgMXUy3l70TzWetjrjAPo=; b=aBZqnEfMPcsuiBGz8/TcizAUmRcc4zu8mrjpWpN2mfaiyCuwtnifFMVi e/lDvkASlBODk08HxX46IuN9m5O63TKCmhwMCo70C8zR7wB6wQpFe149g kcTZQLseaP879fntXloLBWg8M26bnmacN2JPipM461HyqbqbFdL1bkCNO g=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DMAADsuC5gjBbLJq1GHB0BAQEBCQESAQUFAUCBPgUBC?= =?us-ascii?q?wGDIFYBJxIxjUWZLItvBAcBAQEKAwEBKgoEAQGGWyY3Bg4CAwEBAQMCAwEBA?= =?us-ascii?q?QEFAQEBAgEGBBQBAQEBhjoNjAABgwYPP59cjhx0gTSKUQoGgTgBgVKHZYQJQ?= =?us-ascii?q?oICgREnHIJXPoJdBBeCE4J9gisEhAFmgiyQLowInE6DBYMtgTqEU5JUAx+DH?= =?us-ascii?q?wGQIo90n3GSYYNzAgQGBQIWgWoigVkzGggbFWUBgj89EhkNjisNCYNNilpAA?= =?us-ascii?q?y8CNQIGCgEBAwmMEwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,187,1610409600"; d="asc'?scan'208";a="33552640" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Feb 2021 19:03:18 +0000 Received: from [10.61.194.198] ([10.61.194.198]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 11IJ3Hb8001789 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 18 Feb 2021 19:03:18 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_360CBA83-AC53-487D-8308-D5166E0CB218"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <2C877708-606B-439D-AB39-BEAA0637099D@cisco.com> Date: Thu, 18 Feb 2021 20:03:17 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.194.198, [10.61.194.198] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Reminder: interim 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: Thu, 18 Feb 2021 19:03:25 -0000 --Apple-Mail=_360CBA83-AC53-487D-8308-D5166E0CB218 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Meeting starts about an hour from now. Webex is = https://cisco.webex.com/cisco/j.php?MTID=3Dmeada1c54dde3cfddb8022e917f9442= 79 Eliot --Apple-Mail=_360CBA83-AC53-487D-8308-D5166E0CB218 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAuufUACgkQh7ZrRtnS ejMAoAf/RjErq8Ni82X1bEh+Rid9x1coJgiAjuffPOZe7sow9NbuGSpSiBH1Omqu v0SSP2xXs2YEFzyKfRdLclvolFDWgTmOfrTLS2HMaGAQoU0ZOSQmoykGejEiWVlJ If4Y3j6iAr69HuMmNRiFVNZ++gs/h4qH2gtar+ahaXDiCVEHjytBK/zHLt6j2wlR q8ZqRby+RKS2XEzG6rWW86mR3fQw2nFArv20GReZY+vo+C2MWghLtPzCfP7VH43t 7+FFP/N3R2HnTQvV9rMxkwZh4mMegszEyDLj73xT2ccXofybngbz6Qrm34bhtx0/ WfQ3cEw18Yw7Tj05fmr/sM2T4q8YNg== =fx5N -----END PGP SIGNATURE----- --Apple-Mail=_360CBA83-AC53-487D-8308-D5166E0CB218-- From nobody Thu Feb 18 11:33:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4A13A1634 for ; Thu, 18 Feb 2021 11:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6MTTlmiN2YU for ; Thu, 18 Feb 2021 11:33:30 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADB43A1631 for ; Thu, 18 Feb 2021 11:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2724; q=dns/txt; s=iport; t=1613676810; x=1614886410; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=i/EsKN3gznygE38LPQs1gNu6Ub+E1Bm+TXYYpjZKGiw=; b=FUyp77/yvyP2WQ/9pPG6BrSaNKkzvTeWWnih+HBTbqkk13q/RBdAIB5t 4uBhJaRi4SCZPGNunnfW3p1kfaDyqDD4lOQMCG5KEwZH+FvbUYetRKKq3 Rp78h15LY3/+mnQUzd37hE+KgAedX46QLkCJP1tJ+IFmldcbUoS10PJNb U=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BiAAC1wC5g/xbLJq1iGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBgg+DIVYBJxIxhEGJBIgrJQOcSAQHAQEBCgMBAR0LDAQBAYRNA?= =?us-ascii?q?oIMJjgTAgMBAQEDAgMBAQEBBQEBAQIBBgRxhWENhkQBAQEDAQEBIUsLBQsLG?= =?us-ascii?q?CoCAicwBhOCawGCZiAPrlp2gTKFWIR3CgaBOIFTi25CggKBOAwQglc+gl0Bh?= =?us-ascii?q?HY0gisEgkZZDzIRECAPLGkIEVMBAYgpiA6MX5xOgwWDLYE6lycDH5NCj3SOO?= =?us-ascii?q?aNTRoNzAgQGBQIWgWsjgVczGggbFTsqAYI+PhIZDZcihUZAAy83AgYBCQEBA?= =?us-ascii?q?wmMEwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,187,1610409600"; d="asc'?scan'208";a="31121556" 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; 18 Feb 2021 19:33:16 +0000 Received: from [10.61.194.198] ([10.61.194.198]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 11IJXFmK004161 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Feb 2021 19:33:16 GMT From: Eliot Lear Message-Id: <6BFA4518-8043-4C83-BD94-76F6B89EA787@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A285F328-DCDB-463E-BC60-A84B20D1B3D2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 18 Feb 2021 20:33:15 +0100 In-Reply-To: <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.194.198, [10.61.194.198] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Feb 2021 19:33:33 -0000 --Apple-Mail=_A285F328-DCDB-463E-BC60-A84B20D1B3D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This brings up a separate issue that Mirja raised: are people serving on = the AB as representatives or as delegates? Eliot > On 17 Feb 2021, at 21:43, Michael StJohns = wrote: >=20 > On 2/17/2021 11:28 AM, Eliot Lear wrote: >> Well, that=E2=80=99s a question: >>=20 >> What is the likely nature of the appeal? If it is a question of = whether or not the DISCUSSes are permitted, that seems pretty close to = technical. Will this change harm the series? Will this change harm the = stream? Who gets to second guess on that? Anyone? Or are we talking = about process appeals a=E2=80=99la were A-G properly followed? >>=20 >> Eliot >>=20 >=20 > Very good question. We do need to avoid a turtles all the way down = type of problem though. >=20 > Maybe we do this slightly differently - have the bodies that send the = AB members be able to override the vote of their AB member(s) through a = majority vote of their own? That would cover 4 of the votes on the AB. = The request to override would take the form of an appeal and each body = would use its own procedures to discuss the request and then vote. The = RSE wouldn't get a vote, but any Nomcom selected members would (Nomcom = does not direct their vote). Majority of those voting (including the = directed votes by the sending bodies) will override the decision no = matter how bad it might be for the series. >=20 > Mostly, I think there's not going to be a lot of output where a = traditional appeal makes sense which makes the normal "who resolves the = appeals" process kind of an iffy fit. >=20 > Mike >=20 >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_A285F328-DCDB-463E-BC60-A84B20D1B3D2 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAuwPsACgkQh7ZrRtnS ejPO5Qf7BeV6MA1sknUTqocn7O3Nxh0NBZucFGETGdQsFWgpjeG5brYdicHcElvx ArlxvjVDEYTSAzLQqTfUR2Ua1AyH5h1/JNnQpKVlpfBEkKWI3OTlklvko1+8Mw/i rSlTT/8nucn+CrEw5M2hLafeZjrlJYjubOf7P8bX+lGXdgxGswxzAeMqCq7nUK62 9Qhs8TBWwwHrGQ5XOpfCEvNHurS3bsYQMModPKy6k9iGC/0zrEGe6ElG3MlG7fF6 2eKanxgK+snrBjhHtUAkTnjYu3nUa7uuPGwR5jsAqKJoJ8EINWAukG5ZJivOMyfP HWZmIrkolqaxdv5L70BaNmJIyMcqbQ== =dqTt -----END PGP SIGNATURE----- --Apple-Mail=_A285F328-DCDB-463E-BC60-A84B20D1B3D2-- From nobody Thu Feb 18 11:50:45 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F333A1665 for ; Thu, 18 Feb 2021 11:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0_G9yvw1lmv for ; Thu, 18 Feb 2021 11:50:42 -0800 (PST) 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 CE88A3A1640 for ; Thu, 18 Feb 2021 11:50:41 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id z6so1760126qts.0 for ; Thu, 18 Feb 2021 11:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=cXGlWNm4xzNEKi3wz+zQLo1RdzaFy3cC0CIftgN/FwE=; b=nqFNkdXOSZ2ABnsB/+HlhPUQ4bYCBVQKtlGaqD1OJ3nmoMjDEA9x4Tc0xnJ+0q4wh8 wDIDeA9x09Ol9GPnQysr3BYRJe4Wywo6oJlXFXaHqRTZ3mm0eGvlKGTjOzSHo6J+M3GH nNWnM+x0urTOFtWOABEZe8N6vjhqyY6v/q1Tts/ecW/EB7kFoJfM4ByI5nmxhlmB+cVu U89JtHMlP22wCVABG3mF/VxWLJbv1gwXJr07m3Yvnm8HlXJ2zJ+m70eUwBdr72Wox4iO wvAyGK4DakIhvQI37kHHLdP71e3k9Z0cl68mIU6wBAuthUNC5KIAE2GKjiHBsIYmqo70 801A== 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=cXGlWNm4xzNEKi3wz+zQLo1RdzaFy3cC0CIftgN/FwE=; b=qcyaXKI7N72lCAdBvcS0bET5ryFxFRaUtUDukJ7MBTP9P0yudTo9Rw/LjIRhy/1ww+ tRNLW+Axjld1Sp7PTE/857MvEbxnXaSxlqaA/XgEExbMkZEWzibCXXP+ZWQaoumaJ526 UKyoVH11hcdN8gHbwq2xcvL+iHKHYFZjIYS27UP/OTvMDLnWLpaVA+eXhuj3lM93msGq 5hO+Wn4IZ8stXARghbjIcmz5wqJwc2/NGgYA5y1RigDrTX7NAVZBPsy6nkldv7VUuC24 K2g+rPa92RLrNAA/aUypQa1A2HVxnDPUYtzwp5bWNdZJjVFzLvTI55TBiemwXIy87Oa7 BtPw== X-Gm-Message-State: AOAM5316t7Z587vWjyjNuEZJ/OiIg1OxHzgI5VDgr83VNe+C+2jY++Po b50f0FxAlfuIDeTaFAKzSup8mtzNDSmE4d3p X-Google-Smtp-Source: ABdhPJznaWf3eJX6hK2bX5kEy7n5ajFU22hHbSPiJGiMGNbSt/axVpLMjx0qby7Jyy9Je+Po4tmBsA== X-Received: by 2002:ac8:7191:: with SMTP id w17mr5632620qto.327.1613677840118; Thu, 18 Feb 2021 11:50:40 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id y27sm2822466qtv.43.2021.02.18.11.50.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Feb 2021 11:50:39 -0800 (PST) To: Eliot Lear Cc: rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> <6BFA4518-8043-4C83-BD94-76F6B89EA787@cisco.com> From: Michael StJohns Message-ID: Date: Thu, 18 Feb 2021 14:50:38 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <6BFA4518-8043-4C83-BD94-76F6B89EA787@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] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Feb 2021 19:50:43 -0000 On 2/18/2021 2:33 PM, Eliot Lear wrote: > This brings up a separate issue that Mirja raised: are people serving on the AB as representatives or as delegates? Define those two terms as you mean them please - they mostly mean the same to me. Mike > > Eliot > >> On 17 Feb 2021, at 21:43, Michael StJohns wrote: >> >> On 2/17/2021 11:28 AM, Eliot Lear wrote: >>> Well, that’s a question: >>> >>> What is the likely nature of the appeal? If it is a question of whether or not the DISCUSSes are permitted, that seems pretty close to technical. Will this change harm the series? Will this change harm the stream? Who gets to second guess on that? Anyone? Or are we talking about process appeals a’la were A-G properly followed? >>> >>> Eliot >>> >> Very good question. We do need to avoid a turtles all the way down type of problem though. >> >> Maybe we do this slightly differently - have the bodies that send the AB members be able to override the vote of their AB member(s) through a majority vote of their own? That would cover 4 of the votes on the AB. The request to override would take the form of an appeal and each body would use its own procedures to discuss the request and then vote. The RSE wouldn't get a vote, but any Nomcom selected members would (Nomcom does not direct their vote). Majority of those voting (including the directed votes by the sending bodies) will override the decision no matter how bad it might be for the series. >> >> Mostly, I think there's not going to be a lot of output where a traditional appeal makes sense which makes the normal "who resolves the appeals" process kind of an iffy fit. >> >> Mike >> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future From nobody Thu Feb 18 11:56:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED713A17C1 for ; Thu, 18 Feb 2021 11:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 muJ7sUuUAYrf for ; Thu, 18 Feb 2021 11:56:47 -0800 (PST) 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 7FC933A17BC for ; Thu, 18 Feb 2021 11:56:47 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id c11so2013222pfp.10 for ; Thu, 18 Feb 2021 11:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=mijMAve2MvsoWhF05eWnp7KMUakLa3KXrSEjOiSdKWw=; b=McSWR2zxQORThnjufF29Ke9/+nlOv/WuR+ftBGTc0b4vuXvyd7yiARBsFVzsdl5pa7 QjLF4ysKYSR/juxU0MwY0zdvgT5mQ9jCvtpcwuUVDa7sghw2C5gHiUKVElaLp4M+ne21 kz16/0Gruxhcsq2tLfsiJ5FefbQ5CaqC7Xk4eFbLTHWxqQ9iDVsCoVNSpBvM+KYnLeUK 9Xe0iQtr5ysBBD9wKO2nhMobfOu8mUy2ngEx9vnQp8E/dommNRByVfG7Xqvql4QYzV3Q DFMqAkBwjCdb9hwuOiHErLbL3h4xZMcmxeVgAHfmU187oh4HZ8SUls8xtwuYwrhXAfBx cqow== 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=mijMAve2MvsoWhF05eWnp7KMUakLa3KXrSEjOiSdKWw=; b=kHqFKrh/rPk+AXaRYpeOQo4JpIYLPycV2i/VJMrNhCfflcT67A/3J4eqZYFFhsDKQk OmQD5XVOIKK52Esv00ganMoRblYpCN7Aj5De3bVyuuBnBisxYlSlHq3WsLJGXgEgbq+t ohvV7XOBSZSf+BTyuAj2BmBSkjq8Dpk/lsWAw9dAIFEXo+DYiQLQsFgNI2pwdluZwUv/ QhGJDIxljKDd3+CEozt4MlvIqr15//iqtw5r9yOIWMU4CbVGhOMevTaFroMUos+5nUDc nY+V+OKOrdnnhjpOi6vMpiG669QQMmEV5Q3LpDmTdiMBFe0nZ7PvMrdnMaf9IH35JCKS A1MQ== X-Gm-Message-State: AOAM533GOHDKZlNP9UTSYW2mX4wpDPJy0ikRhRUYULo1gnNXpuiV/kd0 QpkAwm70S9b/XjmcXGYmDOCZZzDAFkJ3Yg== X-Google-Smtp-Source: ABdhPJyoxIHNV8TKZD0uzhtvCSGdPb9BCGKNjJ4UCnRpigT7ZgJXInuw2WzaDhhWRv+xwV4L+mZKxg== X-Received: by 2002:aa7:88c7:0:b029:1d1:4f1f:5fb6 with SMTP id k7-20020aa788c70000b02901d14f1f5fb6mr5761518pff.14.1613678206503; Thu, 18 Feb 2021 11:56:46 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id 74sm6965899pfw.53.2021.02.18.11.56.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 11:56:45 -0800 (PST) To: rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> <6BFA4518-8043-4C83-BD94-76F6B89EA787@cisco.com> From: Brian E Carpenter Message-ID: <422e93f9-fd9a-c983-6de2-6742d7f4d27a@gmail.com> Date: Fri, 19 Feb 2021 08:56:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Feb 2021 19:56:49 -0000 On 19-Feb-21 08:50, Michael StJohns wrote: > On 2/18/2021 2:33 PM, Eliot Lear wrote: >> This brings up a separate issue that Mirja raised: are people serving = on the AB as representatives or as delegates? >=20 > Define those two terms as you mean them please - they mostly mean the=20 > same to me. My understanding has always been that delegates vote as they are told, bu= t representatives vote as they think best. (At least, that's my understan= ding from British practice.) Brian >=20 > Mike >=20 >=20 >> >> Eliot >> >>> On 17 Feb 2021, at 21:43, Michael StJohns wr= ote: >>> >>> On 2/17/2021 11:28 AM, Eliot Lear wrote: >>>> Well, that=E2=80=99s a question: >>>> >>>> What is the likely nature of the appeal? If it is a question of whe= ther or not the DISCUSSes are permitted, that seems pretty close to techn= ical. Will this change harm the series? Will this change harm the strea= m? Who gets to second guess on that? Anyone? Or are we talking about p= rocess appeals a=E2=80=99la were A-G properly followed? >>>> >>>> Eliot >>>> >>> Very good question. We do need to avoid a turtles all the way down t= ype of problem though. >>> >>> Maybe we do this slightly differently - have the bodies that send the= AB members be able to override the vote of their AB member(s) through a = majority vote of their own? That would cover 4 of the votes on the AB. T= he request to override would take the form of an appeal and each body wou= ld use its own procedures to discuss the request and then vote. The RSE = wouldn't get a vote, but any Nomcom selected members would (Nomcom does n= ot direct their vote). Majority of those voting (including the directed= votes by the sending bodies) will override the decision no matter how ba= d it might be for the series. >>> >>> Mostly, I think there's not going to be a lot of output where a tradi= tional appeal makes sense which makes the normal "who resolves the appeal= s" process kind of an iffy fit. >>> >>> Mike >>> >>> >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Thu Feb 18 14:04:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EAC3A18FB for ; Thu, 18 Feb 2021 14:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01DSeVsesiEM for ; Thu, 18 Feb 2021 14:04:49 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFFA3A1907 for ; Thu, 18 Feb 2021 14:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3345; q=dns/txt; s=iport; t=1613685884; x=1614895484; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=J+m5oCZlhVR5eahmNUjmn1CZxTS3iySYvGkHzshiaJg=; b=KSWSYsNEsN402CtvzyYyOWfNvRIJUnNnAYuU0imNML++qF6l2neT6AjZ 6pPjqtEm/NWyg3MQQA7IN3j4stAPgvzyZOimGc0tOx8KRmI4ubTrbkbaI txyWtC4EUyHvMzkqFgE7WaiTMD1lmBwh99AE5JRS5E8D0jBRaxlhltz4O c=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BIAABK4y5gjBbLJq1iGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBgg+DIVYBJxIxhEGJBIhRA5xIBAcBAQEKAwEBHQsMBAEBhE0Cg?= =?us-ascii?q?gwmOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBhjoNhkQBAQEDAQEBIUsLB?= =?us-ascii?q?QsLGCoCAicwBhOCawGCZiAPrxh2gTKFWIR5CgaBOIFTi25CggKBOByCVz6CX?= =?us-ascii?q?QGEdjSCKwSCQAZZDzIJCBAgDyxpCBFTAQGIKYgOjF+cToMFgy2BOpcnAx+DM?= =?us-ascii?q?YpJhUiPdI45o1NGg3MCBAYFAhaBayGBWTMaCBsVOyoBgj4+EhkNiEmFb4hqh?= =?us-ascii?q?UZAAy83AgYBCQEBAwmMEwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,187,1610409600"; d="asc'?scan'208";a="33556464" 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; 18 Feb 2021 22:04:35 +0000 Received: from [10.61.213.3] ([10.61.213.3]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 11IM4YMn028653 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Feb 2021 22:04:35 GMT From: Eliot Lear Message-Id: <6CA39C98-CCCE-48E7-A325-EEDF4B11C6C7@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7C8D1981-A2F0-459E-A98A-B3114E465485"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 18 Feb 2021 23:04:33 +0100 In-Reply-To: Cc: rfced-future@iab.org To: Michael StJohns References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> <6BFA4518-8043-4C83-BD94-76F6B89EA787@cisco.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.213.3, [10.61.213.3] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Feb 2021 22:04:51 -0000 --Apple-Mail=_7C8D1981-A2F0-459E-A98A-B3114E465485 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What I meant was that in one instance, representation, the person is not = free to choose to take a position but must refer to the body she or he = is representing, while in the other case, delegation, the person is = asked to make decisions on behalf of the body she or he is representing. Eliot > On 18 Feb 2021, at 20:50, Michael StJohns = wrote: >=20 > On 2/18/2021 2:33 PM, Eliot Lear wrote: >> This brings up a separate issue that Mirja raised: are people serving = on the AB as representatives or as delegates? >=20 > Define those two terms as you mean them please - they mostly mean the = same to me. >=20 > Mike >=20 >=20 >>=20 >> Eliot >>=20 >>> On 17 Feb 2021, at 21:43, Michael StJohns = wrote: >>>=20 >>> On 2/17/2021 11:28 AM, Eliot Lear wrote: >>>> Well, that=E2=80=99s a question: >>>>=20 >>>> What is the likely nature of the appeal? If it is a question of = whether or not the DISCUSSes are permitted, that seems pretty close to = technical. Will this change harm the series? Will this change harm the = stream? Who gets to second guess on that? Anyone? Or are we talking = about process appeals a=E2=80=99la were A-G properly followed? >>>>=20 >>>> Eliot >>>>=20 >>> Very good question. We do need to avoid a turtles all the way down = type of problem though. >>>=20 >>> Maybe we do this slightly differently - have the bodies that send = the AB members be able to override the vote of their AB member(s) = through a majority vote of their own? That would cover 4 of the votes = on the AB. The request to override would take the form of an appeal and = each body would use its own procedures to discuss the request and then = vote. The RSE wouldn't get a vote, but any Nomcom selected members = would (Nomcom does not direct their vote). Majority of those voting = (including the directed votes by the sending bodies) will override the = decision no matter how bad it might be for the series. >>>=20 >>> Mostly, I think there's not going to be a lot of output where a = traditional appeal makes sense which makes the normal "who resolves the = appeals" process kind of an iffy fit. >>>=20 >>> Mike >>>=20 >>>=20 >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 --Apple-Mail=_7C8D1981-A2F0-459E-A98A-B3114E465485 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAu5HEACgkQh7ZrRtnS ejM+ewf+PtAWrOtOXRoKw7pEaqoXMb38BCJEByhPc6kXpN3kOEgMCQgKlgD9pAMe pod447GhIGjtVxqCyA0tidwWJDdDb98IKOXPljzxLUaZ58pYyjp+q0o8/BcgeRJd lZAThFDE671n1jKNvLeOfcc+k35Ux4DOF6Z+0EOYco92Val4BH1zu6b4VK9mBaFe HGKY8RPSK4KGkqjh8TEy4eGtdQ+4c6tVjXlvXOLpMVl9q6kk3Ino4IKXvtiYrzG+ Skg2FYd1pzvqqkVejUJj51LO18V6N4N1uojl6INmxUx5gDDd3dPdoCS12PY0lggi V0tYHoUPHRUoSdQSMVajxsclxZ8Bnw== =g81R -----END PGP SIGNATURE----- --Apple-Mail=_7C8D1981-A2F0-459E-A98A-B3114E465485-- From nobody Thu Feb 18 14:12:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9943A190E for ; Thu, 18 Feb 2021 14:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsya5JPhHwzH for ; Thu, 18 Feb 2021 14:12:08 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D933A190D for ; Thu, 18 Feb 2021 14:12:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4DhTTM5SlSz1nv4L; Thu, 18 Feb 2021 14:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1613686327; bh=uq5I8YWROejDiPiGmXM7BTHwnFoOmFj0dbdUfJXEQ4w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BXpndRtZNBr/wqzV7x37ZPE3zvWniUiTm9ZQi+nzKl7WkYLg2Xtdad6qm0c0ejFvL fk6at/h6j1PmFjNN7BkJhh+iz8ImlOb8xHd6WY0TIYH1O7CtPmkqF2cyv/pK+PC3Hw frcR7NBe/Izjcj9HzHqA41N16FwNJnRqw8M6ZiHA= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4DhTTM1tZ2z1nsT7; Thu, 18 Feb 2021 14:12:07 -0800 (PST) To: Eliot Lear Cc: rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> <6BFA4518-8043-4C83-BD94-76F6B89EA787@cisco.com> <6CA39C98-CCCE-48E7-A325-EEDF4B11C6C7@cisco.com> From: "Joel M. Halpern" Message-ID: <68b017b7-cff3-a907-bae2-bc318bdb2488@joelhalpern.com> Date: Thu, 18 Feb 2021 17:12:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <6CA39C98-CCCE-48E7-A325-EEDF4B11C6C7@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Feb 2021 22:12:09 -0000 With those definitions, I sure hope all of the members of the approval body are delegates, that is, they are free to make decisions using their skills. (If they do it wrong, and they are sent from a body, then the body should replace them.) Yours, Joel On 2/18/2021 5:04 PM, Eliot Lear wrote: > What I meant was that in one instance, representation, the person is not free to choose to take a position but must refer to the body she or he is representing, while in the other case, delegation, the person is asked to make decisions on behalf of the body she or he is representing. > > Eliot > >> On 18 Feb 2021, at 20:50, Michael StJohns wrote: >> >> On 2/18/2021 2:33 PM, Eliot Lear wrote: >>> This brings up a separate issue that Mirja raised: are people serving on the AB as representatives or as delegates? >> >> Define those two terms as you mean them please - they mostly mean the same to me. >> >> Mike >> >> >>> >>> Eliot >>> >>>> On 17 Feb 2021, at 21:43, Michael StJohns wrote: >>>> >>>> On 2/17/2021 11:28 AM, Eliot Lear wrote: >>>>> Well, that’s a question: >>>>> >>>>> What is the likely nature of the appeal? If it is a question of whether or not the DISCUSSes are permitted, that seems pretty close to technical. Will this change harm the series? Will this change harm the stream? Who gets to second guess on that? Anyone? Or are we talking about process appeals a’la were A-G properly followed? >>>>> >>>>> Eliot >>>>> >>>> Very good question. We do need to avoid a turtles all the way down type of problem though. >>>> >>>> Maybe we do this slightly differently - have the bodies that send the AB members be able to override the vote of their AB member(s) through a majority vote of their own? That would cover 4 of the votes on the AB. The request to override would take the form of an appeal and each body would use its own procedures to discuss the request and then vote. The RSE wouldn't get a vote, but any Nomcom selected members would (Nomcom does not direct their vote). Majority of those voting (including the directed votes by the sending bodies) will override the decision no matter how bad it might be for the series. >>>> >>>> Mostly, I think there's not going to be a lot of output where a traditional appeal makes sense which makes the normal "who resolves the appeals" process kind of an iffy fit. >>>> >>>> Mike >>>> >>>> >>>> -- >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future >> >> > > From nobody Thu Feb 18 19:21:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03063A0C6C for ; Thu, 18 Feb 2021 19:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Mn27jvN8UrUN for ; Thu, 18 Feb 2021 19:21:46 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410114.outbound.protection.outlook.com [40.107.141.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E803A0C6A for ; Thu, 18 Feb 2021 19:21:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K29GBVQOEpkcjxz6meh7PfwqQ9djUVQ5dAvTp9t70ehnG3Wm9VyaPkYnHsK1bzF1MHNrNjVA83cjRNbFTRiMzY39EmIIKY6IuEwW6wO/IY2VZX7vWybq/DLYT/A+d7lLfE7de6zlIqXu5Us1hc77awiXPyPy00jk9smjLbs3tH79+8I76Bt1TRMZVEF6VwJ53tMGywMFWiRQQtzujdCyvUlVZviJRF+T7wkrm5dVQ+paITl5gONlNGpKATtQGtrMhYTbV+DUs78VfnMen29DAJE4M9lOd/QqvuilAut1W+SKHQJXOlVaYYkBrOrID3K+jBmEOTO7IS4kofdpJZDPuw== 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=0D4o0eKDhyXadLVcFR1fLijz4XKuwCbFdZdztUfBgKM=; b=AZMJ7zG7skdhzso/JXIewWGpI6QA/RvXim3xt99bjkZFdV2vxGGKzsd8W4ZK3SrMG4i6kFsA86kWeFKdAwVzYfzZxLSngP7iHKyTVteRuxMnggDL2WkDJAD0AlPKVgrPyvxx7YhcklUD2e8QM9NBlP6AD8na51KWIhQyENwJPJHNwmOn3CxmethNt+iBkcMCTy4R3zrd0SrCrEcJiItkzuHGtkfJH2lKcP3v0lKCUE+XdOGxG4W5KOjER6aXFPmacyiUrBqOOrs6jH1Yrz7a7zYjJ8SQ1Y3v9OK6TkDahWneH/0ApOOpY+A2ZXRfNHeJATgMQpxy2SzCHCVm8XrZ+w== 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=0D4o0eKDhyXadLVcFR1fLijz4XKuwCbFdZdztUfBgKM=; b=Gx8bxewgZ5poe/BKvUi8dm0u4CP/qFM68hTPTt4PAV2HRDaJWfSEkTAJGpbXhwBO2A2NJYkbWekPLEZjVezzQHlsEEuEFzs8aZ5tdSrV1sMcJ0eSOMqWlxVkXkZxJiftSHIdq9EEx2LOAhw/44XuGH9lyE64Srn6vqLQF13+pDA= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB5197.jpnprd01.prod.outlook.com (2603:1096:404:12d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27; Fri, 19 Feb 2021 03:21:38 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f%7]) with mapi id 15.20.3868.027; Fri, 19 Feb 2021 03:21:38 +0000 To: Eliot Lear , Michael StJohns Cc: rfced-future@iab.org References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> <75722e78-a4b1-7a92-8cba-bf85525e86b4@nthpermutation.com> <6BFA4518-8043-4C83-BD94-76F6B89EA787@cisco.com> <6CA39C98-CCCE-48E7-A325-EEDF4B11C6C7@cisco.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <2828f16d-f1cf-9545-e438-034d84106853@it.aoyama.ac.jp> Date: Fri, 19 Feb 2021 12:21:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <6CA39C98-CCCE-48E7-A325-EEDF4B11C6C7@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.0.75] X-ClientProxiedBy: TY2PR06CA0024.apcprd06.prod.outlook.com (2603:1096:404:42::36) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [100.69.19.251] (133.2.0.75) by TY2PR06CA0024.apcprd06.prod.outlook.com (2603:1096:404:42::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Fri, 19 Feb 2021 03:21:37 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1ca32a54-e631-4426-1b09-08d8d485778b X-MS-TrafficTypeDiagnostic: TYAPR01MB5197: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YlzIsAi+G+L6PHFMqBJFEZTF3th5qFEz4LZypnHz4Dq4VslddkUokZthsC0DfbX+N1OBtR5BhDCNiC0NT0MjJJQ/CptFQev8oK7YKRH/raXKE0CGVeRi3xoT5jfbNmwJJxLsBt5nzJXy7Gxni4Ubr65JcnTS3YIdF/CcM6RF0PWgEYxfZpTEGLlLn/Ir2JUFtWKXenbu+8wIJoE3k4OOpOq18pDCsGd5/LTlx832drJH9D/m7kudrpO/WsMdGimKKZu1gl/KwF7Jh41tI0VDt7XfX247dmlRVvHHVhQReHNCwj3kAr6brtrU2HhOK971U1BrAqu+3nBEwMI/LyRCFslC0sz4bdJp6NlXn2RX/CYZ6/qhnxoH+vn22I2uZR3XQ34fjy9lCobXx3Djb17HorXoRaay0Dc4y7q7HfUMKEMxR6voRIkvzB60lVgJv3L3hCT2JwJyrJ8oJv/dlW2YFk1SLtlIgn+lYQHD248R6wPid0IVRaedXUJDi3X/KzYtnihdBGZXpDCq0dGFsUpusblfoycXB87/5hWg8LNV3gUt7Qzqk0ALAIcYG/1OiFjyfe6ONGUFH49KkQa2h0w266yKwAQHc8Qjbzdg4zWUDQ59EGBUpmoWkbaQKgf9Vb/N X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(39840400004)(366004)(136003)(396003)(376002)(346002)(2906002)(31686004)(66556008)(83380400001)(66476007)(66946007)(478600001)(16576012)(786003)(316002)(86362001)(5660300002)(956004)(8936002)(8676002)(53546011)(110136005)(186003)(4326008)(6486002)(2616005)(36916002)(31696002)(6706004)(16526019)(52116002)(26005)(78286007)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?TlRVa1VsVDlTL3BGbEt4ZTVSR2tNK1ZSOGdteUdGV0gxdmRKK0xhRTd2bFNo?= =?utf-8?B?UzZ0MW5ybm5Hb3IvV2JvWFE0a3hkZnJ2UzZGQW9lZHVrZGZmRGFzUUVvandk?= =?utf-8?B?MnM5Ulpuc1pQM0RYaktuREJWUzhzNmtHUXE1UEI4ZUF5NlBqaXR3M1dPa29q?= =?utf-8?B?QjNDaWZKdnhzaGs1d09VUEZhUTdIVHpCSWVtUlR4NjFNVHVkRXdtTkdLZ3Iv?= =?utf-8?B?TGtFRkx6WkxOcnhiZ3RTMTBjK1lncDE4UWxJU2dSRHdxeEZtVlN0QmtWOGhn?= =?utf-8?B?TjY3NUh4b3BHQ1hWcktOem80aGNlVTJxdk9HbFVzakJpZ2F1UjJ3UzZ2Vlly?= =?utf-8?B?SFdCa2xWbkYrbWgxa3Y3T0tiY3Y5SEV2blVXdzlncTZnRjJkZmpCUUYraWFi?= =?utf-8?B?b1RNTWowdk9qN1F6dGhMcG9PQzdZVkZFU0t1WE83RzdMbjk1R0ZnSUVsYWRO?= =?utf-8?B?ZTNYemJDQlZWTGd2UnVaZjBuZjVpc0V2dmp4NDBBS0g5TmphM1lVdFZmc0t0?= =?utf-8?B?TU9jVCswdlBqR2VyeEp2eHNscDBOMWhDYkVBUXJIeG1vWnhyN3MyQ28yN3dY?= =?utf-8?B?V1JNU3lWN29Vdlp2TFRJc29EUkY1dzB1UlMzUTc0SVFWSWpkQzZaWktnRjV4?= =?utf-8?B?Ui9rRzZDV0IwUlh1aE9rY3VjUCtoeG9SSkpob3NUeEpJTGI1M3VUMDg0OHZT?= =?utf-8?B?V0ErZkJTdllMb3o0bWlaVmsxZVQzUllKaWZpSmp1bkxhNG11UGNZeWZaYnRN?= =?utf-8?B?TGVtQUt2SVBBY2w1T1pHU3ExUVVIVXVrMTFrSER3bm9icnVhQStUaVIrNlNu?= =?utf-8?B?NmVhMHJSWTJQLzluWHZQaFVzblpaWHR1RERyMjB1bm5Ja1hjYjNubTJmb1oz?= =?utf-8?B?OXllK3VuWUZkTXE3TDJld0U0dmRURGtkTW8vbXFMWit3Z1JYZUxDVGxEVWlr?= =?utf-8?B?YVRIL3JscEpvUkZEcUZObnFxVGJRNUg0WXRreFJkK3lFNSs0bFIySENvWEU4?= =?utf-8?B?S0QwbmtnTFFDYUE0N0piaUZqTTkrMUZqRWNzQ2FsMjFRbVMrNzFDZzhTYi9l?= =?utf-8?B?cDh3V2JtekFsY254T1N3U2Q1bzNhb1poWW9jcmtoNWhIM3FWbFRDRXJhMzhP?= =?utf-8?B?RC8xdWFmSmtMelRiWXVVNWRyQzRkTU5GRnBuZGNlQU54OGxvY2d5ZzNydlM2?= =?utf-8?B?Tk4zOEFCeTZ6VFlMbkh3NDRnc0cxWUxqdDhqVmN2WUduVTl6dWNBWUMzeUpM?= =?utf-8?B?Qmpic2w5MThVTlpsQjN1NkpaTG9jWjc5ZFdiUkpmRnYwcUNORE1mLzJNZGpl?= =?utf-8?B?dWhqcytndkIyak01Q3g0RWQyczVjQVV5SFZYQjVlUlo4Y0x1S096clBKNDJD?= =?utf-8?B?eEVJSVdyZTdTZ3E2WGhoUk1oeFNmekI1aTg4Z1dzUnVuN3I4bzMvUWNEdEIy?= =?utf-8?B?TlZlM3JWa3NOVC9BdmU1UEJDLzJGWFYrU1dZaGFMT2pKZEtMV2ZWOG1SQWFI?= =?utf-8?B?L2JkTC91eFNWTVJVSmVDdnBxdmY5RGxseVg4K0ZKUldlb2ZSenlxVzZyMkdB?= =?utf-8?B?Y0h1L1MwUmlFeGI3ejVPOG1KTm43aGNPWk5TSHFkUVhFRUhtb2FqNHMrQjQy?= =?utf-8?B?K21OSWx0TEM1eTQzL1hkVW10R25YNThwM2dOUUlMNE9yYnZ2c3oyaW5yR2pa?= =?utf-8?B?QktYK3FNWDRkL0JaVXhjeFZieEpKWmJDYVpzYmVzWWFRUmdrVlNZcDFkcjk0?= =?utf-8?Q?FmNgeB01avlDruTjGJekgL+PoFQ57QwY0hpjSa8?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 1ca32a54-e631-4426-1b09-08d8d485778b X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2021 03:21:38.2224 (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: d4CMTz/J5YcXAcRjmTaJs7mIWAdeMZ06HgmshE5/2peB8QRYTMEwPcco4xe37dlGAQSAfvKj7+UBJ1e/TINX+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB5197 Archived-At: Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 19 Feb 2021 03:21:48 -0000 On 19/02/2021 07:04, Eliot Lear wrote: > What I meant was that in one instance, representation, the person is not free to choose to take a position but must refer to the body she or he is representing, while in the other case, delegation, the person is asked to make decisions on behalf of the body she or he is representing. Trying to avoid simple terms with ambiguous meaning. There are probably some more shades of gray: - Taking every decision back to the delegating body and just serving as a messenger. - Taking important decisions or decisions where it's not clear what the interest of the delegating body is back to that body. - Representing the interests of the delegating body on their own, but informally exchanging opinions with others in the delegating body. - Representing only the interests of the delegating body, but doing that on their own, i.e. without checking back. - Representing both the interests of the delegating body and the overall interest of the series (with similar variations as above). - Serving on behalf of a delegating body, but with a duty to care for the overall 'cause' first and foremost. In addition to that, it is well possible that people from different bodies will be selected with different criteria or purposes in mind. In some cases, such as the ISE, it will most probably the same person, and this person may have difficulties separating their ISE position from their position on the AB. Some bodies may select people who are good at coordinating back, and watch closely. Others may select people who they trust to do the right thing, and then not care anymore. My preference would be to have the AB members acting on their own (without direction) and both in the overall interest of the series as well as the specific concerns of their streams, in a balanced way. I think this is closest to what happens anyway in other, similar cases (such as the ex officio member of the IESG from the IAB,...), and is also closest to common sense. Regards, Martin. > Eliot > >> On 18 Feb 2021, at 20:50, Michael StJohns wrote: >> >> On 2/18/2021 2:33 PM, Eliot Lear wrote: >>> This brings up a separate issue that Mirja raised: are people serving on the AB as representatives or as delegates? >> >> Define those two terms as you mean them please - they mostly mean the same to me. >> >> Mike From nobody Sun Feb 21 16:59:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824333A0902 for ; Sun, 21 Feb 2021 16:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URDBj6w8ZEqK for ; Sun, 21 Feb 2021 16:59:03 -0800 (PST) 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 5F63B3A08C5 for ; Sun, 21 Feb 2021 16:59:03 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id l18so7904340pji.3 for ; Sun, 21 Feb 2021 16:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=xysiTxKQ97kSjhlkfOs2b+1mwGQW/b3vLw7hDou4V84=; b=bK/JBPxr596oODZXApC2kOHKcv7qmfO8dQl8/bDCHZFkxmV70OFQrPcwp6Q0a6ME3U ghfAnuqX7FML9w/iTVlBHWUyhGR6OtGEm3Ueqa1R4n96ZTgUjz/noV9PX/1wupKZdYXL /AXWMMvTmQmqF+IvwVB2wcQfw9kppOj74NfEFYjsePBpQYt2y/K7MphdD4RRquCcY004 pGb6fG2ECJEp61MOytVP/lght5ZsQje9ltfOxGeNaAlVD1sOjrHknaSgbnAplKWgYICP LmWAiwKBFWDthEkn+8uPsNnSlqfV7s95tBZPuOeInmwbXEzGlQRxJvu+HzaDUGuai+o7 hLCw== 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:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=xysiTxKQ97kSjhlkfOs2b+1mwGQW/b3vLw7hDou4V84=; b=BkLie91rTJFWyuUN4szojq4nwyUKFOS09z06hPzhjrL4wuCLArZNGONVGn8qLItM2w YIKxiMPTewgJhFeIB7Zo3RJS5TMGUR5Qc79AWdv+UuHpvSGFenS3ROdw0LliV+jikJB6 8KlOUo8D6ixNm/6BQeUA2rVSVmGoUnRzeK31NewndN4AKX1mmHE8uBiYgzq7+OyVkudQ Xwa0LqAOgA3/C6as+SKKXL3jfqkxP8TMrH+jP0sy+yY2I00f3hn67+ngUD5rO/oC6gQA b1hGnAOeXyLm+l/wDNFwdfUgt6rmEpXnHwJ1cECMm2PYlIGWCryhT5CwR7l2EFQRHZld 4vTQ== X-Gm-Message-State: AOAM53335nzBu84MO2uzm5iCt9pz3sDs/NRFrAwy91WHD8PuXJQ8khFD xH5zULVY490byh/EB61TRY8Gw5FgJW3jWg== X-Google-Smtp-Source: ABdhPJzJmaEzWPyHjg4oGyhxyU0ZxDCj7e5fCeg7ypqkBxFglx7Sitekv0m1+ihk6PX7twQWwvIWaw== X-Received: by 2002:a17:902:f1d3:b029:e3:fa5d:b0d2 with SMTP id e19-20020a170902f1d3b02900e3fa5db0d2mr1709408plc.26.1613955542524; Sun, 21 Feb 2021 16:59:02 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id f3sm15547462pgh.75.2021.02.21.16.59.00 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Feb 2021 16:59:01 -0800 (PST) To: rfced-future@iab.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <85478666-b379-cc66-26ec-061545bb26b9@gmail.com> Date: Mon, 22 Feb 2021 13:58:58 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] RSE = RFC Series Expert? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 00:59:05 -0000 I think this is an interesting list of experts. Their blog is a class act. Obviously the APA is a much bigger publishing operation than the RFC Editor, but one part-timer seems like a minimum for us: https://blog.apastyle.org/apastyle/apa-style-experts.html Regards Brian Carpenter From nobody Mon Feb 22 05:55:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AA63A07C0 for ; Mon, 22 Feb 2021 05:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NGG0OmYkc39 for ; Mon, 22 Feb 2021 05:55:45 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D9E3A07C8 for ; Mon, 22 Feb 2021 05:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3289; q=dns/txt; s=iport; t=1614002145; x=1615211745; h=from:mime-version:subject:message-id:date:to; bh=0/cbSrQwTYtnPdoW9dn6T3qzjjVGHGIAhShT46kHzQM=; b=IYwcl3bDXZafHtwYu690RK2RqcSwm9PFq1hYMpYqrQWPF7fvOhb7FmEx n2g1QwCb64k1np597RuOGrI+m3obWLTYDP3XaHWa9JjE0uxwh5sYNvod/ lGzbbL7pcB4yTfrNYlSpu9gtwOkWww/oknu9YXKiheWF++L8dIiKmhF23 U=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AKAwDNtjNgjBbLJq1iHgEBCxIMggQLgyFWATmEcokEn?= =?us-ascii?q?QWGIYF8BAcBAQEKAwEBLAgEAQGECYJUJjYHDgIDAQEBAwIDAQEBAQUBAQECA?= =?us-ascii?q?QYEFAEBAQGGOg2GbnUBKxICg10BgwYPnxaOHHaBMoQ/AU8FhSQKBoE4gVOFK?= =?us-ascii?q?AGHB4ICgTgcgUGBFoMbAYItAoJHNIIrBIMuU2YLAp5anE+DBQSDK4E8hFOSW?= =?us-ascii?q?gMWCZNLj3mffpJmg3MCBAYFAhaBWgExgVkzGggbFWUBgj89EhkNjjiDVopaQ?= =?us-ascii?q?AM6LQIGAQkBAQMJiXWCHgEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,197,1610409600"; d="asc'?scan'208,217";a="33571411" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Feb 2021 13:55:40 +0000 Received: from [10.61.193.230] ([10.61.193.230]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 11MDteTf005252 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 22 Feb 2021 13:55:40 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_2B834C42-0D1B-4A4E-B98D-66637EC50B3B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Mon, 22 Feb 2021 14:55:39 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.193.230, [10.61.193.230] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Recording for last 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: Mon, 22 Feb 2021 13:55:47 -0000 --Apple-Mail=_2B834C42-0D1B-4A4E-B98D-66637EC50B3B Content-Type: multipart/alternative; boundary="Apple-Mail=_6394F44A-1415-4BFB-BCE7-2394D57EA123" --Apple-Mail=_6394F44A-1415-4BFB-BCE7-2394D57EA123 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, Thanks for attending last week=E2=80=99s interim. For anyone who missed = the meeting, or anyone who attended and liked it so much that they=E2=80=99= d like to repeat the experience, you can find the recording here = . The password is jPFp4pjW. We=E2=80=99ll have draft minutes out in a few days. Eliot --Apple-Mail=_6394F44A-1415-4BFB-BCE7-2394D57EA123 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone,

Thanks for = attending last week=E2=80=99s interim.  For anyone who missed the = meeting, or anyone who attended and liked it so much that they=E2=80=99d = like to repeat the experience, you can find the recording here.  The = password is jPFp4pjW.

We=E2=80=99ll have draft minutes out in a few = days.

Eliot
= --Apple-Mail=_6394F44A-1415-4BFB-BCE7-2394D57EA123-- --Apple-Mail=_2B834C42-0D1B-4A4E-B98D-66637EC50B3B 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAzt9sACgkQh7ZrRtnS ejP7YQf/b+1yVZf5zAkcdv7795ROtWydZyHyj2JTUlzyiZOx+xA14CsjvkuaUcP0 6JmK5aeARbJ6sHzuPwcjEO8HeHqnKDovGtdOkI7u2/q9UqPLvHpfX5DW0QsiUe5h 2oumtGrxV0ce0JiFEd/ooaeG1P5MA8N5CgyB9XGDvwDaw3trYKy5B+awM9sVkJfN yPEJu5mKPlGerjkxllZmgqkPh8s9sslSId92e/IIKRRNhVkYYondId1mHNf+gazv 04Tnhg/UQMXj1bMUb3htVFNLhWPOEDns5lHBHcF4FfE8l44AquNGNclMG1g+R5lk ZNpyPaZ3Py+boeuW+BjfVxCJoeXn6g== =s4Jw -----END PGP SIGNATURE----- --Apple-Mail=_2B834C42-0D1B-4A4E-B98D-66637EC50B3B-- From nobody Mon Feb 22 09:05:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0333A1DEB for ; Mon, 22 Feb 2021 09:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ufvwzr30fxyB for ; Mon, 22 Feb 2021 09:05:18 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE1E3A1E85 for ; Mon, 22 Feb 2021 09:04:52 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lEEdf-000IcW-5z; Mon, 22 Feb 2021 12:04:51 -0500 Date: Mon, 22 Feb 2021 12:04:45 -0500 From: John C Klensin To: Brian E Carpenter cc: rfced-future@iab.org Message-ID: In-Reply-To: <85478666-b379-cc66-26ec-061545bb26b9@gmail.com> References: <85478666-b379-cc66-26ec-061545bb26b9@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] RSE = RFC Series Expert? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 17:05:20 -0000 Brian, Yes. It may be worth noting that most professional societies that publish one or more journals or similar publications (online or off), including ACM, IEEE, or, to venture a bit further across the pond, the Royal Statistical Society, the International Statistical Institute, and many others have similar groups, often extending well beyond style and perhaps organized differently. And, of course, so do ISO and ITU and, as far as I know, every major technical or scientific publisher. A more interesting question for us might be _why_ they have them. There is a short answer using your example and that may be worth thinking about. Expertise in psychology -- either writing about it or reading materials about the subject-- does not imply expertise in publications, writing style, or, in many cases, even terminology. It is entirely reasonable to trust IETF consensus in matters of networking and network technology within its scope. Believing that IETF consensus is the best way to make decisions or even means anything when the vast majority of IETF participants have little or no publications expertise other than maybe having written Internet Drafts that become RFCs or having read RFCs and many other things (in one or more languages) is, at best, a little strange. best, john --On Monday, February 22, 2021 13:58 +1300 Brian E Carpenter wrote: > I think this is an interesting list of experts. Their blog is > a class act. Obviously the APA is a much bigger publishing > operation than the RFC Editor, but one part-timer seems like a > minimum for us: > > https://blog.apastyle.org/apastyle/apa-style-experts.html > From nobody Mon Feb 22 09:11:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12293A1E37 for ; Mon, 22 Feb 2021 09:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xyAB-5_kzk0k for ; Mon, 22 Feb 2021 09:11:13 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0873A1E2B for ; Mon, 22 Feb 2021 09:11:11 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DkpcF21fCzyTK; Mon, 22 Feb 2021 18:11:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <85478666-b379-cc66-26ec-061545bb26b9@gmail.com> Date: Mon, 22 Feb 2021 18:11:07 +0100 Cc: rfced-future@iab.org X-Mao-Original-Outgoing-Id: 635706667.574261-79157e7bc5a01fdce13fd1c71bafdb6d Content-Transfer-Encoding: quoted-printable Message-Id: <94C958E2-5B42-4D7D-B3F1-7D0A9669F94A@tzi.org> References: <85478666-b379-cc66-26ec-061545bb26b9@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] RSE = RFC Series Expert? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 17:11:23 -0000 On 2021-02-22, at 01:58, Brian E Carpenter = wrote: >=20 > I think this is an interesting list of experts. Their blog is > a class act. Obviously the APA is a much bigger publishing operation > than the RFC Editor, but one part-timer seems like a minimum for us: >=20 > https://blog.apastyle.org/apastyle/apa-style-experts.html Yes, and then we still need the RFC editor for all the non-style work. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Feb 23 02:52:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4233A142D for ; Tue, 23 Feb 2021 02:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBwfwn8XYPM2 for ; Tue, 23 Feb 2021 02:52:47 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833613A140F for ; Tue, 23 Feb 2021 02:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2080; q=dns/txt; s=iport; t=1614077566; x=1615287166; h=from:mime-version:subject:message-id:date:to; bh=sMFu5dy0Vvyzzt2VQZFGaUW8ijTIu56/DWmx9W0bCXo=; b=juMd8d9LRRvXDzTam0WGiH6sywiSsDRG3C0IGAJW3nCoyLcSQEKtbUQb NrF+tpgPf3XGYcpmyyJhWpj5qm2LV1oGt0IX2BwZykjiUY0Hb1QK00ESj L5XMWgQis/Wx1BdqD65IwMqu8UPkcwRFqPRXvL7vQ7O7N9K6k1n4eOQL9 M=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AcAAAL3jRglxbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?T0FAQELAYMgVgE5MY1FnQSGBRyBfAQHAQEBCgMBASwIBAEBhkYmNgcOAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGNg2GO4EnAQKEGwGDBg+gEo4cd?= =?us-ascii?q?IE0hEMCAQ1BhSkKBoE4AYFShSmHCIICgTgcgioBg0cCAwGCKIJ9gisEgy5TZ?= =?us-ascii?q?gueXpxPgwUEgyuBPIRTkloDH5NMj3mff5Jmg3MCBAYFAhaBWwsmgVkzGggbF?= =?us-ascii?q?WUBgj4TKxIZDY44iGqFRkADLwI2AgYKAQEDCYwTAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,199,1610409600"; d="asc'?scan'208,217";a="33659121" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Feb 2021 10:52:38 +0000 Received: from [10.61.192.153] ([10.61.192.153]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 11NAqbL7018991 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 23 Feb 2021 10:52:38 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_01481A4C-BADC-4351-BDC3-0A949981D614"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <74B17A18-BE81-4BB4-B6E4-8715DDF8A6A0@cisco.com> Date: Tue, 23 Feb 2021 11:52:35 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.192.153, [10.61.192.153] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Draft minutes posted X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 10:52:49 -0000 --Apple-Mail=_01481A4C-BADC-4351-BDC3-0A949981D614 Content-Type: multipart/alternative; boundary="Apple-Mail=_80441D3E-10C3-4753-8487-2896F64B1BC1" --Apple-Mail=_80441D3E-10C3-4753-8487-2896F64B1BC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You can find them here = (in markdown here = ). --Apple-Mail=_80441D3E-10C3-4753-8487-2896F64B1BC1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii You can find them here (in markdown here). --Apple-Mail=_80441D3E-10C3-4753-8487-2896F64B1BC1-- --Apple-Mail=_01481A4C-BADC-4351-BDC3-0A949981D614 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmA03nMACgkQh7ZrRtnS ejNIJwgAguHOxB7w3IcDb5k1hxm1OL9/Q8LQL9QIEk4FND1GA6vydYT9U5KFxYFr NR1IBpxLTHwlhV95TWwIrzcRoInKa3GkXXneHss2Yc+0Lg9/bBTCnfLlGesCLEvr x1V8llsVIzYLyL3RDMJLU+TGmoSIzCiHF9Ufo4buDFMLBW/NLshzZ3+NB9KhhPF2 Wqg+e0BEcVmj7BOkM0F+NxljBDU7M1Qb36G/E/c8G0FodaLOaWJbpALTn9i940KM 3DZl3bZv1elgjVyjrQZ8NLrT4p2jc7TbcpuZeMPmJBBlbPXl/mGHGTcYKZ/nhF0h gLYQNLj91s647mY7dk826JZ6PWGSAQ== =GZ+j -----END PGP SIGNATURE----- --Apple-Mail=_01481A4C-BADC-4351-BDC3-0A949981D614--