From nobody Wed Apr 1 02:02:22 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE0B3A0800 for ; Wed, 1 Apr 2020 02:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY6QGft-qsyd for ; Wed, 1 Apr 2020 02:02:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41913A07F7 for ; Wed, 1 Apr 2020 02:02:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A250DBE2E; Wed, 1 Apr 2020 10:02:13 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVmQCT0MLWHD; Wed, 1 Apr 2020 10:02:12 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 068BABDCF; Wed, 1 Apr 2020 10:02:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1585731732; bh=WfFoL2dFgDXkSSY97e0764Qz+EXMKPtmWpeGxHvs674=; h=Subject:To:References:From:Date:In-Reply-To:From; b=S6uxoPdNR//ehxx1RZa20dMkbXwS1CF/L0sseLpIpYN7bq0eTSgwD1ZZ53uZQyJnA np64ucX/Xollta76jjusStOO0w6HI55/VqzoV4HEUU0FooG4QEf1WtyKGeu7Iwp2Jo M4pWpRay+h1azGuMYUL35zBb2J0NCHA/n7H3GoQ4= To: Eliot Lear , rfced-future@iab.org References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 1 Apr 2020 10:02:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MkpMUCBpwMivOHKyZoLs5sz8Tvw8cuBn7" Archived-At: Subject: Re: [Rfced-future] Welcome to the romp! A reminder of what I would like us to decide first... X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 09:02:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MkpMUCBpwMivOHKyZoLs5sz8Tvw8cuBn7 Content-Type: multipart/mixed; boundary="huMGyJAfskrmMWIffFjVqMLLPQviOO5nl"; protected-headers="v1" From: Stephen Farrell To: Eliot Lear , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Welcome to the romp! A reminder of what I would like us to decide first... References: In-Reply-To: --huMGyJAfskrmMWIffFjVqMLLPQviOO5nl Content-Type: multipart/mixed; boundary="------------E4A69A77B9215873C3434AC2" Content-Language: en-US This is a multi-part message in MIME format. --------------E4A69A77B9215873C3434AC2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/04/2020 07:34, Eliot Lear wrote: >=20 > Should the program worry about the structure of the series or should > the program worry about putting in place someone who could lead the > community in worrying about the structure of the series (among other > things)? I think the focus ought be on the latter, or more precisely on defining that role and it's accompanying setup rather than on the direct "putting in place" of a person to fill the role. I hope this process produces an accepted method for the "putting in place" bit but doesn't aim to actually run the hiring process;-) > A related question: >=20 > Should we establish a process that addresses series evolution over > time or should we leave that for later? Personally, I think we ought keep in mind that we are dealing with a 50-year old artefact (the series) that I at least would like to see setup so it could continue for another 50 years, should the content of RFCs in the series continue to be relevant. 50 years is too far into the future to be fair, but I'd like us to aim to set things up so that could happen and I figure that means we need to define the RSE role with that in mind. Concretely, I think that implies some level of independence from IETF process-change may be needed for the RSE - but I don't claim to know how that might best be done. Cheers, S. --------------E4A69A77B9215873C3434AC2 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------E4A69A77B9215873C3434AC2-- --huMGyJAfskrmMWIffFjVqMLLPQviOO5nl-- --MkpMUCBpwMivOHKyZoLs5sz8Tvw8cuBn7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6EWJMACgkQWrL68XsX K+pooRAAjGOdygp/UmNCwf4y+B0F6RRaFqgdhWmGhw7X+F9BHvtE7MoOE+Ee/JCf P9LFSeM8/eC8ExK/fndGwNNB8YE8x+mc7x6FUVJgSp6BFxrOL+mFOZHg7ebF+1gx xR0fOk+b44FiuY55B6oJe6qTl+aJHq2bsgC6vTMw+5WZX8WqSzklY+ZtWe08AOIi VqdX+iEZU8ZV50F1tbafDR7KEayA12tubMTXPrQSOQuzCF+rQ8Z2AUo8goi5tqVH nI/6cs4qmcQAyVhraYceiArFomvQr6kiFRYakLLval2SNtusCs4VSuVBpWUFR6bw XTCCukwTfru6fvwoyVTyNkoSRbcHRb3wfsd+9glcy7tvayVMOP4Tnq0UwqhCbHeB kgfxSsVbU11jEr9CbiuYui12DY9lA/kgxNnYLsptvB7XwWEdjqGlJiqQbY/tVP3y 3GtQDP52NAjcEiq6LDz0XV/l3x1AqwzvcpqDI/PxX+NQRShmLt3wzkz+XnvSXxHk A7KUbESDHdJrCgpB18Nr9L46EmJnQ4BjHiE9uouowjP+b8SkyLtrw9N8HtU4Wqch eE2qJXQQfXT6aNk4qjNtxvIKt/rTv8et5jUO4G9PhK1ZPtfr+1TFH+SviPRcaTn9 C7uxDczj6la/8QsQTDk+52ak4NJw0kyoFFiGfs0l6Ckz891MAzQ= =rGwB -----END PGP SIGNATURE----- --MkpMUCBpwMivOHKyZoLs5sz8Tvw8cuBn7-- From nobody Wed Apr 1 10:47:12 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B6B3A148C; Wed, 1 Apr 2020 10:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaLgmkmX1DpY; Wed, 1 Apr 2020 10:47:07 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8823A1488; Wed, 1 Apr 2020 10:47:07 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jJhSB-00028y-GQ; Wed, 01 Apr 2020 13:47:03 -0400 Date: Wed, 01 Apr 2020 13:46:57 -0400 From: John C Klensin To: Jari Arkko , Eliot Lear cc: rfced-future@iab.org, IAB Message-ID: <4C3D0687FFB29333C9ED2F64@PSB> In-Reply-To: <6C53846B-21A4-41E2-AA5F-4E9EA2FB27BB@piuha.net> References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <0E6D83F8D11D8C1B9B7237B7@PSB> <73C27FFD-BD81-4CF3-9D9D-845DE9544A36@cisco.com> <097a60d7-2229-b849-1ca3-1f6d298cceed@nthpermutation.com> <16726C73-09AB-4F61-8C00-8224E3EF6F1B@mnot.net> <6C53846B-21A4-41E2-AA5F-4E9EA2FB27BB@piuha.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] [IAB] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 17:47:09 -0000 --On Wednesday, April 1, 2020 00:11 +0300 Jari Arkko wrote: >> Should the program worry about the structure of the series or >> should the program worry about putting in place someone who >> could lead the community in worrying about the structure of >> the series (among other things)? > Definitely the latter. Jari, I think it is not as simple as the dichotomy in Eliot's question implies. I'd like to assume, perhaps incorrectly, that the "among other things" in that question implies the kind of expertise in publications and editorial strategy that were part of Heather's job description. If that is true, then getting such a person in place is going to require a job description that is sufficiently specific to allow recruiting the type of person we want (and excluding others). Stephen's comment about the relationship to the RPC is actually a good example of that. I'll respond to that suggestions separately to keep this one from becoming long, but the answer, one way or the other, changes the RSE role significantly enough to probably make some people qualified under one conclusion and others qualified under either. Of course we could write a job description that said "well, maybe this will change and be added or deleted from the job", but my experience, including with people with whom we discussed the job that was ultimately given to Heather, is such as statement will cause otherwise-qualified possible applicants to decide it is not a job that they want. On the other hand, if the only role we care about is to "lead the community in worrying...", then almost anyone in the IETF with a history (and wide community recognition and respect) of being able to lead efforts, foster consensus, and stay personally balanced on the issues rather than, even unintentionally, trying to drive conclusions one way or the other could do the job -- no specialized technical publications strategy background required. As an obvious example, you would be excellent if you were willing to take it on and had the time. The other problem, of course, is that going very far in that direction might mean we wouldn't have an RSE in place until the middle of 2021, if we concluded we need an RSE at all. best, john From nobody Wed Apr 1 13:18:27 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CDD3A064A for ; Wed, 1 Apr 2020 13:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Prj8tiFfC_8s for ; Wed, 1 Apr 2020 13:18:23 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744F93A060D for ; Wed, 1 Apr 2020 13:18:23 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id k3so554448pjj.2 for ; Wed, 01 Apr 2020 13:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=E7MkzUs0l2k2USgsFMUdb5l1q1Nh33zbR3YF2rprBoY=; b=oEP0lK7IQisZL5W6AV7Lvo4tMqVtg8m1d/Pydqbxy3PsgU/Xpb29Nw+SSisPacVC09 uTiZIx4UfGC5TQ8ssGI9f2Bd341mXdVJfS1/Jo+9l8n/gNquv9+yZ6UIwDLj0xE/IBid 3Wzw3Jfjos9L18WERmhjeS35ZtYT0Rs44U+niKQpjWkptkwcGf01QpBi5cuNaQbWnc22 bcyDfT8UzPy9Hnq4kVBMQUnY3wzEQP+f/BNxRp+h/rLzbw5aO2zgbq+0iYviXBdZXYeR xDGK0UL+AQuC2Oyk/uAYl7t99U6bg596gC8ed2cVnTJLTpEiR3DN3A9B8dHXs2i6++4x UeuA== 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=E7MkzUs0l2k2USgsFMUdb5l1q1Nh33zbR3YF2rprBoY=; b=jHMDnEEh+cbx7PogzFeHq/2XmbzDCPjfdLgORG4KAk5mfWtqZVC2QBl1fKjLagLadk LESP5lbse+M8Qmgj/skrdavRiPQmYJHsYjunNg4xFVr63/QS82ydVPSw9pnbakXlbXYC rntH2d7T/vNGcYz4lIEUaULmZ+XVs2nLZR6jAYss9WwENApoku5DeEbLP+mD/6Hnman/ ZYOyYqlQ2u33/wpPF8Tkc1nYL9psVsymKjiILKp3RB3GKZDhoEmhcR2RvlbOjQub40iR Hgs+1IU7gAOGG5f7BC8Te/W3Sys65ckkZpVP1MGdMdUDJGw1L07ZwIytnPhDgl0KBEf6 80Bw== X-Gm-Message-State: AGi0PuaqfN2PnxEQTifDZ79U1f2pwZabNjc3ilQjfTjG+yCU9yVAnUFx 2+d2Dos95Fr6nOSyeEpfhROhui53 X-Google-Smtp-Source: APiQypLV+jWihw0xrN5faV1uV2rtTs9/vBJoqM2NdZSL8lY3wGKOkSM2zE4E+UeZbFhvwtrl5hfNWw== X-Received: by 2002:a17:902:34f:: with SMTP id 73mr10076123pld.50.1585772302212; Wed, 01 Apr 2020 13:18:22 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id c190sm2196499pfa.66.2020.04.01.13.18.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 13:18:21 -0700 (PDT) To: Stephen Farrell , Eliot Lear , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: Date: Thu, 2 Apr 2020 09:18:17 +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] Welcome to the romp! A reminder of what I would like us to decide first... X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 20:18:25 -0000 On 01-Apr-20 22:02, Stephen Farrell wrote: > > > Hiya, > > On 01/04/2020 07:34, Eliot Lear wrote: >> >> Should the program worry about the structure of the series or should >> the program worry about putting in place someone who could lead the >> community in worrying about the structure of the series (among other >> things)? > > I think the focus ought be on the latter, or more precisely > on defining that role and it's accompanying setup rather > than on the direct "putting in place" of a person to fill > the role. I hope this process produces an accepted method > for the "putting in place" bit but doesn't aim to actually > run the hiring process;-) Agreed. But in addition to role & responsibilities, I think we need to be clear about (as was said yesterday) the checks and balances on the role, and how the role relates to the community. As Christian Huitema pointed out more than once, the community for the RFC series is not well defined. But I don't see how we can get very far without some notion of what that community is and how to have a conversation with it. >> A related question: >> >> Should we establish a process that addresses series evolution over >> time or should we leave that for later? > Personally, I think we ought keep in mind that we are > dealing with a 50-year old artefact (the series) that I at > least would like to see setup so it could continue for > another 50 years, should the content of RFCs in the series > continue to be relevant. 50 years is too far into the > future to be fair, but I'd like us to aim to set things > up so that could happen and I figure that means we need > to define the RSE role with that in mind. Concretely, I > think that implies some level of independence from IETF > process-change may be needed for the RSE - but I don't > claim to know how that might best be done. Indeed. Another way of looking at it is: Which bits of RFC8728 and 8729 (and possibly 8730) are we interested in changing as a result of this conversation? (See https://www.rfc-editor.org/rfc/rfc8728.html#model-figure for example.) Stay well, Brian From nobody Wed Apr 1 13:28:39 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FA13A07BF for ; Wed, 1 Apr 2020 13:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAxgEF7CbQbq for ; Wed, 1 Apr 2020 13:28:37 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7FD3A07C2 for ; Wed, 1 Apr 2020 13:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8903; q=dns/txt; s=iport; t=1585772916; x=1586982516; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=fOVuBNSYu4JMmjaAqhJUBNyZ5MCNYSOMuhqT8fTqmus=; b=BnaIBMNnJ3USikSrVxYMSr9+gm6yKjml4XrDtDizK2Br8rPxXwYdBjXD R9n5eLh4ohnyYq9HEoyeXtzmGqSuLDVQFzLnNpaV/7lXQkSk8J6Dsx04h gUUJmazd4J7g0vsCWcEkQJxQz9D4i44q1br7QDfmiDMEeB733CEyvUFXw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxAAA4+YRe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWcHAQELAYEkgXBVIBIqhBqIImCIFYlsiVCGD4F7CgEBAQwBASM?= =?us-ascii?q?MBAEBhEQCglw0CQ4CAwEBCwEBBQEBAQIBBQRthVYMhXABAQEBAgEjQhQFCws?= =?us-ascii?q?YKgICITYGExSDEgGCSwMOIA+uMnWBMoVLgmMNghoGgTgBjEqCAIE4IIIfLj6?= =?us-ascii?q?CHjAZBIR1MoIsBLAIMkaCR4JckAaEPh2PMYxBmn6NAoM1AgQGBQIVgVI5gVg?= =?us-ascii?q?zGggbFTsqAYJBPhIYDY4pFxWIT4VDPwMwAo8zAQE?= X-IronPort-AV: E=Sophos; i="5.72,332,1580774400"; d="scan'208,217"; a="24971432" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2020 20:28:31 +0000 Received: from [10.61.170.180] ([10.61.170.180]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 031KSRAZ008318 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Apr 2020 20:28:29 GMT From: Eliot Lear Message-Id: <482A3273-124A-43AC-BD1C-567F4732C75C@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B984D002-61F7-46CF-9DF9-60367BF998A3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 1 Apr 2020 22:28:27 +0200 In-Reply-To: Cc: Stephen Farrell , rfced-future@iab.org To: Brian E Carpenter References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.170.180, [10.61.170.180] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Welcome to the romp! A reminder of what I would like us to decide first... X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 20:28:39 -0000 --Apple-Mail=_B984D002-61F7-46CF-9DF9-60367BF998A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian, > On 1 Apr 2020, at 22:18, Brian E Carpenter = wrote: > But in addition to role & responsibilities, I think we > need to be clear about (as was said yesterday) the checks and > balances on the role, and how the role relates to the community. > As Christian Huitema pointed out more than once, the community for > the RFC series is not well defined. But I don't see how we can get > very far without some notion of what that community is and how to > have a conversation with it. I have thoughts at least about how to ask that question of this program, = and will propose them in due course. But I do not believe that it has = to be the first question answered. Not to worry. I don=E2=80=99t see = it as that far away. > Indeed. Another way of looking at it is: Which bits of > RFC8728 and 8729 (and possibly 8730) are we interested in > changing as a result of this conversation? > (See https://www.rfc-editor.org/rfc/rfc8728.html#model-figure = > for example.) Which brings us back to the work plan. The basis by which we answer = that question is to understand precisely what we think could stand = improvement. What are we trying to solve for? I speak of this at a = high level, but I am quite certain that everyone on this list could come = up with at least three or four items that they would class as problems, = challenges, or opportunities. I think our next step is me asking that = very question, and everyone taking some time to think about what are the = issues we need to address. Eliot --Apple-Mail=_B984D002-61F7-46CF-9DF9-60367BF998A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Brian,



On 1 Apr 2020, at 22:18, Brian E Carpenter <brian.e.carpenter@gmail.com> = wrote:
But = in addition to role & responsibilities, I think we
need = to be clear about (as was said yesterday) the checks and
balances on the role, and how the role relates to the = community.

As Christian = Huitema pointed out more than once, the community for
the = RFC series is not well defined. But I don't see how we can get
very far without some notion of what that community is and = how to
have a conversation with it.

I have thoughts = at least about how to ask that question of this program, and will = propose them in due course.  But I do not believe that it has to be = the first question answered.  Not to worry.  I don=E2=80=99t = see it as that far away.

Indeed. = Another way of looking at it is: Which bits of
RFC8728 and 8729 (and possibly = 8730) are we interested in
changing as a result of this conversation?
(See https://www.rfc-editor.org/rfc/rfc8728.html#model-figurefor example.)

Which = brings us back to the work plan.  The basis by which we answer that = question is to understand precisely what we think could stand = improvement.  What are we trying to solve for?  I speak of = this at a high level, but I am quite certain that everyone on this list = could come up with at least three or four items that they would class as = problems, challenges, or opportunities.  I think our next step is = me asking that very question, and everyone taking some time to think = about what are the issues we need to address.

Eliot

= --Apple-Mail=_B984D002-61F7-46CF-9DF9-60367BF998A3-- From nobody Wed Apr 1 13:54:59 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37883A040E for ; Wed, 1 Apr 2020 13:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELgkR00LLwpw for ; Wed, 1 Apr 2020 13:54:55 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B663A040B for ; Wed, 1 Apr 2020 13:54:55 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id ay1so477745plb.0 for ; Wed, 01 Apr 2020 13:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+KTRpZL7f5CCTsbp7KwRRUwHRw+3GHAy1Fg5jGZXW/0=; b=rzPzcdKwsOlYdzFiiC1PsuGgXHyqnFNwOcGZOhEo0S20vu4XIpMz6s6YLIFEu5VBdL QrUHA3m9PFiDh6UStNYGrIe2RoBwlOOZm4GUr8fJesjl8nYx0aLDhF3OCqa/RpWmeLPM OfCByNXSm2cIjajfxPC0u9mGihF657hOq//OkhP1mn/uAQ1kM64kByI7Yy2dtx3cBR1z hZBtar0fEqYgmO54BEXB5+Vjpd+NZeICgbNnCaYGtYfw7pI3A40+EFdiL54d59G7QWSo NURG3JUi3qRseLIaXZhsXHm6A19KO7a7U+Na3YB7c7II7rQPF1M7RG8cy7852XKf5lX4 fiiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+KTRpZL7f5CCTsbp7KwRRUwHRw+3GHAy1Fg5jGZXW/0=; b=ubu8ZFoVHozwfEX4y6Gbkg1Be318X8BRnUKJirW6Ec94g+wDEkv6NLCdaj2p2DVsRu cesk8rxKc2vKdwmak8nuc51VVBJEzhz1jkcXKnaQmdvMyJk8f99E0YPK0q/qxjRVuycq q+Sot38yzxZobVDl5W5SR7E8bgCDonFmpZfOK2rUUfwTk0DuG0XUIhOjh4ncQEbdyDrF w6UwdCuba3m9O4EiOpQk/+G9/1LghLLiGbmdmhJboyqfTfEek9oroBXyGVkBP0OZqqpg UdRD+KiZO75JRgWhhgyoNlzbKYb7Vm9aXLhDifTxTBC4ydO70cz66Y5Vgy6ZvCIsv1eg j2Jw== X-Gm-Message-State: ANhLgQ3nYX0pOqtH5WWeyE3Ne1a5NrSKv91+H2ioVe5MpfF/vZM8MplF m5B1ZXgtx7CR2MwvgNVQTqnuxSgf3nmknJo= X-Google-Smtp-Source: ADFU+vt0ZCWst9HdP9V8G+ylAi1tu3eKVOzugk8d/qNS+vx81kIy9x2D/+2FABIm4fpNb1TM4YkvgA== X-Received: by 2002:a17:902:b088:: with SMTP id p8mr24662299plr.106.1585774494646; Wed, 01 Apr 2020 13:54:54 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id e187sm2230297pfe.50.2020.04.01.13.54.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2020 13:54:54 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org References: Organization: http://SoftwareAndServices.NET Message-ID: <64a845e5-ad60-04da-66c7-ce084693cb8d@gmail.com> Date: Wed, 1 Apr 2020 14:54:53 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Welcome to the romp! A reminder of what I would like us to decide first... X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 20:54:57 -0000 Has "what went wrong" been defined? Fixed? I saw a lot of opinions. I don't recall a conclusive resolution or definition. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Wed Apr 1 14:39:49 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371043A0C10 for ; Wed, 1 Apr 2020 14:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOMNEoZe4Boo for ; Wed, 1 Apr 2020 14:39:45 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C8A3A0C09 for ; Wed, 1 Apr 2020 14:39:44 -0700 (PDT) Received: (qmail 70668 invoked from network); 1 Apr 2020 21:39:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1140a.5e850a1e.k2004; bh=NqPiwmt60z40cN3siU2aDtSA9I9v7MLD337NGofRWtg=; b=bTp1JOeZQjibe/OU9bKqvSxyJP/TBi7eL2973DRxyxjwicWmYY47GG7T5EZy8nh7COvSK6EPU1E6J1aboeTq7uPpTyW6vF0I2gbOn9HZCLD7g1fhI3tHQHW1YWUBrhdpAT/LMZT7Oq+kLZlxU7l5Peit4puTIvY/r95Z723wPpNI091Gy6y9nNgHzxUn2oy8Sw20l+/Qxe6a3kz/RuFWTDIK1a5zvqcyjH0sJhwa0i+/g+VrckKD7suaNuhcQIUG Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Apr 2020 21:39:42 -0000 Received: by ary.qy (Postfix, from userid 501) id 01A8C16E35CC; Wed, 1 Apr 2020 17:39:41 -0400 (EDT) Date: 1 Apr 2020 17:39:41 -0400 Message-Id: <20200401213942.01A8C16E35CC@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: john-ietf@jck.com In-Reply-To: <4C3D0687FFB29333C9ED2F64@PSB> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] [IAB] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 21:39:47 -0000 In article <4C3D0687FFB29333C9ED2F64@PSB> you write: >I'd like to assume, perhaps incorrectly, that the "among other >things" in that question implies the kind of expertise in >publications and editorial strategy that were part of Heather's >job description. ... Hi from not-Heather. While Heather definitely knows a lot more than I do about publications and libraries and archives, I'm finding issues about XML and tools where it's useful to have a technical understanding of what the tools do and how they work. We need to think about the long term implications for an archival series of having our own semi-custom document format and custom tools, which needs understanding of both what it means to be archival, and the inevitable issues of software bitrot. So while I certainly agree that the position needs specific skills that typical IETFers don't have, let's not try and pin down details yet. R's, John From nobody Wed Apr 1 15:23:45 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D803A1078 for ; Wed, 1 Apr 2020 15:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpOuEvSKLHiU for ; Wed, 1 Apr 2020 15:23:42 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBE43A107E for ; Wed, 1 Apr 2020 15:23:41 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jJllp-0002hH-Mm; Wed, 01 Apr 2020 18:23:37 -0400 Date: Wed, 01 Apr 2020 18:23:30 -0400 From: John C Klensin To: Stephen Farrell , Eliot Lear , rfced-future@iab.org Message-ID: <612878B544D3F4BD620D9650@PSB> In-Reply-To: References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:23:43 -0000 --On Tuesday, March 31, 2020 22:02 +0100 Stephen Farrell wrote: > > Hi Eliot, > > I'm sure this'll not get forgotten but just to get it > on the table... > > In earlier discussions there seemed to be relatively > broad agreement that the idea that the RSE should be > responsible for the day-to-day performance of the RPC > was outdated, esp. now that we have the LLC. > > So I think revising that part of the RSE role description > is something that should be part of this. Just a comment (the one promised in my note to Jari hours ago -- long day) for the same table. The path we followed in moving from one (or 1 3/4) RFC Editor(s) and staff to separate RPC and RSE functions may turn out to be important here. Some of that is in RFC 8700, particularly Section 3.5. The rest can probably wait for a later date or is not important. The thing that is important is that a traditional (since the split) part of the RSE's role is to make decisions --often in conjunction with decisions with RPC staff-- that can affect most measurements of RPC day-to-day performance. Most of these are small but, especially as we go through the transition process to the new format, others involve quite fundamental decisions about the tradeoffs about Series quality and getting things right for the long term versus document throughput. Having the RPC report and be accountable directly to the IETF Admin LLC Exec Dir while the RSE is accountable to or via some other structure is plausible. Many of us have "day job" experience with similar management arrangements (often described as "matrix management" or in other terms). Sometimes they work. But requiring that the RSE negotiate essentially technical (although publications-technical, not network engineering-technical) decisions with an Exec Dir who is charged with managing day-to-day performance, especially if that is done in quantitative terms, could easily put us into a situation we'd come to regret and, even sooner, change the profile of otherwise-qualified people who would be willing to apply for the RSE position. So, yes, I think we need to review those relationships. And, in the context of my response to Jari, I think we need to nail down what we want (even if it is "no change" in order to write a job description. But let's be careful, especially so because at least a few of us think that part of what got us into this situation was assuming that the RSE was just another contractor who could be evaluated, subjected to competitive bids across a broad number of qualified bidders, and then selected and obtained/managed the same way we issue an RFP and contract for a barrel or two of nails or even a spool of fiber cable. best, john From nobody Wed Apr 1 15:31:15 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A803A10DA for ; Wed, 1 Apr 2020 15:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZDateVQOvYg for ; Wed, 1 Apr 2020 15:31:12 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B773A10D8 for ; Wed, 1 Apr 2020 15:31:11 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jJlt6-0002i3-PE; Wed, 01 Apr 2020 18:31:08 -0400 Date: Wed, 01 Apr 2020 18:31:02 -0400 From: John C Klensin To: Stephen Farrell , Eliot Lear , rfced-future@iab.org Message-ID: <82F388AF9DAA84ED39D1E378@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Welcome to the romp! A reminder of what I would like us to decide first... X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:31:13 -0000 --On Wednesday, April 1, 2020 10:02 +0100 Stephen Farrell wrote: >> Should we establish a process that addresses series evolution >> over time or should we leave that for later? > Personally, I think we ought keep in mind that we are > dealing with a 50-year old artefact (the series) that I at > least would like to see setup so it could continue for > another 50 years, should the content of RFCs in the series > continue to be relevant. 50 years is too far into the > future to be fair, but I'd like us to aim to set things > up so that could happen and I figure that means we need > to define the RSE role with that in mind. Concretely, I > think that implies some level of independence from IETF > process-change may be needed for the RSE - but I don't > claim to know how that might best be done. Strongly agreed. Let me add something that, given your comment about IETF process changes, you may have had in mind: If we are trying to aim for 50 (or more) years, the structure and mechanisms should be sufficiently robust and flexible to adapt to either or both of the following extreme events: (1) The IETF, at least the IETF as we know it as a SDO with a collection of principles and customs, disappears or, alternately, pulls its Standards Track documents out of the RFC Series. (2) XML is superceded by a vastly improved YML, ZML or something else and becomes a historical artifact that people view with about as much amusement (and have current, active, and maintained tools for) as eight inch floppy disks are viewed today. I'm not predicting either of those things, but a 50 year plan that was not sufficiently robust to be able to think clearly about them and adapt is not really a 50 year plan. best, john From nobody Wed Apr 1 15:44:44 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269303A11D9 for ; Wed, 1 Apr 2020 15:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85P8TUsNAasC for ; Wed, 1 Apr 2020 15:44:40 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9908F3A11D2 for ; Wed, 1 Apr 2020 15:44:40 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id f206so741942pfa.10 for ; Wed, 01 Apr 2020 15:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Mep05u/6V3E0vyLqGaytGmuWhb0CKiq/2vCAMLF06bw=; b=QRYmJcxZ1KDNMdqU9P2kQ3c61z35rJD4jfCA11EBSdg7oAuhtVVId0TU32jMkWGE5C iCUtUPnmDx7b7II+C/ICAV4FG7jCY6aOCvdwO8Irsl330sdw0/UTZ2qc5vOg/Y1HR6x7 Y8ZXf4E7Oyw1U6HNWn9uUaGWPbtMK2/0Q8aHbBd0SKkSzvFwAEbg2FaNsNqHdVgOzZpS WVr+GgK/qNsM9mAS+RlEpT7vaBHCCFNbp/l2+LrYvvIlRFGCjCwUJAOQcc3O5l2uZW4Y uMbmy1f5alHSoT99sVlnOmh7ma9GpfMI588FvwBGfWQ0nZozQR71EVUgFs4GHrcTb+BF wSRQ== 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=Mep05u/6V3E0vyLqGaytGmuWhb0CKiq/2vCAMLF06bw=; b=ejsmSGCq/sjZjFPtqBkBZPOmc3NbQ7ZcQnS3n71aDwLwb4TeADb0PNypjIyI7SSYQ1 tBIrU1j8Yu5IOE2QgpMbU5t/kb2rR7rFT9KhBUHgr+n68sBlsq4/g3x2b42Fl5HyYOK/ z81PGp/HiBy59jK0KyVtsHFjABhHVoXkIhNzsMYXSNYZTWuv9RDAfsIAmwt7goAM1Y8H W49KpQBssjHTUPTvoVQtyVXepT7Y4dGl3pB/91ZmsQjr2iWkIVcOe+Fi+KU9tAt6Q2np DkXoor15N9Fcz+fAeg4IvzHpEmfHxCytcXa+gq4BKZYT3XuGtGP6ccRlNh0WE6wH7WWd vzVQ== X-Gm-Message-State: AGi0PuaZ2tNwFWwzwOP4Ob1OW+kx1KS3bCS//wJT37Fl+Lgad3iFK9jM dofiIBIGjmGBAMDXawUb/d+yYwlS X-Google-Smtp-Source: APiQypKI1CTL+IF0ftOM3kifRO2oS285fCnJU/HXym7BR0BnN2Yj3GDHzB/f01ONuwN7+HyWWkD4PQ== X-Received: by 2002:a65:6412:: with SMTP id a18mr487550pgv.322.1585781079632; Wed, 01 Apr 2020 15:44:39 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id q8sm2323699pfg.19.2020.04.01.15.44.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 15:44:38 -0700 (PDT) To: Doug Royer , rfced-future@iab.org References: <64a845e5-ad60-04da-66c7-ce084693cb8d@gmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 2 Apr 2020 11:44: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: <64a845e5-ad60-04da-66c7-ce084693cb8d@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] What went wrong [was Welcome to the romp! A reminder of what I would like us to decide first...] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:44:43 -0000 On 02-Apr-20 09:54, Doug Royer wrote: > > Has "what went wrong" been defined? Fixed? I saw a lot of opinions. I don't recall a conclusive resolution or definition. I think we should avoid finger-pointing, since it wouldn't serve any useful purpose. So I think that means we should look for structural problems that were the ultimate cause of what went wrong. As John Klensin said, an important symptom was people thinking that the RSE was an ordinary contractor with key performance indicators to be measured. Another symptom was that the oversight committee (like the IAOC) was apparently getting far too involved in details. Were there other symptoms? Looking at the symptoms, we might be able to discern the structural problems that caused them. Brian From nobody Wed Apr 1 15:59:51 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2D53A11FA for ; Wed, 1 Apr 2020 15:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc8hdiMLCf10 for ; Wed, 1 Apr 2020 15:59:48 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0AF3A11F7 for ; Wed, 1 Apr 2020 15:59:45 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id k18so582192pll.6 for ; Wed, 01 Apr 2020 15:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SzqogWQeWrAs4mhjy6Dt8qsCadJ7xS4gtRPdbl4HN4A=; b=eGz6WR8VDhpqt9KvA6ZSM4lkY474P4bowTnzgQy8HEIAop2CoH1sg+w5LsXo9BClg0 5sMgtKSoMJNv8eeC4BbVztlUSQBnxO3V8h272j+ZXnqX6Oqs6NmcGIBpmVnDXMPtwETq dO7atWCBCaGIxpKVYc7CE1Z3VGSTbcGbJmmUOFeEwjKzZkqOShHHuPbPVyLlb44idVjj aKZK9LEBSCQnGnLiLHCxGg8eTqAYrzcoNE281OrSvE6/s7zAu/MyaI/MJmouBGotwghQ llzFqLdWJW+jyWkF/b+Ng8uXVAlbQcmXsvMdbrAY7z70cUWgpF9ny61QRh+78doTdZQd 9LjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=SzqogWQeWrAs4mhjy6Dt8qsCadJ7xS4gtRPdbl4HN4A=; b=ToDwWEAikB3Frxe6Xa1hSEH0vtJnFMK4bVkiB7eJGBryBOkDV+2xHjLCGt+LdOPpgf 2ml3crEnREtlRTVbSqjiNB7UnEeYkU8W2ZRCJOCVuTcVc1wGoowuBpLmVcsK3fTQ7OS7 o16nrAyZ8pZDPUJWC+mJNvVr8G/XZ6tvKT5Fr4iS9mvDnVkdYLjSGJM6d4mnlNZgmuqd JK0SOrPhMmvns62esquNUcuA7VZCACXTWujYRsE5IM6+QkG+MvR5KuVPiI2wR+oyXeHH NOYZlSgSr2xgs7WT7ZUvXQATVpSzFaL8Mpir8eG01Mj/k3qMvdId1pdrPBNb52SvJyMF WmMw== X-Gm-Message-State: AGi0PuZcvUqUGAuGbglSmHDG5ORQhIZ4leJ1Ded8TOTUi3vanCSjyKnd S7/th12RMJlxatHzcaBIGhd/k/fZSFvJGJs= X-Google-Smtp-Source: APiQypLZHLuVwNj4nRmNYCXWfdyLasZKEHNt9nGfJj4GY47zo2oB+tm+8lYEdKCmSpodQUFTaACZoA== X-Received: by 2002:a17:902:b48b:: with SMTP id y11mr164020plr.131.1585781984725; Wed, 01 Apr 2020 15:59:44 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id q185sm2350576pfb.154.2020.04.01.15.59.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2020 15:59:44 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org References: <64a845e5-ad60-04da-66c7-ce084693cb8d@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Wed, 1 Apr 2020 16:59:43 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] What went wrong [was Welcome to the romp! A reminder of what I would like us to decide first...] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:59:50 -0000 On 4/1/20 4:44 PM, Brian E Carpenter wrote: > On 02-Apr-20 09:54, Doug Royer wrote: >> >> Has "what went wrong" been defined? Fixed? I saw a lot of opinions. I don't recall a conclusive resolution or definition. > > I think we should avoid finger-pointing, I don't mean it in that way. I don't care *who*. I still don't know what happened. I am now guessing, from your reply, that it was an interpersonal issue. If that was it fine. Was it a too many bosses issue? Was it lack of staff? Was it a lack of job description with too many expectations? If whatever was not fixed, then how will it not happen again? -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Wed Apr 1 16:51:08 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3446F3A1445 for ; Wed, 1 Apr 2020 16:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkwx20oS8Gwh for ; Wed, 1 Apr 2020 16:51:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839763A1455 for ; Wed, 1 Apr 2020 16:51:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D6832BE51; Thu, 2 Apr 2020 00:50:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnYfKJqRCV5g; Thu, 2 Apr 2020 00:50:57 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2340CBE50; Thu, 2 Apr 2020 00:50:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1585785057; bh=TudeTo856CVBYMhFtMemIfcy8QK2YdmfjPP3Is2wCjg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=L+f1UzEbEljsoBS+ZhBhGKLQWN4LIuPZLvrPD/merylxKdx2+ei6VxF15B49iklF3 4mzqjhrWdtqqX0S1otkEeFDWLrVvXS6naK+CzTk0bisu9VUdO9ATjI890oVJoKollv 69q63EhQ/Vda+bSHt6rs+T1eALiSdviEyJLZoUFM= To: John C Klensin , Eliot Lear , rfced-future@iab.org References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <612878B544D3F4BD620D9650@PSB> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Thu, 2 Apr 2020 00:50:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <612878B544D3F4BD620D9650@PSB> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ejd3rJg81iQcCshxKImGng0Z0BrkDnGU8" Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 23:51:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ejd3rJg81iQcCshxKImGng0Z0BrkDnGU8 Content-Type: multipart/mixed; boundary="H5ffGJSOdC4bGESUSX4qdegj3OSbcesER"; protected-headers="v1" From: Stephen Farrell To: John C Klensin , Eliot Lear , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <612878B544D3F4BD620D9650@PSB> In-Reply-To: <612878B544D3F4BD620D9650@PSB> --H5ffGJSOdC4bGESUSX4qdegj3OSbcesER Content-Type: multipart/mixed; boundary="------------7AD9F53B4EC11ABB83774139" Content-Language: en-US This is a multi-part message in MIME format. --------------7AD9F53B4EC11ABB83774139 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/04/2020 23:23, John C Klensin wrote: > a few of us > think that part of what got us into this situation was assuming that > the RSE was just another contractor who could be evaluated, I reckon there's a real element of truth there and I'm myself quite happy to be open about my opinion that it is not a good plan for the RSE to be considered to be "just another contractor." That may be down to a love of books or some such irrelevant bias of course - I am not claiming my opinion here is soundly justifiable;-) That said, there are some IETF participants for whom I have a lot of respect, who, I think, do in fact consider the RSE role as one to be filled by "just another contractor," or maybe they'd describe it differently, perhaps by stating that the person in the RSE role is not guaranteed to be a god-like being or some such. I hope this process can find a way to deal with such divergent views, or find a role description with which we are all equally unhappy, but with which we can all live;-( Cheers, S. --------------7AD9F53B4EC11ABB83774139 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7AD9F53B4EC11ABB83774139-- --H5ffGJSOdC4bGESUSX4qdegj3OSbcesER-- --Ejd3rJg81iQcCshxKImGng0Z0BrkDnGU8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6FKOAACgkQWrL68XsX K+pKohAApbSPW3X4hVGmkWI8nSAluhP8QBFq8o4k7AVit2xmUd9FNbbkUY97nr/z DJ6YlEAY8Ne2wnBD0CdRgtatnBPf4zbfR8Hwvj9tPHQ6p/zBnRNcq1G8F5E1kNVQ Iozn88szcfWuYMaOl27ANsCdlbJXT5PaEB+VbBCGjxpvPFhu0ZgB13K9YCHq3r4w UiLUv7hUfFRF0qJw0+S5keL2DGPz6B5NlVIP5uOi809YVT6V91VL4eJA8LgyzPxa qSlclFkwE929Foo/ZPo+Vs8BnXT0ssyGqhqli/pN7lYaw1KViV0AaWSnWPH8kpg+ pETKTuauOi6+b52cHU+G010ndLL3dI5r9PqLUkQKV0sW/BpTTeMog9EvWHfcSsEt 0H4JS54pyVN0WVs0eeJ1krHE2W3ghuaJlOv2kpT+aU5bWAjUKP+ij8GllmYMQfM0 1N9z94fQBVKkwpjLfkZCrNv9FWz+NcvdfXYf+IFmPMhrLnl8g/NdxxdOmLQLQC0H 5nUp6V4wCXEkQOE+SXxW4SoKsUZMUSfWdxugFxecyuLdHhe92IewFPnYlF0d8MrA anCc/uP47G00FpEtSowXc87IVpYiY4HhRlE7yuq3ffqyi88wJ+1qPCPxzIVIpn+I Gp6eCjUFuUe4Q2peidexQ7DVXOas4jWWvw4Gbtm8u5sAwx/uDdQ= =dFcR -----END PGP SIGNATURE----- --Ejd3rJg81iQcCshxKImGng0Z0BrkDnGU8-- From nobody Wed Apr 1 17:38:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A723A1619 for ; Wed, 1 Apr 2020 17:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me-1_rq9Kzrb for ; Wed, 1 Apr 2020 17:38:22 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91F23A1617 for ; Wed, 1 Apr 2020 17:38:22 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id t24so997540pgj.7 for ; Wed, 01 Apr 2020 17:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=P1bgvgxFzse+j57RM7Tg1tK3LlBq2HzSa6cdjwXgSqs=; b=oHiAab+dhM2ErmRFOD+j9BIsCHJqFKsmKb1XaglHyyBNPLfK1dJucWZuKmufi2oguM rm4UMEp0imMm85f1ESlVuFixPE0WMafWVqjXQ1zddNz5Nn/nYDK/RLHaVFLYzj9oDiN3 X/2XVh2BxQTEEodEMg2TS5TC87wkFOMPqM4ni+23uxoM5L1Lt1CpEvLGY9cWqM1eF4ci B+1kPlOtbWUZZ8Rl2HtTfK2bBe+l2mlg8wUG/WK5rSrwut0mm9lCu9/JJkHxVC3mnXX6 H+R7xvmvV9uws/3VVaoce9p5K7PzGkt6RlJUfl6GtO1F0+9wn+vrDbf01jsuJVQd/2tc wajw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=P1bgvgxFzse+j57RM7Tg1tK3LlBq2HzSa6cdjwXgSqs=; b=G5v2ws0ON0+4QveW67V9fv7r8HWyifqzKWPhcN+kNg+B2fPw3IkAnFNuAksW2xiG1x nMdL/iBxZHkxuJjrW3CcQ2ZCjxC2L5ePVkzc8pv49iYb1YyP+Eo3irKrBStmM3pDgyHf rxjUoBoNmx8Q3qfM19pVeqXUPmYK0aMXV73AnSyyGVReL/+GOM2zbvbsTcesws407SY2 hXe27TsoWGnOYV575T6ycVZX5slda8+imTUjEhGltJK+8YO9KsOF0Ipni5hiCvQM0yEm utebWOYC7+WtAOPTnOVgpdQ3irL4bu5jKQ91GV37Ah0VyMBYCaVhP1qIqZ+z3JM9+WwY vF0w== X-Gm-Message-State: AGi0PuaGo23xwOPlcb2I96ij/MXmg0PYOJEITE3cvYtK2zBtvQ4qnMHV NaXSUfIOHZCtODAwxrzE9ZM= X-Google-Smtp-Source: APiQypL+Pag+tv6ovo8qUWYNj1gzq+2fsn/FpNdoZWYFP8+GHgytI3ovuZ/YFmG4nYlh6k1Q396qFg== X-Received: by 2002:a65:4806:: with SMTP id h6mr817495pgs.295.1585787901900; Wed, 01 Apr 2020 17:38:21 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id c1sm2500727pje.24.2020.04.01.17.38.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 17:38:21 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Stephen Farrell'" , "'John C Klensin'" , "'Eliot Lear'" , References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <612878B544D3F4BD620D9650@PSB> In-Reply-To: Date: Wed, 1 Apr 2020 17:38:20 -0700 Message-ID: <0a9001d60887$02d355e0$087a01a0$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE1+R8uCRV9Abm7PvYymWtFQE+BqAGI0LbWAPvtDC0BdXNepamFQ8Pw Content-Language: en-us Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 00:38:24 -0000 > I hope this process can find a way to deal with such divergent views, = or find > a role description with which we are all equally unhappy, but with = which we > can all live;-( I think the question is how big a scope of "solutions" should be taken = on. At the "large scope" are changes to the nature of RFCs and the series At the "small scope" end I'd suggest -- without any other change -- = focusing on the "AUTH48" status since 48 hours and only the authors = cannot proofread everything that needs proofreading. (History RFC2616 had several errors that were due to bugs in the process = of converting Word to text/plain) I can't tell from the posts and intro material what level of changes to = the process you'd want to contemplate. From nobody Wed Apr 1 17:57:14 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C373A0651 for ; Wed, 1 Apr 2020 17:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 Qc612Np5Jrv4 for ; Wed, 1 Apr 2020 17:57:10 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C243A0640 for ; Wed, 1 Apr 2020 17:57:10 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id 23so935505pfj.1 for ; Wed, 01 Apr 2020 17:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=j6CDxfKPNuC9ZRqlWu25zxnWsvRsuBeFdW0N/6Q6rWg=; b=RYpSAgo3zP2rb8T2cTWfX6QI3svxE4eKbOcbGKDGFBrK+XNyc4NxFbOpU9Be2O95Nu C4M0DSsD0VT63hQQMuoLK3qRcaHWS3QaboILa3g4q5OdS4JFOZf7H76ac0L+ghGoD4xg GJO/unGNywfkWtdeUoIvpKNbHQFBhulumEsKxWJbpK/PA84ROOndzFcl3TVC6UKEXJ+F xfpsxj9eUS9w4+uNy/Zfcp8ehPvbhOQFR999/d2QCRV9M17KcG21HJN3dmA2GWbn9iEC XZGpE9HiY152idRaikctNdZHV7ntn3VEoVDg9d/xiU8Be53HRxp/I10ApyI6FwgbhIgq qbTg== 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=j6CDxfKPNuC9ZRqlWu25zxnWsvRsuBeFdW0N/6Q6rWg=; b=M2tEzn9R99FiHw9GcyTOs9Ox714PazHYLUyIfxU3NK4uvn9LJDK2ApR8faIY0v/t1a NUdg39RwyQVskCoR/E9MP4hW50IxiGziy5StPxOYa+XbadIQKOLXI2fJJvtEnoa+IQPn pcKPKlaydn04fp3iGkHEcUYpG3UcQuHoHj5KWUNki/SNOBCz1+C3FFOu3wcgVkbcXoG1 deqdumE5Yms+5Eu9xd+ToqyxMpj65aVX5gSp+yByc92PffSPnUnt2Wnh0RHqpOpI5C4x jPu2C6gEFHpewMxW968MLd/RsIlDhh/Iqjj8tIesl50+8TYdVqn8z/wy4DHkExIr5Qud ZBaQ== X-Gm-Message-State: AGi0PuYIBrR2VPfyPT+7HImeA/LUxMyZhFw6e8+gtuWDHLTmvg+nFQHa FquLWJVhhVpl71EQy0nFj44S/YeT X-Google-Smtp-Source: APiQypJ45zSaQzewwMmhKh+Ee4NJGaf0fbwFv9c4Mk9KokOwiFHyJjXIYRzdQ7MznY0QCs9CvEGbNA== X-Received: by 2002:a62:1648:: with SMTP id 69mr591404pfw.14.1585789029509; Wed, 01 Apr 2020 17:57:09 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id e7sm2434521pfj.97.2020.04.01.17.57.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 17:57:08 -0700 (PDT) To: Doug Royer , rfced-future@iab.org References: <64a845e5-ad60-04da-66c7-ce084693cb8d@gmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 2 Apr 2020 13:57:04 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] What went wrong [was Welcome to the romp! A reminder of what I would like us to decide first...] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 00:57:13 -0000 On 02-Apr-20 11:59, Doug Royer wrote: > On 4/1/20 4:44 PM, Brian E Carpenter wrote: >> On 02-Apr-20 09:54, Doug Royer wrote: >>> >>> Has "what went wrong" been defined? Fixed? I saw a lot of opinions. I don't recall a conclusive resolution or definition. >> >> I think we should avoid finger-pointing, > > I don't mean it in that way. I don't care *who*. I still don't know what happened. I am now guessing, from your reply, that it was an interpersonal issue. If that was it fine. That's exactly the discussion I don't want to be part of, hence the second part of my message that you elided. > Was it a too many bosses issue? Not exactly, IMHO: but the way the RSOC was set up seems to have led to many cooks trying to stir the same pot. > Was it lack of staff? I have seen no suggestion of that. > Was it a lack of job description with too many expectations? I don't think that Heather, nor Bob Braden, nor Joyce Reynolds, nor John Postel, were ever hampered by that. > If whatever was not fixed, then how will it not happen again? That's what we're here for, isn't it? Stay well, Brian From nobody Wed Apr 1 18:04:48 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55063A07AA for ; Wed, 1 Apr 2020 18:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBaA7nzB-Dut for ; Wed, 1 Apr 2020 18:04:45 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6B73A0945 for ; Wed, 1 Apr 2020 18:04:30 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id b1so1485517ljp.3 for ; Wed, 01 Apr 2020 18:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WZQfyhsDLaMBTeFrxl3O+5Rrf8R8dhY56PMqg/IubJ8=; b=QDeeeRPwl9wZOtVM0AWuS3hv8AcAyxPspptHv16Cl9Mdw+C0Y942jz8k9C1VMnRHkB KXRPWOBylV6k7hOb024Ut11lsUWEeoVzqIw26qnz45lSIH7MAFDoTnOsShRdMK/9xsuM lIyP4GEgknymV4vcG98kQ5SWlmJ6FcIfyLTLZAttP3uvm/o18TAeEixN94GDpNXFd/25 8vPeDcuSRsLnTGdBRqE84XsIKCdlQY0dOhYmeoYaNJHfn32OaLZfvWZS3p2XmpSISfeG OJiBMeBxhvrm8pr9Ga84MOjzO//Ce36VDiBbvmftjJaj0IosAfi72J9i4lMxtd0z5f3e ERtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=WZQfyhsDLaMBTeFrxl3O+5Rrf8R8dhY56PMqg/IubJ8=; b=FcjRLxpDHPxcWxl5LqnhVHg8unlTbRXl+a7PjaTShSAAQgVujj1ccXMBcuiVJSMLJt m6KSb8X/jsLHGe9UdcFVWFchuHx8aganS11OXTKysowdFJrI9F6GeV1EZ4b10JPRnmyy znsbBSs35iM+zuq1hMYZqXlbu7TbUv0UF8hWk2TQ8nk7mUILo0eQTyyFKdvuv9z0+JTm 8YV6DO39KX2kQwJy2KWhuwvmem/D+tanKgDiuLFMTH6JcZOy/8ioyY6ezWsastldDChv 0euGpCAObm0YVTcNxq6TTRkcTtUFQkR87jl7ZFGahfhFrOh3uAyGyobtP3evr0W+yp2n 2IRw== X-Gm-Message-State: AGi0PuYvHABefTgOgDI4MFcdZpXyoTSbZ4UDbrn8qtjixZZVMUotNjLn PVsJMj6a06rlN1itHRn6cvPTHTQNhpoUgCA= X-Google-Smtp-Source: APiQypK4tPBfXJKJtK0FJNRH81HELDUD+OHOr2/iIA3OmvTpG7BZFs9XtUz/RCVpNsUUPYNaj1LMnQ== X-Received: by 2002:a2e:8109:: with SMTP id d9mr493777ljg.31.1585789468697; Wed, 01 Apr 2020 18:04:28 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id b7sm2070364ljo.47.2020.04.01.18.04.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2020 18:04:28 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org References: <64a845e5-ad60-04da-66c7-ce084693cb8d@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Wed, 1 Apr 2020 19:04:25 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] What went wrong [was Welcome to the romp! A reminder of what I would like us to decide first...] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 01:04:47 -0000 On 4/1/20 6:57 PM, Brian E Carpenter wrote: >> If whatever was not fixed, then how will it not happen again? > > That's what we're here for, isn't it? For me, having no clue. I guess I could start with dozens of suggestions, many of which would be shot down as they don't apply to the unknown problem. From what I have read so far, including what I cut out, whatever the issue was, is the problem that shall not be named. I am not trying to be difficult. I am trying to catch up. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Wed Apr 1 18:40:30 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DC13A08FE for ; Wed, 1 Apr 2020 18:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 qpv2x0uCrS19 for ; Wed, 1 Apr 2020 18:40:26 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99E33A08FD for ; Wed, 1 Apr 2020 18:40:25 -0700 (PDT) Received: from xse413.mail2web.com ([66.113.197.159] helo=xse.mail2web.com) by mx16.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jJoq3-0001hi-2f for rfced-future@iab.org; Thu, 02 Apr 2020 03:40:15 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 48t5NC1wclz2yCj for ; Wed, 1 Apr 2020 18:39:55 -0700 (PDT) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jJopn-0003Gv-4t for rfced-future@iab.org; Wed, 01 Apr 2020 18:39:55 -0700 Received: (qmail 9795 invoked from network); 2 Apr 2020 01:39:54 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.77]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Apr 2020 01:39:54 -0000 To: Larry Masinter , 'Stephen Farrell' , 'John C Klensin' , 'Eliot Lear' , rfced-future@iab.org References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <612878B544D3F4BD620D9650@PSB> <0a9001d60887$02d355e0$087a01a0$@acm.org> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <450dc214-2606-d764-a24d-5b91a642f3bb@huitema.net> Date: Wed, 1 Apr 2020 18:39:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <0a9001d60887$02d355e0$087a01a0$@acm.org> Content-Type: multipart/alternative; boundary="------------BCDA38B62DB414B7BF2FABEC" Content-Language: en-US X-Originating-IP: 66.113.197.159 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.24) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0VxB0mWeGZk2wSOLROvd+japSDasLI4SayDByyq9LIhVDQkOVpcP52To uBa7BIuHMUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4jBVSuYK5BAb8HFQrnIvXAiQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEFTr1kXHz+fWAZp3N0TEAHQ7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsewdockuvmFY9cQ88McMLiJhycP4K1Fpu7HXiVspqMvyECYL55LT26FMFhWvL1KtYbSS ax8yVT5LNQc0pviCIZ+V87H2ECndxkpBwp1FkQyHa0qTD2ipD9y2znxCv9uYkc8RFZ4oobg8BBg3 Jq+ntzj0mqRwdviactTHZEYuduPWrw9mDnaXtu0kZC/OWmUorWj4f6Y8UFcNzerySM+HBFNtXHis TbzgJnN+fdmznd9vTHW8TfMUfXZNQGXIjuXCLLpTtDPVba95reW5u8DDiJv4z1caQoi44Wcfj1z/ J5tTt7j1ptfltBQnq8NvNwuG6kuhBG0YWFj/7xYZzwR7/PiKfowXlsolACJrkW/vjDp2NmSdEOMf tBjsWb6BDQzjSsG66974nkMwEqjhfSKHlA2Q3p5onVdn12r9xqR15ROHBesyXD9BkbKX7eGI2jGt /RQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 01:40:28 -0000 This is a multi-part message in MIME format. --------------BCDA38B62DB414B7BF2FABEC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/1/2020 5:38 PM, Larry Masinter wrote: >> I hope this process can find a way to deal with such divergent views, = or find >> a role description with which we are all equally unhappy, but with whi= ch we >> can all live;-( > I think the question is how big a scope of "solutions" should be taken = on. > At the "large scope" are changes to the nature of RFCs and the series > At the "small scope" end I'd suggest -- without any other change -- foc= using on the "AUTH48" status since 48 hours and only the authors cannot p= roofread everything that needs proofreading. > > (History RFC2616 had several errors that were due to bugs in the proces= s of converting Word to text/plain) > > I can't tell from the posts and intro material what level of changes to= the process you'd want to contemplate. There is indeed an issue with AUTH48, but there is a more general issue with "changing documents after consensus is declared". For the IETF stream, the current process puts the final phase of editing after the final vote by the IESG. This is a source of both tensions and delays. The tension is obvious: if a document can be changed after it has been approved, how do we guarantee that the changes do not change the meaning of the documents in a way that alters consensus? The process puts that responsibility on the authors and the AD, but the authors may or may not have the time to examine the changes closely, and the AD may or may not be already overloaded. So that create delays, not because the copy editors are slow, but because the authors and AD end up responding slowly. Removing tensions and delays would make life easier for everybody. -- Christian Huitema --------------BCDA38B62DB414B7BF2FABEC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 4/1/2020 5:38 PM, Larry Masinter wrote:
I hope this process can find a way to deal with such divergent views, or find
a role description with which we are all equally unhappy, but with which we
can all live;-(

I think the question is how big a scope of "solutions" should be taken on.
At the "large scope" are changes to the nature of RFCs and the series
At the "small scope" end I'd suggest -- without any other change -- focusing on the "AUTH48" status since 48 hours and only the authors cannot proofread everything that needs proofreading.

(History RFC2616 had several errors that were due to bugs in the process of converting Word to text/plain)

I can't tell from the posts and intro material what level of changes to the process you'd want to contemplate.


There is indeed an issue with AUTH48, but there is a more general issue with "changing documents after consensus is declared".

For the IETF stream, the current process puts the final phase of editing after the final vote by the IESG. This is a source of both tensions and delays. The tension is obvious: if a document can be changed after it has been approved, how do we guarantee that the changes do not change the meaning of the documents in a way that alters consensus? The process puts that responsibility on the authors and the AD, but the authors may or may not have the time to examine the changes closely, and the AD may or may not be already overloaded. So that create delays, not because the copy editors are slow, but because the authors and AD end up responding slowly.

Removing tensions and delays would make life easier for everybody.

-- Christian Huitema

--------------BCDA38B62DB414B7BF2FABEC-- From nobody Wed Apr 1 19:22:31 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B3E3A0A82 for ; Wed, 1 Apr 2020 19:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 DBSPODufQH52 for ; Wed, 1 Apr 2020 19:22:28 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5ED63A0A58 for ; Wed, 1 Apr 2020 19:22:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48t6KH4pmkz6GHV9; Wed, 1 Apr 2020 19:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1585794147; bh=jFkVVcP+FAA9Oq9mxZwn0Guvxe+cdYwjCLXxmQJ5bXQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EOL/cMxrNw+aJOx8gRQ7i7DOMPxbRiFtSa5OPh6IV0rjclhA4mVHGI8yz7WlbRSRR z3X5Gcgck//bfOjkjJ7DVuJm37gTYu61FQ6qEAznRmdhDN9H6/tqQ5csLvzM2Eij/a ArOkxgOM81YIdUYRCaJlqariNvi88u6htO9DQk/k= X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 48t6KH09tDz6GHTt; Wed, 1 Apr 2020 19:22:26 -0700 (PDT) To: Christian Huitema , rfced-future@iab.org References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <612878B544D3F4BD620D9650@PSB> <0a9001d60887$02d355e0$087a01a0$@acm.org> <450dc214-2606-d764-a24d-5b91a642f3bb@huitema.net> From: "Joel M. Halpern" Message-ID: Date: Wed, 1 Apr 2020 22:22:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <450dc214-2606-d764-a24d-5b91a642f3bb@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] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 02:22:29 -0000 Christian, I am a bit confused by your message. Removing post-approval editing, while it would reduce tension and delay, would also significantly reduce document quality. The RPC does an impressive job of fixing the many minor but significant errors we put in our documents. Ranging from inconsistent terminology to really bad grammar. I, for one, would be really unhappy at trying to decide we did not need that. Yours, Joel On 4/1/2020 9:39 PM, Christian Huitema wrote: > > On 4/1/2020 5:38 PM, Larry Masinter wrote: >>> I hope this process can find a way to deal with such divergent views, or find >>> a role description with which we are all equally unhappy, but with which we >>> can all live;-( >> I think the question is how big a scope of "solutions" should be taken on. >> At the "large scope" are changes to the nature of RFCs and the series >> At the "small scope" end I'd suggest -- without any other change -- focusing on the "AUTH48" status since 48 hours and only the authors cannot proofread everything that needs proofreading. >> >> (History RFC2616 had several errors that were due to bugs in the process of converting Word to text/plain) >> >> I can't tell from the posts and intro material what level of changes to the process you'd want to contemplate. > > > There is indeed an issue with AUTH48, but there is a more general issue > with "changing documents after consensus is declared". > > For the IETF stream, the current process puts the final phase of editing > after the final vote by the IESG. This is a source of both tensions and > delays. The tension is obvious: if a document can be changed after it > has been approved, how do we guarantee that the changes do not change > the meaning of the documents in a way that alters consensus? The process > puts that responsibility on the authors and the AD, but the authors may > or may not have the time to examine the changes closely, and the AD may > or may not be already overloaded. So that create delays, not because the > copy editors are slow, but because the authors and AD end up responding > slowly. > > Removing tensions and delays would make life easier for everybody. > > -- Christian Huitema > > From nobody Wed Apr 1 19:30:29 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8BB3A0BB2 for ; Wed, 1 Apr 2020 19:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q-MCo6k6kTHf for ; Wed, 1 Apr 2020 19:30:26 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8A53A0B9B for ; Wed, 1 Apr 2020 19:30:25 -0700 (PDT) Received: from xse193.mail2web.com ([66.113.196.193] helo=xse.mail2web.com) by mx14.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jJpcW-0006XU-AT for rfced-future@iab.org; Thu, 02 Apr 2020 04:30:23 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48t6VB5Vn4z1FdR for ; Wed, 1 Apr 2020 19:30:10 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jJpcQ-0004tP-Km for rfced-future@iab.org; Wed, 01 Apr 2020 19:30:10 -0700 Received: (qmail 8010 invoked from network); 2 Apr 2020 02:30:10 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.77]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Apr 2020 02:30:10 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Christian Huitema Mime-Version: 1.0 (1.0) Date: Wed, 1 Apr 2020 19:30:09 -0700 Message-Id: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> References: Cc: rfced-future@iab.org In-Reply-To: To: "Joel M. Halpern" X-Mailer: iPhone Mail (17D50) X-Originating-IP: 66.113.196.193 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.193/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.193/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.27) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0VxB0mWeGZk2wSOLROvd+japSDasLI4SayDByyq9LIhVS2DySMDOBxeC Xy8UiTnaZkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4i8siKZCspOKEqNymTPLAamQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEIAgOjD+G97FMiE2PPlf1fw7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsezUTEAumaS8EPUiWeF3NFNfJ7Um9X1e60u5Tfw0/jskt4nlBK73iIGeb9u1UAIcv3Lo Oo70iqAlsD2ZyQe0MRcoCPlKuO9fhDLQHtSeLrs2CARRiI4FYjmNWKK4C97xdQjTPpuFqUUQz+mM 8JAD4ECWglTmqrVEf2hmgeycp2/U+hzd1TBXbJNvBC1nKO3+wSPwHuQZYqHfyH2MZZY3oKGxJRKf +yzvyC72Z5dVNmO7B1FfEoXm0/FPF8PR0w363lm+wEXov6OGIvFokmpxgv8DyLIB1jT1Bo29o7Zg vtIBLnR6mMZiP8hyi9JD/oRrQtQcSyQwpbsYuxSOGTH6k0lfJmkP8s1HCfLKOW1F2ohPJ/AFMvX7 q8M4x6bP/gjzw0OgghQYwZVLClIproNi1WM01Bh4x4h9uYrmdPlyGg3lun80sIBTfGesZu6FzlJ8 P6r2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 02:30:28 -0000 I did not write that we should remove copy editing. But we could certainly f= ind models in which it happens before approval, not after it. -- Christian Huitema=20 > On Apr 1, 2020, at 7:22 PM, Joel M. Halpern wrote: >=20 > =EF=BB=BFChristian, I am a bit confused by your message. Removing post-ap= proval editing, while it would reduce tension and delay, would also signific= antly reduce document quality. The RPC does an impressive job of fixing the= many minor but significant errors we put in our documents. Ranging from in= consistent terminology to really bad grammar. > I, for one, would be really unhappy at trying to decide we did not need th= at. >=20 > Yours, > Joel >=20 >> On 4/1/2020 9:39 PM, Christian Huitema wrote: >> On 4/1/2020 5:38 PM, Larry Masinter wrote: >>>> I hope this process can find a way to deal with such divergent views, o= r find >>>> a role description with which we are all equally unhappy, but with whic= h we >>>> can all live;-( >>> I think the question is how big a scope of "solutions" should be taken o= n. >>> At the "large scope" are changes to the nature of RFCs and the series >>> At the "small scope" end I'd suggest -- without any other change -- focu= sing on the "AUTH48" status since 48 hours and only the authors cannot proof= read everything that needs proofreading. >>>=20 >>> (History RFC2616 had several errors that were due to bugs in the process= of converting Word to text/plain) >>>=20 >>> I can't tell from the posts and intro material what level of changes to t= he process you'd want to contemplate. >> There is indeed an issue with AUTH48, but there is a more general issue w= ith "changing documents after consensus is declared". >> For the IETF stream, the current process puts the final phase of editing a= fter the final vote by the IESG. This is a source of both tensions and delay= s. The tension is obvious: if a document can be changed after it has been ap= proved, how do we guarantee that the changes do not change the meaning of th= e documents in a way that alters consensus? The process puts that responsibi= lity on the authors and the AD, but the authors may or may not have the time= to examine the changes closely, and the AD may or may not be already overlo= aded. So that create delays, not because the copy editors are slow, but beca= use the authors and AD end up responding slowly. >> Removing tensions and delays would make life easier for everybody. >> -- Christian Huitema >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Apr 1 19:30:45 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415CC3A0B9B for ; Wed, 1 Apr 2020 19:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J4Rj7pL9vHG for ; Wed, 1 Apr 2020 19:30:34 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22AB3A0BCD for ; Wed, 1 Apr 2020 19:30:34 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id g7so2054702qtj.13 for ; Wed, 01 Apr 2020 19:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=B4cFqb1IP0n5jUL/fmpHXQ8SzgwZ+AYumarPNGcYoOo=; b=n/B8LavOAK93/Jy972kia8iboM9WBbFtCVSWu7Qab1FCpWTuixiE89ZOXpv2h0ytHh HBHPZ6rk/YXOO4RFgwAKoQ/fsKsgPIRBivz31ssAOSLEmil2MpXCsVmM1eI5DFEWRXcA x+yU8ZJiyptSbxKHJDfocnuTf0H8bhfAJZxEGAbjwpaDz0L2GWWZAiGbi+EbGpBctFtD 425UJcPB6gWQmkxiaozL/7YMTZvIX9wHottYwDDA1Pll33BbGDOazfnEITesIroLE+bq d74hlv5NV/Z6WMe4hVHECJnsM6uIftg99WdM9N1LUrsSvo++5/AcTMOr6kQwOGt1Y8G0 MXBA== 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=B4cFqb1IP0n5jUL/fmpHXQ8SzgwZ+AYumarPNGcYoOo=; b=IOppzNWmePdDGh4P4dYxc8962D2hWkmrRNX5V+6Qd8iXSPBYlCiiFlDT8dw2bXiIY0 EX92qT6YOPPUBQ1AeEv29HunHs5TqXSrx6l2GjpxEVB3C6kr47S6eHt1YkXrFtsJ+epi nB9rcno+EDxMbUk7bOmRIjrxsx6zki5AnAOZg1kHYwee66t5zhz79HjdjkXPs+DudT9G 0ccwc+XPiNms8PAHKd1W7JDrwQtZzTVvNJNiR9za0EqEuur9inPUGlZiE5zz57fO3g8F 9yhFHs3WE4/Gi32F4h8YppoVgHM1Vn1OtvIGUC+IYJgYwSLn06OzTcREEf2O5vGAlQTe owVw== X-Gm-Message-State: AGi0PuZlZC/xxTgJjnUpFbdZtbZ7qkUtuMvlCfLSBee7rimidKly9Tk6 DMX8CZphEQ6qOe2uPj8ETzi7xiVW0a8= X-Google-Smtp-Source: APiQypL7bnwgIBrpGgG8ybQxlsPvY9C8YJJW7lz/FALBB4DF/ljpzf5O5TkjBsJAEQ5cgDLked93BA== X-Received: by 2002:ac8:4d1c:: with SMTP id w28mr795029qtv.189.1585794633422; Wed, 01 Apr 2020 19:30:33 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id z11sm2683970qti.23.2020.04.01.19.30.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2020 19:30:32 -0700 (PDT) To: rfced-future@iab.org References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <612878B544D3F4BD620D9650@PSB> <0a9001d60887$02d355e0$087a01a0$@acm.org> From: Michael StJohns Message-ID: Date: Wed, 1 Apr 2020 22:30:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <0a9001d60887$02d355e0$087a01a0$@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 02:30:36 -0000 On 4/1/2020 8:38 PM, Larry Masinter wrote: >> I hope this process can find a way to deal with such divergent views, or find >> a role description with which we are all equally unhappy, but with which we >> can all live;-( > I think the question is how big a scope of "solutions" should be taken on. > At the "large scope" are changes to the nature of RFCs and the series > At the "small scope" end I'd suggest -- without any other change -- focusing on the "AUTH48" status since 48 hours and only the authors cannot proofread everything that needs proofreading. > > (History RFC2616 had several errors that were due to bugs in the process of converting Word to text/plain) > > I can't tell from the posts and intro material what level of changes to the process you'd want to contemplate. > > I'm pretty sure that is not really part of this.  It shows all the signs of being a rat hole.   Maybe write up a proposal entitled "AUTH48 considered harmful" and propose a fix? For this set of tasks, let's stick more to figuring out the model of the RFC editor (e.g. a range of micro managed peon to completely independent entity co-equal with the various I* on one axis and someone who knows how to write a complete sentence to someone who has the mad skills to develop, manage, edit and publish a world class document series on the other). And before someone asks "what about oversight?", leave it on the table for now - that comes easier once you have the model. Maybe a way of going about this is to look at Jon, Bob/Joyce and Heather and identify what each brought to the series and, of those items, what we want to see in a future RSE.    Then compare that against what the IAB and IESG and other various folk want as changes.  And by changes, I mean to the model - changes to the streams or publication policies or the use of the RFC name I would suggest strongly are out of scope. Mike From nobody Wed Apr 1 19:32:03 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA073A0BD6 for ; Wed, 1 Apr 2020 19:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-hRwLYPbvqj for ; Wed, 1 Apr 2020 19:32:00 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB3F3A0BD5 for ; Wed, 1 Apr 2020 19:32:00 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id z12so2113345qtq.5 for ; Wed, 01 Apr 2020 19:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=+HIWgcoJg/9uSqofUhLKdIh/zBBeYNX9p3WZjmoeNKk=; b=pyEIDCL1WM+HOOcAYyYNmYSiPGh8ADb50gQ9jVfwLE+qwWoelzfVnh2wLNS6Y9kvW4 ofQ5m94DvxdHSlBxm7B1Q8r/6pbYcqwo5+DeieENT9AdMWTN5uZ0Z0Qn/jJijJ6t4iDL NGUCvogRJ2GVWVw0sRyHRMk5wODUn8VL9MmPvjLPDGp49MmVufMKlTLrmDK9ECcOYz9o JNRVOzk813wK8tGZF6nUVHMECidNynlIoUORZAn7u1fgPuwxGggsRke15ZAsEHnMDWEV AG4OBm5SZJUjuoSEfEvSASXzEQOkdAJ3JTD7N28wZGlcSOMe2GBP5dLutOAVPij4kyZ0 0LGg== 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=+HIWgcoJg/9uSqofUhLKdIh/zBBeYNX9p3WZjmoeNKk=; b=T0vdPuvgf7gV1+XAK0yL7PNI3yhmbPXpAhvDmLs/LCW8fw2lOCp6VVV1m8SgzorpH4 0t7/cJcSp+6KOyA36RbtmqQUQC5WOT/chGPNP9JY9V+b3Q3nJAdRk3dgAbM7Sd/9i/GV NHuj60zhO5mED/Srx19QBPmFTJp4nJD/2VdPleGLhYmK+eHfYz69i4IKqeoorkH+ph7F 811C3bvUAoh+j6P6sRAl0ra/m+dw9btX6CifgbgMbC10R9qhxMXdoUoLgOILLXz8AUim Z9vryzxvOG5+0PltOuuSqA+B2l1XtaTN16RaTqpI4vDt6fn6Zs7pmeWkHr8UR3Org01/ yGVQ== X-Gm-Message-State: AGi0Puag2QTRlmZa7lRVMp9A6Q282LE/biqsQv+AJELwnN1Owg9Q5XtG FX8jUl5fHbBrIv0R8Br33DZjP5JUW60= X-Google-Smtp-Source: APiQypIbJO4LLQZbrA+SLI4XLyitUPOWM4X/ex/tR35WQRy+WLujNI+adrbl4w2zjzzUO3N7ZYimWw== X-Received: by 2002:aed:208e:: with SMTP id 14mr776476qtb.335.1585794719417; Wed, 01 Apr 2020 19:31:59 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id y17sm2873838qth.59.2020.04.01.19.31.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2020 19:31:58 -0700 (PDT) To: rfced-future@iab.org References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> From: Michael StJohns Message-ID: <9e9696d8-bf2f-6306-eaec-9d0e26cb025f@nthpermutation.com> Date: Wed, 1 Apr 2020 22:31:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 02:32:03 -0000 As I suggested in my response to Larry, perhaps this is a rat hole that should be avoided at this point in the discussion? Mike On 4/1/2020 10:30 PM, Christian Huitema wrote: > I did not write that we should remove copy editing. But we could certainly find models in which it happens before approval, not after it. > > -- Christian Huitema > >> On Apr 1, 2020, at 7:22 PM, Joel M. Halpern wrote: >> >> Christian, I am a bit confused by your message. Removing post-approval editing, while it would reduce tension and delay, would also significantly reduce document quality. The RPC does an impressive job of fixing the many minor but significant errors we put in our documents. Ranging from inconsistent terminology to really bad grammar. >> I, for one, would be really unhappy at trying to decide we did not need that. >> >> Yours, >> Joel >> >>> On 4/1/2020 9:39 PM, Christian Huitema wrote: >>> On 4/1/2020 5:38 PM, Larry Masinter wrote: >>>>> I hope this process can find a way to deal with such divergent views, or find >>>>> a role description with which we are all equally unhappy, but with which we >>>>> can all live;-( >>>> I think the question is how big a scope of "solutions" should be taken on. >>>> At the "large scope" are changes to the nature of RFCs and the series >>>> At the "small scope" end I'd suggest -- without any other change -- focusing on the "AUTH48" status since 48 hours and only the authors cannot proofread everything that needs proofreading. >>>> >>>> (History RFC2616 had several errors that were due to bugs in the process of converting Word to text/plain) >>>> >>>> I can't tell from the posts and intro material what level of changes to the process you'd want to contemplate. >>> There is indeed an issue with AUTH48, but there is a more general issue with "changing documents after consensus is declared". >>> For the IETF stream, the current process puts the final phase of editing after the final vote by the IESG. This is a source of both tensions and delays. The tension is obvious: if a document can be changed after it has been approved, how do we guarantee that the changes do not change the meaning of the documents in a way that alters consensus? The process puts that responsibility on the authors and the AD, but the authors may or may not have the time to examine the changes closely, and the AD may or may not be already overloaded. So that create delays, not because the copy editors are slow, but because the authors and AD end up responding slowly. >>> Removing tensions and delays would make life easier for everybody. >>> -- Christian Huitema >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Apr 1 19:45:08 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16A73A03EE for ; Wed, 1 Apr 2020 19:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDxLpvhFOH83 for ; Wed, 1 Apr 2020 19:45:05 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106523A03ED for ; Wed, 1 Apr 2020 19:45:05 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id q3so1024765pff.13 for ; Wed, 01 Apr 2020 19:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=sMbQTS0Ni7D3EOHs1AuCQEOAHaqTebflWClT9sF831c=; b=a19Uc0PCxcR5NV6DLG9q7zF0quWPv3Qt8ih4Au7KjCX3XvktqSV3CyRROOpCNlMhC0 0lERpcgcXl1lTbWX6U77FexAYqunhSnBJLwjY2II40Oj2NriFiQK0XoRZELQTpYARdhX oogmwHmn1b0ufuCmjEhGBvdiLJBGa3qfqJ2LksiEezgVPD+k0Vg6/AdAr3ETB6HhNUK5 OR/Ee88Ut8fZYlSsKjDmsPbg/oIeGewGHXKcnO5YKvBzXgb6etUrHmxgYxvuvo100Wfu vYIqZxMRHRe3NlxRteffvqLzeBhK5hlxp+I73vCguB4mt5zkp48pAGc9CJO92ElKem+u BcFg== 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=sMbQTS0Ni7D3EOHs1AuCQEOAHaqTebflWClT9sF831c=; b=Kieea/GL0NXp4Sn6MUE3PM2x2ZWsAzOGGl2Ba4GZ8l1z5NZnfgBVE3utMJSxBxAldb SR2MPEKvGt9yoDD5KyvMFt+xxMO6NHqJJsk9s5JSaZPoMeDiVtN3GKDokLTaQ6hkooHC QyHW553WB7peSAA1TfA7ITJiIM3xZgjtEv5OqmDY3sn8HuIjp8aqdpX88V1xXWdPNybZ tMn803N+jCkNq1+s+hqEBn8eZ4Nbb4uylYYb/WQGXiabbzjot6aFJsGNQ78h4L48w7G7 7CFS2kL53HpwWquGj1wTujoifQVFxFkXSF/6v3vQsC0DtpdcSRuNjTAMGNDQCmr90Ve7 ZJrg== X-Gm-Message-State: AGi0PuZi8Gr2B6JKKAh/GrmYN1nntkij8XMCJrpD3KksV71JKE9Op4Nf /xBJ6JOG69Z4bdtJE25vUrtMnhFz X-Google-Smtp-Source: APiQypJOtHtssHc3aVDujdtj23DyyP9qD6sf5dACLaXN2XlVCjG70yUhA5YGnTAWf2TFYEwBx3hIjg== X-Received: by 2002:a62:2b05:: with SMTP id r5mr899773pfr.120.1585795503199; Wed, 01 Apr 2020 19:45:03 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id j96sm2613229pje.32.2020.04.01.19.45.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 19:45:02 -0700 (PDT) To: "Joel M. Halpern" , Christian Huitema , rfced-future@iab.org References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <612878B544D3F4BD620D9650@PSB> <0a9001d60887$02d355e0$087a01a0$@acm.org> <450dc214-2606-d764-a24d-5b91a642f3bb@huitema.net> From: Brian E Carpenter Message-ID: Date: Thu, 2 Apr 2020 15:44: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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 02:45:07 -0000 On 02-Apr-20 15:22, Joel M. Halpern wrote: > Christian, I am a bit confused by your message. Removing post-approval > editing, while it would reduce tension and delay, would also > significantly reduce document quality. The RPC does an impressive job > of fixing the many minor but significant errors we put in our documents. > Ranging from inconsistent terminology to really bad grammar. > I, for one, would be really unhappy at trying to decide we did not need > that. Fully agreed. The WG Chairs and Area ADs are CCed on AUTH48 and I assume they will look out for changes of semantics. If not, why are they copied? Certainly any substantive changes must be properly reviewed, in the worst case by going back to WGLC. But that is vanishingly rare, I think. Brian > > Yours, > Joel > > On 4/1/2020 9:39 PM, Christian Huitema wrote: >> >> On 4/1/2020 5:38 PM, Larry Masinter wrote: >>>> I hope this process can find a way to deal with such divergent views, or find >>>> a role description with which we are all equally unhappy, but with which we >>>> can all live;-( >>> I think the question is how big a scope of "solutions" should be taken on. >>> At the "large scope" are changes to the nature of RFCs and the series >>> At the "small scope" end I'd suggest -- without any other change -- focusing on the "AUTH48" status since 48 hours and only the authors cannot proofread everything that needs proofreading. >>> >>> (History RFC2616 had several errors that were due to bugs in the process of converting Word to text/plain) >>> >>> I can't tell from the posts and intro material what level of changes to the process you'd want to contemplate. >> >> >> There is indeed an issue with AUTH48, but there is a more general issue >> with "changing documents after consensus is declared". >> >> For the IETF stream, the current process puts the final phase of editing >> after the final vote by the IESG. This is a source of both tensions and >> delays. The tension is obvious: if a document can be changed after it >> has been approved, how do we guarantee that the changes do not change >> the meaning of the documents in a way that alters consensus? The process >> puts that responsibility on the authors and the AD, but the authors may >> or may not have the time to examine the changes closely, and the AD may >> or may not be already overloaded. So that create delays, not because the >> copy editors are slow, but because the authors and AD end up responding >> slowly. >> >> Removing tensions and delays would make life easier for everybody. >> >> -- Christian Huitema >> >> > From nobody Wed Apr 1 19:51:01 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D6A3A043A for ; Wed, 1 Apr 2020 19:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uo9zvMZGYvz for ; Wed, 1 Apr 2020 19:50:58 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24AFA3A0437 for ; Wed, 1 Apr 2020 19:50:57 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id q73so980335qvq.2 for ; Wed, 01 Apr 2020 19:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=RzVCnFQBGU3ReqIYNUZSmYoKUOJNaPEJTZblCtTg5aM=; b=jv/qqEol1sMpYCbJ4d2C0Exo+ArB7m6z/dtWqUpkEbd6qUQx8r9WDuYYZxDA2MbVSz vOcMjHlT81YeWBEOahRwRMhHPuHC6ZMwlXTEf5ZIUoV0YnXnYaUu3hw7opy9utdtgIGr xzr24TCzJPZT1hltF+qpCkaOU7apgLvyeK/OiuOefa8uzJQ6IGmdAnlAMyfDjQKrwIhX MKVuTZo9AsWnMWeSp3N6xE7+vVE/tocvHYbqqgJMO93GUaHFGu9hWAzTHxr8TSP4k266 mihbVuqB3s/yh8Pxe9okUyBaoLqZ44fTLziDPbi9Gzw7vg+4b/D+yBAyWS6QL6aOM7EN 0bQA== 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=RzVCnFQBGU3ReqIYNUZSmYoKUOJNaPEJTZblCtTg5aM=; b=ixO/SB7SNJwDv41TBC1shLOcsYCNTCvG91aVnNHDLyIFXp4hJDj1rhf6quMQtyMmyf RtUriK7pwcE39hXrgjaYcHPdqjjaY5wkPySLO2dF8Hu7sWbVgtn6x8IjeRFTmyKLotOT XfP0DRqkKbS0iGFnegvyc4VCqj9Pff07ZmpCDi/xw+IJX+WiB9kVW50j4kLQ1o3UGmGp jCAc9PqIdFUDLRVYj8RlAYA1FMl7/82w6mM+bfcV+lKWt1jJvyPKcxcFbBUMj4/YfQgw bQ3MQtY6D1CxW20IeEx0KJs8Xxg01fvQHjS6X9TDWISbagP6L7QypAqD+ZV+Sjt2BYKB ANSg== X-Gm-Message-State: AGi0PuavxPYg7YIx8ltjTOkHlCbZ++6WysE8F+YFLmgJxbHfbeXkVxNA ducAYk0vTt3N5pvHsioIdKoCVsMmbHU= X-Google-Smtp-Source: APiQypIBV/8hRli8UjTPVFSS7nD8IA3zW/q9gUPqhyNcc95/Akw7HZnd0Q2m95by1uA/EAdcj/sQEg== X-Received: by 2002:a05:6214:14b1:: with SMTP id bo17mr1205039qvb.196.1585795856430; Wed, 01 Apr 2020 19:50:56 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id o186sm2705421qke.39.2020.04.01.19.50.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2020 19:50:55 -0700 (PDT) To: rfced-future@iab.org References: <64a845e5-ad60-04da-66c7-ce084693cb8d@gmail.com> From: Michael StJohns Message-ID: <0819a6e7-9564-dddd-620b-06d1ee0fa031@nthpermutation.com> Date: Wed, 1 Apr 2020 22:50:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] What went wrong [was Welcome to the romp! A reminder of what I would like us to decide first...] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 02:51:00 -0000 On 4/1/2020 6:44 PM, Brian E Carpenter wrote: > On 02-Apr-20 09:54, Doug Royer wrote: >> Has "what went wrong" been defined? Fixed? I saw a lot of opinions. I don't recall a conclusive resolution or definition. > I think we should avoid finger-pointing, since it wouldn't serve any useful purpose. So I think that means we should look for structural problems that were the ultimate cause of what went wrong. I agree with this.  Hopefully, this will be forward looking, and will map out changes to create a sustainable structure. > > As John Klensin said, an important symptom was people thinking that the RSE was an ordinary contractor with key performance indicators to be measured. Another symptom was that the oversight committee (like the IAOC) was apparently getting far too involved in details. Were there other symptoms? As a general thought, the technical leadership of the IETF probably shouldn't be involved in day-to-day  or even month-to-month management of the non-technical portion of the IETF as that's not generally their expertise.  A given member of a given I* might have the specific skills to do that oversight, but what happens when we do the turnover to a new person or a new board?    I think that covers the RSE, RPC, IT, Tools and the Secretariat.   Input is needed from these groups - control is not. Another symptom was the RSOC was not (and is not) responsible to the community and there is no way for the community to express its displeasure if it runs off the rails.  For the IAB at least, we have the annual NOMCOM process and there is the rarely used recall process. Going back to John's comment.  The RSE contract was structured  - for good and useful reasons - as two years plus 2 two-year renewals.  My understanding of this was that the renewal periods were proforma and there mainly to allow for unforeseen changes in the situations (financial or otherwise) of either the IETF or Heather.  It shouldn't have been possible for this to change without community discussion. Mike > > Looking at the symptoms, we might be able to discern the structural problems that caused them. > > Brian > > From nobody Wed Apr 1 19:55:57 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D623A0774 for ; Wed, 1 Apr 2020 19:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjvySCYFG1KO for ; Wed, 1 Apr 2020 19:55:52 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA353A0772 for ; Wed, 1 Apr 2020 19:55:52 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id g32so1165018pgb.6 for ; Wed, 01 Apr 2020 19:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=X4n4VLNHneSdV7MRYQVWxZ+c2aloeiQVeVKWPe+QNZI=; b=K2S80DZQuIEKXNoXlXFnEOKeY1ehqgjl7lkkB9yYSQSPXku/yPtjMUMUNtYhJpXGZP 6cgnisFj3ZJ269qWlcmo75Rwg3APBWW30X9/2b0an+kU7lveGP4z8pOLHoB4GnJO1vDe 73BnAhQCeK3mjVROX+Qka5mVsqNH//htSRolOxvxjL+EPhAhpmWYhzKRPUGXS3gV0d/u Xdl0uyxpwK/DUyC1iDsf3FX8Z2TlPHY31HULHwdGjB3CozM2P0CsVsVvbaX8vVatbnmc c6sreksFOWd0in+z3vepT+oMPxIC5ipsQIg60MzL9SOMqaB4WSoLklc0JpZKmNWD9KDO FpXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=X4n4VLNHneSdV7MRYQVWxZ+c2aloeiQVeVKWPe+QNZI=; b=JQJ+prec2fPWhZqeeJzUVlPNezzafr0HjWy3wPqsAI6pk4iFEiUbv/+W9+EcOiM73F Xw7eW/vScZ3VPgig4flHvJwwucd8ge3bje907FXAG1mvoJycd72ODpAA+ibawLLxONgs zKdYnNJsrVZXujRd91GSipKnFq0ygYS4CtHe0fSSEHL8sijxOhoBSpdjZNcdFmeYpVcU Q0k8444n8JHH4rb+GLsc7uqnlBeYrBURDF/8DD5+xhdAiL2ZAc0qmOMYJwfaksc3iJpX 5NgKoRQlxKOoXinipQkU33XHxZpJ+dkqyA1KJF8PzPaZpYc6iTFGU5jouXxoYYDTwKw/ K54Q== X-Gm-Message-State: AGi0Pua7rsBUyVoJHutKig7Xcc2xVv66QTJsdXGpwEDPvLHRupOym3Yw dSo/YypAz0zx8MPDsoI5Vxo6GC2GJCa5m3E= X-Google-Smtp-Source: APiQypKuVCBRHwXPMTTY3B/3j4QDgf2bq2FLfEzSJP5DeZn4YlEqL7KTaq4MWH3OuG0RF44eg7dXvg== X-Received: by 2002:a62:8202:: with SMTP id w2mr948224pfd.117.1585796151645; Wed, 01 Apr 2020 19:55:51 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id mu15sm2784947pjb.30.2020.04.01.19.55.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2020 19:55:51 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org References: <64a845e5-ad60-04da-66c7-ce084693cb8d@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <10fb66c6-2725-f76c-4727-0ded3095c77b@gmail.com> Date: Wed, 1 Apr 2020 20:55:49 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] What went wrong [was Welcome to the romp! A reminder of what I would like us to decide first...] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 02:55:55 -0000 > As John Klensin said, an important symptom was people thinking that the RSE was an ordinary contractor with key performance indicators to be measured. Another symptom was that the oversight committee (like the IAOC) was apparently getting far too involved in details. Were there other symptoms? > > Looking at the symptoms, we might be able to discern the structural problems that caused them. I am writing this while reading the incoming messages on this list. I am learning a lot. This might be and old rehash for many of you. This may be long an boring for some. I want to help and I need to understand. I am trying to see the problem and possible fixes in my head. So, thoughts, suggestions ... >> Was it a too many bosses issue? > > Not exactly, IMHO: but the way the RSOC was set up seems to have led to many cooks trying to stir the same pot. (1) To the too many cooks comment: Those problem look like an employer problem and too many bosses all of which think they are the only or most important boss. I have worked in jobs where I had a company boss (say IAOC) and a project boss (say RSE lead). In those situation the company boss gave me the raises, and the project boss evaluated my performance for my raises and gave me my assignments. I sometimes had several projects in on year. That seems to me to be the existing RSE mode - two or more bosses. Whenever my company-boss gave me conflicting assignments than my project boss, we had a meeting and the problem was resolved. If the conflict continued, then I would step out of the meeting and let them slug it out. I did not care which direction things went. I would just work on another lower priority task until resolved. It always got resolved. I do remember reading a mailing list comment that made me think it was attempting to change the priority or process for some documents. If so, then a document showing the processing flow and how exceptions work. That would include the process used to resolve those exceptions before bothering the editors that do the work. Were they getting direction from more than one IAOC individual at a time? If so, would only one agreed on individual at a time in the IAOC be the point person for the RSE maybe solve the problem? And perhaps that IAOC individual needs approval from the IAOC committee and the RSE manager before asserting an exception to editors. In that context the RSE manager would be effectively on the IAOC for that process role. Are there a lot of exceptions? If so, maybe one (or few) assigned to deal with the exceptions. And everyone else does the normal flow. Does the existing RSE team have a manager? If so, then everyone else takes direction from that manager or team leader. And maybe rotate the lead in the RSE office if that works. At Sun we had a project motto "no foreign orders". That means that each individual only took direction from one person. Whenever possible when asked to change direction, they would be referred to that lead. And have only one lead at a time. So when an editor is working on draft-awesome, they would work only on that document, until redirected by their lead. If your not a lead, you don't interact with the IAOC (or whoever else). Document out of band communications, perhaps: Editors communicate only for clarification and not process issues to the IAOC members or draft authors. Otherwise, it goes through the lead. In summary, if possible, isolate the workers from the exception flow and priority conflicts. (2) What do they spend their time doing that may cause too many process flow problems: I have always been confused about the internal workings of the editors office. xml2rfc should have reduced the load by minimizing the content formatting. Is there a written list of the tasks an editor does? There has to be checklist, even if it is a checklist of RFC's to conform to at any point in time. I remember for a while (maybe still) the editors took the output from xml2rfc and edit that, effectively throwing away the XML original. If so, why? Does xml2rfc only do part of the formatting work? Bugs? Are the editors unfamiliar with (or unwilling to learn) editing XML documents to fix the original? I can see changes to text using that process taking a lot more time than would be expected and it would lead to frustration when yet another from above change happens. What percent of the editors time is spent actually editing documents? What percent is tracking things down, or what? I would think it would be more efficient to have editors and one manager or lead. Do some edit only? Do some research for accuracy and not others? Does everyone do everything for the draft they are working on? In my minimal experience with the editors. In person they were great. With email - I felt like I was bothering them and I often got answers that confused me more. In one case I was told 'not to bother them again', when I thought I was answering their question. I guessed they were overworked. I still felt bad for bothering them. How many are in the RSE office / team when all positions are filled? Would volunteer pre-screeners solve some of the problems? What percent of the issues that need to be resolved are process flow vs xml2rfc vs content of the document or drawn images or ABNF or text emphasis is? I am sure they have a gripe list of repeat problems even if not written down :-) And what does "ACCOUNTABLE" mean to the RSE? Does anyone have a flowchart perhaps drawn by dia that shows the flow and "accountable to who" links? Do people think that only micro changes are needed? Is the general thinking that too much of the flow is undocumented and this is causing problems? Is everyone always in all loops - causing anxiety when hearing about things that may never happen? If so, have a manager that deals with the process and editors that are awesome with grammar and readability (unlike me). -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Wed Apr 1 20:14:07 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729093A0801 for ; Wed, 1 Apr 2020 20:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmyvDtHTRITo for ; Wed, 1 Apr 2020 20:14:05 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2993A07FD for ; Wed, 1 Apr 2020 20:14:05 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id c23so1192732pgj.3 for ; Wed, 01 Apr 2020 20:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=rOeTvKl3EQMa1V6JBjBo8DFzKhQyYc1CqluuGabdwWw=; b=YMQPQRA1Liu+OkXeanAARgZOJ3de53Hu68VEuxVKU83WY1Bv3qNWgY3T8t0r9/nmg2 YNOKEYgka3ucp94SQAvXcZF8asR311pn7wsrgyyUYO0T0KfyKv9bb+uoDylOzlY3P0Ac JpAa1j/GTc+T+HS90iFxOD/spgdAVylzxqhD6cs69D+zgVRzm/XDT1PfvpJ4HApx6vGl LDKpXPnbRJRWkrYNGk19QCDWGMM54RSO6fkWjVRjGa7hyZaT3VKJMTJ1jwUQl4cRyau1 Ldr+xNWxNFMcHkCyI2CogwqCHbYGoDjvYsN9r5otMp6gBY77ofKgCSIM9wDwI8qWD6QI anpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=rOeTvKl3EQMa1V6JBjBo8DFzKhQyYc1CqluuGabdwWw=; b=OaS4u4GYue2e+9FDxmBwCvVHdNutyidbHGJEBNzMJ0rqLrPEM3H6dL/ohI4Xx2Ufmg VyO9e1hMT8ZUpOXP6VssndmeIAxXfZnd9wEAtLbOdk42lo1QPO0hKqJqGveWidLAsub/ bg2bNVyBRURdvW27X+2suIe/LQk8hiSYFebXR8tmonvqOermT09tNk9QBSRcWEYD6RQH p1Jhex57dmp6MNYYIuQc6Jy4V5yufMxvYeXE2NCxZRxaOs6RvyRgwFRuozdqoz8v0tmX WY8YsDrUbZc230dy8eeOEn0DsCGwhSHTXWYuAO0ZJPPx6KKuoKMeewOUkEf3rnm3HZP5 M31Q== X-Gm-Message-State: AGi0PuYaDayyfUe/wzQdBcZI+R00c+tsXPvR7IaiuY1qlGZ6z9fI7Hqt ls+HIBct9Dhx1V488ZtfCp4Z2ZeEohU= X-Google-Smtp-Source: APiQypIn4iNWYgM30c/3yfgKpJoW/dDW18n/ILEKpezdbDSR4wKK8iuq5YzsQdObpegcmzMkvO2bbA== X-Received: by 2002:a62:64c9:: with SMTP id y192mr1075271pfb.26.1585797244652; Wed, 01 Apr 2020 20:14:04 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id j26sm2565664pfi.192.2020.04.01.20.14.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 20:14:03 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Michael StJohns'" , References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <612878B544D3F4BD620D9650@PSB> <0a9001d60887$02d355e0$087a01a0$@acm.org> In-Reply-To: Date: Wed, 1 Apr 2020 20:14:03 -0700 Message-ID: <0ac801d6089c$c36031b0$4a209510$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE1+R8uCRV9Abm7PvYymWtFQE+BqAGI0LbWAPvtDC0BdXNepQGgWDedAyrEptCpXxEoQA== Content-Language: en-us Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 03:14:07 -0000 I think what I'm calling the "AUTH48" problem was greatly exacerbated by = the format switch, making the normal publishing process of reviewing = "galley proofs" to be too onerous for those familiar with the material = vs. the RFC Editor who has enough to worry about without knowing what = might or might not be significant elements of typography, spacing, = emphasis in formats that the author didn't even review (text, html, pdf) IMHO, the "real problem" from a publishing workflow point of view is = that there is a workflow task that is not explicitly assigned, namely to = validate that the to-be-published RFC, in all its published formats, = reflects the intent of the author and the body that approved it. It's easy to imagine the results would be a lot of unmet expectation and = finger pointing, and arguments about what the "real problem" was. -- https://LarryMasinter.net =20 From nobody Wed Apr 1 20:26:57 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4143A0899 for ; Wed, 1 Apr 2020 20:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gof5ppQO2Ebn for ; Wed, 1 Apr 2020 20:26:54 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59473A08B8 for ; Wed, 1 Apr 2020 20:26:53 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jJqVA-0003Jr-T0; Wed, 01 Apr 2020 23:26:44 -0400 Date: Wed, 01 Apr 2020 23:26:37 -0400 From: John C Klensin To: Christian Huitema , Larry Masinter , 'Stephen Farrell' , 'Eliot Lear' , rfced-future@iab.org Message-ID: <5682175E041DE79BF10563D9@PSB> In-Reply-To: <450dc214-2606-d764-a24d-5b91a642f3bb@huitema.net> References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <612878B544D3F4BD620D9650@PSB> <0a9001d60887$02d355e0$087a01a0$@acm.org> <450dc214-2606-d764-a24d-5b91a642f3bb@huitema.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 03:26:56 -0000 --On Wednesday, April 1, 2020 18:39 -0700 Christian Huitema wrote: >... > There is indeed an issue with AUTH48, but there is a more > general issue with "changing documents after consensus is > declared". > > For the IETF stream, the current process puts the final phase > of editing after the final vote by the IESG. This is a source > of both tensions and delays. The tension is obvious: if a > document can be changed after it has been approved, how do we > guarantee that the changes do not change the meaning of the > documents in a way that alters consensus? The process puts > that responsibility on the authors and the AD, but the authors > may or may not have the time to examine the changes closely, > and the AD may or may not be already overloaded. So that > create delays, not because the copy editors are slow, but > because the authors and AD end up responding slowly. > > Removing tensions and delays would make life easier for > everybody. I completely agree with the comments above and would add that, sometimes, between when IETF Last Call ends and when the IESG votes, the IESG insists on changes to the document. In my experience, the vast majority of those changes improve things but some come very close to changing substantive details of the specification. While the author(s), shepherd, and WG Chair(s) are normally aware of the changes, returning the revised document to the WG and through IETF Last Call for a final check in the substantive issues (possibly a matter of judgment) is very rare. The net result is similar to (and, from the outside, often indistinguishable from) part of the AUTH48 problem you mention above: the document that is published may differ in significant (not just minor editorial) ways from the document on which IETF consensus is reached during Last Call or earlier. That said, I strongly recommend that we not take that on as part of this effort. It is a problem exclusive to the IETF Stream (other streams may or may not have similar problems). It involves significant issues in how documents in that stream are handled and with the dynamics between the RPC and the IESG (or particular ADs or IETF stream authors). It does not significantly involve the RSE (although I understand that some RSEs, including Heather, sometimes found themselves trying to mediate among the various parties). So, if we want to focus on the issues needed to write a good job description and get a new RSE on board, this is probably not one of those issues. best, john From nobody Wed Apr 1 20:43:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1423A0902 for ; Wed, 1 Apr 2020 20:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 RxttGY3hc9q9 for ; Wed, 1 Apr 2020 20:43:21 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014C93A078F for ; Wed, 1 Apr 2020 20:43:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 48t86c5rR8z1p0cx; Wed, 1 Apr 2020 20:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1585799000; bh=djF2RBFFr5i+jIoob52rCfzqvns2YTXb1ME/4y3Da+I=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=AiJdIjRFd8nUAALVozklmpbQlTbWF3m+CiUOhy69O9V+CE3D3WOxd9V/nQLKsqyhm K1aLdJosKqm+6iUL9LMabyGkHZ2Zs0Oj56ACBLdE0KO/SLi4UuT9N6WR7knctM1FTT yCrilH0jPmyyQ7f6vSS89rF11qYj/j+6t4mQsQ9o= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.135.88] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 48t86c1mcXz1p0ct; Wed, 1 Apr 2020 20:43:20 -0700 (PDT) SavedFromEmail: jmh.direct@joelhalpern.com Date: Wed, 01 Apr 2020 23:43:17 -0400 In-Reply-To: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> Importance: normal From: "jmh.direct@joelhalpern.com" To: Christian Huitema , "Joel M. Halpern" Cc: rfced-future@iab.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_15488489452618590" Message-Id: <20200402034321.014C93A078F@ietfa.amsl.com> Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 03:43:23 -0000 ----_com.samsung.android.email_15488489452618590 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 R2l2ZW4gdGhlIGFtb3VudCBvZiBjaGFuZ2UgSSBoYXZlIHNlZW4gKGFuZCBJIGhhdmUgbm90IGJl ZW4gb24gdGhlIElFU0cgaW4gTUFOWSB5ZWFycykgZHVyaW5nIGFwcHJvdmFsLMKgIGl0IHdvdWxk IGJlIHJlYWxseSBoYXJkIHRvIGRvIHRoZSBSUEMgd29yayBiZWZvcmUgSUVTRyByZXZpZXcuwqAg V2UgY291bGQgZG8gYW5vdGhlciByb3VuZCBvZiByZXZpZXcgYWZ0ZXIgUlBDLsKgIEJ1dCB0aGF0 IHdvdWxkIGluY3JlYXNlIGRlbGF5LCBub3QgZGVjcmVhc2UgaXQuWW91cnMsSm9lbFNlbnQgdmlh IHRoZSBTYW1zdW5nIEdhbGF4eSBTNywgYW4gQVQmVCA0RyBMVEUgc21hcnRwaG9uZQotLS0tLS0t LSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRl bWFAaHVpdGVtYS5uZXQ+IERhdGU6IDQvMS8yMCAgMjI6MzAgIChHTVQtMDU6MDApIFRvOiAiSm9l bCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gQ2M6IHJmY2VkLWZ1dHVyZUBpYWIu b3JnIFN1YmplY3Q6IFJlOiBbUmZjZWQtZnV0dXJlXSBXZWxjb21lIHRvIHRoZSBSRkMgRWRpdG9y IEZ1dHVyZSBEZXZlbG9wbWVudCBQcm9ncmFtIEkgZGlkIG5vdCB3cml0ZSB0aGF0IHdlIHNob3Vs ZCByZW1vdmUgY29weSBlZGl0aW5nLiBCdXQgd2UgY291bGQgY2VydGFpbmx5IGZpbmQgbW9kZWxz IGluIHdoaWNoIGl0IGhhcHBlbnMgYmVmb3JlIGFwcHJvdmFsLCBub3QgYWZ0ZXIgaXQuLS0gQ2hy aXN0aWFuIEh1aXRlbWEgPiBPbiBBcHIgMSwgMjAyMCwgYXQgNzoyMiBQTSwgSm9lbCBNLiBIYWxw ZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZTo+ID4g77u/Q2hyaXN0aWFuLCBJIGFtIGEg Yml0IGNvbmZ1c2VkIGJ5IHlvdXIgbWVzc2FnZS7CoCBSZW1vdmluZyBwb3N0LWFwcHJvdmFsIGVk aXRpbmcsIHdoaWxlIGl0IHdvdWxkIHJlZHVjZSB0ZW5zaW9uIGFuZCBkZWxheSwgd291bGQgYWxz byBzaWduaWZpY2FudGx5IHJlZHVjZSBkb2N1bWVudCBxdWFsaXR5LsKgIFRoZSBSUEMgZG9lcyBh biBpbXByZXNzaXZlIGpvYiBvZiBmaXhpbmcgdGhlIG1hbnkgbWlub3IgYnV0IHNpZ25pZmljYW50 IGVycm9ycyB3ZSBwdXQgaW4gb3VyIGRvY3VtZW50cy7CoCBSYW5naW5nIGZyb20gaW5jb25zaXN0 ZW50IHRlcm1pbm9sb2d5IHRvIHJlYWxseSBiYWQgZ3JhbW1hci4+IEksIGZvciBvbmUsIHdvdWxk IGJlIHJlYWxseSB1bmhhcHB5IGF0IHRyeWluZyB0byBkZWNpZGUgd2UgZGlkIG5vdCBuZWVkIHRo YXQuPiA+IFlvdXJzLD4gSm9lbD4gPj4gT24gNC8xLzIwMjAgOTozOSBQTSwgQ2hyaXN0aWFuIEh1 aXRlbWEgd3JvdGU6Pj4gT24gNC8xLzIwMjAgNTozOCBQTSwgTGFycnkgTWFzaW50ZXIgd3JvdGU6 Pj4+PiBJIGhvcGUgdGhpcyBwcm9jZXNzIGNhbiBmaW5kIGEgd2F5IHRvIGRlYWwgd2l0aCBzdWNo IGRpdmVyZ2VudCB2aWV3cywgb3IgZmluZD4+Pj4gYSByb2xlIGRlc2NyaXB0aW9uIHdpdGggd2hp Y2ggd2UgYXJlIGFsbCBlcXVhbGx5IHVuaGFwcHksIGJ1dCB3aXRoIHdoaWNoIHdlPj4+PiBjYW4g YWxsIGxpdmU7LSg+Pj4gSSB0aGluayB0aGUgcXVlc3Rpb24gaXMgaG93IGJpZyBhIHNjb3BlIG9m ICJzb2x1dGlvbnMiIHNob3VsZCBiZSB0YWtlbiBvbi4+Pj4gQXQgdGhlICJsYXJnZSBzY29wZSIg YXJlIGNoYW5nZXMgdG8gdGhlIG5hdHVyZSBvZiBSRkNzIGFuZCB0aGUgc2VyaWVzPj4+IEF0IHRo ZSAic21hbGwgc2NvcGUiIGVuZCBJJ2Qgc3VnZ2VzdCAtLSB3aXRob3V0IGFueSBvdGhlciBjaGFu Z2UgLS0gZm9jdXNpbmcgb24gdGhlICJBVVRINDgiIHN0YXR1cyBzaW5jZSA0OCBob3VycyBhbmQg b25seSB0aGUgYXV0aG9ycyBjYW5ub3QgcHJvb2ZyZWFkIGV2ZXJ5dGhpbmcgdGhhdCBuZWVkcyBw cm9vZnJlYWRpbmcuPj4+ID4+PiAoSGlzdG9yeSBSRkMyNjE2IGhhZCBzZXZlcmFsIGVycm9ycyB0 aGF0IHdlcmUgZHVlIHRvIGJ1Z3MgaW4gdGhlIHByb2Nlc3Mgb2YgY29udmVydGluZyBXb3JkIHRv IHRleHQvcGxhaW4pPj4+ID4+PiBJIGNhbid0IHRlbGwgZnJvbSB0aGUgcG9zdHMgYW5kIGludHJv IG1hdGVyaWFsIHdoYXQgbGV2ZWwgb2YgY2hhbmdlcyB0byB0aGUgcHJvY2VzcyB5b3UnZCB3YW50 IHRvIGNvbnRlbXBsYXRlLj4+IFRoZXJlIGlzIGluZGVlZCBhbiBpc3N1ZSB3aXRoIEFVVEg0OCwg YnV0IHRoZXJlIGlzIGEgbW9yZSBnZW5lcmFsIGlzc3VlIHdpdGggImNoYW5naW5nIGRvY3VtZW50 cyBhZnRlciBjb25zZW5zdXMgaXMgZGVjbGFyZWQiLj4+IEZvciB0aGUgSUVURiBzdHJlYW0sIHRo ZSBjdXJyZW50IHByb2Nlc3MgcHV0cyB0aGUgZmluYWwgcGhhc2Ugb2YgZWRpdGluZyBhZnRlciB0 aGUgZmluYWwgdm90ZSBieSB0aGUgSUVTRy4gVGhpcyBpcyBhIHNvdXJjZSBvZiBib3RoIHRlbnNp b25zIGFuZCBkZWxheXMuIFRoZSB0ZW5zaW9uIGlzIG9idmlvdXM6IGlmIGEgZG9jdW1lbnQgY2Fu IGJlIGNoYW5nZWQgYWZ0ZXIgaXQgaGFzIGJlZW4gYXBwcm92ZWQsIGhvdyBkbyB3ZSBndWFyYW50 ZWUgdGhhdCB0aGUgY2hhbmdlcyBkbyBub3QgY2hhbmdlIHRoZSBtZWFuaW5nIG9mIHRoZSBkb2N1 bWVudHMgaW4gYSB3YXkgdGhhdCBhbHRlcnMgY29uc2Vuc3VzPyBUaGUgcHJvY2VzcyBwdXRzIHRo YXQgcmVzcG9uc2liaWxpdHkgb24gdGhlIGF1dGhvcnMgYW5kIHRoZSBBRCwgYnV0IHRoZSBhdXRo b3JzIG1heSBvciBtYXkgbm90IGhhdmUgdGhlIHRpbWUgdG8gZXhhbWluZSB0aGUgY2hhbmdlcyBj bG9zZWx5LCBhbmQgdGhlIEFEIG1heSBvciBtYXkgbm90IGJlIGFscmVhZHkgb3ZlcmxvYWRlZC4g U28gdGhhdCBjcmVhdGUgZGVsYXlzLCBub3QgYmVjYXVzZSB0aGUgY29weSBlZGl0b3JzIGFyZSBz bG93LCBidXQgYmVjYXVzZSB0aGUgYXV0aG9ycyBhbmQgQUQgZW5kIHVwIHJlc3BvbmRpbmcgc2xv d2x5Lj4+IFJlbW92aW5nIHRlbnNpb25zIGFuZCBkZWxheXMgd291bGQgbWFrZSBsaWZlIGVhc2ll ciBmb3IgZXZlcnlib2R5Lj4+IC0tIENocmlzdGlhbiBIdWl0ZW1hPiA+IC0tID4gUmZjZWQtZnV0 dXJlIG1haWxpbmcgbGlzdD4gUmZjZWQtZnV0dXJlQGlhYi5vcmc+IGh0dHBzOi8vd3d3LmlhYi5v cmcvbWFpbG1hbi9saXN0aW5mby9yZmNlZC1mdXR1cmU= ----_com.samsung.android.email_15488489452618590 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5HaXZlbiB0aGUgYW1vdW50IG9mIGNoYW5nZSBJIGhhdmUgc2VlbiAoYW5kIEkgaGF2ZSBu b3QgYmVlbiBvbiB0aGUgSUVTRyBpbiBNQU5ZIHllYXJzKSBkdXJpbmcgYXBwcm92YWwsJm5ic3A7 IGl0IHdvdWxkIGJlIHJlYWxseSBoYXJkIHRvIGRvIHRoZSBSUEMgd29yayBiZWZvcmUgSUVTRyBy ZXZpZXcuJm5ic3A7IFdlIGNvdWxkIGRvIGFub3RoZXIgcm91bmQgb2YgcmV2aWV3IGFmdGVyIFJQ Qy4mbmJzcDsgQnV0IHRoYXQgd291bGQgaW5jcmVhc2UgZGVsYXksIG5vdCBkZWNyZWFzZSBpdC48 L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5Zb3Vycyw8L2Rp dj48ZGl2IGRpcj0iYXV0byI+Sm9lbDwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRp diBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgaWQ9 ImNvbXBvc2VyX3NpZ25hdHVyZSIgZGlyPSJhdXRvIj48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUl O2NvbG9yOiM1NzU3NTciIGRpcj0iYXV0byI+U2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFM3 LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTwvZGl2PjwvZGl2PjxkaXYgZGlyPSJhdXRv Ij48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29s b3I6IzAwMDAwMCIgZGlyPSJhdXRvIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0t LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IENocmlzdGlhbiBI dWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDQvMS8y MCAgMjI6MzAgIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86ICJKb2VsIE0uIEhhbHBlcm4iICZs dDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OyA8L2Rpdj48ZGl2PkNjOiByZmNlZC1mdXR1cmVAaWFi Lm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbUmZjZWQtZnV0dXJlXSBXZWxjb21lIHRvIHRo ZSBSRkMgRWRpdG9yIEZ1dHVyZSBEZXZlbG9wbWVudCBQcm9ncmFtIDwvZGl2PjxkaXY+PGJyPjwv ZGl2PjwvZGl2PkkgZGlkIG5vdCB3cml0ZSB0aGF0IHdlIHNob3VsZCByZW1vdmUgY29weSBlZGl0 aW5nLiBCdXQgd2UgY291bGQgY2VydGFpbmx5IGZpbmQgbW9kZWxzIGluIHdoaWNoIGl0IGhhcHBl bnMgYmVmb3JlIGFwcHJvdmFsLCBub3QgYWZ0ZXIgaXQuPGJyPjxicj4tLSBDaHJpc3RpYW4gSHVp dGVtYSA8YnI+PGJyPiZndDsgT24gQXByIDEsIDIwMjAsIGF0IDc6MjIgUE0sIEpvZWwgTS4gSGFs cGVybiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDsgd3JvdGU6PGJyPiZndDsgPGJyPiZndDsg 77u/Q2hyaXN0aWFuLCBJIGFtIGEgYml0IGNvbmZ1c2VkIGJ5IHlvdXIgbWVzc2FnZS4mbmJzcDsg UmVtb3ZpbmcgcG9zdC1hcHByb3ZhbCBlZGl0aW5nLCB3aGlsZSBpdCB3b3VsZCByZWR1Y2UgdGVu c2lvbiBhbmQgZGVsYXksIHdvdWxkIGFsc28gc2lnbmlmaWNhbnRseSByZWR1Y2UgZG9jdW1lbnQg cXVhbGl0eS4mbmJzcDsgVGhlIFJQQyBkb2VzIGFuIGltcHJlc3NpdmUgam9iIG9mIGZpeGluZyB0 aGUgbWFueSBtaW5vciBidXQgc2lnbmlmaWNhbnQgZXJyb3JzIHdlIHB1dCBpbiBvdXIgZG9jdW1l bnRzLiZuYnNwOyBSYW5naW5nIGZyb20gaW5jb25zaXN0ZW50IHRlcm1pbm9sb2d5IHRvIHJlYWxs eSBiYWQgZ3JhbW1hci48YnI+Jmd0OyBJLCBmb3Igb25lLCB3b3VsZCBiZSByZWFsbHkgdW5oYXBw eSBhdCB0cnlpbmcgdG8gZGVjaWRlIHdlIGRpZCBub3QgbmVlZCB0aGF0Ljxicj4mZ3Q7IDxicj4m Z3Q7IFlvdXJzLDxicj4mZ3Q7IEpvZWw8YnI+Jmd0OyA8YnI+Jmd0OyZndDsgT24gNC8xLzIwMjAg OTozOSBQTSwgQ2hyaXN0aWFuIEh1aXRlbWEgd3JvdGU6PGJyPiZndDsmZ3Q7IE9uIDQvMS8yMDIw IDU6MzggUE0sIExhcnJ5IE1hc2ludGVyIHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IEkgaG9w ZSB0aGlzIHByb2Nlc3MgY2FuIGZpbmQgYSB3YXkgdG8gZGVhbCB3aXRoIHN1Y2ggZGl2ZXJnZW50 IHZpZXdzLCBvciBmaW5kPGJyPiZndDsmZ3Q7Jmd0OyZndDsgYSByb2xlIGRlc2NyaXB0aW9uIHdp dGggd2hpY2ggd2UgYXJlIGFsbCBlcXVhbGx5IHVuaGFwcHksIGJ1dCB3aXRoIHdoaWNoIHdlPGJy PiZndDsmZ3Q7Jmd0OyZndDsgY2FuIGFsbCBsaXZlOy0oPGJyPiZndDsmZ3Q7Jmd0OyBJIHRoaW5r IHRoZSBxdWVzdGlvbiBpcyBob3cgYmlnIGEgc2NvcGUgb2YgInNvbHV0aW9ucyIgc2hvdWxkIGJl IHRha2VuIG9uLjxicj4mZ3Q7Jmd0OyZndDsgQXQgdGhlICJsYXJnZSBzY29wZSIgYXJlIGNoYW5n ZXMgdG8gdGhlIG5hdHVyZSBvZiBSRkNzIGFuZCB0aGUgc2VyaWVzPGJyPiZndDsmZ3Q7Jmd0OyBB dCB0aGUgInNtYWxsIHNjb3BlIiBlbmQgSSdkIHN1Z2dlc3QgLS0gd2l0aG91dCBhbnkgb3RoZXIg Y2hhbmdlIC0tIGZvY3VzaW5nIG9uIHRoZSAiQVVUSDQ4IiBzdGF0dXMgc2luY2UgNDggaG91cnMg YW5kIG9ubHkgdGhlIGF1dGhvcnMgY2Fubm90IHByb29mcmVhZCBldmVyeXRoaW5nIHRoYXQgbmVl ZHMgcHJvb2ZyZWFkaW5nLjxicj4mZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyAoSGlzdG9y eSBSRkMyNjE2IGhhZCBzZXZlcmFsIGVycm9ycyB0aGF0IHdlcmUgZHVlIHRvIGJ1Z3MgaW4gdGhl IHByb2Nlc3Mgb2YgY29udmVydGluZyBXb3JkIHRvIHRleHQvcGxhaW4pPGJyPiZndDsmZ3Q7Jmd0 OyA8YnI+Jmd0OyZndDsmZ3Q7IEkgY2FuJ3QgdGVsbCBmcm9tIHRoZSBwb3N0cyBhbmQgaW50cm8g bWF0ZXJpYWwgd2hhdCBsZXZlbCBvZiBjaGFuZ2VzIHRvIHRoZSBwcm9jZXNzIHlvdSdkIHdhbnQg dG8gY29udGVtcGxhdGUuPGJyPiZndDsmZ3Q7IFRoZXJlIGlzIGluZGVlZCBhbiBpc3N1ZSB3aXRo IEFVVEg0OCwgYnV0IHRoZXJlIGlzIGEgbW9yZSBnZW5lcmFsIGlzc3VlIHdpdGggImNoYW5naW5n IGRvY3VtZW50cyBhZnRlciBjb25zZW5zdXMgaXMgZGVjbGFyZWQiLjxicj4mZ3Q7Jmd0OyBGb3Ig dGhlIElFVEYgc3RyZWFtLCB0aGUgY3VycmVudCBwcm9jZXNzIHB1dHMgdGhlIGZpbmFsIHBoYXNl IG9mIGVkaXRpbmcgYWZ0ZXIgdGhlIGZpbmFsIHZvdGUgYnkgdGhlIElFU0cuIFRoaXMgaXMgYSBz b3VyY2Ugb2YgYm90aCB0ZW5zaW9ucyBhbmQgZGVsYXlzLiBUaGUgdGVuc2lvbiBpcyBvYnZpb3Vz OiBpZiBhIGRvY3VtZW50IGNhbiBiZSBjaGFuZ2VkIGFmdGVyIGl0IGhhcyBiZWVuIGFwcHJvdmVk LCBob3cgZG8gd2UgZ3VhcmFudGVlIHRoYXQgdGhlIGNoYW5nZXMgZG8gbm90IGNoYW5nZSB0aGUg bWVhbmluZyBvZiB0aGUgZG9jdW1lbnRzIGluIGEgd2F5IHRoYXQgYWx0ZXJzIGNvbnNlbnN1cz8g VGhlIHByb2Nlc3MgcHV0cyB0aGF0IHJlc3BvbnNpYmlsaXR5IG9uIHRoZSBhdXRob3JzIGFuZCB0 aGUgQUQsIGJ1dCB0aGUgYXV0aG9ycyBtYXkgb3IgbWF5IG5vdCBoYXZlIHRoZSB0aW1lIHRvIGV4 YW1pbmUgdGhlIGNoYW5nZXMgY2xvc2VseSwgYW5kIHRoZSBBRCBtYXkgb3IgbWF5IG5vdCBiZSBh bHJlYWR5IG92ZXJsb2FkZWQuIFNvIHRoYXQgY3JlYXRlIGRlbGF5cywgbm90IGJlY2F1c2UgdGhl IGNvcHkgZWRpdG9ycyBhcmUgc2xvdywgYnV0IGJlY2F1c2UgdGhlIGF1dGhvcnMgYW5kIEFEIGVu ZCB1cCByZXNwb25kaW5nIHNsb3dseS48YnI+Jmd0OyZndDsgUmVtb3ZpbmcgdGVuc2lvbnMgYW5k IGRlbGF5cyB3b3VsZCBtYWtlIGxpZmUgZWFzaWVyIGZvciBldmVyeWJvZHkuPGJyPiZndDsmZ3Q7 IC0tIENocmlzdGlhbiBIdWl0ZW1hPGJyPiZndDsgPGJyPiZndDsgLS0gPGJyPiZndDsgUmZjZWQt ZnV0dXJlIG1haWxpbmcgbGlzdDxicj4mZ3Q7IFJmY2VkLWZ1dHVyZUBpYWIub3JnPGJyPiZndDsg aHR0cHM6Ly93d3cuaWFiLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JmY2VkLWZ1dHVyZTxicj48YnI+ PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_15488489452618590-- From nobody Wed Apr 1 20:51:31 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3A3A094E for ; Wed, 1 Apr 2020 20:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOlPzYNk_P3r for ; Wed, 1 Apr 2020 20:51:28 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F96E3A094D for ; Wed, 1 Apr 2020 20:51:28 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jJqt2-0003N8-VQ; Wed, 01 Apr 2020 23:51:24 -0400 Date: Wed, 01 Apr 2020 23:51:18 -0400 From: John C Klensin To: Christian Huitema , "Joel M. Halpern" cc: rfced-future@iab.org Message-ID: <75FEFDC1BB902A9091739F47@PSB> In-Reply-To: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 03:51:30 -0000 (I've changed the subject line because I really hope we can split this off and either set it aside until other work is finished or find another way to handle it as an issue.) --On Wednesday, April 1, 2020 19:30 -0700 Christian Huitema wrote: > I did not write that we should remove copy editing. But we > could certainly find models in which it happens before > approval, not after it. Christian, see my earlier note and Mike's response, with while I agree. However, fwiw, models are well-known in which documents reach a certain state before the final community decision process that would be nearly equivalent (as process steps) to the combination of our Last Call and IESG final review are pulled out and subjected to what is essentially final editing. There is then usually an opportunity for the group that produced the draft document to review it and argue with the editors. The edited, document then goes into final reviews. If those reviews identify changes that require changes, the changes are made and the document re-edited, and then, depending on the extent of the changes, either the whole document or the changes go through the review process again. A few details and small differences aside, that is the method used in ITU-T, in ISO and ISO/IEC JTC1, in many (perhaps most) ISO National Member Bodies, and in a variety of other SDOs. The IETF is probably not unique in the way we do things, but I suspect we don't have a lot of company. I'm aware of a number of proposals to shift to something closer to the other model, at least on during Heather's term and the first probably in the late 1980s. The decision to not do so was always based on what were considered bad tradeoffs with multiple issue, almost always including: (1) The editing process takes time. The IETF has never been willing to have a WG finish a document and then go into a wait state for some weeks or months while that document is being edited, then wake up, review it, and recommend that it be put out for Last Call. At least in the past, our way of working was perceived as incompatible with that. (2) Editing documents that may never be approved, or that will be approved only with significant changes (and then edited again), is costly in people and hours. I vaguely recall Heather (probably with help from Sandy and/or Alice) making some rough estimates of how much additional staff would be needed. I don't remember the numbers, but it was certainly enough to affect the bottom line. When I remember the idea being reviewed, those potential costs were a consideration. I do think that things have changed enough that it is time to ask the question again. But, again, I think this effort is not the right place or time. best, john From nobody Wed Apr 1 21:40:51 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A033A0C27 for ; Wed, 1 Apr 2020 21:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ZlJWlPZ/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Bs4HmcT9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ggdXPVMKcsC for ; Wed, 1 Apr 2020 21:40:48 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F033A0C26 for ; Wed, 1 Apr 2020 21:40:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 7D40C693 for ; Thu, 2 Apr 2020 00:40:46 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 02 Apr 2020 00:40:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=AqPEyB7rtFuhqJ5MDiQYtHbG3WMkxqruC7OjdzWnkmY=; b=ZlJWlPZ/ RTjcCIF51cRuuYV4TF/EAUtLObHeVTF0RPUuJt/0BYNxb1vxEVnDkRzzZhIxWb74 EXTux6DEyMloIbKl6rYCbKgzZUAcn6O4ZWaw5Tj9RN2+7BZ+KRWoEH22nIHqxHNH WTh2IFcFwAKaK/kRu5mmzmhBtDzlH43mwW8efQoeU2aOFFM3NeV7WKY7LLMXoEvd 3ykygfa5PNEDDnSmrBxx6UMD0pL0Vv6zZOZcshI5XjacHh6IUU5XsLyX6w61cA9m amxp9aL/caAec1keVK+hJTamM/lbXv2jH2tzhLaRME5HHiTJdzAdrcQFpX4B1XOC Dpg0qlIUtRUUag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=AqPEyB7rtFuhqJ5MDiQYtHbG3WMkx qruC7OjdzWnkmY=; b=Bs4HmcT9Oirgl6AnoF5VJ3saWuSa+zZ+jDDohVkB5NfSr st0jbig4jD3+Ki2jjCRGicy5zrfH9Lx8Sti0Z3TmrW/SRzA4riMWnQrMDAJBjQbI DD18sn6XgJdqet8a719jrUkTFxr5/i8VsvMuSC1MLd76kcx0m2qyORgkBY9WFmHg A7LUAi9piMTEdnpSV04iJnIShufACdev62gH9iJCG7m3HdCsxGnG+cdTOTMaXiyA bW/FHIlu4TfqCTJ3f/NXzuDLqyfA1bKT26Rp7P5KIERjUxgtp72VEpfKiF9z68yf MGXRHPhx8W8OAQE+tb0GY+xY+U0NVPdzXAwAfod4g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdefgdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhho phihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id ABA0EE00A6; Thu, 2 Apr 2020 00:40:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1079-ga710375-fmstable-20200402v4 Mime-Version: 1.0 Message-Id: Date: Thu, 02 Apr 2020 15:40:25 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: [Rfced-future] What do we need/want? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 04:40:50 -0000 I appreciate Brian's attempt to avoid blame in trying to look for problems. I think that we also need to ask what this community needs and wants from this function. Maybe that's a little out of scope, but I think that it matters a great deal. https://iaoc.ietf.org/documents/RSE-descr-2016-r6-Clean.pdf contains a recent statement of work. RFC 8728 defines what the RFC editor *is*. Plus the other stuff Eliot shared. But in terms of the structure in which the function sits, what is truly important? In terms of over-arching goals, I have heard "good enough to support the series for another 50 years if the content is up to snuff", paraphrasing Stephen (hopefully accurately), which might be good as an abstract mission statement, even if it is a bit of a mouthful. That last clause about the quality of content does a lot more work than I'd like there as well. This does imply some unspecified strategic decisions; you don't have a hope of operating on that timescale without a lot of forethought. Worrying about a legacy over very long periods is not worth the effort that might be expended on it. You could examine the system we have - one that clearly exhibits survivor bias - with the hope that you might learn something relevant, but we could instead concentrate on doing the best we can over periods that are more relevant. 5 years is a solid length of time to plan for, if not 10-15. The other meta-goal I routinely hear "keep the RFCs coming". That might lead to ignoring or downplaying the challenges we might need to anticipate. I happen to think that this is highly relevant, if not the totality of the overall goal. The format change has not been good in that regard. I had a simple, standalone document that was relatively time-sensitive sit in queue for almost 4 months after approval. At the other extreme, I also have another document that is still being processed after almost 4 years in queue. My understanding is that the RSE is responsible for anticipating and working to avoid systemic or structural problems of that nature. To use the words the RSOC used: that's an important, but tactical function. To me, the series exists to serve a community of people who benefit from creating a record of their agreements (and disagreements if you like). That we use a bespoke and user-hostile format is not a feature, but a bug. That we depend on extensive and expensive copy-editing is more bug than feature, as much as I appreciate the improved quality of the result. That we insist on these artifacts being immutable is a bug. And many other things that I'm sure will elicit much disagreement. However, those are not important characteristics of the series; the content - and often the agreements that the content codifies - is what matters. And besides that, those questions aren't in scope for this effort. Our goal is to work out how we might designate responsibility for leadership on those - and other matters - to a role that fits within our organizational structure. Again, I'm tempted to ignore that scope and ask why we need that leadership to be so delegated, but I will try to keep on target. We have, for the longest time, had a single figurehead to shepherd those aspects of the series that matter least. I don't see any editorial control being exercised over content, with the exception of the Independent Submissions Stream, where ISE discretion is the entire purpose of the stream. What has been achieved there in to my knowledge has been largely tactical. Yes, it matters that we have DOIs on documents and that we can use real names, those are changes with long-term value. Archival agreements and rescuing data from old bits of paper is similarly good, but not really strategic. Assigning responsibility to anticipate and address problems like that is important, but it does not require someone with the stature of previous RSEs. Meanwhile, valuable content continues to be published in RFCs. And other SDOs produce work with far less pomp and circumstance. So while we have created a role to which great gravitas has accrued, maybe we don't need that and a little more employee and less venerated elder is in order. For the leadership part, maybe we should look to the community. From nobody Wed Apr 1 22:23:49 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB243A012A for ; Wed, 1 Apr 2020 22:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe9Ja6WW9iVF for ; Wed, 1 Apr 2020 22:23:45 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF43D3A00D5 for ; Wed, 1 Apr 2020 22:23:45 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id r14so1194765pfl.12 for ; Wed, 01 Apr 2020 22:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=qv1EY4fW6oxuOYdFaV/hBZEcz1kFpz1YWTDdfKVQ+JY=; b=sEvziR/5b/LfsdMZJN+o+Y/JTXN0qTG8/75kotmO7oVWBrN2IA3y/A7lmUXr+KUPDl TIVkx43wreIj/WYEA7EGR4HOLgIWVeNnt7EGMOCJAQIBv6oYdbfCAm6X3QfDXgzMqC9W ygF9IWqMC8+ahZP6wrzCKuq1fLE++eezCxDu7cfZzcX1JsPpNyhLktXvDvnqFH9TqcEr 7/XvK/T76y/1Py02exCXe+lBKVwkKO6i0sdF/kU9DQBi5hESDs2jT41aL5sXF/jD6JIH CmqTwiMvab8BwtBby4WxW9e4ut3P5xjlddZxUWh3pNVE/FTnFswYUElfhyey3mjfhH7n ap+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=qv1EY4fW6oxuOYdFaV/hBZEcz1kFpz1YWTDdfKVQ+JY=; b=F5HsYwGRq5DmUc4UgF4LCA0PHdJhlnm9Hzvr+iIxg/crbiVSxlNKxSjoWfuU9UGs+i uOoivrPnbb8TQ4V9sMxtyOGJGByn7Peq2tK5dAdNovOmFLJk/pde40tUFXtJgdreNLAl sXqtbk7pzT1MQNzpKf4GMef+w5lzp+6QRvGaaFKBB6dEHTsZR/Zik4KtK+mPN30oIT36 ziFByd4r1Y7tGyzgxR7ePXzVNSAQSxjKJsu4/EWrdZD6FZuSXRiipWd+so+8C85sr9fe +ZkpMuUPi0mLjuhnorPGv8NNGn8YQsUQwl6qyspLgUlH1K4aleWQDI9FYdkmmi0ZocPa nUsA== X-Gm-Message-State: AGi0PuYv3oppoMdU839IFTyT2kDB/uLYG5oPmDeSNzwiRcTjfeIJRnjz 9TdzxCZn2uIz20sZvwpdfSo= X-Google-Smtp-Source: APiQypI0gatux12PlDhK4l1r8Sc4SI0zzRbYfl7ezaDJZ5bar0f3aRcxhKYHKM10UOArV/Gnnq5AXw== X-Received: by 2002:a62:834c:: with SMTP id h73mr1453248pfe.59.1585805024818; Wed, 01 Apr 2020 22:23:44 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id s9sm2852576pjr.5.2020.04.01.22.23.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 22:23:43 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Michael StJohns'" , References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <9e9696d8-bf2f-6306-eaec-9d0e26cb025f@nthpermutation.com> In-Reply-To: <9e9696d8-bf2f-6306-eaec-9d0e26cb025f@nthpermutation.com> Date: Wed, 1 Apr 2020 22:23:42 -0700 Message-ID: <0af901d608ae$e09b8ab0$a1d2a010$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHF3WBhyogH6aTr1uBc7M4aMcelCQMPX/FpAsG4ZrGoVxMAgA== Content-Language: en-us Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 05:23:48 -0000 > As I suggested in my response to Larry, perhaps this is a rat hole = that should > be avoided at this point in the discussion? That's fine. I just meant AUTH48 as an example of a "small" problem. Feel free to propose a smaller (non-)rathole that would make the Editor job less onerous and the qualifications more fillable. > >>> On 4/1/2020 5:38 PM, Larry Masinter wrote: > >>>> I think the question is how big a scope of "solutions" should be = taken on. > >>>> At the "large scope" are changes to the nature of RFCs and the > >>>> series At the "small scope" end I'd suggest -- without any other = change --=20 > >>>> focusing on the "AUTH48" status since 48 hours and only the = authors=20 > >>>>cannot proofread everything that needs proofreading. > >>>> > >>>> (History RFC2616 had several errors that were due to bugs in the > >>>> process of converting Word to text/plain) > >>>> > >>>> I can't tell from the posts and intro material what level of = changes to > >>>> the process you'd want to contemplate. -- https://LarryMasinter.net=20 https://going-remote.info=20 About rats: https://www.nytimes.com/2020/04/01/science/coronavirus-animals-wildlife-g= oats.html From nobody Thu Apr 2 01:00:20 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD5C3A0D0F for ; Thu, 2 Apr 2020 01:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK2kNxHk5cL7 for ; Thu, 2 Apr 2020 01:00:18 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A133E3A0D0E for ; Thu, 2 Apr 2020 01:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1289; q=dns/txt; s=iport; t=1585814417; x=1587024017; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Iwh9BBh6jTqUIYu24CA1iA25t/S69ddHVBsat9vH72Q=; b=kCH5j9u3YerPkOZWKbbouPVQuh1sg+oXH5SaXVUL6XZCR2L4PTFLwdcV 1DZAg8zm5N+BjbO58dZsQT6AXtiMWKoh6EtzUER7dIufLiZAiQIr6iYlV LfobordhN2mhxWBU6SxVem5+ThnEYhykFZB5ySw86IgI4skFQCjcvKGz+ c=; X-IPAS-Result: =?us-ascii?q?A0ARAQD4moVe/xbLJq1mGwEBAQEBAQEFAQEBEQEBAwMBA?= =?us-ascii?q?QGBe4MVVAEgEiqEG4kBiBSbRwoBAQEMAQEjDAQBAYREAoJkOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEFBG2FVgyFcAEBAQEBAQEjVgULCw4KAgImAgJXBhMUgxIBg?= =?us-ascii?q?lwgD64KdYEyhElBQYUYBoEOKoxLggCBOCCBT34+gmcCAYFkgxIygiwEjWSjH?= =?us-ascii?q?oJHgl2FDI8yHYJMjGgnjBeYSo8/HoMYAgQGBQIVgWkigVczGggbFTsqAYI+P?= =?us-ascii?q?hIYDZckhUM/AzACj0UBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.72,335,1580774400"; d="scan'208";a="22660936" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2020 08:00:15 +0000 Received: from [10.61.170.180] ([10.61.170.180]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03280Ajh006764 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2020 08:00:13 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Thu, 2 Apr 2020 10:00:10 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <7FC70855-D23D-493D-854F-5B2418EF9897@cisco.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.170.180, [10.61.170.180] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] What do we need/want? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 08:00:19 -0000 Hi Martin Thanks for your well thought-out message. Two points below. > On 2 Apr 2020, at 06:40, Martin Thomson wrote: >=20 > I appreciate Brian's attempt to avoid blame in trying to look for = problems. >=20 > I think that we also need to ask what this community needs and wants = from this function. Maybe that's a little out of scope, but I think = that it matters a great deal. >=20 > https://iaoc.ietf.org/documents/RSE-descr-2016-r6-Clean.pdf contains a = recent statement of work. I have added this to the suggested reading list. It=E2=80=99s good to = read because it make it quite concrete as to what was being asked of the = RFC Editor at that point in time. People can use it to think about = which items in the SoW should be under the purview of the RSE, which are = missing, which should be under someone else=E2=80=99s remit, and which = takes shouldn=E2=80=99t be performed at all. As to the rest of your message, it outlines your vision and your = concerns, and that in turn drives a point of view as to how the role = needs to be structured. And so I don=E2=80=99t find the message to be = at all out of scope for this group but rather well worth the read, even = if one disagrees with your point of view. Eliot From nobody Thu Apr 2 03:33:02 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11173A0F72 for ; Thu, 2 Apr 2020 03:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 hF_z-MIcO1UK for ; Thu, 2 Apr 2020 03:32:58 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D983A044F for ; Thu, 2 Apr 2020 03:32:57 -0700 (PDT) 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 032AWtRS004367 for ; Thu, 2 Apr 2020 11:32:55 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6AAA0221A4 for ; Thu, 2 Apr 2020 11:32:55 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 55A14221A5 for ; Thu, 2 Apr 2020 11:32:55 +0100 (BST) Received: from LAPTOPK7AS653V (81-174-206-152.bbplus.pte-ag2.dyn.plus.net [81.174.206.152] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 032AWsQ2016273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Apr 2020 11:32:54 +0100 Reply-To: From: "Adrian Farrel" To: References: <64a845e5-ad60-04da-66c7-ce084693cb8d@gmail.com> <10fb66c6-2725-f76c-4727-0ded3095c77b@gmail.com> In-Reply-To: <10fb66c6-2725-f76c-4727-0ded3095c77b@gmail.com> Date: Thu, 2 Apr 2020 11:32:54 +0100 Organization: Old Dog Consulting Message-ID: <10a201d608da$11e0db90$35a292b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJWdFj4VQxbaQHCwS2ApJi6TVeihQLiFtXWAm+Qg90CRWlvE6coDhQA X-Originating-IP: 81.174.206.152 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-25328.006 X-TM-AS-Result: No--17.842-10.0-31-10 X-imss-scan-details: No--17.842-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25328.006 X-TMASE-Result: 10--17.842000-10.000000 X-TMASE-MatchedRID: CxmI61mtwh/gJ+zJf+ap/3FPUrVDm6jtW1eClGWYNyhxps32fZo2QREa mnVaSH89DLu8MazwdBuUgjpAAuN4mOduH/w2XtZICuDAUX+yO6aVTzTd3tUSXxw0HKhKjTfpddD NUlHYqIgNtArjqrQyhR/Ne6ZdAvcM7fE5/CB8CmEZSUX8zcPGnw5vuI6Hi/n9tCd8V1JGWd0gYE YKevuTAnYh2XkjlCNqNdyDQ1iZXsG+STuCag5qNtqLN7nigLBU+JzoxrXf659E7KMPPUNR012tv sxNXD/l4ZqeCfqSJPL+w331TsHWu7BAQLqGlKiv8eSmTJSmEv3NUTeBBPKQKlddtl4yXVYP1obu nPgpS8vNcoYQ/FPqABcpSblA2quTXFeHpESDmTMASCpNzgtLhAeCHewokHM/aQZligpxepr6QRz jTw1oyuysvPro1t23NBf+mU70Fo4CWAJNioDShfRUId35VCIe9+PHtghP8GIZwGrh4y4izOvQnF ZiDWR57Nv+w9W53t3Dsq2pwN4F1I/GLM+NjhSNXOy4Q4JDh9ZM8zV+hbhmAxFc+kN2Q/Fm5Czl3 JKva9D6sHCdbHiVK97x/oGnlZAtv2iF+sKYKqMAL9GXi3BNv5SfT6NbBiX5JuqAODSZpXbKjxq2 fvLVJtknnKQJdQu/kfqw5SEoWEC/IXaVjUkD1AfPRih6NN52uSNyZKeaiD613P7r6QU9aG8AyzA JO0+xRsDjoEWfpCx2rRhnehzaPzGhYyUOZAftexVKHJlPnb+HnrXtAg8lIxbozYDXkvVAabteRF PzJKBaQGdsp7nF+2NylGyM4/UfNpu3wV7I/s2eAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg/cUt5lc1lLgp73d9StH8ClVaBFytIQUtw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] What went wrong [was Welcome to the romp! A reminder of what I would like us to decide first...] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 10:33:00 -0000 I have a lot of sympathy for Doug's question. One logical way to approach this project is to look at history and "what went wrong" and try to fix it. But I agree with Brian that "finger-pointing" will not be productive (although it might be therapeutic ;-) and may just burn cycles. Is a better way to approach this simply to work out how we want things to be, and then design a process for that? Of course, not learning from the past can have risks, but perhaps rather than trying to agree on what we can learn, we can each (privately) apply the lessons we think we have learned to help shape the outcomes. That means we need a positive engineering process where we work towards objectives. That leaves our initial problem being to work out what our objectives are. How do we want things to be, not what do we not want to go wrong? Of course, the conversation might now be "why don't we want it to be exactly how it was?" but I suggest that is the easy question to ask because it avoids considering how we want things to be. So the next step is to try to imagine the functioning RFC Series and what the RSE's job should be. A -----Original Message----- From: Rfced-future On Behalf Of Doug Royer Sent: 02 April 2020 03:56 To: rfced-future@iab.org Subject: Re: [Rfced-future] What went wrong [was Welcome to the romp! A reminder of what I would like us to decide first...] > As John Klensin said, an important symptom was people thinking that the RSE was an ordinary contractor with key performance indicators to be measured. Another symptom was that the oversight committee (like the IAOC) was apparently getting far too involved in details. Were there other symptoms? > > Looking at the symptoms, we might be able to discern the structural problems that caused them. I am writing this while reading the incoming messages on this list. I am learning a lot. This might be and old rehash for many of you. This may be long an boring for some. I want to help and I need to understand. I am trying to see the problem and possible fixes in my head. So, thoughts, suggestions ... >> Was it a too many bosses issue? > > Not exactly, IMHO: but the way the RSOC was set up seems to have led to many cooks trying to stir the same pot. (1) To the too many cooks comment: Those problem look like an employer problem and too many bosses all of which think they are the only or most important boss. I have worked in jobs where I had a company boss (say IAOC) and a project boss (say RSE lead). In those situation the company boss gave me the raises, and the project boss evaluated my performance for my raises and gave me my assignments. I sometimes had several projects in on year. That seems to me to be the existing RSE mode - two or more bosses. Whenever my company-boss gave me conflicting assignments than my project boss, we had a meeting and the problem was resolved. If the conflict continued, then I would step out of the meeting and let them slug it out. I did not care which direction things went. I would just work on another lower priority task until resolved. It always got resolved. I do remember reading a mailing list comment that made me think it was attempting to change the priority or process for some documents. If so, then a document showing the processing flow and how exceptions work. That would include the process used to resolve those exceptions before bothering the editors that do the work. Were they getting direction from more than one IAOC individual at a time? If so, would only one agreed on individual at a time in the IAOC be the point person for the RSE maybe solve the problem? And perhaps that IAOC individual needs approval from the IAOC committee and the RSE manager before asserting an exception to editors. In that context the RSE manager would be effectively on the IAOC for that process role. Are there a lot of exceptions? If so, maybe one (or few) assigned to deal with the exceptions. And everyone else does the normal flow. Does the existing RSE team have a manager? If so, then everyone else takes direction from that manager or team leader. And maybe rotate the lead in the RSE office if that works. At Sun we had a project motto "no foreign orders". That means that each individual only took direction from one person. Whenever possible when asked to change direction, they would be referred to that lead. And have only one lead at a time. So when an editor is working on draft-awesome, they would work only on that document, until redirected by their lead. If your not a lead, you don't interact with the IAOC (or whoever else). Document out of band communications, perhaps: Editors communicate only for clarification and not process issues to the IAOC members or draft authors. Otherwise, it goes through the lead. In summary, if possible, isolate the workers from the exception flow and priority conflicts. (2) What do they spend their time doing that may cause too many process flow problems: I have always been confused about the internal workings of the editors office. xml2rfc should have reduced the load by minimizing the content formatting. Is there a written list of the tasks an editor does? There has to be checklist, even if it is a checklist of RFC's to conform to at any point in time. I remember for a while (maybe still) the editors took the output from xml2rfc and edit that, effectively throwing away the XML original. If so, why? Does xml2rfc only do part of the formatting work? Bugs? Are the editors unfamiliar with (or unwilling to learn) editing XML documents to fix the original? I can see changes to text using that process taking a lot more time than would be expected and it would lead to frustration when yet another from above change happens. What percent of the editors time is spent actually editing documents? What percent is tracking things down, or what? I would think it would be more efficient to have editors and one manager or lead. Do some edit only? Do some research for accuracy and not others? Does everyone do everything for the draft they are working on? In my minimal experience with the editors. In person they were great. With email - I felt like I was bothering them and I often got answers that confused me more. In one case I was told 'not to bother them again', when I thought I was answering their question. I guessed they were overworked. I still felt bad for bothering them. How many are in the RSE office / team when all positions are filled? Would volunteer pre-screeners solve some of the problems? What percent of the issues that need to be resolved are process flow vs xml2rfc vs content of the document or drawn images or ABNF or text emphasis is? I am sure they have a gripe list of repeat problems even if not written down :-) And what does "ACCOUNTABLE" mean to the RSE? Does anyone have a flowchart perhaps drawn by dia that shows the flow and "accountable to who" links? Do people think that only micro changes are needed? Is the general thinking that too much of the flow is undocumented and this is causing problems? Is everyone always in all loops - causing anxiety when hearing about things that may never happen? If so, have a manager that deals with the process and editors that are awesome with grammar and readability (unlike me). -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 -- Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future From nobody Thu Apr 2 08:52:20 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAB73A1619 for ; Thu, 2 Apr 2020 08:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXKaKhSbZ8ua for ; Thu, 2 Apr 2020 08:52:17 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E1A3A1618 for ; Thu, 2 Apr 2020 08:52:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2AA6B300B5A for ; Thu, 2 Apr 2020 11:52:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IiPBJT76nnXS for ; Thu, 2 Apr 2020 11:52:13 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 889B9300A93; Thu, 2 Apr 2020 11:52:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <75FEFDC1BB902A9091739F47@PSB> Date: Thu, 2 Apr 2020 11:52:14 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> To: John C Klensin , Christian Huitema X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 15:52:19 -0000 > On Apr 1, 2020, at 11:51 PM, John C Klensin wrote: >=20 > (I've changed the subject line because I really hope we can > split this off and either set it aside until other work is > finished or find another way to handle it as an issue.) >=20 > --On Wednesday, April 1, 2020 19:30 -0700 Christian Huitema > wrote: >=20 >> I did not write that we should remove copy editing. But we >> could certainly find models in which it happens before >> approval, not after it. The IESG approval process almost always leads to changes based in = DISCUSS or COMMENT. Sometimes these are technical changes. We should = not do copy edits until the technical document is stable. That is = exactly where the copy editing is in the current process. We did a few process experiments where the RFC Editor was invited to do = copy edits earlier in the process. Theses experiments did not reduce = the review, approval, or final copy editing times significantly. My = conclusion is that the copy editing is in the right place in the = process. The use of the diff files has made the copy edit review MUCH easier that = it used to be. I'd be very happy to explore what other tools could make = it even easier. Russ From nobody Thu Apr 2 09:12:47 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954353A1179 for ; Thu, 2 Apr 2020 09:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNZXNtNNUmsg for ; Thu, 2 Apr 2020 09:12:44 -0700 (PDT) Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7BE3A1176 for ; Thu, 2 Apr 2020 09:12:43 -0700 (PDT) Received: by mail-qv1-xf41.google.com with SMTP id v38so1937476qvf.6 for ; Thu, 02 Apr 2020 09:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lQUisIOhxcqU2yaBZGsiVE6aaYFjJ9zy1pRuN6CPUFM=; b=JKq36c0lwxEs68xcxDM+vVfrlK9Tl6Zg5aLsjEav1KjETYyTOTFjrp/gPKN090UVUu 86kqeAl2sNbD2+t1MXOhziISvpCF/LYLphvY31csO09SDa/R8S5pTrmzPzHyFecpT8XC 1lzIAdPIyIkSvwToaWJdv6W3+CG1Avy982QUCwn9UsHWjH5rZeiPUuKo0qaEnP1fCd1S mdXIuHHMMEUM8u/fkLimK3CEbxBf/7cXqe8Sgu/HZ0DCQjjtQ5Ol7xPyLclxhfmgGri0 zlte0klvuuD9IzN1WnEpzcMkc3JJ+PiavMRc6/sPZ+YfQJT88rbxjNLJf1cgCF85bNwz 5WFw== 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=lQUisIOhxcqU2yaBZGsiVE6aaYFjJ9zy1pRuN6CPUFM=; b=S7oBmTtzl7QRzLTiuAllaYxronSKpFc3RzFG4U5vHrifBzIe5iawN7pYsKOr9pKXp7 ROe5EVeVm+M+PykFVSDYRCVBJt51cCDUVr5b9rbTWIpJJ1N7jXN3sEDzS1o3m1VxPOb7 ktSlF6fT602WKgxDonaBuw9U3fSpjkOaP74iBKDoL9IZyMGbtqxRcxHTiho7EIxTp5j9 nzr3+siLeo8fLVcksoaYrnDQoOMobcbmj805duZzo4fCmTKMuw52AesuLUstE0yzHl1M BEWOHT1hFUVWXyMYRYRjQDf/0NKFDTGrXmab3YLCpFyFfwK+l7Y6OeIcPdfvWw2oGgYj iKLA== X-Gm-Message-State: AGi0PubFdrbxInUeFra4i+eqn/i4e+h1yUbYr2s74fjWV+Wp+JuLtl2o GYqeiR6lhPOBTmbOB8Hm5W944gSZaIM= X-Google-Smtp-Source: APiQypIf+IiwSChDW6ePsZj6D7HEbG9r0kDzR+Wu/dAogEe4v0kdiQruN5+86DZxkuvkDMrE9rHMHA== X-Received: by 2002:ad4:54d4:: with SMTP id j20mr3918545qvx.75.1585843962665; Thu, 02 Apr 2020 09:12:42 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id p38sm4119258qtf.50.2020.04.02.09.12.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 09:12:41 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D2439C50-295F-4359-A918-9B207F25D78B" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) Date: Thu, 2 Apr 2020 12:12:38 -0400 In-Reply-To: Cc: John C Klensin , Christian Huitema , rfced-future@iab.org To: Russ Housley References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 16:12:46 -0000 --Apple-Mail=_D2439C50-295F-4359-A918-9B207F25D78B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 2, 2020, at 11:52 AM, Russ Housley wrote: > The IESG approval process almost always leads to changes based in = DISCUSS or COMMENT. Sometimes these are technical changes. We should = not do copy edits until the technical document is stable. That is = exactly where the copy editing is in the current process. One thing to bear in mind is that it is not uncommon to discover a = technical issue in AUTH48, just as we do with errata. I don=E2=80=99t = think the right thing to do is to say =E2=80=9Cdon=E2=80=99t fix it, = since it=E2=80=99s AUTH48.=E2=80=9D I also don=E2=80=99t think the = right thing to do is to say =E2=80=9Cjust fix it and don=E2=80=99t check = with the WG.=E2=80=9D However, in at least one case, we had some = serious problems that were caught in AUTH48 after the WG had disbanded. = We fixed these, and I think did an IETF last call, although this was ten = years ago and my recollection is imperfect. I say this not to propose a solution, but simply to point out that this = is a nasty problem. I don=E2=80=99t think there=E2=80=99s an easy = solution, but I=E2=80=99m sure that we could define a formal process if = there were energy to do this. I agree with other commenters who say = that this is out of scope for the current effort, since this is really = an IETF-track problem, not an all-track problem. --Apple-Mail=_D2439C50-295F-4359-A918-9B207F25D78B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 2, 2020, at 11:52 AM, Russ Housley <housley@vigilsec.com> wrote:
The IESG approval process almost always leads to changes = based in DISCUSS or COMMENT.  Sometimes these are technical = changes.  We should not do copy edits until the technical document = is stable.  That is exactly where the copy editing is in the = current process.

One thing to bear in mind is that it is not = uncommon to discover a technical issue in AUTH48, just as we do with = errata.  I don=E2=80=99t think the right thing to do is to say = =E2=80=9Cdon=E2=80=99t fix it, since it=E2=80=99s AUTH48.=E2=80=9D =  I also don=E2=80=99t think the right thing to do is to say =E2=80=9C= just fix it and don=E2=80=99t check with the WG.=E2=80=9D  However, = in at least one case, we had some serious problems that were caught in = AUTH48 after the WG had disbanded.  We fixed these, and I think did = an IETF last call, although this was ten years ago and my recollection = is imperfect.

I = say this not to propose a solution, but simply to point out that this is = a nasty problem.  I don=E2=80=99t think there=E2=80=99s an easy = solution, but I=E2=80=99m sure that we could define a formal process if = there were energy to do this.  I agree with other commenters who = say that this is out of scope for the current effort, since this is = really an IETF-track problem, not an all-track problem.

= --Apple-Mail=_D2439C50-295F-4359-A918-9B207F25D78B-- From nobody Thu Apr 2 09:51:58 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA953A089C for ; Thu, 2 Apr 2020 09:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXiCU5IFFe9I for ; Thu, 2 Apr 2020 09:51:53 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076313A087D for ; Thu, 2 Apr 2020 09:51:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 86719300B53 for ; Thu, 2 Apr 2020 12:51:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id O3JWZnDKYMls for ; Thu, 2 Apr 2020 12:51:48 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id CE789300A51; Thu, 2 Apr 2020 12:51:47 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ADAB80EE-B455-46A5-AF64-404EF30A5554" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 2 Apr 2020 12:51:49 -0400 In-Reply-To: Cc: John C Klensin , Christian Huitema , rfced-future@iab.org To: Ted Lemon References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 16:51:56 -0000 --Apple-Mail=_ADAB80EE-B455-46A5-AF64-404EF30A5554 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 2, 2020, at 12:12 PM, Ted Lemon wrote: >=20 > On Apr 2, 2020, at 11:52 AM, Russ Housley > wrote: >> The IESG approval process almost always leads to changes based in = DISCUSS or COMMENT. Sometimes these are technical changes. We should = not do copy edits until the technical document is stable. That is = exactly where the copy editing is in the current process. >=20 > One thing to bear in mind is that it is not uncommon to discover a = technical issue in AUTH48, just as we do with errata. I don=E2=80=99t = think the right thing to do is to say =E2=80=9Cdon=E2=80=99t fix it, = since it=E2=80=99s AUTH48.=E2=80=9D I also don=E2=80=99t think the = right thing to do is to say =E2=80=9Cjust fix it and don=E2=80=99t check = with the WG.=E2=80=9D However, in at least one case, we had some = serious problems that were caught in AUTH48 after the WG had disbanded. = We fixed these, and I think did an IETF last call, although this was ten = years ago and my recollection is imperfect. >=20 > I say this not to propose a solution, but simply to point out that = this is a nasty problem. I don=E2=80=99t think there=E2=80=99s an easy = solution, but I=E2=80=99m sure that we could define a formal process if = there were energy to do this. I agree with other commenters who say = that this is out of scope for the current effort, since this is really = an IETF-track problem, not an all-track problem. This is very rare, but it does happen. When it does, the AD needs to = decide if the fix is obvious or if the fix need to go back to a WG or = IETF Last Call. Russ --Apple-Mail=_ADAB80EE-B455-46A5-AF64-404EF30A5554 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 2, 2020, at 12:12 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Apr 2, 2020, at = 11:52 AM, Russ Housley <housley@vigilsec.com> wrote:
The IESG approval process almost always leads to changes = based in DISCUSS or COMMENT.  Sometimes these are technical = changes.  We should not do copy edits until the technical document = is stable.  That is exactly where the copy editing is in the = current process.

One thing to bear in mind is that it is not = uncommon to discover a technical issue in AUTH48, just as we do with = errata.  I don=E2=80=99t think the right thing to do is to say = =E2=80=9Cdon=E2=80=99t fix it, since it=E2=80=99s AUTH48.=E2=80=9D =  I also don=E2=80=99t think the right thing to do is to say =E2=80=9C= just fix it and don=E2=80=99t check with the WG.=E2=80=9D  However, = in at least one case, we had some serious problems that were caught in = AUTH48 after the WG had disbanded.  We fixed these, and I think did = an IETF last call, although this was ten years ago and my recollection = is imperfect.

I = say this not to propose a solution, but simply to point out that this is = a nasty problem.  I don=E2=80=99t think there=E2=80=99s an easy = solution, but I=E2=80=99m sure that we could define a formal process if = there were energy to do this.  I agree with other commenters who = say that this is out of scope for the current effort, since this is = really an IETF-track problem, not an all-track = problem.

This is = very rare, but it does happen.  When it does, the AD needs to = decide if the fix is obvious or if the fix need to go back to a WG or = IETF Last Call.

Russ

= --Apple-Mail=_ADAB80EE-B455-46A5-AF64-404EF30A5554-- From nobody Thu Apr 2 09:55:45 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244FF3A0C22 for ; Thu, 2 Apr 2020 09:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MMIcGEDCaZA for ; Thu, 2 Apr 2020 09:55:33 -0700 (PDT) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3CF3A0966 for ; Thu, 2 Apr 2020 09:55:24 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id u4so4658697qkj.13 for ; Thu, 02 Apr 2020 09:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Gi1BNn7gGa+w6RTmIE73Nz+oxqV8P4/cj74t/auO0VQ=; b=wc/KcvDU+AIw0vPZcb9AKQxX3zfIfdzfbU21pLScOGL4bKZgVVF0nM0zKPmoxxvsKO HKI5FPFrROHm8hct+x8f8GO882rDgGazqEw9S2HTgeSEhnvuv6swbGngT/CvyABVGXsA zCpnz3brwg0AT9h4iCxFmsT04vAI7/+0RP5jSrDdwWZPcc/BoASnUCVEbmW1EAEWIcgo 6CKwjwf0uM1uSz2S7T6EMBfevT3PpScKwt9J206JEV4d1o/9suLSpQSocB9SajKSBpTr 5mpf8o/yxF/VLWoh1eGTi+so4YbpIN5iNjNwBefdWwPAWX3A9sg3EBCKdXXwrrCe87lW Ghaw== 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=Gi1BNn7gGa+w6RTmIE73Nz+oxqV8P4/cj74t/auO0VQ=; b=OlTurVPj0/i1JoFyMN7g4E1rahqTcvrbvcWjluK1e+kIAsH/j2OoKTgLkEwKs+sPQM lShHJyWsLzLuo3o9srzv/VtfQ86Nez0zQNmLlRJlFCLkqdSCt3rTedcrB4f0SuK4tnWa eYSKCCe6ZLOFIO9x33I/Lyc6kSQtjrYT2Ew1CPAcLZTjYavLntfwbDElXED+k0vyS5c0 wbLDShvQQpqJILWVA9QjGNAqNg9yVLeIGXT95v++yqLkqIe3kBflr+tDzpHGGpXqx3Dc 3YHWh5GNyepSMD0H2K/cZOLpxq5IUhAjygyXm6Rk2fYZvyPiaqyI5XIMpB83ys+MZGzn j4qw== X-Gm-Message-State: AGi0Pubab7YVHsEyLKHmxGQGEM//uSvLFXxyGJRVeNnihFWnICDR+/2F W7GmfnSyFnf9pdhiuoGQSjL14g== X-Google-Smtp-Source: APiQypL6rTbOnGuSZ9sH+oMDS189MJjwZzhRmJEKceL6OeKyheJVaRbUbRxVM26RkV2iPw80jAkb6w== X-Received: by 2002:a37:a151:: with SMTP id k78mr4548055qke.62.1585846523440; Thu, 02 Apr 2020 09:55:23 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id f7sm1074834qtq.33.2020.04.02.09.55.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 09:55:22 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3C96EF9D-BD33-4262-B94D-DE4CAA202D14" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) Date: Thu, 2 Apr 2020 12:55:21 -0400 In-Reply-To: Cc: John C Klensin , Christian Huitema , rfced-future@iab.org To: Russ Housley References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 16:55:43 -0000 --Apple-Mail=_3C96EF9D-BD33-4262-B94D-DE4CAA202D14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 2, 2020, at 12:51 PM, Russ Housley wrote: > This is very rare, but it does happen. When it does, the AD needs to = decide if the fix is obvious or if the fix need to go back to a WG or = IETF Last Call. I agree. Just saying, there could be a more detailed policy written if = someone wants it, and there is no way to make this problem go away that = doesn=E2=80=99t guarantee worse outcomes. --Apple-Mail=_3C96EF9D-BD33-4262-B94D-DE4CAA202D14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 2, 2020, at 12:51 PM, Russ Housley <housley@vigilsec.com> wrote:
This is very rare, but it does = happen.  When it does, the AD needs to decide if the fix is obvious = or if the fix need to go back to a WG or IETF Last = Call.

I agree. =  Just saying, there could be a more detailed policy written if = someone wants it, and there is no way to make this problem go away that = doesn=E2=80=99t guarantee worse outcomes.


= --Apple-Mail=_3C96EF9D-BD33-4262-B94D-DE4CAA202D14-- From nobody Thu Apr 2 10:12:29 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B3C3A093B for ; Thu, 2 Apr 2020 10:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgQUPxy0nAxk for ; Thu, 2 Apr 2020 10:12:24 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075023A0932 for ; Thu, 2 Apr 2020 10:12:24 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48tV4623R1zyS1; Thu, 2 Apr 2020 19:12:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Thu, 2 Apr 2020 19:12:21 +0200 Cc: Russ Housley , John C Klensin , rfced-future@iab.org, Christian Huitema X-Mao-Original-Outgoing-Id: 607540341.679796-0f53ea189a36afeb6f263f2875cdd567 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> To: Ted Lemon X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 17:12:27 -0000 On 2020-04-02, at 18:55, Ted Lemon wrote: >=20 > On Apr 2, 2020, at 12:51 PM, Russ Housley = wrote: >> This is very rare, but it does happen. When it does, the AD needs to = decide if the fix is obvious or if the fix need to go back to a WG or = IETF Last Call. >=20 > I agree. Just saying, there could be a more detailed policy written = if someone wants it, and there is no way to make this problem go away = that doesn=E2=80=99t guarantee worse outcomes. Right. WG members that pay attention can already observe the = progression of the /authors/ drafts, but it would be nice if the WG was = involved more early if changes that are not purely editorial (whatever = that means) are being made. Usually, the WG can just watch and silently = agree, so there wouldn=E2=80=99t be additional overhead. But let me agree here that we are doing this in the right order. It is = fundamentally impossible to avoid minor reiterations at the last process = step, and my experience has been that this has mostly been handled well, = with a few surprises that happened anyway. (There is also the RFC 7386/RFC 7396 thing that happened, and might not = have if more people were invited to pay attention during AUTH48. But = then RFC 7158/7159 demonstrated that accidents can happen even in the = post-AUTH48 processing steps.) Gr=C3=BC=C3=9Fe, Carsten PS.: And while I was writing this, in a WG Jabber: =E2=80=A6"Please let me know when it goes to Auth48 so I can re-check = the examples.=E2=80=9D=E2=80=A6 Another reason to involve the WG in AUTH48. From nobody Thu Apr 2 10:16:36 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB443A095C for ; Thu, 2 Apr 2020 10:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFdB1PmUoisG for ; Thu, 2 Apr 2020 10:16:28 -0700 (PDT) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B143A0955 for ; Thu, 2 Apr 2020 10:16:24 -0700 (PDT) Received: by mail-qv1-xf2e.google.com with SMTP id g4so2050031qvo.12 for ; Thu, 02 Apr 2020 10:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:reply-to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=u79hislCTfK/WVpK3tQUNzjauYMZ/G2ADtXC0GQtvyk=; b=CU2quVOasYWH6VBtZe7CU+jTPKwQXRN98bcJz/PQBAsNUuQ/DKmyWK7ne7SyUunKCB 3/jOMqQHO5qf7FzXlqdn67pex6q4+7RIs7vBxpRHV/ZaUNAd5C3or8781PUwEftSYkph 6hbxfF6fFOytaxtqYpJgIfZdGvmUt1A0MX+BIdM9BzfA8m34yj3+dWS6FxxVPkk9y3R8 KvTT0BlFPoDnn2vvfOHbIMf2rbuo/2w+AhMxxJOzmRIIcvzNo8G4aP06p7W694VKdcf5 WWrpuby7QBvXII1wdIXvqhL1zlcIxPcWdn+PamDtJloIPjqI0g6GnOxNw+9XL+zqxHHT JZyw== 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:reply-to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=u79hislCTfK/WVpK3tQUNzjauYMZ/G2ADtXC0GQtvyk=; b=W4eqXKMd6chnUBSCfNxjCAja9fAs2KS/nA5CyN5MfykG2g1TfI42xfhY+ZfbkxIn0q nkgcsv9xyRJEkxDyZMlmr5uRVf242Kz/iupPYX9IaE06gy4etuDdQBcjmyaH23rHxYWw m32CHQuOGg6FswX0j2tZKC3NYfBIBQUgmXcQWlXyyrkdTShWGU7kJ5o5SZtT4cfICzLv V630VVU5ltK4R/veC4L0+TCLWOf8BQ6qWoUNPIXnJRxTbSn3H+JsbQ1R+IM9EoIvWfGi 7/FHmeNMzWIs0xCdptUGKQWzJU9qfFrDjvhbP8vXyMltY9xUww+1yUNIEm1lgTnzEZ9l 9UNA== X-Gm-Message-State: AGi0PuYZrRuKsMV8UtPIDwPM9iS6gs7C7ys4NGjM8Fqb64ZNKPgAcVsz zqMvAnX0VjHq6+r7Pr8HWYofk/VtpDA= X-Google-Smtp-Source: APiQypJMnFk+OogcmULq4S5aFKNwzCqAAjeSZJZMx4OSRnCdqgx7KBxEeJn3vOV3a9SVqohUQGX2DA== X-Received: by 2002:a05:6214:60d:: with SMTP id z13mr4305915qvw.183.1585847783354; Thu, 02 Apr 2020 10:16:23 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id f68sm4004017qtb.19.2020.04.02.10.16.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2020 10:16:22 -0700 (PDT) To: rfced-future@iab.org References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> Reply-To: RFC Interest From: Michael StJohns Message-ID: <2021749f-5bfe-58be-8044-547b644c9019@nthpermutation.com> Date: Thu, 2 Apr 2020 13:16:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 17:16:35 -0000 Trying again to move this to the appropriate list.  Mike On 4/2/2020 1:12 PM, Carsten Bormann wrote: > On 2020-04-02, at 18:55, Ted Lemon wrote: >> On Apr 2, 2020, at 12:51 PM, Russ Housley wrote: >>> This is very rare, but it does happen. When it does, the AD needs to decide if the fix is obvious or if the fix need to go back to a WG or IETF Last Call. >> I agree. Just saying, there could be a more detailed policy written if someone wants it, and there is no way to make this problem go away that doesn’t guarantee worse outcomes. > Right. WG members that pay attention can already observe the progression of the /authors/ drafts, but it would be nice if the WG was involved more early if changes that are not purely editorial (whatever that means) are being made. Usually, the WG can just watch and silently agree, so there wouldn’t be additional overhead. > > But let me agree here that we are doing this in the right order. It is fundamentally impossible to avoid minor reiterations at the last process step, and my experience has been that this has mostly been handled well, with a few surprises that happened anyway. > (There is also the RFC 7386/RFC 7396 thing that happened, and might not have if more people were invited to pay attention during AUTH48. But then RFC 7158/7159 demonstrated that accidents can happen even in the post-AUTH48 processing steps.) > > Grüße, Carsten > > PS.: And while I was writing this, in a WG Jabber: > …"Please let me know when it goes to Auth48 so I can re-check the examples.”… > Another reason to involve the WG in AUTH48. > From nobody Thu Apr 2 10:26:34 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A753A0D2D for ; Thu, 2 Apr 2020 10:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejtDzS2LWhZZ for ; Thu, 2 Apr 2020 10:26:25 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8ED3A0BFB for ; Thu, 2 Apr 2020 10:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1162; q=dns/txt; s=iport; t=1585848366; x=1587057966; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=zp9GwORJIHVqiVDUqaGWGacpJdNIj35z7j6xf+mxFbI=; b=g6bO/BWRi+fF8tAyFvrm1aoFOIoqnA1MMjd+OXropFz+m0ivviT7Q8eD 41abLC0m/ghyy46JgTRQwItoghYUe2+9YdJbxL4sXg3kiqG5mWmcIxbpT 8n5pxio2UZFVzHB+RvxhNqqlphBuC+Ch3KdXix7JpqXuDxfTl5Gpo/J5D o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAQD/H4Ze/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4NpASASjUaHaJNiiAoKAQEBDAEBLwQBAYREAoJlOBM?= =?us-ascii?q?CAwEBCwEBBQEBAQIBBQRthWKFZwoGeRALAwEKLQtXBoM5gn2vHIInhUuFKIE?= =?us-ascii?q?4jEuCAIE4DBSCHy4+iBKCLASHA5EVmGqCR4JdlD4dm3KoCYM2AgQGBQIVgWk?= =?us-ascii?q?igVczGggbFWUBgj89EhgNjlWOEj8Dj3cBAQ?= X-IronPort-AV: E=Sophos; i="5.72,336,1580774400"; d="scan'208,217"; a="24939899" 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; 02 Apr 2020 17:25:59 +0000 Received: from ams3-vpn-dhcp3624.cisco.com (ams3-vpn-dhcp3624.cisco.com [10.61.78.40]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 032HPwrZ010359 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2020 17:25:59 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ED812DAE-2190-41E5-AD44-DED2B0BF0CD5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 2 Apr 2020 19:25:58 +0200 In-Reply-To: Cc: Ted Lemon , John C Klensin , rfced-future@iab.org, Christian Huitema , Russ Housley To: Carsten Bormann References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.78.40, ams3-vpn-dhcp3624.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 17:26:33 -0000 --Apple-Mail=_ED812DAE-2190-41E5-AD44-DED2B0BF0CD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All: Can we distill the high level point that needs addressing in this = process? Are the touch points and flow the responsibility of the RFC Editor to = define, or should that be this group? Eliot --Apple-Mail=_ED812DAE-2190-41E5-AD44-DED2B0BF0CD5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii All:

Can we distill the high level point that needs addressing in this process?

Are the touch points and flow the responsibility of the RFC Editor to define, or should that be this group?

Eliot

--Apple-Mail=_ED812DAE-2190-41E5-AD44-DED2B0BF0CD5-- From nobody Thu Apr 2 10:39:26 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D215B3A0C14 for ; Thu, 2 Apr 2020 10:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlJVFFWn1btd for ; Thu, 2 Apr 2020 10:39:23 -0700 (PDT) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1F03A0C13 for ; Thu, 2 Apr 2020 10:39:23 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id l25so4913496qki.7 for ; Thu, 02 Apr 2020 10:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7MvABQrN0xgQmfncvJIcIu4PfyNgbPveux3O4Ha2YBU=; b=rhZv3drVVIXa+HwKnfW7afKX0hiaEXry69LNe8kIOJmS3w7vdo1mb3nAkiMEMn69YU IXePTllOCRVKT3UFwcRdcOjYS9sUKo+TiYng18eF8SYdnwR7aR8nb6psl+qrNOVavl8C paAiy0WZse0NbXuRYE/OyIsBVi1osjbpqVsyZ8lOjcHTsqvzypbXM7IICc+3rBbKMpfG IwLMPPCTMDx6NUOJ8g+tjxN5ylaHD1XagjrHJcbtm0Naok93AVyR2A//MdDOlw+4up6q G1+lFhlNLGJAHUtWgBFDfyuQIbrt1D0/qhdMKtUzGaz4dMg2vpeYCYn0ZPTWkyL7sLnr bslw== 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=7MvABQrN0xgQmfncvJIcIu4PfyNgbPveux3O4Ha2YBU=; b=Avodx33rfNX3GAho3SZhc9LK+r+TAgUsYYjlLR6Evi+EVBWHS0CcNkq6OLY52gyxvO s2/FnUaU1jYc/oktQnTJrN3QVjRUzIpCK3HU93tQ4BVDP5jcEhmiqnczdGkzmbloLUkj NQGMpqaS5F9cLM7qCH0QBq4EpRDnmdGAdWMqwTNXh9mSovQJVgw+xGBEUhhKDum4zirq dRX1zFA1tEU7xb3L+MlinxKUuGuT+MeZfwFpaDGBR/eFbEVvRUMibO5wRpO+0GN3NuvC n7l8D+EqJ8DOe3+MLcG2awsqeq4yg4oVDc8++lY8rImn1WSFYOC/hluGC8y1LYDg4tJQ GUsw== X-Gm-Message-State: AGi0PuZFAY+pmj077SKhVeqDHITZfiV6ylATDwWfAtuj94j59Ocx9GvK BIRCuWo9CvKJ1aSgNzFEJ260CQ== X-Google-Smtp-Source: APiQypL3jh3v3ldlFYiHZTasVIRFkYwLxQ+tWKecr4spu9xk6h2df4lkof6sTwgXnQY75b6jKbalZg== X-Received: by 2002:ae9:e210:: with SMTP id c16mr96241qkc.179.1585849162462; Thu, 02 Apr 2020 10:39:22 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id v75sm4092158qkb.22.2020.04.02.10.39.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 10:39:21 -0700 (PDT) From: Ted Lemon Message-Id: <10C6D11D-69C8-4913-A48A-CF5EEBCDE590@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BD6CAA88-0652-4CFD-9CF8-62CDAF1F0CBC" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) Date: Thu, 2 Apr 2020 13:39:20 -0400 In-Reply-To: Cc: Carsten Bormann , John C Klensin , rfced-future@iab.org, Christian Huitema , Russ Housley To: Eliot Lear References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 17:39:25 -0000 --Apple-Mail=_BD6CAA88-0652-4CFD-9CF8-62CDAF1F0CBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 2, 2020, at 1:25 PM, Eliot Lear wrote: > Are the touch points and flow the responsibility of the RFC Editor to = define, or should that be this group? My conclusion from this discussion is that the AUTH48 question is out of = scope for this group. --Apple-Mail=_BD6CAA88-0652-4CFD-9CF8-62CDAF1F0CBC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On Apr 2, 2020, at 1:25 PM, Eliot Lear <lear@cisco.com> wrote:
Are the touch points and flow the responsibility of the RFC Editor to define, or should that be this group?

My conclusion from this discussion is that the AUTH48 question is out of scope for this group.

--Apple-Mail=_BD6CAA88-0652-4CFD-9CF8-62CDAF1F0CBC-- From nobody Thu Apr 2 12:32:03 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFD13A1014 for ; Thu, 2 Apr 2020 12:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bP795qBw5UJq for ; Thu, 2 Apr 2020 12:31:59 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6183A1023 for ; Thu, 2 Apr 2020 12:31:59 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jK5ZE-00068n-FD; Thu, 02 Apr 2020 15:31:56 -0400 Date: Thu, 02 Apr 2020 15:31:50 -0400 From: John C Klensin To: Russ Housley , Christian Huitema cc: rfced-future@iab.org Message-ID: In-Reply-To: References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 19:32:02 -0000 --On Thursday, April 2, 2020 11:52 -0400 Russ Housley wrote: >> On Apr 1, 2020, at 11:51 PM, John C Klensin >> wrote: >> >> (I've changed the subject line because I really hope we can >> split this off and either set it aside until other work is >> finished or find another way to handle it as an issue.) >> >> --On Wednesday, April 1, 2020 19:30 -0700 Christian Huitema >> wrote: >> >>> I did not write that we should remove copy editing. But we >>> could certainly find models in which it happens before >>> approval, not after it. > > The IESG approval process almost always leads to changes based > in DISCUSS or COMMENT. Sometimes these are technical changes. > We should not do copy edits until the technical document is > stable. That is exactly where the copy editing is in the > current process. > > We did a few process experiments where the RFC Editor was > invited to do copy edits earlier in the process. Theses > experiments did not reduce the review, approval, or final copy > editing times significantly. My conclusion is that the copy > editing is in the right place in the process. > > The use of the diff files has made the copy edit review MUCH > easier that it used to be. I'd be very happy to explore what > other tools could make it even easier. Russ, I was just trying to explain that the alternative Christian seemed to have been suggesting had been used (and was in use) in other places and how it worked. I was not, and would not, argue for it for the IETF because making it work here would, I believe, require major changes in procedures and maybe even in culture. An observation just in case it turns out to be useful in other contexts. What the Production Center does often goes beyond what most of the publishing industry considers copy editing. It rarely gets far into the range of what is often described as technical editing (or, more accurately, technical rewriting), but it, especially when combined with changes made at the behest of the IESG after Last Call, goes into that territory. The boundary, more or less, is when subject matter expertise, even expertise on the vocabulary and basic concepts of the relevant field and/or fairly extensive familiarity with other works in the same area(s) is required to do the expected editing job. The distinction is important for two reasons. First, if all they did was simple copy editing, we either wouldn't need AUTH48 or AUTH48 would be confined to things like misspellings they had missed. They do much more, they have acquired a great deal of expertise in our documents along the line, their work is important to us, and describing what they do as copy-editing not only fails to recognize that but risks our slipping into the problem of treating the RPC and its staff as just another set of basically interchangeable contractors. Second, my concern (and, if I understood Christian's note, at least part of his) is that we have too many documents that get to the end of community review during Last Call and then change enough via IESG action or RPC efforts to be only barely recognizable as the same document. The changes may be substantive ones that the IESG considers minor or the writing styles or skills in writing technical English of some authors may have required major rewrites of paragraphs or sections by the RPC. I've rarely seen either cause harm, but the fact remains that the community is signing off on one document and then a different document is being published. At least in principle, that is a risk and maybe se should be thinking about it and whether adjustments are in order (with the understanding that reordering the editing and approval processes is not the only option). best, john From nobody Thu Apr 2 12:58:39 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122B63A125D for ; Thu, 2 Apr 2020 12:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GUG0TgltYmq for ; Thu, 2 Apr 2020 12:58:34 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34F23A125F for ; Thu, 2 Apr 2020 12:58:33 -0700 (PDT) Received: (qmail 12710 invoked from network); 2 Apr 2020 19:58:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=31a4.5e8643e7.k2004; bh=pRoi7Z4viyY6KaehGK9QWHPY9H1RfYwqiNctW1drTas=; b=uIrAALXxljs89m4h3/EpKam43fFV6jNLBJ4ZGGL7RnMgeI4rRfMVBikcehrAdR6acffK+jtIqtVLJ/nNa2kVzNkjOENg2jvj64nIQrwp+waHcPoq+OIDJAVFubcLu/UzQZG3ozTxrNH110y3/klbNUkD3vwdoKVwL57Qu3JULSNAXI6Q2gAQFQVsAYWbKVtMb94yC6zNh6dBuEPxojmt4ljz/m15+Mobx7jduKP03APzsK6JPrP/ikRd1OgBgTSc Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 02 Apr 2020 19:58:31 -0000 Received: by ary.qy (Postfix, from userid 501) id 264FC16EE898; Thu, 2 Apr 2020 15:58:30 -0400 (EDT) Date: 2 Apr 2020 15:58:30 -0400 Message-Id: <20200402195831.264FC16EE898@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: lear@cisco.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 19:58:37 -0000 In article you write: >Can we distill the high level point that needs addressing in this process? > >Are the touch points and flow the responsibility of the RFC Editor to define, or should that be this group? It is a fact of life that errors will always turn up at inconvenient points in the process. One time I found a mistake in one of my books while doing the equivalent of AUTH48. I found that the same error was in two previous editions, and none of my coauthor, our quite competent editors, or me had noticed it before. We need to consider the tradeoffs between fixing them and living with them, with the costs of fixing them being delay and perhaps rework, and the possibility that the fix will be wrong, too. R's, John From nobody Thu Apr 2 12:59:51 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7780F3A1262 for ; Thu, 2 Apr 2020 12:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpqOwqLedQ3Q for ; Thu, 2 Apr 2020 12:59:49 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E103A125D for ; Thu, 2 Apr 2020 12:59:49 -0700 (PDT) Received: (qmail 12856 invoked from network); 2 Apr 2020 19:59:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3236.5e864434.k2004; bh=sT012wgNCjf/i1233zlIlUCd18DUTG1RsOOxA97saKg=; b=GwFLztN6jcHDr9tnEuFAk6pYhsRSX3V5NQCYISP+YUVT17a8lkVeNI789HVoSINUQd73h9OgSElLQg9QgscJDEbm9K+rvIpM2dsTCvflAzKvEfk89GRRoAyM9IeHtQmyZF1ljyHWiXQa5XjuhQ25WNItB2wskpRH7R7q6hQVAap0cEs71cMpHGNf/In+eV1KwCl69d5U4Pw1gYjn6gSSY223JQYhFTqT5KKJZsCl3zjDCCCD89aauBoCq4/vgD7v Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 02 Apr 2020 19:59:47 -0000 Received: by ary.qy (Postfix, from userid 501) id D569E16EE8CE; Thu, 2 Apr 2020 15:59:47 -0400 (EDT) Date: 2 Apr 2020 15:59:47 -0400 Message-Id: <20200402195947.D569E16EE8CE@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: LMM@acm.org In-Reply-To: <0ac801d6089c$c36031b0$4a209510$@acm.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 19:59:50 -0000 In article <0ac801d6089c$c36031b0$4a209510$@acm.org> you write: >IMHO, the "real problem" from a publishing workflow point of view is that there is a workflow task that is not explicitly >assigned, namely to validate that the to-be-published RFC, in all its published formats, reflects the intent of the author >and the body that approved it. Trust me, that's not possible. R's, John From nobody Thu Apr 2 13:26:07 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E74B3A172B for ; Thu, 2 Apr 2020 13:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljw3E4YoNcHY for ; Thu, 2 Apr 2020 13:26:04 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E333A172F for ; Thu, 2 Apr 2020 13:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1187; q=dns/txt; s=iport; t=1585859164; x=1587068764; h=from:mime-version:subject:message-id:date:to; bh=bIXC2wNMWZDaTaV4ZB7ZKWTbyMR+AC1qg4sQlfa9yFo=; b=Ox4siuBDn11vUVIQzhffQsZE7wonQObAPPfGvexf2LJX9Bfyy31iAXvR 7GuwFBtVr5exnAJ8WE4bpKzkU6j4E8+tpGPkqWc0j4r2M63zbedMQ4Jbc ydrAr8EcMhdHnNCdC4i5pjK3Yk4Kj6CgW/dFUmaEDjyB6vUFJpOY31I6E 8=; X-IPAS-Result: =?us-ascii?q?A0CJBQAwSYZe/xbLJq1mHgELHIUQVSASKoQbiQGHaJNhh?= =?us-ascii?q?XOCFwoBAQEMAQElCgQBAYcrOBMCAwEBAQMCAwEBAQEFAQEBAgEFBG2FVgyFZ?= =?us-ascii?q?zN0AQI8AoQYAYJ8D6EijhF1gTKFS4UCBoE4jEuCAIE4DBCCIAGDUQKCMoJFM?= =?us-ascii?q?oIsBLEEgkcEglqFDY80HZt4mEyPQYM3AgQGBQIVgWkigVczGggbFWUBgj4+E?= =?us-ascii?q?hgNWJE4ilc/AzCPNAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.72,336,1580774400"; d="scan'208,217"; a="22680471" 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; 02 Apr 2020 20:26:02 +0000 Received: from ams3-vpn-dhcp3624.cisco.com (ams3-vpn-dhcp3624.cisco.com [10.61.78.40]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 032KQ0Kp010391 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Apr 2020 20:26:02 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_F215A32F-7148-4BA7-9D51-F83F47254D57" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Thu, 2 Apr 2020 22:26:00 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.78.40, ams3-vpn-dhcp3624.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Attempting to collect key points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 20:26:06 -0000 --Apple-Mail=_F215A32F-7148-4BA7-9D51-F83F47254D57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If anyone wants to see the notes I=E2=80=99m taking, and those notes may = be entirely too abbreviated or just plain wrong, you can see them here = . I=E2=80=99m a few hours behind at the moment.= --Apple-Mail=_F215A32F-7148-4BA7-9D51-F83F47254D57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = anyone wants to see the notes I=E2=80=99m taking, and those notes may be = entirely too abbreviated or just plain wrong, you can see them here.  I=E2=80=99m a few hours = behind at the moment.= --Apple-Mail=_F215A32F-7148-4BA7-9D51-F83F47254D57-- From nobody Thu Apr 2 14:01:24 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019953A19B5 for ; Thu, 2 Apr 2020 14:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTtoZvnzBKTk for ; Thu, 2 Apr 2020 14:01:21 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8113A19BA for ; Thu, 2 Apr 2020 14:01:20 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id b62so5779316qkf.6 for ; Thu, 02 Apr 2020 14:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1kTUbTY+aimT0XDDc8zER+chS46cXEo0HjWrPHBDMOM=; b=IML0WmqCStj6Hv+dh3/yqPFGCyZGScltunkoS4AeMs/0EQdEl1Qs3t6Pdep6atZFSK zCil6RLyDhYb3hyFXx2PtBODf8up3U2LvNQYqiPu8faCFN1NcZaPgDbFGyf0C9MyV16D xiP7A7T8XDihiUY7RmgZPOKLXg1oiaOMu1O/oJTR8biUUxOygPvguKK0fx5iVuxsKRjn deVKTzfuQgbcU5tu8tEnV4q+RuxZLK+sYNFxOA0p8tJmZ91iw+PSIvVXehRz8sg3/Ns5 qDFD52raMhL+Lo/cUxasGv/gTX9TCnlI+bRZ4HJJHnlnfTZCThHvMbG3yy9+hpICcohp LBSg== 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=1kTUbTY+aimT0XDDc8zER+chS46cXEo0HjWrPHBDMOM=; b=V+brpqQKlSF4G2ksqs83TXcnOZaxqI35uBcC9kSj2cggztCqq3aMETRyD6PrBElMyJ 2nLgJzaPtYwkwQrMYfx5eFOOt0mptr527MjmDUYpgfqhayCug+YqpPSVGZ64yPmhOrod XM6yUZKMdNsbJw3VYo2/4C3WTEsXLD+dcSItEInwevZ/nDDbnylZnhIIwn/kmW9Exrsx WgoQuPoVNCQPqOnA3xZLWN2p/h+HnBCNhqQn6FLS6YSaV1oWDGXVhir5bY/5IfHORAak 14h1ZydjpYf+9pE6GRwphKJwg7Zb40PE4ELzc2qch54u+FEPlFJVzD2bdd+lxepv9vBU +ylg== X-Gm-Message-State: AGi0PuZpYvkD68aV1CNcdELY6Y4ir7753tYTHzJStJ181qV5m297xTGX JXaZIuRpJ2y8OQ3epg5yn/Mc9OfiqHA+W8jWvgc= X-Google-Smtp-Source: APiQypJF4mRyEIN/wl2KUmkDuGngT4sSObq3o64bhArWZjRA1zt0SzHp9JQN6eNSZEgLqUKn+3VsU90yqPNaZ4BeotU= X-Received: by 2002:ae9:efd0:: with SMTP id d199mr5197780qkg.406.1585861279702; Thu, 02 Apr 2020 14:01:19 -0700 (PDT) MIME-Version: 1.0 References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> In-Reply-To: <20200402195947.D569E16EE8CE@ary.qy> From: "Andrew G. Malis" Date: Thu, 2 Apr 2020 17:01:08 -0400 Message-ID: To: John Levine Cc: rfced-future@iab.org, LMM@acm.org Content-Type: multipart/alternative; boundary="0000000000003d637b05a2551a62" Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 21:01:23 -0000 --0000000000003d637b05a2551a62 Content-Type: text/plain; charset="UTF-8" John, I'd like to dig into your reply a bit. We've both been through our share of AUTH48s. When I get the proposed changes and questions back from the RFC Editor, I do my best to make sure that the primary output format (until recently, the text format, and going forward, the HTML format) will be correct from a content point of view and hasn't changed anything technically substantive - changes are strictly editorial or to correct errors like typos. If necessary, I've consulted with the responsible AD to make sure that she or he agrees with the proposed changes. I then trust the RFC Editor that the secondary formats (PDF, etc.) will match the primary from a content viewpoint. But following this process, I'm fairly certain that "the to-be-published RFC, in all its published formats, reflects the intent of the author and the body that approved it." So I'm curious why you feel that's not possible. Cheers, Andy On Thu, Apr 2, 2020 at 3:59 PM John Levine wrote: > In article <0ac801d6089c$c36031b0$4a209510$@acm.org> you write: > >IMHO, the "real problem" from a publishing workflow point of view is > that there is a workflow task that is not explicitly > >assigned, namely to validate that the to-be-published RFC, in all its > published formats, reflects the intent of the author > >and the body that approved it. > > Trust me, that's not possible. > > R's, > John > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000003d637b05a2551a62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John,

I'd like to dig into your rep= ly a bit. We've both been through=C2=A0our share of AUTH48s. When I get= the proposed changes and questions=C2=A0back from the RFC Editor, I do my = best to make sure that the primary output format (until recently, the text = format, and going forward, the HTML format) will be correct from a content = point of view and hasn't changed anything=C2=A0technically substantive = - changes are strictly editorial or to correct=C2=A0errors like typos. If n= ecessary, I've consulted with the responsible AD to make sure that she = or he agrees with the proposed changes. I then trust the RFC Editor that th= e secondary formats (PDF, etc.) will match the primary from a content viewp= oint.=C2=A0 But following this process, I'm fairly certain that "t= he to-be-published RFC, in all its published formats, reflects the intent o= f the author and the body that approved it."=C2=A0 So I'm curious = why you feel that's not possible.

Cheers,
Andy


On Thu, Apr 2, 2020 at 3:59 PM John Levine &= lt;johnl@iecc.com> wrote:
In article <0ac801d60= 89c$c36031b0$4a209510$@acm.org> you write:
>IMHO, the "real problem" from a publishing workflow point of = view=C2=A0 is that there is a workflow task that is not explicitly
>assigned, namely to validate that the to-be-published RFC, in all its p= ublished formats, reflects the intent of the author
>and the body that approved it.

Trust me, that's not possible.

R's,
John

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000003d637b05a2551a62-- From nobody Thu Apr 2 14:09:47 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721A53A19DA for ; Thu, 2 Apr 2020 14:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VWXtWfVHZz2 for ; Thu, 2 Apr 2020 14:09:43 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A253A19D9 for ; Thu, 2 Apr 2020 14:09:42 -0700 (PDT) Received: (qmail 30170 invoked from network); 2 Apr 2020 21:09:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=75d8.5e865494.k2004; i=johnl-iecc.com@submit.iecc.com; bh=XcQwGl/BMafb3BmPCGgZ2MWJRK51o5Ch0UtUDqMUKls=; b=gb00f2YrmD+bIDuO3VexOMwGUED4FAWKD10Bu6k/0Zh2EAgNZ/tjr5hAzf6a/KwoeoAHLt5TvplwkLvCfm0tRFt9PhVqCmy7b7MkGZ0K3/sxJffAhTX0O4wMHpXeNhlBZw/f6WaADoWfQFp7N2dUpSm2UkoCKpTh/Iqxjoc7G61RjdHMXvo5aOBk9LiMP1KlUcg9mWJkmPG9/jGtTMQmPAPE/QUTEFAZ/9lD0kE1XDnFk2X1CWL0hqdiIteW4l2e Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 02 Apr 2020 21:09:39 -0000 Date: 2 Apr 2020 17:09:39 -0400 Message-ID: From: "John R. Levine" To: "Andrew G. Malis" Cc: rfced-future@iab.org, LMM@acm.org In-Reply-To: References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 21:09:45 -0000 > But following this process, I'm fairly certain that "the to-be-published > RFC, in all its published formats, reflects the intent of the author and > the body that approved it." So I'm curious why you feel that's not > possible. Usually it will, but sometimes no matter how careful everyone is, sometimes they'll miss something. I'm certainly not saying that we shouldn't try to make the quality as good as possible, but I am saying that as good as possible is not perfect and our processes have to be able to deal with that reality. Sometimes it slips through all the way to the published RFC, which is why we have errata. We have a lot of them, not infrequently for documents published many years ago. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Apr 2 14:46:34 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18E83A09AF for ; Thu, 2 Apr 2020 14:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 MdDYarrKyh19 for ; Thu, 2 Apr 2020 14:46:30 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05CC3A088F for ; Thu, 2 Apr 2020 14:46:24 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id l14so2483361pgb.1 for ; Thu, 02 Apr 2020 14:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XmTm2KWeYl2T4Fiu2WPCnKwc70r+WbKu1YKLlRN72fg=; b=qHYh5uDiCeGlvdC6jbW2fRWLinIF8lkDryuqo5Q9+JjMqYF1kCBHmjh1U3uFKkUYZu x2qqsthuFR8jVOK81OCHjnUIRHgRC5Sptgkk7MkSnuN9ezpNZ7L+61UbGEY/E2pJICFJ FHLZKBpdZuDPRQBhALx0vey0XUKQdQLsn0iCAQxs/tPf4j91JekUGHuqzotQVeMK1L94 ubr2P88LWzSqABcCw1p00Tbj5jDK8FZ4egFjLqhcP2cjoPM9CsDHeZkYiDFSjyR9Qam/ iygYMW3VX8TdAzOKuHe73gTJ6Zzgcb4P/5WLh0Q6n44ZP0UUDU0LaVcxGa/LxSS0Qp8x MM/A== 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=XmTm2KWeYl2T4Fiu2WPCnKwc70r+WbKu1YKLlRN72fg=; b=FhxcngWr9/Y1OoxihNizADFnNhc3pmUHdl+9KN1uW/UNzQnjlEwbdTmprz5O5DCx3z qcGlnlOpnDqzkfBRi3CNNse+GSqRixoNJaeXKTJG0PMLN/z4fCcqBp0KmNpIvbVLVgdG c1waGBt9cswFa5j1fZHx7Z6o0mF4/pnNKIzFodIftcl3plYSE1s0dPxg6LKCpeXW+C9e ackwof4pKwIMxrPUumtuD2wFwm0+nPHk/C/Wg2ZQ18CcAumjNz8TywXm0zudZ7j/4IyY 4Iprp5O5/Ag6O3CEiLfpNE5ytrYFsOt0emzJ7IFXHEGCCVd6iRLDs263dwARhkLFhRVO v1EA== X-Gm-Message-State: AGi0PuZVntjPgy7fhtpPiKmqTEmWmzmpS8CLGEgCNJRO/VGT1RcmDejb 3qW/2md39uuABjCvZeOA9gEUVJJG X-Google-Smtp-Source: APiQypJ/gQrWeK7rCFvzNdOotq3PJt2xYflQOjH476Mqb94cslSKX5Vm8mmx8lQ+QiUkeD0dzfpzBw== X-Received: by 2002:a63:fd4f:: with SMTP id m15mr5243651pgj.323.1585863984139; Thu, 02 Apr 2020 14:46:24 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id u18sm4409945pfl.40.2020.04.02.14.46.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 14:46:23 -0700 (PDT) To: Eliot Lear , Carsten Bormann Cc: John C Klensin , rfced-future@iab.org, Christian Huitema , Russ Housley , Ted Lemon References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> From: Brian E Carpenter Message-ID: Date: Fri, 3 Apr 2020 10:46:18 +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: [Rfced-future] Up level [Re: AUTH48 and editing before approval] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 Apr 2020 21:46:32 -0000 On 03-Apr-20 06:25, Eliot Lear wrote: > All: >=20 > Can we distill the high level point that needs addressing in *this*=C2=A0= process? >=20 > Are the touch points and flow the responsibility of the RFC Editor to d= efine, or should that be this group? Definitely the former. If we talk about such things here, we are already = micro-managing at least as badly as the RSOC seems to have done. Actually= , I'm simply deleting the thread at this point, so it's lucky I saw Eliot= 's question. Brian From nobody Thu Apr 2 17:12:03 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854B83A08FE for ; Thu, 2 Apr 2020 17:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV2uv1P4AHGb for ; Thu, 2 Apr 2020 17:11:37 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FB63A08F3 for ; Thu, 2 Apr 2020 17:11:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 079CF300A01 for ; Thu, 2 Apr 2020 20:11:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id i34j9JJVFWJz for ; Thu, 2 Apr 2020 20:11:13 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 94F7C3001A7; Thu, 2 Apr 2020 20:11:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: Date: Thu, 2 Apr 2020 20:11:14 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 00:11:56 -0000 John: Just responding to the second point: > Second, my concern (and, if I understood Christian's note, at > least part of his) is that we have too many documents that get > to the end of community review during Last Call and then change > enough via IESG action or RPC efforts to be only barely > recognizable as the same document. The changes may be > substantive ones that the IESG considers minor or the writing > styles or skills in writing technical English of some authors > may have required major rewrites of paragraphs or sections by > the RPC. I've rarely seen either cause harm, but the fact > remains that the community is signing off on one document and > then a different document is being published. At least in > principle, that is a risk and maybe se should be thinking about > it and whether adjustments are in order (with the understanding > that reordering the editing and approval processes is not the > only option). In the IETF, WG chairs, review teams, and ADs all have a role in turning = back documents that are so poorly written that they need more that just = copy editing. I know that I have tried to do this in my working groups. = It is hard to tell someone that their document needs mush more work to = be ready to progress, but that is the right place to apply the = judgement. The RFC Editor ought to be able to tell the approving stream that the = document is not ready for copy editing as well. I understand that the = RFC Production Center is very reluctant to do that. Russ From nobody Thu Apr 2 17:31:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2D73A0962 for ; Thu, 2 Apr 2020 17:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtxUvvDBb2Oq for ; Thu, 2 Apr 2020 17:30:57 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F493A0948 for ; Thu, 2 Apr 2020 17:30:52 -0700 (PDT) Received: from xse369.mail2web.com ([66.113.197.115] helo=xse.mail2web.com) by mx16.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jKAEQ-00059u-Hd for rfced-future@iab.org; Fri, 03 Apr 2020 02:30:50 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 48tgnw1q8wz3Cqn for ; Thu, 2 Apr 2020 17:30:44 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jKAEO-0006vZ-3q for rfced-future@iab.org; Thu, 02 Apr 2020 17:30:44 -0700 Received: (qmail 14706 invoked from network); 3 Apr 2020 00:30:43 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.77]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 3 Apr 2020 00:30:43 -0000 To: Russ Housley , John C Klensin Cc: rfced-future@iab.org References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <4df17196-5d31-58c0-246d-75c189077fb3@huitema.net> Date: Thu, 2 Apr 2020 17:30:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DBA4B119B79C2E2BB918EC90" Content-Language: en-US X-Originating-IP: 66.113.197.115 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0VxB0mWeGZk2wSOLROvd+japSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4jWz/BeTstK11osv26wFvviQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEFTr1kXHz+fWAZp3N0TEAHQ7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsewdockuvmFY9cQ88McMLiJhycP4K1Fpu7HXiVspqMvyEB+H419EBFy2GgttQP0RzYmS ax8yVT5LNQc0pviCIZ+V87H2ECndxkpBwp1FkQyHa0qTD2ipD9y2znxCv9uYkc8RFZ4oobg8BBg3 Jq+ntzj0CwrK4jgBzEk72Eqb1SV77A9mDnaXtu0kZC/OWmUorWhGrjmKT7eS1my0gZ+ieneFycwh Ai5wggaaQGVX0EhMrXW8TfMUfXZNQGXIjuXCLLrcH/a5WtRktZms74EeOHyoz1caQoi44Wcfj1z/ J5tTt7j1ptfltBQnq8NvNwuG6kuhBG0YWFj/7xYZzwR7/PiKfowXlsolACJrkW/vjDp2NmSdEOMf tBjsWb6BDQzjSsG66974nkMwEqjhfSKHlA2Q3p5onVdn12r9xqR15ROHBesyXD9BkbKX7eGI2jGt /RQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 00:31:14 -0000 This is a multi-part message in MIME format. --------------DBA4B119B79C2E2BB918EC90 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/2/2020 5:11 PM, Russ Housley wrote: >> Second, my concern (and, if I understood Christian's note, at >> least part of his) is that we have too many documents that get >> to the end of community review during Last Call and then change >> enough via IESG action or RPC efforts to be only barely >> recognizable as the same document. The changes may be >> substantive ones that the IESG considers minor or the writing >> styles or skills in writing technical English of some authors >> may have required major rewrites of paragraphs or sections by >> the RPC. I've rarely seen either cause harm, but the fact >> remains that the community is signing off on one document and >> then a different document is being published. At least in >> principle, that is a risk and maybe se should be thinking about >> it and whether adjustments are in order (with the understanding >> that reordering the editing and approval processes is not the >> only option). > In the IETF, WG chairs, review teams, and ADs all have a role in turning back documents that are so poorly written that they need more that just copy editing. I know that I have tried to do this in my working groups. It is hard to tell someone that their document needs mush more work to be ready to progress, but that is the right place to apply the judgement. > > The RFC Editor ought to be able to tell the approving stream that the document is not ready for copy editing as well. I understand that the RFC Production Center is very reluctant to do that. How is "your document needs mush more work to be ready to progress" any different from "I found five attacks that your security considerations do not address" ? -- Christian Huitema --------------DBA4B119B79C2E2BB918EC90 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 4/2/2020 5:11 PM, Russ Housley wrote:
Second, my concern (and, if I understood Christian's note, at
least part of his) is that we have too many documents that get
to the end of community review during Last Call and then change
enough via IESG action or RPC efforts to be only barely
recognizable as the same document.  The changes may be
substantive ones that the IESG considers minor or the writing
styles or skills in writing technical English of some authors
may have required major rewrites of paragraphs or sections by
the RPC.  I've rarely seen either cause harm, but the fact
remains that the community is signing off on one document and
then a different document is being published.  At least in
principle, that is a risk and maybe se should be thinking about
it and whether adjustments are in order (with the understanding
that reordering the editing and approval processes is not the
only option).

In the IETF, WG chairs, review teams, and ADs all have a role in turning back documents that are so poorly written that they need more that just copy editing.  I know that I have tried to do this in my working groups.  It is hard to tell someone that their document needs mush more work to be ready to progress, but that is the right place to apply the judgement.

The RFC Editor ought to be able to tell the approving stream that the document is not ready for copy editing as well.  I understand that the RFC Production Center is very reluctant to do that.

How is "your document needs mush more work to be ready to progress" any different from "I found five attacks that your security considerations do not address" ?

-- Christian Huitema

--------------DBA4B119B79C2E2BB918EC90-- From nobody Thu Apr 2 20:01:24 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE33A0D03 for ; Thu, 2 Apr 2020 20:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw4Ew0d0bh3s for ; Thu, 2 Apr 2020 20:01:21 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C7E3A0D01 for ; Thu, 2 Apr 2020 20:01:21 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id b72so2767920pfb.11 for ; Thu, 02 Apr 2020 20:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=6T/2KKgh1E4osoSCKnZrC+LIEDqueh/q6ETFMAFm9uo=; b=fkWeonK8ht5Iru4+AxUsxa4KO9Uvh6l0MgYireeAUwKYNH9W5ofcK/ptK4V6BWIvuu L/DqaPLf1hUaifHsjkqwBri9fd7Gfe7OqUJn8G2JSiHUSdg9IfidYS01CQncmpX8Ip2O YUqGfmBsxPcJcDGVIKB8qm/nT6ek6Q4lqjeaaW1HHQNv+Cd2Ps0u7+2l9F+3Haxa/Mep BJUPqWGD4ClzwY7bSwT/HuwkHnksCt/2g1hqOQX71Fnd6mIueBNIFSvFCE7Ht2lV16xH jqMuCB5+JZC9TWirGO3WkR60bKJodyvGkAjH5R26ZAl8e/Q7NvvO/WSeb0CugM6Gpz5F ILgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-language:thread-index; bh=6T/2KKgh1E4osoSCKnZrC+LIEDqueh/q6ETFMAFm9uo=; b=U8HoadMDPTpU3AqlwFZQsnSYzaO9VpIQbjFqxIRjk9RK1mhYeYOnDucO8X6OggAeJX zd9SC+AuyHHc9MYH+wd8oIuAVRv9cnYq6d7cy7jsVEwgfcC1wodu4YgFz9EkNneP956G TRo7lnEG6bgthp8QamOEai6wgSqr5PDNrglvXB7x1I0abMYjrrLlqc9a+Ogi2SSuNtYO KkSRGeiiM4HzCzCZoG9TJUaQCsrQvcNZes03OGetR6GqDtK5Ml7qEDK3KdILyW02tdba WqYgjodWXz9NVmQnKD0JA/2KGj0Sfh+1/8XH1gpUc4j8KSkdtQMQLBTH+AMipBQTbyo4 P/lA== X-Gm-Message-State: AGi0PubFKYZO09emVs+EjeA0yXZ2DH4z0/A06w8Nly16s13KLMmkOHf7 Yynn00HT4nuZ2bU2wXqGL54= X-Google-Smtp-Source: APiQypL5m4tgYGVk30NIJppnyj51wZ2ygZAoaK13Ny7nUHxenTrzeKtZq2j3n8WnY9bqxI5hvWrkVA== X-Received: by 2002:a63:3850:: with SMTP id h16mr6146902pgn.326.1585882880735; Thu, 02 Apr 2020 20:01:20 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id x186sm4691854pfb.151.2020.04.02.20.01.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 20:01:19 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Andrew G. Malis'" , "'John Levine'" Cc: References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> In-Reply-To: Date: Thu, 2 Apr 2020 20:01:18 -0700 Message-ID: <009601d60964$2648e7a0$72dab6e0$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01D60929.79EA5DC0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGkjSKuW/6XuDC0UyTNV+RTdQKGoQHzE8PkAcIhXdCorADEcA== Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 03:01:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0097_01D60929.79EA5DC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 > I then trust the RFC Editor that the secondary formats (PDF, etc.) = will match the primary from a content viewpoint. =20 =20 There=E2=80=99s a reason why typical publishing workflows involve = proofreading a =E2=80=9Cgalley proof=E2=80=9D the already =E2=80=9Ctypeset=E2=80=9D format with the exact placement. =20 =20 I don=E2=80=99t want to belabor the =E2=80=9CAUTH48=E2=80=9D problem = except as an example of the mismatch of expectation (trust) against = something not in the job description might lead to problems. =20 During the AUTH48 period, whoever is reviewing the document needs to = check ALL of the formats, especially around examples and figures and any = non-ascii text. =20 ------=_NextPart_000_0097_01D60929.79EA5DC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

> = I then trust the RFC Editor that the secondary formats (PDF, etc.) will = match the primary from a content viewpoint. 

 

There=E2=80=99s a reason why typical publishing = workflows involve proofreading a =E2=80=9Cgalley = proof=E2=80=9D

the already = =E2=80=9Ctypeset=E2=80=9D format with the exact = placement.

 

 

I = don=E2=80=99t want to belabor the =E2=80=9CAUTH48=E2=80=9D problem = except as an example of the mismatch of expectation (trust) against = something not in the job description might lead to = problems.

 

During the AUTH48 period, whoever is reviewing the = document needs to check ALL of the formats, especially around examples = and figures and any non-ascii text.

 

------=_NextPart_000_0097_01D60929.79EA5DC0-- From nobody Thu Apr 2 20:07:59 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159173A0D1D for ; Thu, 2 Apr 2020 20:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT3ShWgWEcEK for ; Thu, 2 Apr 2020 20:07:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BDD3A0D01 for ; Thu, 2 Apr 2020 20:07:54 -0700 (PDT) Received: (qmail 84457 invoked from network); 3 Apr 2020 03:07:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=149e7.5e86a888.k2004; i=johnl-iecc.com@submit.iecc.com; bh=72fL4LyzlcTFE1BD0HF7XLYGOBe+LAHwbvSSd4ViZkc=; b=kE5nfwKFtfo8Vob11x1hncn0D2rocIRT43iawMd81OSeoXpIfn1LIMxeBlxi6j+RVljrY1M35ClbLOMjnn5uNUsOoVevIMFVf+TpY/JeCz5C9O6vjtjW5Ommt04uxUhjeYAD5FOfh+o7we2wM1QarQliW60mB9xXWEE7qutWtV4tR2jwURNdAGNolrWlfDRnR2pGOUiRWMTW43AFEaZfMUmcpiFmPDzwMwXI7njOtMTCrAHfyqHMX6/Y8/LsrNI6 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 03 Apr 2020 03:07:51 -0000 Date: 2 Apr 2020 23:07:51 -0400 Message-ID: From: "John R. Levine" To: "Larry Masinter" , "'Andrew G. Malis'" Cc: rfced-future@iab.org In-Reply-To: <009601d60964$2648e7a0$72dab6e0$@acm.org> References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 03:07:56 -0000 > During the AUTH48 period, whoever is reviewing the document needs to check ALL of the formats, especially around examples and figures and any non-ascii text. Currently the RPC people are proofreading all of the output formats, which takes a lot of work. I hope authors are also, but that's up to them. Keeping in mind that only the XML is canonical, and that PDF layout turns out to be surprisingly hard, one of the things we're considering to keep the documents flowing is to live with less than perfect PDF rendering for now, and to rerender them later once we understand the issues better. I am NOT suggesting that we thrash this out now, just that we need to keep that not every file one might see is necessarily part of the permanent archive. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Apr 2 21:46:50 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6801D3A0EB2 for ; Thu, 2 Apr 2020 21:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-nprWMm-jcj for ; Thu, 2 Apr 2020 21:46:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2603A0EB5 for ; Thu, 2 Apr 2020 21:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1585889193; bh=D9r57cRr2GVL/LDsdhobuv1iXfuFB3Mqbl33XYtbOsM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=M92d6NbrSSmpHCF/zeYVSspPirX6Vp70Db2CreDwgMNZZF61bVRwjmyTfak1oRm/2 lPjdnwanxg0pO0v90zB4vA2/7EXSB0AQZ/WjGjxGXkDkvu7O2STdRkUanxohKTKcdF Pq4WycQ3vIZMf6G+y8zpd/0toEM8b5ZZXJg40xY4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.49.230]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MsYv3-1j4TQI2i8x-00u2Br; Fri, 03 Apr 2020 06:46:33 +0200 To: "John R. Levine" , Larry Masinter , "'Andrew G. Malis'" Cc: rfced-future@iab.org References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> From: Julian Reschke Message-ID: <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> Date: Fri, 3 Apr 2020 06:46:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ecRN7OtbgDhmSYS7vBQH98YpS+HTVwIyiBrOxhtk4n6Ek7s9oMM ewyCeUNQdf0IACfdkhQzTMEmjCx0EhZSbHcazLcrrHeyLqcMQxs6BwJX1W0MhS2wz8nP49T p2iCqMOCq7+lKeJbO9BnsGvMny1IxPX+YSknP9Y6pMEknI6dL4YrLcyIQX+6+KEJ7r26kuD s49+n7rFJVxtPhXd0EaEw== X-UI-Out-Filterresults: notjunk:1;V03:K0:2oBwt/pkELk=:JTPQUOI7w68Ry1N57OOhyN qGk5J87SlHPjzzudK/CeXYURtsxjWmSQb2FcTQg6TJeEX6Ex3ta2eTIVJ7aJODFj8saLPDfu8 gTXxBAmeEppV955H7zztD+aZv9r/EDDLQBnvpSLyNkgciZs+3e7teFZvOAQvEdvVa3IW8WO/z lP27j7GUltfe/Fg2jIK6oEr18OqInqOfts70m/bnvF+Mj9q9oFf0eU6g9LUrNlJy/QQkPEiYW 4Qd2hISMwbLR7F/nSFPijCGnlxmv2VQbQvJyipitnZgL67YroJg46HNLdLhqwNzrSqo3MQGlw y9AcETuM7mh1UKsQ3VLtrlqG/WiyD7+s6GIKLQiDKp5s2o46c+KRUswlQZx+h9uA5qJB6XPZC e8s88eWeKtXjJEnigvfwaiPley1HTYXlVVbUvZ4P2uynPg61MDjf5vLuI4iKpPSJElftEKsjC S6KRGF+DQTlmDRbs3CE01AkR6oAgp3aRwjZ0ilic4AJbqTi+z7Qwn5DsWfW7FpANERCbVYL/W 2r+0XYd12jErNfIEgvN2g/UYWdz1Yv97KOEq7Okdbix8rD3vMy5UsLaIvTXdYZLK2+AktWylD rAwCitf4jyVygh9ULAOfZhxKy13cqrUJ9fmUaVv8TphNfFxrGyXybakFAvcBKhVsSHiTxJJs6 PySi04bi6qQnMD28/fpTkFdCzOviZ+qkfL2AkFiiQMJNNKZJH+HsI+9yU8dgLpJKHtzq7MKQz bDEZF2WOauR52/kde0QP7ROW29iko0LS1YwrQe82MgpsEvgl4lAnSJNyZavfZ/XMiOliU/UGp cqeYaV6otmKQ7kMFjLWa83bgL+EG9VEj/y/1V2YpoAyogYi9VRFR3rUKDRDtIETLcrWnkueQu HUYi3rVOR4ur+PegzOIUVT0PEMf8z7EmfNSg5261yv5y99efImV78RE4MXW3A3fV7qbjggrfP aWd5UYfAe6q1Q5MgkDhXOTIBgty6ZPrzYgjXj6lSCFIq+vIAlplE4bEeZSVukYvpj7f+/z2Ar bj7ukes5FEsTijJQE/eAeZ82DHsYJFWobgHhiqWQcpb30WOrFh+5OsGproJVK2fb6ber3yFEi 1Ve40jDA0CfGNwnFe4jdyrM+mSO5ytGvwcLyyH/FzWqdPTjW7n0EJC8W1090R+x71tcdbsNGJ OZC8m99+rJBerNSqlJZSQxBdR+kTsAZCyiRXQCL3EcHNkoda6O20GMuI+3RPscOtwLEwQor8q cV4fj6oGfzgfG/3pZ Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 04:46:49 -0000 On 03.04.2020 05:07, John R. Levine wrote: >> During the AUTH48 period, whoever is reviewing the document needs to >> check ALL of the formats, especially around examples and figures and >> any non-ascii text. > > Currently the RPC people are proofreading all of the output formats, > which takes a lot of work.=C2=A0 I hope authors are also, but that's up = to them. > ... That sounds like a bug in the process to me. And it won't scale if we add ePub. There should be *one* format that is to be proofread, HTML. If the other output formats have an issue, that's a tooling problem that needs to be solved, and the other formats can be regenerated. > ... Best regards, Julian From nobody Thu Apr 2 22:25:33 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FDF3A0F8F for ; Thu, 2 Apr 2020 22:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyQZR8eABxTB for ; Thu, 2 Apr 2020 22:25:30 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474BB3A0F8E for ; Thu, 2 Apr 2020 22:25:29 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48tpKy3vwrz107V; Fri, 3 Apr 2020 07:25:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> Date: Fri, 3 Apr 2020 07:25:26 +0200 Cc: "John R. Levine" , Larry Masinter , "Andrew G. Malis" , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 607584325.959883-9264ae827c3a625b6f5493d6034072f6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 05:25:33 -0000 On 2020-04-03, at 06:46, Julian Reschke wrote: >=20 > On 03.04.2020 05:07, John R. Levine wrote: >>> During the AUTH48 period, whoever is reviewing the document needs to >>> check ALL of the formats, especially around examples and figures and >>> any non-ascii text. >>=20 >> Currently the RPC people are proofreading all of the output formats, >> which takes a lot of work. I hope authors are also, but that's up to = them. >> ... >=20 > That sounds like a bug in the process to me. And it won't scale if we > add ePub. >=20 > There should be *one* format that is to be proofread, HTML. If the = other > output formats have an issue, that's a tooling problem that needs to = be > solved, and the other formats can be regenerated. This doesn=E2=80=99t work too well in an environment where the tooling = is fluid, and in fact the format that the tooling works from and its = interpretation is fluid as well. When the tooling has a bug (read: it uses the interpretation of = 2020-04-02), and the XML is adapted to work around this bug, and the = tooling is then fixed (read: it now uses the interpretation of = 2020-04-03), the new output may be erroneous. Putting the =E2=80=9Cto be interpreted with the bugs of 2020-04-02=E2=80=9D= into the XML makes this workable, but it might be preferable to give up = the idea that the XML is immutable and allow up-conversion into the = format of 2020-04-03. We probably should have recognized that we would be working with a beta = v3 for a while. We could still recognize that there will be a v4, and a = v5, ... I=E2=80=99m not saying that I have a solution to this problem. = Proofreading the HTML is probably the right thing for an author (in = particular if not an XML aficionado). One view at the TXT is prudent as = well. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 2 22:36:50 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03D3A0FC9 for ; Thu, 2 Apr 2020 22:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G00tSKXXoM24 for ; Thu, 2 Apr 2020 22:36:48 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C993A0FC7 for ; Thu, 2 Apr 2020 22:36:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 48tpb40h9Yz1p0VF; Thu, 2 Apr 2020 22:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1585892208; bh=ZDsl5QdsivWUVlPq0fH8ZbLfWH6NIyzFLIyGdG9xd74=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bqPqcfZ6dGNByaDdjYXtmJg9O2Lcls2yFiSkuo3Ps8QrBrATv/ul0OSXY9rL/Ol9f SyxRR5ZI8QNxSVeOPW97r+FAAJ64HicK5+74m34ih5N5nn+99iE8wOMhaXPQAGbOvI Q9XncLuuvJr7I9PXuI/KC1cySZq6h/Y5dC2J7OSg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 48tpb30mp9z1nxr5; Thu, 2 Apr 2020 22:36:47 -0700 (PDT) To: Julian Reschke Cc: rfced-future@iab.org References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> From: "Joel M. Halpern" Message-ID: <85cc8179-52ce-49f3-4412-c9403d3aec31@joelhalpern.com> Date: Fri, 3 Apr 2020 01:36:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 05:36:49 -0000 Julian, on what basis do you assert that the HTML is all that matters. As far as I know, the agreements we have in place make the HTML one of the output formats, no more and no less privileged. You may want a different answer, but until we have rough consensus on such a different answer, asserting one does not make it so. Yours, Joel On 4/3/2020 12:46 AM, Julian Reschke wrote: > On 03.04.2020 05:07, John R. Levine wrote: >>> During the AUTH48 period, whoever is reviewing the document needs to >>> check ALL of the formats, especially around examples and figures and >>> any non-ascii text. >> >> Currently the RPC people are proofreading all of the output formats, >> which takes a lot of work.  I hope authors are also, but that's up to >> them. >> ... > > That sounds like a bug in the process to me. And it won't scale if we > add ePub. > > There should be *one* format that is to be proofread, HTML. If the other > output formats have an issue, that's a tooling problem that needs to be > solved, and the other formats can be regenerated. > >> ... > > Best regards, Julian > From nobody Thu Apr 2 22:37:45 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8702A3A0FD3 for ; Thu, 2 Apr 2020 22:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dXc8y95qDGM for ; Thu, 2 Apr 2020 22:37:42 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495033A0FCD for ; Thu, 2 Apr 2020 22:37:42 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id o26so2973895pgc.12 for ; Thu, 02 Apr 2020 22:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=rkO0WMAUjp9SUN3gnTDNEYhgp8EKL6gHgRUvPaaRHOc=; b=iMw8+/VYxtooudN4VATp59EGQngrnLTT+zj9dPc7MVn0fWHEcIAWB/orcKh24KK3VT 0ZrJagyqVMBBHeigAfUn+LK131G5S6cLoVu7gkNBbl2drKTWgNsAckdte8mVps8AT0Rs Relgzc698PxYCvGQl54D3dpRLGq5jLFeL8JjynnVAyD+YypIxmxy5/Tqg6cJgaN1HZTz qzOUvoWKlSyZj01MwnfeZrWxSLob5BH2nl+T+Q/BvvWurv5myMCyodhODnJ1sKkCcr/X Vp9hyH3e5/DE1ZlCUZlDNXyDauPLeQTwkOUe23jueAURU0lYFjIcA/0UYY8mIpyDA0It VfBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-language:thread-index; bh=rkO0WMAUjp9SUN3gnTDNEYhgp8EKL6gHgRUvPaaRHOc=; b=JDbEUF/5SI7FNCsYhJZVuyNhQd+/X8G7HrQX3ZLQP52KcbX2eafy7f44v9XxajxbKf kK7F9Q+H9Y8Zd3ymoe1BhiRbDcS3nB2gewOMMFaSGmwibvsVBvkGmGZAzZoyxuGDHqiW q3IEnCU8Zz2J4TZ7LeH78lqfszyrWBVl6eeoNmsn7KrPsjqeP7UbIcSsD9bs1TmY0oR9 lIWmp+2gKW7hforf6coHZLedxeIsN+PG7LKZI0v9HeLcioNHMW/cxcKsWphe6M/BHac4 7q/WfLYK8tR3RzI7uupSw5Hj7Ovm2f75PrO+f+3yQ/wSsgVYKGVVrP06ZeNvrDlyV3/+ 2FsA== X-Gm-Message-State: AGi0PuZA+cspxcYWiTgVpR58GYoAWHK1iBU7EeTAfgIw7xKO4A5PoTkQ N/I9eUUm6T2D/vCPFg/YWkKsVKco X-Google-Smtp-Source: APiQypJgbJcoWFDKShPCfNZH+xuR1bEYueLLRkuTaOiYwpFUi+1rhoMf6IseNWwFu6eZe/Z0oOhOLw== X-Received: by 2002:a63:7e10:: with SMTP id z16mr6720518pgc.412.1585892261343; Thu, 02 Apr 2020 22:37:41 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id g75sm4861928pje.37.2020.04.02.22.37.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 22:37:40 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Eliot Lear'" , References: In-Reply-To: Date: Thu, 2 Apr 2020 22:37:39 -0700 Message-ID: <010301d60979$fdde1090$f99a31b0$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0104_01D6093F.517F86B0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGSy5r9VV8/1Ja5QJZGtIRIKhBRtKjtOf9Q Archived-At: Subject: Re: [Rfced-future] Attempting to collect key points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 05:37:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0104_01D6093F.517F86B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Let me try again =20 The point of the AUTH48 example was as an area where user=E2=80=99s = expectation of the RFC editor often are greater than the RFC editor job = description. Either change the process or add to the job description. =20 It was intended as a =E2=80=9Csmall=E2=80=9D problem statement under the = proposed agenda of first step 1 listing things that need to be fixed. =20 Suggested reading =E2=80=9Cpublishing workflow=E2=80=9D and = =E2=80=9Cgalley proof=E2=80=9D =20 ------=_NextPart_000_0104_01D6093F.517F86B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Let me try = again

 

The point of the AUTH48 example was as an area where = user=E2=80=99s expectation of the RFC editor often are greater than the = RFC editor job description. Either change the process or add to the job = description.

 

It was intended as a =E2=80=9Csmall=E2=80=9D problem = statement under the proposed agenda of first step 1 listing things that = need to be fixed.

 

Suggested = reading =E2=80=9Cpublishing workflow=E2=80=9D and =E2=80=9Cgalley = proof=E2=80=9D

 

------=_NextPart_000_0104_01D6093F.517F86B0-- From nobody Fri Apr 3 00:00:18 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E143A1115 for ; Fri, 3 Apr 2020 00:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXNO3-xQyaG5 for ; Fri, 3 Apr 2020 00:00:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08593A09DE for ; Fri, 3 Apr 2020 00:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1585897193; bh=vdZ9Sz04AuDLsS9bjyycrvJ1EnxmspN+IQkLa/76TAs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=JORXHY+/rKLbXjO7xQtJbGrD8rABHzG1kOnMot5oMr+V6U0+qp5SjERVNjALWatMG 1jGnetFnES2ZV45KF0yx2gLWu2BqGO8gGD+nu3ET/bQyQLtsAbE2nulWmZVn/v3OzH mmigdD4pPdRYaBYHsTaOag18t8kUyogz/EoRVOwM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.49.230]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MybGh-1j8CZQ1T5x-00yzSX; Fri, 03 Apr 2020 08:59:53 +0200 To: Carsten Bormann Cc: "John R. Levine" , "Andrew G. Malis" , rfced-future@iab.org, Larry Masinter References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> From: Julian Reschke Message-ID: <3b1df23c-d1e4-46f9-d7d4-6fac978be8d3@gmx.de> Date: Fri, 3 Apr 2020 08:59:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:j5jr+Ay6STQ8YjxuxzRcn7p4zLydrJghWgwPrAJTA2dmZFwTyJx FSmn53OR9CkSxLjo2s50wavcRF/YTpSLN7Vp8uUEnO1iGE3R8sD0EHLPOA2vUn0+Vdj0eL1 EZzJ6NfjLxpZnbTx17nNXcXJycV5gVPEkekm+9mNvrPiRV1tnmbvQzz5zyJo4HNpegH5jBz 0hsnz1VJf87zqPdhnTz2A== X-UI-Out-Filterresults: notjunk:1;V03:K0:mrMlTPpp8s4=:LO9n2C7Cd1B4VSVAIJi2aK Rv6cSu8V9XiuBAnTcDfD9M3PphzY0ko6oxMaAu8UvWEMlZ4uqLGwsm0R6Z1p552r6cEd8TWhR gB6m/T9xtIqihc/xRvg3o7t5w5lKgvqhYY2ziRBpJgHFVzUi1wTr7vhxOsBXQwCr9eD6cHmXX W3ZerC777EGUwDd3rk5OAjZYhdttaVZTQeqoHsnlY8De77RTPLjckTo0rIaDc1A8U7zLEpDPG t34yQL/0pwqmHVcV5Hghpgvv1JrYjx3MQkysHTO/xKAfxlzugpb2tZJrNjvan14/HC2RBdNdK B+Yhh2dvRgriudJjVqXVlFu2MgwX94OdtYwrepPLueLOJ/+Xuj4zc6K3kS4KxK8mVQk0hCc5X VPOJvF8l15lSjW59+LI4IFe35QvmJR1ML6ESEAm3o+lbr6Fn0X49fN7JbaTca8ZgC9cxHyQc4 CdKTQ31Rm3/g4Cs8P3yAnzqF0ev5sTarCYGxU6Kdadeir4UkEyQqEOZAE9fcGiuT+iCPo3TYb QWzCpWgq1BaEX0/3ztauobo1mwnzGMuNysx/y3k7zW2NjUwXM/klP9XD6aiTlhnP10VM0wxAZ UV6TfEW1stzb/x6DvxWHXQuOGtAGootvu4O9RQiMmpfQ64CtPB4COEEXA1mDJhXHy64FPs+bJ KYKQP+P94UGjKgEsjh1Kw7lBWc2TqsSwJGJR+dIqOuwwAFQNNHLCIYqZbI23xn0EEF5LMhFmU pcl4LXSeYOxeuSxP0Eia0C/BiiqCdX5IQpzZ2R7Fq9qzrEJzztH710bzPoqEoEHV8Cb24Nv4Q +rvp5L88EoL+I0zsSIIlCTUeIi3zcLBSxSdyd64xFFo4Y4TsAEOCUTnYnfyw2/XtNycfTFbRr HHF6igRK+j4gXFQiv2iynd5zmVNu83IERrOxMuNBQ2upMdV1sQXFIjasfIBlf74rNcQGrW5uL 5zBTBx5ASq/fy1re3a0iSZsfw5bmDZWUzVGtnck+DonqsvhmWfeHiQI916tEgQsd7gf7I2umg oMTSjSs/+7Q2P7YjmdjOlrD+xIExJvWcRoJInMLE1XfXBPiAAdDEqz2UKXktzbSJvKcAnzdiy jOzaHtiz8gj3/zGQfru9YrYhnwQ54xz4VWWu7Vb3R0wm5zEuzZXFP1yzbV2wsj6rDyPFFrrtK A3h5rq5bNuIzGbQkcyl03xWJnJdTE1zioAAMDb31yr7iKc2KPOMNfTvWmNo4h74Spa8AECpN8 AaBHY/HJSVm+3qFe+ Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 07:00:16 -0000 On 03.04.2020 07:25, Carsten Bormann wrote: > On 2020-04-03, at 06:46, Julian Reschke wrote: >> >> On 03.04.2020 05:07, John R. Levine wrote: >>>> During the AUTH48 period, whoever is reviewing the document needs to >>>> check ALL of the formats, especially around examples and figures and >>>> any non-ascii text. >>> >>> Currently the RPC people are proofreading all of the output formats, >>> which takes a lot of work. I hope authors are also, but that's up to = them. >>> ... >> >> That sounds like a bug in the process to me. And it won't scale if we >> add ePub. >> >> There should be *one* format that is to be proofread, HTML. If the othe= r >> output formats have an issue, that's a tooling problem that needs to be >> solved, and the other formats can be regenerated. > > This doesn=E2=80=99t work too well in an environment where the tooling i= s fluid, and in fact the format that the tooling works from and its interp= retation is fluid as well. If the tooling is that fluid (is it for HTML?), that shows that we shouldn't have started the switch yet... > When the tooling has a bug (read: it uses the interpretation of 2020-04-= 02), and the XML is adapted to work around this bug, and the tooling is th= en fixed (read: it now uses the interpretation of 2020-04-03), the new out= put may be erroneous. The (canonical, published) XML never ever should be adjusted to work around a bug. Is this happening? > ... Best regards, Julian From nobody Fri Apr 3 00:02:42 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4B63A1125 for ; Fri, 3 Apr 2020 00:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nU67GN_punF for ; Fri, 3 Apr 2020 00:02:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF1C3A1127 for ; Fri, 3 Apr 2020 00:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1585897351; bh=30434bCbZCCkOHTJXDLqb9naFYaKm/a0Up6q/9DoGdM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=PC7rsPlgGQ/7eFW+Zbw8TQzWGMpMQ/Lt9oGiUxDfYqpScY3eya277ge4ajCuZ3HYg ZZtWuTC9oiolOahrD0ZDmBLwVYOOruHzHpb6JkwSQ1EHK0NKy2OJar+NFqapKGbB3F wpXtF6E1xRzrmw2AZtjdY76ks5N7+5h4bgjfR8eY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.49.230]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MRCOE-1jf4UM3Njg-00NAqo; Fri, 03 Apr 2020 09:02:30 +0200 To: "Joel M. Halpern" Cc: rfced-future@iab.org References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> <85cc8179-52ce-49f3-4412-c9403d3aec31@joelhalpern.com> From: Julian Reschke Message-ID: <3d0e3847-6ed5-9e2a-028f-7ce5f886965d@gmx.de> Date: Fri, 3 Apr 2020 09:02:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <85cc8179-52ce-49f3-4412-c9403d3aec31@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:QvCtKuxDoxaJiITXT1rdtoSugPx2EJrb1axPuK/9sU/Q6AcdIZl nJHzwOnd8bC7ZcmPrJ8V34D8bW+S7nxlVfhtvJQOdrWWsXvElf4ZsNRvH9QxgT57efg8fzp r2tm8+d3DJmu+WZZjEqQaB3Z9zJvgT0wefI2qqcnzi9m1wj67FB8TTs8sD6QOBFe+rV+fYe WLa3RE8WyuFOIZgFKfxag== X-UI-Out-Filterresults: notjunk:1;V03:K0:fluzuuC3JuM=:j/OY92x+RjEyGoOxNI42jD nijWTLzzGdDkPlBNRAiiv+JfVk0oDiB/j7YoCG4qZWnEH9qUOGY2KBL8Y1K26hZkMM5tI4MKv mz6b0z3HRKWvCKQIVPAzv00PRXjK45teLmzjaKPmFqFzl/iiy8bQpMO83jiIYNvxCu6RBJXjI PFAjNeRUmhIOXWgkWiR37unK5mxzRCYqEv/yu2a26/PG9SJ7iUFXZLAd+xCmktRN/vQev2Taq Wm9AvmcMZBz2XvxSCgiC34c4AaZo8l6VMXvfE+aRZ7kr0t+DqsWaSjI/9SozKXvH2CV0fWN1V 2gTiDQz8PFVJN/7FcKVmsI6s4+9oDGhUHhMv4zjjFRrlH/hsRrvr+EbS/LavA0MhdpsmMfME9 WKhTC4o2aV4RQWZsrdL8RdDgpG7Xa/bsTLQK7owFk1WWh5carHp0PcP8/X90AARupc9dYIjWI 9PnGcmncjHKuowCvjnEHD8TrSk7rbbJLAiE8/iYrSM6Ej+efI866piGZZMxNNqA9wye1RnbQ5 othuBrI5Qk450+gf845ML9/tayCxl/7GfSAJxMLeM7ra5tHxXn88af5Sai6GfCG2OlHrUypSQ vUFiicpBPluOlm6gvNqsO/Xzb+5f/8/cQZNfhG1cDc+VCthEeJeOnb19LpDtx/shFIcm0qjS2 CqgZS0aMrMQNBBga0JedBU2t10fqoxhMRZqr6CMx8HPuKT6b7LSvqRfacHqkdZltw4tvfzKbA ItBOTbYmr82y4lylXbFVA/9qoHKi4GuH+aZngG7qI5964D7MiqVMLqUD/qBMA/M5FxgKFaSXp CCXeWlaHlQ+YXhp/mDQNie+C4dmgvD3wu+kcYdGtPx0SxU2YfGn7ZVzjEIYKAg4WgpiQ5lHlR PMnJJyEE07KJpQ5ephumbdapF6z7fD1afMO76lOJD/Zxxz0K4lJNOUczXUTqyRvL6xuWfh5gs ZZ2q5hLFXEYM3NBq7T+ZkQ2U6ngNLvFlROOUS/1wNn1fOYfsEcIV5zQrKsbXd8g3Z3awPyegh cOBpCJjxYlBTg1xo+JkSYCn0UHQ1GzOM3xFeB2ZWHwh6BjkME3WUaLj9sXJ8R956bOV9rlPuK eRZFEYvyP14Eq7Tbujdf9EwuUdmj62YLXkQO40xzU7epvIXaRIY6rJpa3dgNxEs64XCeO8xwj gba5GCfYNIwz6AFMwxc5Lkvldjh6gKGgRhKcw4YGu6uUmvtX6w4Cn6wO412Acpgk6YeNd1xAa 5L60Gizf8ynS+XfLX Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 07:02:40 -0000 On 03.04.2020 07:36, Joel M. Halpern wrote: > Julian, on what basis do you assert that the HTML is all that matters. > As far as I know, the agreements we have in place make the HTML one of > the output formats, no more and no less privileged. You may want a > different answer, but until we have rough consensus on such a different > answer, asserting one does not make it so. > ... It's a practical observation. - TXT can not support all features of the vocabulary, thus just checking the TXT in general would not be sufficient - PDF generation (IMHO) has had less development time, and is (IMHO) is less used Best regards, Julian From nobody Fri Apr 3 08:48:51 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267E13A194D for ; Fri, 3 Apr 2020 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhHqWFr7nQBB for ; Fri, 3 Apr 2020 08:48:46 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD043A1948 for ; Fri, 3 Apr 2020 08:48:45 -0700 (PDT) Received: (qmail 24960 invoked from network); 3 Apr 2020 15:48:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=617d.5e875adc.k2004; i=johnl-iecc.com@submit.iecc.com; bh=HnmWu51c/KQonaaQ5MERBOvMMMIq1uXbU34LRfSusVc=; b=Yu65OwNqRfApARhuzK2Es6wSzFuLSkrcOUHCz/Q8eAp4775Fi+vym5awZ6mW2Fc1VolQzbDI/qA/JrTotMkk7L4ufx6gjBO4NCS9BoiFKAqHyRBg4R7XDKGic80IKwTwA4C6I3E8HAtvX3XXFmGCn7ATLIaOzDRv2cOfBgBZIIsXQpGmN+icjW0KRDTq6QS/sshFm5po4s0FYTsNNc8YE6wjGYEezW1FNTcAR531/19g2zF8tp/7pWoAG04V1AoA Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 03 Apr 2020 15:48:43 -0000 Date: 3 Apr 2020 11:48:43 -0400 Message-ID: From: "John R. Levine" To: "Julian Reschke" , "Larry Masinter" Cc: rfced-future@iab.org In-Reply-To: <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 15:48:49 -0000 > There should be *one* format that is to be proofread, HTML. If the other > output formats have an issue, that's a tooling problem that needs to be > solved, and the other formats can be regenerated. Yeah, that's why I've been suggesting we temporarily live with less than beautiful PDF output. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 3 12:41:39 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08DA3A081C for ; Fri, 3 Apr 2020 12:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylj4YUsp1XuB for ; Fri, 3 Apr 2020 12:41:29 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A5A3A082F for ; Fri, 3 Apr 2020 12:41:27 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jKSBr-000Amr-4Z; Fri, 03 Apr 2020 15:41:19 -0400 Date: Fri, 03 Apr 2020 15:41:13 -0400 From: John C Klensin To: Eliot Lear , Carsten Bormann cc: Ted Lemon , rfced-future@iab.org, Christian Huitema , Russ Housley Message-ID: In-Reply-To: References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 19:41:38 -0000 --On Thursday, April 2, 2020 19:25 +0200 Eliot Lear wrote: > Can we distill the high level point that needs addressing in > this process? > > Are the touch points and flow the responsibility of the RFC > Editor to define, or should that be this group? Eliot, I think "touch points and flow" is an oversimplification and that this thread illustrates that. Let me see if I can divide things up without going on too long about it. (1) This particular issue is out of scope because the problem is probably exclusive to the IETF streams. If other streams have the same issues, we haven't heard about them, but, even if they have, per-stream solutions are likely to be needed. I don't think there is any reason to make reconsideration of the stream model part of this process. (2) At the same time, the question of the responsibilities and authority of the RFC Editor Function seems to me to be very much on-topic. Historically, the RFC Editor has always had the authority to say "this is not publishable in its current form, please fix it" (see Appendix A.2 of draft-flanagan-7322bis-05, posted today). In ancient times (i.e., during the Postel-Reynolds period) drafts were periodically bounced because they were not coherent enough to be editable with reasonable resources. Btw, in those times, drafts were also bounced because the RFC Editor judged them to be technically incoherent. And, sometimes the RFC Editor would apply a "fix" to a document that had substantive technical input... and a few incidents of that were what set us on the path to having an AUTH48 process. However, in more recent times, when the RFC Editor has pushed back (and I'm not aware of that occurring in many years, so what I'm about to say is not a criticism of any present or recent IESG), the responses from the IESG were rather hostile.. and that is why we have an explicit provision that says the IESG can tell the RSE/RPC to publish a document exactly as the IESG prefers with the RFC Editor able to only add a note indicating that occurred. I think that immediately goes to two types of questions I think are in scope and, indeed, critical for this group: (a) Noting that the decision to edit (or not) a problematic document will often have consequences on overall workflow, do we want the decision as to whether to do so be made by the RPC in conjunction with (or under the authority of) the RSE or under the authority of the Executive Director (who may have no publication or editing experience). If general guidelines are developed within the RFC Editor Function about the properties that should cause a document to be pushed back, is that an RSE function, an RPC one without the RSE, of an Executive Director matter? (b) Is the RSE ultimately independent or simply a contractor who can be managed, and whose decisions can be second-guessed, by the IESG, IAB, RSOC, or some other group, either directly or via the Executive Director? thanks, john From nobody Fri Apr 3 13:06:15 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C883A092E for ; Fri, 3 Apr 2020 13:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxIWXAiIhpjY for ; Fri, 3 Apr 2020 13:06:09 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619C23A093D for ; Fri, 3 Apr 2020 13:06:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E205D300B58 for ; Fri, 3 Apr 2020 16:06:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nSoALj7ilyci for ; Fri, 3 Apr 2020 16:06:04 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id AEB4B300A51; Fri, 3 Apr 2020 16:06:04 -0400 (EDT) From: Russ Housley Message-Id: <49D8A42C-B203-43B2-9E1C-CEBE6E139DA1@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5C67FEAD-0B2A-427F-869F-7D4FB9A38D03" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Fri, 3 Apr 2020 16:06:05 -0400 In-Reply-To: <4df17196-5d31-58c0-246d-75c189077fb3@huitema.net> Cc: John C Klensin , rfced-future@iab.org To: Christian Huitema References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> <4df17196-5d31-58c0-246d-75c189077fb3@huitema.net> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 20:06:13 -0000 --Apple-Mail=_5C67FEAD-0B2A-427F-869F-7D4FB9A38D03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 2, 2020, at 8:30 PM, Christian Huitema = wrote: >> On 4/2/2020 5:11 PM, Russ Housley wrote: >>> Second, my concern (and, if I understood Christian's note, at >>> least part of his) is that we have too many documents that get >>> to the end of community review during Last Call and then change >>> enough via IESG action or RPC efforts to be only barely >>> recognizable as the same document. The changes may be >>> substantive ones that the IESG considers minor or the writing >>> styles or skills in writing technical English of some authors >>> may have required major rewrites of paragraphs or sections by >>> the RPC. I've rarely seen either cause harm, but the fact >>> remains that the community is signing off on one document and >>> then a different document is being published. At least in >>> principle, that is a risk and maybe se should be thinking about >>> it and whether adjustments are in order (with the understanding >>> that reordering the editing and approval processes is not the >>> only option). >> In the IETF, WG chairs, review teams, and ADs all have a role in = turning back documents that are so poorly written that they need more = that just copy editing. I know that I have tried to do this in my = working groups. It is hard to tell someone that their document needs = mush more work to be ready to progress, but that is the right place to = apply the judgement. >>=20 >> The RFC Editor ought to be able to tell the approving stream that the = document is not ready for copy editing as well. I understand that the = RFC Production Center is very reluctant to do that. > How is "your document needs mush more work to be ready to progress" = any different from "I found five attacks that your security = considerations do not address" ? >=20 The first is a statement about the clarity of the writing in the = document. The second is a statement about the technical quality of the = document. I do not expect the RFC Editor to make the second assessment. Russ --Apple-Mail=_5C67FEAD-0B2A-427F-869F-7D4FB9A38D03 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On 4/2/2020 5:11 PM, Russ Housley wrote:
Second, my concern (and, if I understood Christian's note, at
least part of his) is that we have too many documents that get
to the end of community review during Last Call and then change
enough via IESG action or RPC efforts to be only barely
recognizable as the same document.  The changes may be
substantive ones that the IESG considers minor or the writing
styles or skills in writing technical English of some authors
may have required major rewrites of paragraphs or sections by
the RPC.  I've rarely seen either cause harm, but the fact
remains that the community is signing off on one document and
then a different document is being published.  At least in
principle, that is a risk and maybe se should be thinking about
it and whether adjustments are in order (with the understanding
that reordering the editing and approval processes is not the
only option).

In the IETF, WG chairs, review teams, and ADs all have a role in turning back documents that are so poorly written that they need more that just copy editing.  I know that I have tried to do this in my working groups.  It is hard to tell someone that their document needs mush more work to be ready to progress, but that is the right place to apply the judgement.

The RFC Editor ought to be able to tell the approving stream that the document is not ready for copy editing as well.  I understand that the RFC Production Center is very reluctant to do that.

How is "your document needs mush more work to be ready to progress" any different from "I found five attacks that your security considerations do not address" ?


The first is a statement about the clarity of the writing in the document.  The second is a statement about the technical quality of the document.  I do not expect the RFC Editor to make the second assessment.

Russ

--Apple-Mail=_5C67FEAD-0B2A-427F-869F-7D4FB9A38D03-- From nobody Fri Apr 3 13:32:48 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8973A0A56 for ; Fri, 3 Apr 2020 13:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II6YbBJIT0GP for ; Fri, 3 Apr 2020 13:32:45 -0700 (PDT) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EFB3A0A53 for ; Fri, 3 Apr 2020 13:32:45 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id 142so4075446pgf.11 for ; Fri, 03 Apr 2020 13:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gBKamDYUDVlM6NwOn26od9aDtux62AyWz/jHUGEtjSA=; b=kPev1HNzB+0lRGuVpnIqJMBdWZZy5kYVSd4rXlSElFxkG7AIUY8RtzLHslOrniNUPB X61B7Ntqq2emRrau1MATXdYZNkx+9OXGqSATb9EMy+AnQp+02Lnd5CxrXmhUY9NOavHZ D52s63eiukjhBLIE5DyoZoOQJ/Lvrle7VNFgbJRKneLfaDMfXEDgUsByUCSa2sWnc9cr WiXxTrwJUOXFPQUX1Npmo5a3RVwNNBppODY+c2EjegbQL3+U4yTcCymOk3n1h8D2MT7U 8dQWebuDtLxA1knLyel8K3ScB9c4UrMdrGgnWrsKRXKA4LTBw1zI+TaKilcr4PpcD2CA ctkA== 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=gBKamDYUDVlM6NwOn26od9aDtux62AyWz/jHUGEtjSA=; b=CAA1wH6fCaRDyVXmNbW3Zu89bJWE8e7QLNSZI1A6/YKOLCUM3t4uqT0EsduGzJLVfB zPUUaJFV58MXCAPK/r4FvQ6MSD7UVdvVI2qxn85/RBtsIcjDT+fkebvdpsPHFjKwdUva KlKQxvwZd108InVP93hQrlqj4+kHfT2rrO6Bn+QxRHFmZsBId6l+CXBqWRSuQMdvWvAt 6Zs+UeLD8wDxeOL46F4NB9GVhN/xRagFuBpCsf2ML/mQPUULisrDojXc6y306qdlyI6W NEfGIcaxBfeaNLivHmB32fNwS7/ltgYsAVgWhQ1Mnwo8DnkWz8Ml7bGjE/Ql4yUx66WJ Zs8w== X-Gm-Message-State: AGi0PuYmGP2hxk5rGJ6kJ3YMvf1YCizZpIfBo34GQUds1EWxPS5jQl9A 4OuKO/LM5wwuZYdfaQA+sY8= X-Google-Smtp-Source: APiQypJGbyVmj1kegbiYka8m5YLXmk6uP+EQ2sUnUCWj+53nigACY0lblxIfoBhn4aA+FKdHeik/Mw== X-Received: by 2002:a63:1245:: with SMTP id 5mr9832469pgs.55.1585945965073; Fri, 03 Apr 2020 13:32:45 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id b125sm5815597pga.92.2020.04.03.13.32.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2020 13:32:44 -0700 (PDT) To: Julian Reschke , Carsten Bormann Cc: "John R. Levine" , rfced-future@iab.org, Larry Masinter , "Andrew G. Malis" References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> <3b1df23c-d1e4-46f9-d7d4-6fac978be8d3@gmx.de> From: Brian E Carpenter Message-ID: <46ebaffc-9c69-f5ce-8155-bd7dda3cde7c@gmail.com> Date: Sat, 4 Apr 2020 09:32:38 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <3b1df23c-d1e4-46f9-d7d4-6fac978be8d3@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 20:32:47 -0000 Julian, On 03-Apr-20 19:59, Julian Reschke wrote: > On 03.04.2020 07:25, Carsten Bormann wrote: >> On 2020-04-03, at 06:46, Julian Reschke wrote:= >>> >>> On 03.04.2020 05:07, John R. Levine wrote: >>>>> During the AUTH48 period, whoever is reviewing the document needs t= o >>>>> check ALL of the formats, especially around examples and figures an= d >>>>> any non-ascii text. >>>> >>>> Currently the RPC people are proofreading all of the output formats,= >>>> which takes a lot of work. I hope authors are also, but that's up t= o them. >>>> ... >>> >>> That sounds like a bug in the process to me. And it won't scale if we= >>> add ePub. >>> >>> There should be *one* format that is to be proofread, HTML. If the ot= her >>> output formats have an issue, that's a tooling problem that needs to = be >>> solved, and the other formats can be regenerated. >> >> This doesn=E2=80=99t work too well in an environment where the tooling= is fluid, and in fact the format that the tooling works from and its int= erpretation is fluid as well. >=20 > If the tooling is that fluid (is it for HTML?), that shows that we > shouldn't have started the switch yet... But we did, so that ship has sailed. =20 >> When the tooling has a bug (read: it uses the interpretation of 2020-0= 4-02), and the XML is adapted to work around this bug, and the tooling is= then fixed (read: it now uses the interpretation of 2020-04-03), the new= output may be erroneous. >=20 > The (canonical, published) XML never ever should be adjusted to work > around a bug. Is this happening? =20 It should be happening. For the period during which v3 is in= flux, we should indeed update already-published v3 XML files, not consta= ntly, but on some sort of snapshot or checkpoint basis. Obviously we must= not update the substantive content, and we should have an audit trail, b= ut only by doing such updates can we have a reasonable situation at the e= nd. If there isn't a v3.n sub-version number in the XML files today, there ce= rtainly should be. Brian From nobody Fri Apr 3 13:36:40 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7959D3A0ADB for ; Fri, 3 Apr 2020 13:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1RINTS1ScXN for ; Fri, 3 Apr 2020 13:36:33 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4C53A0ABA for ; Fri, 3 Apr 2020 13:36:32 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48vBYC0Xzxzyvx; Fri, 3 Apr 2020 22:36:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <46ebaffc-9c69-f5ce-8155-bd7dda3cde7c@gmail.com> Date: Fri, 3 Apr 2020 22:36:30 +0200 Cc: Julian Reschke , "John R. Levine" , rfced-future@iab.org, Larry Masinter , "Andrew G. Malis" X-Mao-Original-Outgoing-Id: 607638990.470348-ae9f276134b848e0558de5b8b4553ccd Content-Transfer-Encoding: quoted-printable Message-Id: <94ADF208-3965-4E20-8BAF-EC497E323C51@tzi.org> References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> <3b1df23c-d1e4-46f9-d7d4-6fac978be8d3@gmx.de> <46ebaffc-9c69-f5ce-8155-bd7dda3cde7c@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 20:36:39 -0000 On 2020-04-03, at 22:32, Brian E Carpenter = wrote: >=20 > It should be happening. Yes! > For the period during which v3 is in flux, we should indeed update s/update/up-convert/ > already-published v3 XML files, not constantly, but on some sort of = snapshot or checkpoint basis.=20 Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 3 13:46:27 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36D13A0ADE for ; Fri, 3 Apr 2020 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj4XQ--1u2PX for ; Fri, 3 Apr 2020 13:46:19 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2C93A0A98 for ; Fri, 3 Apr 2020 13:46:19 -0700 (PDT) Received: (qmail 83042 invoked from network); 3 Apr 2020 20:46:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14460.5e87a099.k2004; i=johnl-iecc.com@submit.iecc.com; bh=+m0X/GL6xtcjQRuf/bKAaZ7CPFLKpvcsa+rdxhvVtiM=; b=D35nYHzt0AYJNkjBw7tsmZHDOKyeuzpLNfy/vjXCO62+OBzujDPF/cW8g6JSNCHAbDq2mHAClvIlDHSvxuoJ6LUSrXDDPEokSKv/+iqKmEJKV6973R8Ra6mqbZTE1qYBYliMuI9W0/tBvkdTBNnNhpNySx4C3Agq7040knNnZjDwaJAUkI46pnHNDn4LlRnlfoiy2V/jb6eZgP6c7hWKSeu5aWswAO10/qgkv88TgalEyvq9IDAelQ8b/WQ1MUhc Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 03 Apr 2020 20:46:17 -0000 Date: 3 Apr 2020 16:46:17 -0400 Message-ID: From: "John R. Levine" To: "Brian E Carpenter" , "Julian Reschke" Cc: rfced-future@iab.org In-Reply-To: <46ebaffc-9c69-f5ce-8155-bd7dda3cde7c@gmail.com> References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> <3b1df23c-d1e4-46f9-d7d4-6fac978be8d3@gmx.de> <46ebaffc-9c69-f5ce-8155-bd7dda3cde7c@gmail.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Apr 2020 20:46:25 -0000 >> The (canonical, published) XML never ever should be adjusted to work >> around a bug. Is this happening? I sure hope not. The RPC now has a document state TI that means that a document is waiting for tools to be fixed. That's happened a few times but so far the fixes have been simple enough that Henrik has been able to do them without unduly delaying the documents. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 3 20:23:18 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4FF3A08DC for ; Fri, 3 Apr 2020 20:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5-c3YIdOp65 for ; Fri, 3 Apr 2020 20:23:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1ABD3A08CF for ; Fri, 3 Apr 2020 20:23:13 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jKZOq-000C0T-3x; Fri, 03 Apr 2020 23:23:12 -0400 Date: Fri, 03 Apr 2020 23:23:05 -0400 From: John C Klensin To: Russ Housley cc: rfced-future@iab.org Message-ID: <1516CEFE987AC5BC0037F452@PSB> In-Reply-To: References: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net> <75FEFDC1BB902A9091739F47@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Apr 2020 03:23:17 -0000 --On Thursday, April 2, 2020 20:11 -0400 Russ Housley wrote: > John: > > Just responding to the second point: > >> Second, my concern (and, if I understood Christian's note, at >> least part of his) is that we have too many documents that get >> to the end of community review during Last Call and then >> change enough via IESG action or RPC efforts to be only barely >> recognizable as the same document. The changes may be >> substantive ones that the IESG considers minor or the writing >> styles or skills in writing technical English of some authors >> may have required major rewrites of paragraphs or sections by >> the RPC. I've rarely seen either cause harm, but the fact >> remains that the community is signing off on one document and >> then a different document is being published. At least in >> principle, that is a risk and maybe se should be thinking >> about it and whether adjustments are in order (with the >> understanding that reordering the editing and approval >> processes is not the only option). > > In the IETF, WG chairs, review teams, and ADs all have a role > in turning back documents that are so poorly written that they > need more that just copy editing. I know that I have tried to > do this in my working groups. It is hard to tell someone that > their document needs mush more work to be ready to progress, > but that is the right place to apply the judgement. Yes. And that also means being much more careful about saying "the RFC Editor will sort that out" -- something we heard Heather comment on or complain about several times. There are many things about which that is appropriate and most of them really are copy editing (capitalization, commas, grammar,...), but many things that may not be. > The RFC Editor ought to be able to tell the approving stream > that the document is not ready for copy editing as well. I > understand that the RFC Production Center is very reluctant to > do that. Yes. In part I assume because they have been treated badly when they have tried to do that in the past (I knew several instances, long ago, in which that did occur and assume that is part of what made them reluctant). I think this is something else we should come back to after we have a new RSE in place and perhaps when we are far enough into the xml2rfc v3 transition to have a clearer picture of levels of effort but I wonder if things could be improved by asking the RPC to make a very quick, triage-level, pass through a document at about the time the IESG starts a Last Call. The intention would not be to start editing but rather to be able to give the IESG quick advice -- advice for which the RPC would not be taken to task if they got wrong -- about how much work and of what sorts the document would need if it was approved in that form. I could see the IESG, assisted by that sort of report, tentatively approving a document after Last Call but returning it to a WG for sorting out the explanation of technical editorial details to the point that the intent of the specification would be clear to all readers. That wouldn't eliminate the need for the RPC to do a copy editing job (and a lightweight technical editing one), but it might well eliminate many or most of the "did you really intend this to mean X or Y" discussions at AUTH48 with all of the risks such questions imply. best, john From nobody Sat Apr 4 08:55:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0983A0F33 for ; Sat, 4 Apr 2020 08:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 iTluHrn3-sEa for ; Sat, 4 Apr 2020 08:55:22 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DE33A0F2F for ; Sat, 4 Apr 2020 08:55:22 -0700 (PDT) Received: from xse100.mail2web.com ([66.113.196.100] helo=xse.mail2web.com) by mx18.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jKl8e-0006RM-2n for rfced-future@iab.org; Sat, 04 Apr 2020 17:55:20 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 48vhG802NYz1s9b for ; Sat, 4 Apr 2020 08:55:12 -0700 (PDT) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jKl8Z-0000ij-SF for rfced-future@iab.org; Sat, 04 Apr 2020 08:55:11 -0700 Received: (qmail 7059 invoked from network); 4 Apr 2020 15:55:11 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.77]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Apr 2020 15:55:11 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-5C7A0EC2-CAD1-4C41-BA2D-6949D6318FE1 Content-Transfer-Encoding: 7bit From: Christian Huitema Mime-Version: 1.0 (1.0) Date: Sat, 4 Apr 2020 08:55:10 -0700 Message-Id: References: <49D8A42C-B203-43B2-9E1C-CEBE6E139DA1@vigilsec.com> Cc: John C Klensin , rfced-future@iab.org In-Reply-To: <49D8A42C-B203-43B2-9E1C-CEBE6E139DA1@vigilsec.com> To: Russ Housley X-Mailer: iPhone Mail (17D50) X-Originating-IP: 66.113.196.100 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.100/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.100/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0VxB0mWeGZk2wSOLROvd+japSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4iy6iUVRZYSMQyXN4ThauYLQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEVy1fjNZA0UnjqgajXwVOqw7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsezUTEAumaS8EPUiWeF3NFNfXt7BluAMaAukv11AovGyYgTFrmMH3G/vAWBmvi+KwILo Oo70iqAlsD2ZyQe0MRcoXn2AACkl3R04y1L/ttkpHwRRiI4FYjmNWKK4C97xdQjTPpuFqUUQz+mM 8JAD4ECWn6f4sEyC1hUSXYAmHvoRFxzd1TBXbJNvBC1nKO3+wSPn51js98kG4vJNKMKAQRgrPPiM Yx8a9Z+eOSy/2ANeR1FfEoXm0/FPF8PR0w363lmnlK6rkS0bZpAfglustONXPAxAF1L8Ie0o/U0y NFk8uXR6mMZiP8hyi9JD/oRrQtQcSyQwpbsYuxSOGTH6k0lfJmkP8s1HCfLKOW1F2ohPJ/AFMvX7 q8M4x6bP/gjzw0OgghQYwZVLClIproNi1WM01Bh4x4h9uYrmdPlyGg3lun80sIBTfGesZu6FzlJ8 P6r2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Apr 2020 15:55:24 -0000 --Apple-Mail-5C7A0EC2-CAD1-4C41-BA2D-6949D6318FE1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable -- Christian Huitema=20 > On Apr 3, 2020, at 1:06 PM, Russ Housley wrote: >=20 >> How is "your document needs mush more work to be ready to progress" any d= ifferent from "I found five attacks that your security considerations do not= address" ? >>=20 >=20 > The first is a statement about the clarity of the writing in the document.= The second is a statement about the technical quality of the document. I d= o not expect the RFC Editor to make the second assessment. I think people elaborated on that thread, but it boils down to being able to= push back on documents that are in a bad shape and would require too much e= diting work. Of course this will create some push back from authors or from t= he IESG. I think the reformed process should be explicit about how to handle= such push back. -- Christian Huitema=20= --Apple-Mail-5C7A0EC2-CAD1-4C41-BA2D-6949D6318FE1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

-- Christian Huitema 

On Apr 3, 2020, at 1:06 PM, Russ Housley <housley@vigilsec.com> wrote:

How is "your document needs mush more work to be ready to progress" any different from "I found five attacks that your security considerations do not address" ?


The first is a statement about the clarity of the writing in the document.  The second is a statement about the technical quality of the document.  I do not expect the RFC Editor to make the second assessment.

I think people elaborated on that thread, but it boils down to being able to push back on documents that are in a bad shape and would require too much editing work. Of course this will create some push back from authors or from the IESG. I think the reformed process should be explicit about how to handle such push back.

-- Christian Huitema 
--Apple-Mail-5C7A0EC2-CAD1-4C41-BA2D-6949D6318FE1-- From nobody Sat Apr 4 09:57:44 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374B23A1038 for ; Sat, 4 Apr 2020 09:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIq-nwmrYR8M for ; Sat, 4 Apr 2020 09:57:38 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EEA3A103A for ; Sat, 4 Apr 2020 09:57:38 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jKm6q-000End-UX; Sat, 04 Apr 2020 12:57:28 -0400 Date: Sat, 04 Apr 2020 12:57:23 -0400 From: John C Klensin To: Brian E Carpenter , Julian Reschke cc: Carsten Bormann , "John R. Levine" , rfced-future@iab.org, Larry Masinter , "Andrew G. Malis" Message-ID: <75931C805FEF3FE1B51C5A0D@PSB> In-Reply-To: <46ebaffc-9c69-f5ce-8155-bd7dda3cde7c@gmail.com> References: <0ac801d6089c$c36031b0$4a209510$@acm.org> <20200402195947.D569E16EE8CE@ary.qy> <009601d60964$2648e7a0$72dab6e0$@acm.org> <1533669f-6891-e50a-be08-b5293fc5cbbf@gmx.de> <3b1df23c-d1e4-46f9-d7d4-6fac978be8d3@gmx.de> <46ebaffc-9c69-f5ce-8155-bd7dda3cde7c@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] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Apr 2020 16:57:42 -0000 --On Saturday, April 4, 2020 09:32 +1300 Brian E Carpenter wrote: > Julian, > On 03-Apr-20 19:59, Julian Reschke wrote: >> On 03.04.2020 07:25, Carsten Bormann wrote: >>> On 2020-04-03, at 06:46, Julian Reschke >>> wrote: >>>> >>>> On 03.04.2020 05:07, John R. Levine wrote: >>>>>> During the AUTH48 period, whoever is reviewing the >>>>>> document needs to check ALL of the formats, especially >>>>>> around examples and figures and any non-ascii text. >>>>> >>>>> Currently the RPC people are proofreading all of the >>>>> output formats, which takes a lot of work. I hope authors >>>>> are also, but that's up to them. ... >>>> >>>> That sounds like a bug in the process to me. And it won't >>>> scale if we add ePub. >>>> >>>> There should be *one* format that is to be proofread, HTML. >>>> If the other output formats have an issue, that's a tooling >>>> problem that needs to be solved, and the other formats can >>>> be regenerated. >>> >>> This doesn't work too well in an environment where the >>> tooling is fluid, and in fact the format that the tooling >>> works from and its interpretation is fluid as well. >> >> If the tooling is that fluid (is it for HTML?), that shows >> that we shouldn't have started the switch yet... > > But we did, so that ship has sailed. > >>> When the tooling has a bug (read: it uses the interpretation >>> of 2020-04-02), and the XML is adapted to work around this >>> bug, and the tooling is then fixed (read: it now uses the >>> interpretation of 2020-04-03), the new output may be >>> erroneous. >> >> The (canonical, published) XML never ever should be adjusted >> to work around a bug. Is this happening? > > It should be happening. For the period during > which v3 is in flux, we should indeed update already-published > v3 XML files, not constantly, but on some sort of snapshot or > checkpoint basis. Obviously we must not update the substantive > content, and we should have an audit trail, but only by doing > such updates can we have a reasonable situation at the end. > > If there isn't a v3.n sub-version number in the XML files > today, there certainly should be. Agreed. A bad solution but, given that we made the switch while, at least retrospectively, in experimental mode, almost certainly less bad than others. I know it is widely believed that HTML is so important in the world and so widely used that it will survive in its current form for centuries if not millennia, however, it is almost certainly the least stable of the three output forms for at least two reasons. First, in the circa 30 years since it appeared, the community has already gone through five versions and is working on a sixth (or, if you prefer, tuning the 5th). Even more extremely, normally-sensible people are claiming that HTML has outlived its usefulness and should be replaced by something they (or their colleagues) have invented. AFAICT, none of those have gotten significant traction for more than specific applications, but there is certainly no way to guarantee that state will continue forever, i.e., that nothing will come along that is actually sufficiently better that it becomes the norm and HTML a historical legacy and artifact. It seems hard to be certain that whatever we do now will be easily and compatibly rendered by whatever passes for a browser in even 75 or 100 years. The biggest advantage of using HTML as one of the standard output formats -- that it can be interpreted and rendered passably well on a variety of different devices with appropriate style sheets -- is also a risk if we consider it the "real" format (e.g., the only one that is subject to final ("AUTH48" or whatever we call it) review, at last as long as we care at all about presentation. It is a specification format, not a presentation format and, even as a specification format, it is not self-contained, depending instead on style sheets and local conventions to precise specify presentation. If one is working with a document, trying to create new versions, etc., XML as the official/archival form is probably ok and most of us might prefer to work with HTML or even plain text. But, if one is concerned about archival availability of a presentation format, it is either the PDF/A for which proofreading and layout-checking is important or we need to be checking all three formats to be sure they yield plausible results. From nobody Sat Apr 4 10:52:10 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9545B3A112B for ; Sat, 4 Apr 2020 10:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCKJsdsJ56hj for ; Sat, 4 Apr 2020 10:52:05 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940DE3A112A for ; Sat, 4 Apr 2020 10:52:05 -0700 (PDT) Received: (qmail 43605 invoked from network); 4 Apr 2020 17:52:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a9f8.5e88c943.k2004; bh=U9fhO2yHwXpxEvL49VAL52XKejESqiZmxWhIeX+0ARQ=; b=EIoi+vAX2RiTB5nTJasLNKruJS93M6OvkaaRMXlh7GfyI294T4aaWT3Wwh7FgnvPLEi6pMcOlFWEV2SBP3Kl4zWu49GQiroZfCs++Ro+klDeJID+6BOvKd32xD9NucmjJ0bwzuzm4dc2kpG88tpHYEtf0NgNY1vYDhCPiUpc3nNdNwygk0ylKJj128JOrTisQHHK6FqfbSwiEcNi5HW7RfDnBdM8OqzOEt9rbkVAcbFzQ6G74E+dc0vHuI3A5t6p Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 04 Apr 2020 17:52:03 -0000 Received: by ary.qy (Postfix, from userid 501) id 6680C1708A35; Sat, 4 Apr 2020 13:52:02 -0400 (EDT) Date: 4 Apr 2020 13:52:02 -0400 Message-Id: <20200404175203.6680C1708A35@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: john-ietf@jck.com In-Reply-To: <75931C805FEF3FE1B51C5A0D@PSB> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Apr 2020 17:52:08 -0000 In article <75931C805FEF3FE1B51C5A0D@PSB> you write: >> If there isn't a v3.n sub-version number in the XML files >> today, there certainly should be. > >Agreed. A bad solution but, given that we made the switch >while, at least retrospectively, in experimental mode, almost >certainly less bad than others. My preference would be once we've defined the final XML vocabulary, go back and adjust the XML (not the text) in the published RFCs to match. Why force people for the next 50 years to live with our goofs? The changes won't be very large since the changes since v3 are still pretty minor. FWIW all the changes so far are backward compatible so all published RFCs are valid with the current version. The changes to the XML would be if we decide to back out or modify some of the changs to the spec. > >I know it is widely believed that HTML is so important in the >world and so widely used that it will survive in its current >form for centuries if not millennia, however, it is almost >certainly the least stable of the three output forms for at >least two reasons. ... Actually, I agree. I am sure there will be something called HTML for many decades (sort of like there's something called Fortran) but it won't be all that much like what we have now. That's why the HTML is an output format, not canonical. On the other hand, HTML is expressive enough that if we can get a good quality translation of the XML into whatever HTML is now, that should be the main place for proofreading. R's, John From nobody Sat Apr 4 16:10:27 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E283A0E64 for ; Sat, 4 Apr 2020 16:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQ56lS1cnd8r for ; Sat, 4 Apr 2020 16:10:24 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869713A0E66 for ; Sat, 4 Apr 2020 16:10:24 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id v23so2684229pfm.1 for ; Sat, 04 Apr 2020 16:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tVNpP8VAO81wIRniSnFYPC73sVv7u5je3eejguEk51Q=; b=Wj6LUHeObmrzdGEuVRDVIunVi0GK9LBWvqrUEi5uhicaPRKZMfPhD6IEBI1R+6PzLE WE9CwCG4l+IXQhUc3iPjJH1rCIZVe5yQH/FF74I/WHF9KXp9fFltWvJ5f+62XPRYHXv2 03jBdNJQIb95mhl/GB1cbR/25YPLPZwVNisio8RqVAJYxw3v5wJWbnlBpRfZFAYA5TDY 3eGSBCX0hUqsuB73TuyOIq1nj76xnJV/iN6YKHOZj8SJQ522rktHnoCKW0Z4MmEh0Nil QPkkrLQqqb/iqVdcxpdpGvKnM5kQcyBImZfM3R+X63Vnx1Th5qELLqriwSqGTPjq3kUc Sa+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=tVNpP8VAO81wIRniSnFYPC73sVv7u5je3eejguEk51Q=; b=TZ+xblltmMe+kQzLHJ4vAh54c0ArKyAutmmJfUZTuBmoJCRUe57/W64iEYoBDVKR48 i4J8anQ4kUtb4cuFvHSyLHYG1apeSaD3mi9FBXjxtmIq+MW5h6o9K3ktwnfXWqPwCcRA FRCtnQjjCXB3kkzJCGFXlIP8criCDSUwuP49zQSw2DaixMmRFn9S5vXha0/rsjQZRPvG JgMnYECISjxA2Vv3pdPf1awZYn7D/PJ6JDXq9vqa2vw6LtNB+CnnNw+jYGl1jPYUfHq5 gBGEvjt3W5QAWrGRELE4p1p28YUr3W8xPXeSYquNwntGVduOF85qVEm6J9Tej5DqboBD /ueQ== X-Gm-Message-State: AGi0PuZSchPE3QTQu3jAjofSZCtIsIBAFKpoe0h0rmBx3u2BQeTUiEXi OkVkPn5dfsWGW9Rc+ZTLIfRTGXb7 X-Google-Smtp-Source: APiQypJbLPbvTslc3Cp8/xVma4UrWj7R+xWzPEXC0YQibiw8quceB4iR2du2xFqEh3YlJhwoYjwk1g== X-Received: by 2002:a65:498c:: with SMTP id r12mr14673727pgs.14.1586041823250; Sat, 04 Apr 2020 16:10:23 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id g30sm7662536pgn.40.2020.04.04.16.10.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Apr 2020 16:10:22 -0700 (PDT) To: Eliot Lear , rfced-future@iab.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <2d84ee1d-c1d2-e0c6-37cc-e237cc9b6381@gmail.com> Date: Sun, 5 Apr 2020 11:10:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Rfced-future] Suggested key point [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Apr 2020 23:10:26 -0000 Hi Eliot, In your notes I see "What happens to the series if the IETF disappears?" We could also ask: What happens to the IETF if the series disappears? Regards Brian On 03-Apr-20 09:26, Eliot Lear wrote: > If anyone wants to see the notes I=E2=80=99m taking, and those notes ma= y be entirely too abbreviated or just plain wrong, you can see them=C2=A0= here . =C2=A0I=E2=80=99m a few hours behind at the moment.= >=20 From nobody Sat Apr 4 16:12:20 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3C73A0E67 for ; Sat, 4 Apr 2020 16:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65YpiI6MdBEZ for ; Sat, 4 Apr 2020 16:12:15 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC723A0E6D for ; Sat, 4 Apr 2020 16:12:15 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id w9so4803736pjh.1 for ; Sat, 04 Apr 2020 16:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=UbwkyiN8tDd5afFCEImSNku/dE3ivYbEsZf43ZcS6ek=; b=j1UPrfHiHFgWaX7HGE2ya2R4+4Ubd/a2efFIUeim0mMvmiueF0rAojle/sF+zYCdQI py95W/twUiFfGf3veXukwBDJidWAx/QiTh1kXnNGeXqgRk2wABxzYhSoxMmVlLlUqrkd N08+68n79K6Glj5ClAKFN0kaKZetL2qbmy2S882fiWRGibr2pdeKyjO3m7RAxaNi8Osh ctl+xyoqcXI59Fgz6DIRZrRmaN9jYY+byBbCx5fUHFfPxt4jlk1jJuYK5iZ+XNTMWxr6 5viOKHuscsEt5ReTg8DFz4ppHJQypRAuWVJCQzJ7Ah6kkThUtWqtKWZwx3P0NKXtRtWr yvng== 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=UbwkyiN8tDd5afFCEImSNku/dE3ivYbEsZf43ZcS6ek=; b=QAHp+A531+klOdKk7bnbdtvdVBNT4XUw+2iggDXO4tGibMV44wzg/NgW6PdbHclPWJ sT2eQ5lKPhRsoc6GKPYi6QZ2TPjyg3FsAHc0zDyFPSNb306Mz4PNvX6uyGg4cElVtWVu zaAg0CCwoa3cKHwN73ph8jLpdoxIsEjHnqlWqt3kVedL27+GFFV/hB2XB+2ooa2pZNkH xqRYCMgcB+XO2/+BxWbQmAXNsBn3mXVSEzQEWrJF3scYkBxBm8jpviK2iR1vPDE2f4Rj v1j9nh+YGZILLyhertQEE41qyxu017BI934AYqyjbm0z1M7E6Bp244v7LTRIe+f1PVkL iCDg== X-Gm-Message-State: AGi0PuZ1fCg7wrnMKY0jX1bgEZnerpI30WmkuJcW7yXhxSp8fAQD3XWx zKxLhrJiaMUFCyOhZNlI16oxRQwX X-Google-Smtp-Source: APiQypINrkPMInzUo0WV6x9YsM/IgTCTbgYdyxG0kons07a6mlf6ogdeDaMPwxyIcN0wSzHOpZYf/Q== X-Received: by 2002:a17:902:aa49:: with SMTP id c9mr14627135plr.145.1586041934307; Sat, 04 Apr 2020 16:12:14 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id k5sm7746417pgl.3.2020.04.04.16.12.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Apr 2020 16:12:13 -0700 (PDT) To: Eliot Lear , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> Date: Sun, 5 Apr 2020 11:12:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Apr 2020 23:12:18 -0000 Another point that I think has been mentioned: What is the community of i= nterest for this discussion? More than IETF+IRTF, but how much more? Can = we even define it? Regards Brian On 03-Apr-20 09:26, Eliot Lear wrote: > If anyone wants to see the notes I=E2=80=99m taking, and those notes ma= y be entirely too abbreviated or just plain wrong, you can see them=C2=A0= here . =C2=A0I=E2=80=99m a few hours behind at the moment.= >=20 From nobody Sat Apr 4 18:02:30 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7933A0FDA for ; Sat, 4 Apr 2020 18:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyFg2JzqIv7x for ; Sat, 4 Apr 2020 18:02:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD503A0FD0 for ; Sat, 4 Apr 2020 18:02:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 38A47BE20; Sun, 5 Apr 2020 02:02:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ94j7zh2u3m; Sun, 5 Apr 2020 02:02:20 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2025CBDCF; Sun, 5 Apr 2020 02:02:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1586048540; bh=R45GCWw+SRuWf9BfDws+TICtV6KW+EgFctAeHfLozBo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=r99xyoj+2S2WpczOGjZZIqIGSCIpcvrJqtImWkE75CzmykBpfK8IQ9u78VCyNsaX1 D9+6u0ARTzQT0llMg0UGn3QvF9BvJHgQaMertq1ye1z4FSPFWwud51nmmYtXxgWRus HnzN/b/YPA1+QPwt4oSn+WY5bUBna+E0IjkAtSeU= To: Brian E Carpenter , Eliot Lear , rfced-future@iab.org References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sun, 5 Apr 2020 02:02:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CGJnUDM6Zo6d13rg3EWGGlEKyRpYg9PIV" Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 01:02:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CGJnUDM6Zo6d13rg3EWGGlEKyRpYg9PIV Content-Type: multipart/mixed; boundary="9iRD7Z51G9eXJqIStdh9gwEpGqxyw9R5Y"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter , Eliot Lear , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> In-Reply-To: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> --9iRD7Z51G9eXJqIStdh9gwEpGqxyw9R5Y Content-Type: multipart/mixed; boundary="------------A519750B706734DD32D3C908" Content-Language: en-US This is a multi-part message in MIME format. --------------A519750B706734DD32D3C908 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/04/2020 00:12, Brian E Carpenter wrote: > Another point that I think has been mentioned: What is the community > of interest for this discussion? More than IETF+IRTF, but how much > more? Can we even define it? So I know that others (who I respect) disagree with me, but I'm always puzzled as to why this is a puzzle: the community of interest for RFCs seems to me like it has to be the set of people who read RFCs. The community of interest for this exercise then has to be the subset of that set of people who decide to involve themselves actively, here on this list. That does mean those of us involved, esp. those of us who think we'd benefit from broader participation, have an onus on us to try reach out to other RFC readers and encourage them to be more involved, but I honestly don't see that any of that is complicated, nor that there's any other alternative. S. >=20 > Regards Brian >=20 > On 03-Apr-20 09:26, Eliot Lear wrote: >> If anyone wants to see the notes I=E2=80=99m taking, and those notes m= ay be >> entirely too abbreviated or just plain wrong, you can see them here >> . >> I=E2=80=99m a few hours behind at the moment. >>=20 >=20 --------------A519750B706734DD32D3C908 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------A519750B706734DD32D3C908-- --9iRD7Z51G9eXJqIStdh9gwEpGqxyw9R5Y-- --CGJnUDM6Zo6d13rg3EWGGlEKyRpYg9PIV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6JLhsACgkQWrL68XsX K+rGTRAAsVT/nCb2DmPy8vZbI8YrrJL5loQM5BYo/qc4hXTn9Yjq+ovOLHq/EFde 9Rxsd7X58H76PDJWm38sfOiB0Vq/rMHk6WECCWWBxNTr0fIJHYYf2BCPxuQkqxX/ QxVr6ZNjE/qiaulFyiGe3CUv0GoJvRX2FV9Kg4OhbGErga2WdO2w7X/M+bEvkEdJ fw7YyV6+MTkb3Kc0LP3PvBCebc9dHZGki/qz8zonPYpGwUUwMzUXZFvzxYKYiWA6 LqnQqzC0z8yykW+A+1ycZgaNBt3bVr5+itWvMmcpcW4KT4lK7rspT4UBkp9rVtbl FA/wqO/odmTw0OIg2+MR09i0OrrinWYN15Ru9HsNH5rCjs1ao3ScJuDWLKvG4Vsd 8KpW49A9KfH5i68fdASPhj3Hn6/BDdZ0vimw8ZsMVNa6WlSUJuFQaamoZ2yYhDfQ RUbPnZlN1QRpMQv4pOChHgQgiIY+zqnED9oEjA6Gp9NdH/gSqwn3qk+YTA6tKAEz 607My0OKM7xi5Xl7cnu9x+9invwOUf1gjKGMuCnHCIGmHBPhwGGibVJti/N7wcDt enOUib0EeapM3C4HvUV1Q/MTlke6B+c0HD3x0N3bWgdKfAr1PdBZSGmed99cp7h7 WeBINHy0vnYo6RTzq29NszXb4HJDS1TamCsH5A1DFIKxsnjlb0o= =oqL4 -----END PGP SIGNATURE----- --CGJnUDM6Zo6d13rg3EWGGlEKyRpYg9PIV-- From nobody Sat Apr 4 18:44:29 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C533A103C for ; Sat, 4 Apr 2020 18:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PsMtTVoR2eM for ; Sat, 4 Apr 2020 18:44:25 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B3E3A103D for ; Sat, 4 Apr 2020 18:44:25 -0700 (PDT) Received: (qmail 21622 invoked from network); 5 Apr 2020 01:44:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5474.5e8937f7.k2004; bh=STVIbbQb+1Wdb7SOmGaWu1qKccrkdN3H1+CL6qT3tgM=; b=dSI1MRotOPg7W+DrTK8VuKCn1iTJ2kxMa9HhwdNbRxuaoDi3DxtAFihWbImlethZ7lcS3mLrouQb5oQ469kyyWNrKACsIY1EFT0OVvIFHEXWqb2oRn60cLsfExK7YbxLPNHun6z20d1zxo767NDALS3wtlVumVe+9K5nzIbjIMsf5h0UtmgPIt23VeiWXTMTsuOn/d6FuwM2+7KYC9BLs1Tp1BPQtued3NTjEb1CIyrDuBwS98GZevWcM1D+i3Tm Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 05 Apr 2020 01:44:23 -0000 Received: by ary.qy (Postfix, from userid 501) id 835EE170C7A2; Sat, 4 Apr 2020 21:44:23 -0400 (EDT) Date: 4 Apr 2020 21:44:23 -0400 Message-Id: <20200405014423.835EE170C7A2@ary.qy> From: "John Levine" To: rfced-future@iab.org In-Reply-To: <2d84ee1d-c1d2-e0c6-37cc-e237cc9b6381@gmail.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Suggested key point [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 01:44:28 -0000 In article <2d84ee1d-c1d2-e0c6-37cc-e237cc9b6381@gmail.com> you write: >Hi Eliot, > >In your notes I see "What happens to the series if the IETF disappears?" > >We could also ask: What happens to the IETF if the series disappears? In view of the way the funding works, I think the former question is a lot more interesting. R's, John From nobody Sat Apr 4 18:53:38 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08423A1058 for ; Sat, 4 Apr 2020 18:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEvO0qTsQhjE for ; Sat, 4 Apr 2020 18:53:31 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B12A3A1057 for ; Sat, 4 Apr 2020 18:53:31 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id h11so4433830plr.11 for ; Sat, 04 Apr 2020 18:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=7XMj9lZi6TgYjy/BkckZ3KwNLUOnH2JXz6UGo3NDRo0=; b=jj6XgRO9wHfTzjAwydQnqYM26eLbLDIUJqLC1ulvZVXrr8MFOibNABH8lHjrHUwx4C 0Ogc9vTkY8NRAyJBGN9/Xsuv/0aGt+1Ypg6WEz5zpEECzQAS/P/T21/g4LQtq+zeHbgm XpvnzmbE03oEZNRESDYBwMN7hbQVs0RdLHc+ekF/8rTI48/qPlXJxZzwG7lnqqvNT3Kz iZr3rmdnFXUo/W8WVF2wpngT5INK7mMKJvuLVFtu5Tx57hNrbrandUxJB1N3iCnGjjyD +AUp6cRywSEPHUAmCiaD8zWtjBgdfy1sN3HZ9ud7KOR9VAuQPeM//NCQiLiTTvv5oeuO 73Ug== 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=7XMj9lZi6TgYjy/BkckZ3KwNLUOnH2JXz6UGo3NDRo0=; b=Sj71hStJpUEt2SLDGdXSc/vVmTbT0dtxZ7f4CqO5GrzpTHnR3P+ZhrkEcm8bY1gtY5 jPMVyy2K1Eb622Tpv9Y8dHuE6ujccDmuEdvs00xzhEtqwhcRWTaaM/dsLHnWdfDL6OZc WC0GRYbbtbkuocJ6bz5eiLaYxCii4znTww+2TCPANx8qYBM9swQy7qomKOrtSSUbkRz5 OHPcADAT4TeZeQyM4QvYYJqQVL6BM/ylzDbIMuWbqGCsS+ylbGH+smyCL0F+L2VWOXo3 qLOyG1gULuxErV/7epWphTRPVIxVAg7hC0bQA7/uWaoIfTYa3wF8OVRNIIhpIYdPyLXx KIlA== X-Gm-Message-State: AGi0PuZLZVcGpNbMWy0DTWqZLSKCv0OVsQ76jGF5cHLN3013TB1tW16H ccAPz3hSk2TQ55eDAj9gvvE8iXOo X-Google-Smtp-Source: APiQypLoVfxIfHO5G65bhHI0dd5XnRPaK/mth01kVlnDoitmZZxI7e7ck8xODQ2A/V/scfL8jhjmmg== X-Received: by 2002:a17:902:b7cb:: with SMTP id v11mr15215614plz.307.1586051610125; Sat, 04 Apr 2020 18:53:30 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id f129sm8573113pfb.190.2020.04.04.18.53.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Apr 2020 18:53:29 -0700 (PDT) To: John Levine , rfced-future@iab.org References: <20200405014423.835EE170C7A2@ary.qy> From: Brian E Carpenter Message-ID: <9d69766d-5998-a5ed-4520-ab6f0589a209@gmail.com> Date: Sun, 5 Apr 2020 13:53:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200405014423.835EE170C7A2@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Suggested key point [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 01:53:36 -0000 On 05-Apr-20 13:44, John Levine wrote: > In article <2d84ee1d-c1d2-e0c6-37cc-e237cc9b6381@gmail.com> you write: >> Hi Eliot, >> >> In your notes I see "What happens to the series if the IETF disappears?" >> >> We could also ask: What happens to the IETF if the series disappears? > > In view of the way the funding works, I think the former question is a > lot more interesting. Probably, but if we're doing any kind of scenario analysis, then istm that both questions arise. Brian From nobody Sat Apr 4 19:01:37 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F8D3A106F for ; Sat, 4 Apr 2020 19:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GujQStRK7U1X for ; Sat, 4 Apr 2020 19:01:32 -0700 (PDT) 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 D21F33A106E for ; Sat, 4 Apr 2020 19:01:32 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id c23so5711262pgj.3 for ; Sat, 04 Apr 2020 19:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ApxY3RaN4unq4hfXS7/PWxoSm0u5zJ6k87QP3duNMBU=; b=MjhM0HoO//Cvg5H0aEQG2Gmpbrpyjc7rEK3taS8+bHbAXnf7I9Xxy+tYUh0gF2ceyl /3rteOtY/hHWJCRHDZncojipvYz/veWKCrsdpWmDeu+aRGn+s8+p9RVM0Fxth44ZFqFk iN+Eg6milqPIhquyRABVKS4bT42117vNn1d0UDAKPuJC4B0HV79ir5LHwJbFB5cVLMI/ tcOL/xxpNmOGdh133eHD/6mUVe47s0uwq6xWwCR4aEEXzVwu2/ysA5Tlu1lBTgz0Q8xr M5cqJwCE+lcBjIAWVcS3ef6cMzKEi7O0DQaFTSNd/3D0MMxBaK3c04zPqqzrE4Wnp7FI UOyg== 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=ApxY3RaN4unq4hfXS7/PWxoSm0u5zJ6k87QP3duNMBU=; b=aFunWwRhUszkdMvcOIAvmCB7DwXUrJpXSc1zpDVxt0V54bo+TNVbhbPVYqeQHy5F0z 0H/chZ50l/LXMUIPQYztQkMhjwPj+NmDa5D63awxXkMB2ZG+Q+FWbmfsbjBOS9fjbDRj Q7Lmgkx6OXg6F6utbQtRwuiX5Rof7GALwdIo6g5y3b6L45OzS1vk0/UcUTPWkcXmdWrD NzfMHgkHlP0PfyO7RmQU88HtnuB68cdTD5fD6Q0RxWKJewbmHlMrRLZrZHqSQkbzgRkF 38y7YHB03cxg/IB9QFubKp55yb48GTEszdG/dx0KD+rEuPTCpFRF16DTBpr3iMKuj+n/ z7OA== X-Gm-Message-State: AGi0PuafNlHa157OKGK2Z6H9aOTCsBPpQ3dw0X5OA52sKAxPe8FbgiLw JznrU7FXH+9rV189NI9CpI6vv0ks X-Google-Smtp-Source: APiQypJqi986LHNfnDeVCXadXAMfn+YTiZzJgSzNE2lk5ecj3QqTQJhz2YJik1qMPoH3mc4SBL/JOA== X-Received: by 2002:a63:4d11:: with SMTP id a17mr14386500pgb.392.1586052091824; Sat, 04 Apr 2020 19:01:31 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id ml17sm8890604pjb.13.2020.04.04.19.01.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Apr 2020 19:01:31 -0700 (PDT) To: Stephen Farrell , Eliot Lear , rfced-future@iab.org References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> From: Brian E Carpenter Message-ID: <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> Date: Sun, 5 Apr 2020 14:01:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 02:01:35 -0000 > the > community of interest for RFCs seems to me like it has > to be the set of people who read RFCs. I tend to agree, and if we want the opinion of RFC consumers, not just producers, we might want to consider how to reach them. There are certainly a lot of people who read RFCs that are not on any of our regular mailing lists. (I see that the RFC Editor has=20 RSS and Atom feeds for recently published RFCs, but I have no idea how many people use them.) Regards Brian On 05-Apr-20 13:02, Stephen Farrell wrote: >=20 >=20 > On 05/04/2020 00:12, Brian E Carpenter wrote: >> Another point that I think has been mentioned: What is the community >> of interest for this discussion? More than IETF+IRTF, but how much >> more? Can we even define it? >=20 > So I know that others (who I respect) disagree with me, > but I'm always puzzled as to why this is a puzzle: the > community of interest for RFCs seems to me like it has > to be the set of people who read RFCs. >=20 > The community of interest for this exercise then has to > be the subset of that set of people who decide to involve > themselves actively, here on this list. >=20 > That does mean those of us involved, esp. those of us who > think we'd benefit from broader participation, have an onus > on us to try reach out to other RFC readers and encourage > them to be more involved, but I honestly don't see that any > of that is complicated, nor that there's any other > alternative. >=20 > S. >=20 >> >> Regards Brian >> >> On 03-Apr-20 09:26, Eliot Lear wrote: >>> If anyone wants to see the notes I=E2=80=99m taking, and those notes = may be >>> entirely too abbreviated or just plain wrong, you can see them here >>> . >>> I=E2=80=99m a few hours behind at the moment. >>> >> From nobody Sun Apr 5 01:53:43 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44F23A0774 for ; Sun, 5 Apr 2020 01:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NQlmhh8Kk03C for ; Sun, 5 Apr 2020 01:53:38 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789AC3A0770 for ; Sun, 5 Apr 2020 01:53:38 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0358rZdD025323 for ; Sun, 5 Apr 2020 09:53:35 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7EDE72203A for ; Sun, 5 Apr 2020 09:53:35 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 6A1FB22032 for ; Sun, 5 Apr 2020 09:53:35 +0100 (BST) Received: from LAPTOPK7AS653V ([87.113.132.10]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0358rYMU017131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 5 Apr 2020 09:53:35 +0100 Reply-To: From: "Adrian Farrel" To: References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> In-Reply-To: <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> Date: Sun, 5 Apr 2020 09:53:35 +0100 Organization: Old Dog Consulting Message-ID: <146601d60b27$b11e4770$135ad650$@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 Content-Language: en-gb Thread-Index: AQGSy5r9VV8/1Ja5QJZGtIRIKhBRtAIM6Gn2AhsPJKMBJB9ztajGVkxg X-Originating-IP: 87.113.132.10 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-25336.006 X-TM-AS-Result: No--15.019-10.0-31-10 X-imss-scan-details: No--15.019-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25336.006 X-TMASE-Result: 10--15.019000-10.000000 X-TMASE-MatchedRID: ZFzIhWOuIzvxIbpQ8BhdbPRUId35VCIeIVpGz/U+S0igDWpkqTKvoRef HreY/LygOPcZNwfu/ZAC2nO+QJ/Bp9+rie5PWDOXxTpJ3OQjb3ciC3XPiJxBK4+l4fZNSHjuVja sJdRYLom6FMWGdhLBChAgipU1AOLBlkiUy/sOvViQ1SnerYd+EBmyTBaqiJvctdz+6+kFPWj6bZ jBep1BMZjWd6qZUITtap6C+yAVJoRBJacAbR6CMRn0wrEetTLhqROwUsrCyCLB+Z+eWYE9bnLMR Sx26gTifdbpn+lW3eDtD1/racpwX7REGv26e1/EIiU9hx6W6ebBnL3AaGm9o09CJC/MWIZ4y6ig HaxqQh+uK2CoOfWQDpVjgp35aMGTW8sQMvPj/XyY4WcYQvQk43607foZgOWyUCgEErrUGFwinPT zXT8bNwiVp4brsgVHgRJ2G4R/OHFiiQUVNdWRf5kuHsgxfUFHCyj2gR0nEXWoLZarzrrPmWuDXe FkjZjCeP+LHF4CW2KlugrXm5IKcMNOo16VCf1yx/Stmah0FpZ9LQinZ4QefNQdB5NUNSsiU2Qzq 85WfnB0HSe131POnuJGF26G8SWypfzLa08EuFBTuRfgPSkGS3wR9W1GPZFCYEmDsT89v16bjkYS NfwJQhFpAvtbqHx2 X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 08:53:41 -0000 Thoughts: Should this program be advertised in some way on the rfc-editor.org web = pages? Should it be promoted through the IETF social media and press presences? But then, is the purpose of this program to bring in as many people as = possible at this early stage, or is it to have a focused sub-group of = interested parties to come up with a working proposal that can then be = debated more widely by the entire community of interested parties? I have only questions, not answers. Adrian -----Original Message----- From: Rfced-future On Behalf Of Brian E = Carpenter Sent: 05 April 2020 03:01 To: Stephen Farrell ; Eliot Lear = ; rfced-future@iab.org Subject: Re: [Rfced-future] Community [Re: Attempting to collect key = points] > the > community of interest for RFCs seems to me like it has > to be the set of people who read RFCs. I tend to agree, and if we want the opinion of RFC consumers, not just producers, we might want to consider how to reach them. There are certainly a lot of people who read RFCs that are not on any of our regular mailing lists. (I see that the RFC Editor has=20 RSS and Atom feeds for recently published RFCs, but I have no idea how many people use them.) Regards Brian On 05-Apr-20 13:02, Stephen Farrell wrote: >=20 >=20 > On 05/04/2020 00:12, Brian E Carpenter wrote: >> Another point that I think has been mentioned: What is the community >> of interest for this discussion? More than IETF+IRTF, but how much >> more? Can we even define it? >=20 > So I know that others (who I respect) disagree with me, > but I'm always puzzled as to why this is a puzzle: the > community of interest for RFCs seems to me like it has > to be the set of people who read RFCs. >=20 > The community of interest for this exercise then has to > be the subset of that set of people who decide to involve > themselves actively, here on this list. >=20 > That does mean those of us involved, esp. those of us who > think we'd benefit from broader participation, have an onus > on us to try reach out to other RFC readers and encourage > them to be more involved, but I honestly don't see that any > of that is complicated, nor that there's any other > alternative. >=20 > S. >=20 >> >> Regards Brian >> >> On 03-Apr-20 09:26, Eliot Lear wrote: >>> If anyone wants to see the notes I=E2=80=99m taking, and those notes = may be >>> entirely too abbreviated or just plain wrong, you can see them here >>> = . >>> I=E2=80=99m a few hours behind at the moment. >>> >> --=20 Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future From nobody Sun Apr 5 05:46:53 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8593A07F5 for ; Sun, 5 Apr 2020 05:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t8P3dA6MOA3 for ; Sun, 5 Apr 2020 05:46:49 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1805B3A07F4 for ; Sun, 5 Apr 2020 05:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=328; q=dns/txt; s=iport; t=1586090809; x=1587300409; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=T0OU78v7MOrGR6pPAkURfxP6F2JwCrHlzFbjT3MVRSQ=; b=kdsqC7M2sdYMTuNOFTsoucG5j8ruqa0bJYCJvS/v208exUr6U7egwQ7v /i/cMMqybJYtDYsQLLOa16e1qnkxTbigxAw7ObE8LYDbdDqEuTOqsqq4n DgX9xgON81PtghxO6JBy3Lc9KbNiQVl02mqTbiveZTzF2YvcaStjbsqKQ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAACs0ole/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWcHAQELAYNpIBIqhBuIIWCIC4luj16BewoBAQEMAQEvBAEBhEQ?= =?us-ascii?q?Cgmo0CQ4CAwEBCwEBBQEBAQIBBQRthWKFcAEBAQECASNWBQsLGAICJgICITY?= =?us-ascii?q?GE4MmgkwDDiCuNXWBMoVLgncNgiGBDioBjEyCAIE4HIJNPoIegjCDEjKCLAS?= =?us-ascii?q?wVkiCR4JekBGEOx2CPQGZRJsZjQuDOAIEBgUCFYFSOYFXMxoIGxU7KgGCPj4?= =?us-ascii?q?SGA2cZz8DMAKPKQEB?= X-IronPort-AV: E=Sophos;i="5.72,347,1580774400"; d="scan'208";a="25063293" 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; 05 Apr 2020 12:46:45 +0000 Received: from ams3-vpn-dhcp6253.cisco.com (ams3-vpn-dhcp6253.cisco.com [10.61.88.108]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 035CkiEj013557 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Apr 2020 12:46:45 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <2d84ee1d-c1d2-e0c6-37cc-e237cc9b6381@gmail.com> Date: Sun, 5 Apr 2020 14:46:44 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A383FF9-FC78-4B40-A30C-059E030601D7@cisco.com> References: <2d84ee1d-c1d2-e0c6-37cc-e237cc9b6381@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.88.108, ams3-vpn-dhcp6253.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Suggested key point [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 12:46:52 -0000 > On 5 Apr 2020, at 01:10, Brian E Carpenter = wrote: >=20 > Hi Eliot, >=20 > In your notes I see "What happens to the series if the IETF = disappears?" >=20 > We could also ask: What happens to the IETF if the series disappears? Now that=E2=80=99s on the list as well.=20 Eliot From nobody Sun Apr 5 05:53:01 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4123A080E for ; Sun, 5 Apr 2020 05:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF8cDCH_q9vG for ; Sun, 5 Apr 2020 05:52:57 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DAB3A080C for ; Sun, 5 Apr 2020 05:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=834; q=dns/txt; s=iport; t=1586091177; x=1587300777; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LsL/NRJfqPllpWKNMPGK8zZEAa6JBvZZiUQwL0drFTY=; b=G2Lw+Ehm1RHI8zTHENhppHor+eSOw2or7HC7zCY/E/jbcTsHzNYlBNOH aYqpdzdqbDo+9LXQaWp2jX9nXtCqOVT2iaORkSuZC0bO62mcLhAvK76ki vS+CTfPgRvoNtk7rytE0xPrGw+5wDzIMuCwNjNzc5UcvwmH31TwENvkuE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAAAW1Ile/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWcHAQELAYMUVSASKoQbiCFgiAyZTIF7CgEBAQwBARsUBAEBhEQ?= =?us-ascii?q?Cgmo0CQ4CAwEBCwEBBQEBAQIBBQRthVYMhXABAQEBAgEjVgULCxgCAiYCAlc?= =?us-ascii?q?ZFIMSAYJcIK40dYEyhUuFKIEOKgGMTIIAgTgcgk0+hE5NgkUygiwEsR6CR4J?= =?us-ascii?q?ehRKPOh2cAqgkgzgCBAYFAhWBUjmBVzMaCBsVZQGCPgk1EhgNlySFQz8DMI8?= =?us-ascii?q?rAQE?= X-IronPort-AV: E=Sophos;i="5.72,347,1580774400"; d="scan'208";a="25063359" 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; 05 Apr 2020 12:52:53 +0000 Received: from ams3-vpn-dhcp6253.cisco.com (ams3-vpn-dhcp6253.cisco.com [10.61.88.108]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 035CqqEr014453 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Apr 2020 12:52:53 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <146601d60b27$b11e4770$135ad650$@olddog.co.uk> Date: Sun, 5 Apr 2020 14:52:52 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <4EE786E5-3B24-487E-9D56-07F542736F9B@cisco.com> References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.88.108, ams3-vpn-dhcp6253.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 12:52:59 -0000 Hi Adrian > On 5 Apr 2020, at 10:53, Adrian Farrel wrote: >=20 > Thoughts: >=20 > Should this program be advertised in some way on the rfc-editor.org = web pages? >=20 > Should it be promoted through the IETF social media and press = presences? Good questions, and I like Stephen=E2=80=99s answer, but let me ask the = question this way: Do we want to ask the IAB to send liaisons to various places who we know = use our output? If we are discussing the form and future of the series = itself, then I would think we=E2=80=99d want a broad approach. If we = are talking about the internal management and oversight of the role, and = putting aside the form and future of the series, then I don=E2=80=99t = see the benefit. These are not binary. There=E2=80=99s some crossover. Eliot= From nobody Sun Apr 5 12:16:46 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44C63A0883 for ; Sun, 5 Apr 2020 12:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcIVAhAEEfQ3 for ; Sun, 5 Apr 2020 12:16:43 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F793A0881 for ; Sun, 5 Apr 2020 12:16:43 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id q3so6428826pff.13 for ; Sun, 05 Apr 2020 12:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Ficc49svghl2g5JZFW4lBXo0lVrOPlSb9qOUNyBh6lU=; b=Eiy9cv1vYqmAMDnAkndsjiQu541eDEZAVAd4RBf6kOVLbtYgkbbwjdacUKzFNy5R+L gflTGncaIfI6vd2/oaMehK+NhJ2MtiFkHkE4o6AVSw4P4g4wdHbTX8am7gIPm2m63JSz muPuBtsQrErPXJoI8OXiS+F/B8io3AhkGzHx/X9oRjeTlUZcCEXo0zs4GyOncA2VPTPf LqFwbnHDMRWe9BLyZOplgnXs3MuW7JtraEs8eFqRqSnnFiH9bmWcKFLkFyrVLrZIZIcL mSSNWKVGnzq88ecDNWRDfHupcwI2j7CG/r3y8lT+XR/ggVePNe50bTisRAEmJiS/5lKd HUCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Ficc49svghl2g5JZFW4lBXo0lVrOPlSb9qOUNyBh6lU=; b=t3Q/1Okmse0P2Bf8wqp6FaFIEGWHoHu0kh9mJvarVm/Y22GXor726VKlVo1KN/RfY+ ZKr6h+KQzV4UZs6Ljy0DB9le4sjwL5laqflUG2Wso5xHw06YVHiYzec6pmya8niERiw2 db8YfV0wUWCGejvT/ImUkifEpFbf9HNIY0bz3nzqb5ugzcVNUi+QhUrkvlT7QkuKmx+O 8iqA3dhvfGe4B9fN70mucZ8/5vg9JDSLMJLlE2raoRwYIikITqLRtjtc+sHgSlfnwbsD Z9vKHiJGfRslFiFVFOjxBltOCJErn4eCGovqkUwLaQbyJYjtGTqMbgtT2ei0cAbW9rmV JRqg== X-Gm-Message-State: AGi0Puaa7ZontrswGe+gUjWg5ierF195eiCAjHLe9G4I1d2d5nXmmDlK XMHkz1FRVBOyEN7Ouw+a9pmTXBUH X-Google-Smtp-Source: APiQypLEI2Izs7BDJY/zw+qmSd9+JuWZozVzQ294KvsPZJGAJV/1LNuW7RycWLyZBNSoNJ5asMuqLQ== X-Received: by 2002:a63:d90c:: with SMTP id r12mr17842585pgg.158.1586114202723; Sun, 05 Apr 2020 12:16:42 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id l15sm9282350pgk.59.2020.04.05.12.16.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Apr 2020 12:16:41 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: , References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> In-Reply-To: <146601d60b27$b11e4770$135ad650$@olddog.co.uk> Date: Sun, 5 Apr 2020 12:16:40 -0700 Message-ID: <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGSy5r9VV8/1Ja5QJZGtIRIKhBRtAIM6Gn2AhsPJKMBJB9ztQL0/mQgqK9EiuA= Content-Language: en-us Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 19:16:45 -0000 The community of interest is NOT "those who read RFCs" and trying to do = surveys of them a bad idea. The community of interest is NOT "anyone who cares enough to sign up = here" although that might be convenient. RFCs and the RFC series and streams have a role to play in assuring the = robustness of the Internet. Reliability (especially in an always-update-software world) means = avoiding vendor-lock-in as a single point of failure. The RFCs have a requirement to be somehow = useful to the community involved in the process of specifying, producing, debugging, = operating, documenting, etc multiple independent interoperable implementations. As the WebRTC discussion on the IETF list seems to indicate, there are = differences of perspective around the processes of IETF vs WHATWG/W3C. Standards-track = with internet drafts, a document editor producing unmodifiable RFCs followed = by errata and updates on the one hand, and "Living Standards" with GitHub issues = and forking=20 with pull requests on the other, and a more modular way of specifying = and=20 approving extensions based on implementation. What I don't understand is how much in that difference in perspective is = due to the layer of the stack and how much is just old vs. newer. -- https://LarryMasinter.net=20 https://going-remote.info =20 From nobody Sun Apr 5 12:42:15 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE5F3A0974 for ; Sun, 5 Apr 2020 12:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sp9X9CS5Zhms for ; Sun, 5 Apr 2020 12:42:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8639A3A0970 for ; Sun, 5 Apr 2020 12:42:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6A998BE20; Sun, 5 Apr 2020 20:42:03 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYjw6WdUegGz; Sun, 5 Apr 2020 20:42:00 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 48C6DBDCF; Sun, 5 Apr 2020 20:42:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1586115720; bh=VXVIhlAhit+x8RyTqHEe6cnW4xPYI+WqLld13yOJ3SQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=O50JoVkJkeBbBRoyMCw3P0DDVxF1P8wXkLcpYvmUSd3QugmN+40ovOOSrxCuPaxDu dqZlJ5SPDzsUXjx1hLMApIqdUJtQoHqugM3mlBR80JI9KC9fhxV+PsX+/7iUhezH3M +V39ytNbF4fIB62cKE9zjrQjjLgNyvp5Zl9PX5BU= To: Larry Masinter , rfced-future@iab.org References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sun, 5 Apr 2020 20:41:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FWpP8yUFeiatOP7r1E2XHA4Lk0ZjBZEEC" Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 19:42:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FWpP8yUFeiatOP7r1E2XHA4Lk0ZjBZEEC Content-Type: multipart/mixed; boundary="HjjPpuEsyPQ1HLxxHjX1qFJPfAiR4x7kc"; protected-headers="v1" From: Stephen Farrell To: Larry Masinter , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> In-Reply-To: <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> --HjjPpuEsyPQ1HLxxHjX1qFJPfAiR4x7kc Content-Type: multipart/mixed; boundary="------------D56F608CCD135810A2DCC52E" Content-Language: en-US This is a multi-part message in MIME format. --------------D56F608CCD135810A2DCC52E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 05/04/2020 20:16, Larry Masinter wrote: > The community of interest is NOT "those who read RFCs" and trying to > do surveys of them a bad idea. The community of interest is NOT > "anyone who cares enough to sign up here" although that might be > convenient. >=20 > RFCs and the RFC series and streams have a role to play in assuring > the robustness of the Internet. Reliability (especially in an > always-update-software world) means avoiding vendor-lock-in as a > single point of failure. The RFCs have a requirement to be somehow > useful to the community involved in the process of specifying, > producing, debugging, operating, documenting, etc multiple > independent interoperable implementations. So I can see how one might conclude that, but still figure I prefer my definition:-) The argument I'd make is to point out that the community of interest for RFCs is not the community of interest for the set of technologies described in RFCs. For example, I'd still care about https even if the specification for https was written in Ogham ([1] basically - scratch marks on standing stores:-) If you accepted that argument then I think you might conclude as I've done. (I'm not saying you will, I'm only saying you might:-) Cheers, S. [1] https://en.wikipedia.org/wiki/Ogham >=20 > As the WebRTC discussion on the IETF list seems to indicate, there > are differences of perspective around the processes of IETF vs > WHATWG/W3C. Standards-track with internet drafts, a document editor > producing unmodifiable RFCs followed by errata and updates on the one > hand, and "Living Standards" with GitHub issues and forking with pull > requests on the other, and a more modular way of specifying and=20 > approving extensions based on implementation. >=20 > What I don't understand is how much in that difference in perspective > is due to the layer of the stack and how much is just old vs. newer.=20 > -- https://LarryMasinter.net https://going-remote.info >=20 >=20 >=20 --------------D56F608CCD135810A2DCC52E Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------D56F608CCD135810A2DCC52E-- --HjjPpuEsyPQ1HLxxHjX1qFJPfAiR4x7kc-- --FWpP8yUFeiatOP7r1E2XHA4Lk0ZjBZEEC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6KNIcACgkQWrL68XsX K+qk5A/+LLkHqlNk2yXQx5Vk3pCX/dTzj94isRGP3C0un3sZuTTZ2ibAkmov+uL5 ocGNp+llohXvKL+dkiybXfXGKm7m5jGpFC6nAGyDgkBcmSQ10AK5r5lvN9eiE+J7 GA1jZtmI87pg8ePxz8JNONXgB3hJtOGY/kJxey5zH68QIbkgllM0XGyn0DJANvR/ 34skB+qwITZS8lowRaZmaYsLh6sQdqAVBCepyud+/wcZcW+A6BnANdJ8elfNsymQ +irolwR9gYs211/eLKFyX+tskMVujd13yAc4z5IeuQbRGxPeyYxzW4L55UjFJoAt UK+cR3IFaeZS6+eIb30q1gS6IoVytUBIcj07rJ1lUYszeD4nYm48IVEPWEs5BjOY ufcv2C6MsDW5mg5itBnwbygEhIdV/b+SdBkDIn83e02fk9ldkjo0zsa1jmrkDITV WkoNtkRskiA/Z57O3kLEXHU5zbqnWo/6PMIkjRhs/S2oAvCt8HJAgwmfYTuTc7T7 DuoB3jmWWiHKaVmGxnju2jZqU1ppejVgAqQ4WJu8Q1S6i8XO3fObTfiTC+K2R3ay b3b6KZvL08pEhd6GTlpYN4zgo0dIKie2TlDWcj27vEq2HaYz3XWQtRIMz6XefXk6 sJG8sj3I8xAqw9Dsy5VbUQi3dlHkPEqn4iDYmjyK6FWonvtze7k= =9hVR -----END PGP SIGNATURE----- --FWpP8yUFeiatOP7r1E2XHA4Lk0ZjBZEEC-- From nobody Sun Apr 5 13:31:43 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559B23A0C0C for ; Sun, 5 Apr 2020 13:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwXb1kYGnbBp for ; Sun, 5 Apr 2020 13:31:37 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DA43A0C0A for ; Sun, 5 Apr 2020 13:31:36 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id o26so6495587pgc.12 for ; Sun, 05 Apr 2020 13:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NQtczVwW7BKD+eEDqBieA1PRb5zR6OXVnLAy7IgYHRY=; b=Cvr91wyYGy5RT9NFXnTEB/WafxswZb29Grv7SUXKdmC5G/5hpFMc0DXUCqNJ+RwewV U1tZbe1IJ/9iw3Ts/6NK+dkBMxcdpckX86IDnnWXpFMruHqRieoa/0irPlT1bdaKWviG EI1ubJJlZsISLyOhG6zdSG0UsnENOqp6vBAIPWtYqmCMbE02h+xjILHGh00UCOnczfTD 0ZqTjmfK6FB1RZ5vnlkC/1j9a/wc+arpCb62N2L/li8d22Oe+JgqizvrV0d9EreVSPHy 1MA1AAwNBvPpB7dhvUDJmioNrn5fQ6s3r78KVoeT6e1kiWf0RxwZOrufWDK6APus+Oq7 WdCA== 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=NQtczVwW7BKD+eEDqBieA1PRb5zR6OXVnLAy7IgYHRY=; b=rAYXjfQ6vtHUal+3X+5jx8RiAZGhHG8JZzLVMWN2Bz3v+atH7M3i6Zt5HRG9esgUZ6 UWyN1CZ9BdplzOOH/pNhyJrct55h9qqGqZMDrNlwZDl1KcrLqWYSYaQx+4jhDelYjLJy KIkjGDwYEbfgCqnzGjgMeHWLBt7DwY0GHs0zzfOQ+eHOCj1eZByixC2EOqXA8OLMyFUO VHri0aAUn482G4VGSB8qeBjWX+tnn6lzSn5Ij80NeIAFU//KpWAgV15Z0YbRB26se1Kq y83D8eVEljaDmUpjcrEEfMyedcdOivzfzvTUXr2BbJV1DiwHIH74eVNsyvoT3Co0pW4N nckw== X-Gm-Message-State: AGi0Pua2fySskplsG6BZqxnUAQQZjKB8M4WjarxMumHnvBpPH9PQTTZw 8uLtOT5h2b0LDfJESbP6WzyQCPdz X-Google-Smtp-Source: APiQypL67QVeevulBLwyB/k9dUeWwQZxhVNcK9pBxwwBkzcjy7AOrecrvZB4ICDt/9CZAjEX8X1e5A== X-Received: by 2002:aa7:953b:: with SMTP id c27mr18915758pfp.201.1586118695948; Sun, 05 Apr 2020 13:31:35 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id d3sm10403820pjc.42.2020.04.05.13.31.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Apr 2020 13:31:35 -0700 (PDT) To: Eliot Lear Cc: rfced-future@iab.org References: <2d84ee1d-c1d2-e0c6-37cc-e237cc9b6381@gmail.com> <2A383FF9-FC78-4B40-A30C-059E030601D7@cisco.com> From: Brian E Carpenter Message-ID: <523371a6-5566-ca28-9fc3-befd2c2cfcf7@gmail.com> Date: Mon, 6 Apr 2020 08:31:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2A383FF9-FC78-4B40-A30C-059E030601D7@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested key point [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 20:31:40 -0000 On 06-Apr-20 00:46, Eliot Lear wrote: >=20 >=20 >> On 5 Apr 2020, at 01:10, Brian E Carpenter wrote: >> >> Hi Eliot, >> >> In your notes I see "What happens to the series if the IETF disappears= ?" >> >> We could also ask: What happens to the IETF if the series disappears? >=20 > Now that=E2=80=99s on the list as well.=20 Thanks. I'm not, by the way, suggesting that this is a *likely* scenario.= Brian From nobody Sun Apr 5 16:19:09 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BA93A0803 for ; Sun, 5 Apr 2020 16:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcpMy3YgpIRd for ; Sun, 5 Apr 2020 16:19:01 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8ADE3A0802 for ; Sun, 5 Apr 2020 16:19:01 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id cp9so2295145pjb.0 for ; Sun, 05 Apr 2020 16:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=eOlUURT+AZg6jhNigrR3LwojEMp+SfYDMendpkkvkPQ=; b=mL4tm2MVM0i1xyDG+RaxQ+U/mkivS4nS8YMGh2+TDPWrDRwH5nAHPOI1eof4XY6Bip /Ug4UeVfbm8HZEBPGOsfCw2f3vNglsPP0+/4QGMkIKiTY9GS3mFDtkIAlQbrnE/fzUTI GWgsyW4SIlvd7T3HgTjxVh2R0GElMJfy6TMznG4a2B+K4VQEQWtW9e7Vwe7q5Y2xECCI LPDfpFz1fbyGBzypWRIIFGwiDeb3q8fRF2FJ+IE7mkvhPfZBlIVZtiMSw5iwbpbSVoI2 s4xi84s/SZybvaImRW/9UPO+cNr9XLnoql95nqf42TcHUVArJv7ic4V3zOwe2BpSZqjo Ng0w== 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=eOlUURT+AZg6jhNigrR3LwojEMp+SfYDMendpkkvkPQ=; b=eboFxQ386h+kA8ouO5ZMeQfRom6GEJzhhBP3a7wDj3Nz6jxi+Ht25/ezQ62lRyquiG DqtZrErcYJ10VV9RaH8Oc/8cQzbSTxfHYMWnAvKDzJC7ilLu44Xa6lMRKz414T4Eb1za tXbZyIrrw5Oz7MrKD0lLoyvpipxXKH96vjS5aPc37eYOZi1xAl3lgidC2lpsSma/lxMO mF1Tm5B7uhghg++9FZ9V5/OnSfltZii5F+/185ZpYEC3lyuPOfzxRAnkmkjcZagokAhr Sy903cL5NwfKU9iPLsXffK1/lNM5uK/TkH20DY7OtPq7BUyqMeJmxAZ7qEZ+ryPN8F0G AlXQ== X-Gm-Message-State: AGi0PubHnpnFl3TBSCd7qnIfDRpQ6QqCJTF59yqPFau7j1RirUoINie/ FJCMpdsJe3pqNosczmFsgha+95DA X-Google-Smtp-Source: APiQypLxmyGW9Hg0vJFGe1q/Xkzz062DrJc4EsXhmnoAAgoOXHCvYc2PoZTuOP8NtXaQ4+YNtoGpLA== X-Received: by 2002:a17:902:bf01:: with SMTP id bi1mr18312050plb.132.1586128740658; Sun, 05 Apr 2020 16:19:00 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id x188sm9480151pgb.76.2020.04.05.16.18.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Apr 2020 16:18:59 -0700 (PDT) To: Stephen Farrell , Larry Masinter , rfced-future@iab.org References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> From: Brian E Carpenter Message-ID: Date: Mon, 6 Apr 2020 11:18:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 23:19:06 -0000 On 06-Apr-20 07:41, Stephen Farrell wrote: > > Hiya, > > On 05/04/2020 20:16, Larry Masinter wrote: >> The community of interest is NOT "those who read RFCs" and trying to >> do surveys of them a bad idea. The community of interest is NOT >> "anyone who cares enough to sign up here" although that might be >> convenient. >> >> RFCs and the RFC series and streams have a role to play in assuring >> the robustness of the Internet. Reliability (especially in an >> always-update-software world) means avoiding vendor-lock-in as a >> single point of failure. The RFCs have a requirement to be somehow >> useful to the community involved in the process of specifying, >> producing, debugging, operating, documenting, etc multiple >> independent interoperable implementations. Yes. I think that's well proxied by "the people who read RFCs", so I don't understand Larry's remark. The people who read RFCs include coders, testers, product managers, network designers, operators, and sometimes people writing RFPs. And certainly, people active in other SDOs. Brian > So I can see how one might conclude that, but still > figure I prefer my definition:-) > > The argument I'd make is to point out that the community of > interest for RFCs is not the community of interest for the > set of technologies described in RFCs. For example, I'd > still care about https even if the specification for > https was written in Ogham ([1] basically - scratch marks > on standing stores:-) > > If you accepted that argument then I think you might > conclude as I've done. (I'm not saying you will, I'm > only saying you might:-) > > Cheers, > S. > > [1] https://en.wikipedia.org/wiki/Ogham > >> >> As the WebRTC discussion on the IETF list seems to indicate, there >> are differences of perspective around the processes of IETF vs >> WHATWG/W3C. Standards-track with internet drafts, a document editor >> producing unmodifiable RFCs followed by errata and updates on the one >> hand, and "Living Standards" with GitHub issues and forking with pull >> requests on the other, and a more modular way of specifying and >> approving extensions based on implementation. >> >> What I don't understand is how much in that difference in perspective >> is due to the layer of the stack and how much is just old vs. newer. >> -- https://LarryMasinter.net https://going-remote.info >> >> >> >> From nobody Sun Apr 5 23:54:59 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA533A0794 for ; Sun, 5 Apr 2020 23:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaoK1ItMAD7m for ; Sun, 5 Apr 2020 23:54:56 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AB93A0793 for ; Sun, 5 Apr 2020 23:54:55 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id l14so7116924pgb.1 for ; Sun, 05 Apr 2020 23:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=YFUf6O6LHxAeqg03OJmGSQDmaV1z1wXGHiGvia1grFE=; b=SuLqiLGhh6BDGUR8nDxB2QDlivkmkcoQkJIm8wJVBTeyTBskIkCG9xEGL/SqgCKttx m9fXgP6rDtPWkNQipbSKdQ9yvCAJShxXnTX8AARVmaPU+6BTKXdixgTEkHzJEVAPQELN eSEUTmoUL/fDavCKT07Wck+/EYOv4w2GWkTBR4/T/mhbye7w7JYGmVpU6ZH9Ggh9o+l2 ELjjVJiT2fCrIYv9csEg+u+lryz1Pqbxod2de2YvH21qAOvnHbOuioDwk7FFabJEEs/x 4wSg0xSqKf07rYxKJwi+tRz7HYFbQCWUxH87h7uzQhMmZAdFL1gSwXmn7pj7EhK7Hl71 siUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=YFUf6O6LHxAeqg03OJmGSQDmaV1z1wXGHiGvia1grFE=; b=bQU2NwuEUmubA0hwlbUb5w6BkCyPZNEkyDzaPXg/+egTwegrBjK9ixp0Nu3AXh3izw vaOI1GKUr7LkgBF5Ee4Od/xQFXqxh+CuPBXSyPzLqLRDn77XbhavnvfbcvxC5HymDMH0 pMPeG9e2E0jIac8maDI+qvMGJnpL7hdmDFqWFc8l5TBE4E23XpI7racvRzE0rqsiZ7SI qnfslGAjIGeON5zNJ8Z5P6rBk9yiflct6xVbfBQVZMIP9xGtCx+R9bmjVzHLVo7eMKWG AR4u/ZZ9K3NzUpRr9dPlykpwxK/NfqT7eo6bgVmvyShGBod7FZtKl+jNQ3PF0CP/zXBz vgHQ== X-Gm-Message-State: AGi0PuYxuoD7AkoE2DqIOHuFPmrv3ajesURCfHrkfbqNlRkngpbNGAaR 0V07SgvGPU+z9w8PpzXUPpk= X-Google-Smtp-Source: APiQypKuVQLgnT8qpNJGpMopDUvp4lvxXMqXCqWnqb/jQ8I3T9XkUv2UIYJD2M5hMyWfCY1DtXDbrw== X-Received: by 2002:a63:a35c:: with SMTP id v28mr20839801pgn.251.1586156095279; Sun, 05 Apr 2020 23:54:55 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id w2sm10589165pff.195.2020.04.05.23.54.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Apr 2020 23:54:54 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Brian E Carpenter'" , "'Stephen Farrell'" , References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> In-Reply-To: Date: Sun, 5 Apr 2020 23:54:53 -0700 Message-ID: <001601d60be0$47172f90$d5458eb0$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGSy5r9VV8/1Ja5QJZGtIRIKhBRtAIM6Gn2AhsPJKMBJB9ztQL0/mQgAeJYHWQB2k7HEQKxBxX/qHymx2A= Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 Apr 2020 06:54:57 -0000 > Yes. I think that's well proxied by "the people who read RFCs", so I don't > understand Larry's remark. The people who read RFCs include coders, > testers, product managers, network designers, operators, and sometimes > people writing RFPs. And certainly, people active in other SDOs. Why do RFC's have Editors or Authors? Why not let the heatmap of the GitHub repo of the spec stand in? It would reduce the problems of Unicode author's names and more than 6 names. But then it would reduce the effectiveness of author-recruiting among those seeking tenure might want to claim an RFC counts as a peer-reviewed article. The readers are the tenure committee. Are they part of the required community of interest for the RFC series? being useful to tenure track academics was a reason given for adding DOIs to RFCs. But if you have different RFCs with the same number, Don't they need different DOIs. -- https://LarryMasinter.net https://going-remote.info From nobody Mon Apr 6 01:10:52 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4771A3A0A16 for ; Mon, 6 Apr 2020 01:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdCgFkvoMd_C for ; Mon, 6 Apr 2020 01:10:46 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FAE3A0AE0 for ; Mon, 6 Apr 2020 01:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4528; q=dns/txt; s=iport; t=1586160631; x=1587370231; h=from:mime-version:subject:message-id:date:to; bh=z05zPqq6OCXc/ex+vSHJFCMGJ/Wyxum1UNXDC/Xcu0I=; b=UAOzL2to/vbPAr1PZaRajW9JfR+TjojkB3UwqtAzNxzZMcl/gRnlsVc4 DOqCoB3Uq/+FcDedWUUAKsN7hNqPyQDgzrNWHmVYFGHDP1aiPdSFp9Vhb 7stcHnH0MF/LtGnxgS3Bl9+go32uJ3krDgImTDUIO7IFdddZnzE4hd2Ic U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMBQDE4ope/xbLJq1mhioBIBKERYk?= =?us-ascii?q?Bm0eGI4FnCgEBAQwBAS8EAQGHMDgTAgMBAQsBAQUBAQECAQUEbYVihhpLKj4?= =?us-ascii?q?CgQ2DC4J9oCaOEXWBMoVLhSiBOIxNggCBOByCGIUMARIBgzMygiwEsR6CR4J?= =?us-ascii?q?elEwdnAKoJIM4AgQGBQIVgWkiZ3AzGggbFTsqAYI/PRIYDVacET8DkAgBAQ?= X-IronPort-AV: E=Sophos; i="5.72,350,1580774400"; d="scan'208,217"; a="25079036" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Apr 2020 08:10:28 +0000 Received: from ams3-vpn-dhcp6253.cisco.com (ams3-vpn-dhcp6253.cisco.com [10.61.88.108]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0368AQRA004760 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 6 Apr 2020 08:10:28 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_0F2C2D85-9CA1-40DE-8D25-B0F7EA6BBDA0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <49DDA59C-7BCE-4591-BC7E-FF7347771491@cisco.com> Date: Mon, 6 Apr 2020 10:10:25 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.88.108, ams3-vpn-dhcp6253.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] "Interm meetings" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 Apr 2020 08:10:50 -0000 --Apple-Mail=_0F2C2D85-9CA1-40DE-8D25-B0F7EA6BBDA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good morning, everyone, from Switzerland. A good number of us have shown interest in trying to figure a way = forward for the RFC Editor role and the series. As you have seen, I = have been collecting these thoughts, so as to keep track of the ideas. I am wondering if people would like the opportunity to meet virtually in = the next few weeks, perhaps several times, so that participants can lay = out their visions. This would be along the lines of the questions I = asked. Namely: What are the big problems that need solving, or as Adrian put it, what = is one=E2=80=99s vision for where we need to be in the future? What should be done by this group now to achieve that vision, or things = that can be left for later? These virtual roundtables would not decisional, but just an opportunity = to articulate one=E2=80=99s views, to clarify those views based on = questions asked, and to hear the views of others. Obviously timezones are a big issue, and I would propose several times = that are equally convenient, and calls would be recorded, and notes = taken and brought back to the mailing list. I am suggesting that we take this one step at a time. That is, now = doesn=E2=80=99t seem to me the time to start solutions-engineering, but = rather simply to articulate vision, and to surface those issues that are = foremost on participants=E2=80=99 minds. Also, nothing stops people from doing just what I proposed in email, if = one can=E2=80=99t make the calls. Can I have feedback on these virtual meetings? If it is positive I will = propose dates toward the end of this week. Eliot --Apple-Mail=_0F2C2D85-9CA1-40DE-8D25-B0F7EA6BBDA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good = morning, everyone, from Switzerland.

A good number of us have shown interest = in trying to figure a way forward for the RFC Editor role and the = series.  As you have seen, I have been collecting these thoughts, = so as to keep track of the ideas.

I am wondering if people would like the = opportunity to meet virtually in the next few weeks, perhaps several = times, so that participants can lay out their visions.  This would = be along the lines of the questions I asked.  Namely:

  • What are the big problems that need = solving, or as Adrian put it, what is one=E2=80=99s vision for where we = need to be in the future?
  • What should be done by this = group now to achieve that vision, or things that can be left for = later?

These virtual roundtables would not decisional, but just an = opportunity to articulate one=E2=80=99s views, to clarify those views = based on questions asked, and to hear the views of others.

Obviously timezones are = a big issue, and I would propose several times that are equally = convenient, and calls would be recorded, and notes taken and brought = back to the mailing list.

I am suggesting that we take this one step at a time. =  That is, now doesn=E2=80=99t seem to me the time to start = solutions-engineering, but rather simply to articulate vision, and to = surface those issues that are foremost on participants=E2=80=99 = minds.

Also, = nothing stops people from doing just what I proposed in email, if one = can=E2=80=99t make the calls.

Can I have feedback on these virtual = meetings?  If it is positive I will propose dates toward the end of = this week.

Eliot

= --Apple-Mail=_0F2C2D85-9CA1-40DE-8D25-B0F7EA6BBDA0-- From nobody Mon Apr 6 08:08:09 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D5F3A093D for ; Mon, 6 Apr 2020 08:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XXHvQIPw230 for ; Mon, 6 Apr 2020 08:07:50 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D65463A097B for ; Mon, 6 Apr 2020 08:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YSgVKwt/NkfeFqRt4FWqXtLYJsMyEaEEqV4COCIp1CY=; b=T9bK2/fESCOlvx5E3jtkB09tc Ze3RjI+bbWzKNROZISwZf8sZM248CU6MzNnDtomJszfoBlY349sh3kRhKF/wJjRX1207cMrcF4Zx1 5t/pgNtFB+B0MRAiGW9KY/cLFJIlUQ/RDvmgPoVDyznePmuT0AkghMNDNOwC6Uj9TZoH9tQ9OblKf Bb44rAD+betlWZkb5IDBIfBii1UUf9i4n97nh5OXpEJZv1Pmm8Q/3PxceS13xReOq31EnN3GILFby VDDn0RKgs2+3ftq4/jB9gvIbw/42vKB8eWYhZHCfyUF1Ip4cx7j2kkUuf4kVsF2R3Ce0GflwbOMRR GXJGYxpWA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52527 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jLTLk-000ljE-0B; Mon, 06 Apr 2020 11:07:48 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_01B54FBA-9655-4A6E-84AD-5F8A1CE1421F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Joseph Touch In-Reply-To: <001601d60be0$47172f90$d5458eb0$@acm.org> Date: Mon, 6 Apr 2020 08:07:43 -0700 Cc: Brian E Carpenter , Stephen Farrell , rfced-future@iab.org Message-Id: <2469C4E3-72CF-4F05-AFEE-6CBCD1F5045B@strayalpha.com> References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> <001601d60be0$47172f90$d5458eb0$@acm.org> To: Larry Masinter X-Mailer: Apple Mail (2.3445.9.5) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 Apr 2020 15:07:52 -0000 --Apple-Mail=_01B54FBA-9655-4A6E-84AD-5F8A1CE1421F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 5, 2020, at 11:54 PM, Larry Masinter wrote: >=20 > Why do RFC's have Editors or Authors? Why not let the heatmap of the > GitHub repo of the spec stand in? Because authorship is - or should be - determined by a policy that can = be complex and cannot be so trivially automated. Although USC is not a paragon of ethics by any sort, it did have a = reasonable policy on this matter that helps illustrate why it=E2=80=99s = not merely a matter of who contributes text: = https://research.usc.edu/files/2011/07/URC_on_Authorship_and_Attribution_1= 0.20111.pdf = And yes, although this matters more for bean-counting tenure committees = and deans - who paradoxically use the kind of blind automation you = suggest above - it=E2=80=99s no less relevant here in the IETF. The = Author Overload policy only exacerbates this effect.=20 Joe= --Apple-Mail=_01B54FBA-9655-4A6E-84AD-5F8A1CE1421F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 5, 2020, at 11:54 PM, Larry Masinter <LMM@acm.org> = wrote:

Why do RFC's have Editors or = Authors? Why not let the heatmap of the
GitHub repo of the spec stand = in?

Because = authorship is - or should be - determined by a policy that can be = complex and cannot be so trivially automated.

Although USC is not a paragon of ethics = by any sort, it did have a reasonable policy on this matter that helps = illustrate why it=E2=80=99s not merely a matter of who contributes = text: https://research.usc.edu/files/2011/07/URC_on_Authorship_and_At= tribution_10.20111.pdf

And yes, although this matters more for bean-counting tenure = committees and deans - who paradoxically use the kind of blind = automation you suggest above - it=E2=80=99s no less relevant here in the = IETF. The Author Overload policy only exacerbates this = effect. 

Joe
= --Apple-Mail=_01B54FBA-9655-4A6E-84AD-5F8A1CE1421F-- From nobody Wed Apr 8 01:27:22 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5B73A0D0B for ; Wed, 8 Apr 2020 01:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP5rFG6CJBWj for ; Wed, 8 Apr 2020 01:27:20 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17C83A0D09 for ; Wed, 8 Apr 2020 01:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6445; q=dns/txt; s=iport; t=1586334439; x=1587544039; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=UYDopxRQvqmrYJ9qk4mKVsmFMI/swqvv9KbWDiISxYY=; b=CU/gRY8WgEKMfBynN8UUibhLAAwchY5l/Deu6hIwXn/k3fMxHTuMrI66 SGcEFpY+VXuJuS2BXoXX7W/aX1g0RcyNnkEx9SBnkdyvzvvpuTFonlXO7 7qoftFxfbr+mjOWcycFp1oV0Ar/qUf/Tzw9wti1uIJXL/WdGJCgQ2V8El A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAAAnio1e/xbLJq1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7AoMTVSASKoQciQGHbCWTQIYigWcKAQEBDAE?= =?us-ascii?q?BGAEKDAQBAYREAoIrOQUNAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQIBAQE?= =?us-ascii?q?hSwsFCwsYJwMCAicfEQYTG4MLAYJcIA+vQXWBMoVLhSEGgTiMTYIAgTgMEII?= =?us-ascii?q?YNT6CZwEDgS4BEgGDMzKCLASxMIJHgmGUVB2cCKgvgzgCBAYFAhWBaiFncDM?= =?us-ascii?q?aCBsVOyoBgj4+EhgNVplThUM/AzACj1ABAQ?= X-IronPort-AV: E=Sophos; i="5.72,357,1580774400"; d="scan'208,217"; a="25082608" 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; 08 Apr 2020 08:27:17 +0000 Received: from ams3-vpn-dhcp5345.cisco.com (ams3-vpn-dhcp5345.cisco.com [10.61.84.224]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0388RGeU024333 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2020 08:27:17 GMT From: Eliot Lear Message-Id: <62548610-CC42-4011-855B-54527D8C50BF@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_32B3A717-11D9-45A3-B452-C8A532D436A0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 8 Apr 2020 10:27:16 +0200 In-Reply-To: <49DDA59C-7BCE-4591-BC7E-FF7347771491@cisco.com> Cc: rfced-future@iab.org To: Eliot Lear References: <49DDA59C-7BCE-4591-BC7E-FF7347771491@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.84.224, ams3-vpn-dhcp5345.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] "Interm meetings" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Apr 2020 08:27:22 -0000 --Apple-Mail=_32B3A717-11D9-45A3-B452-C8A532D436A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A reminder. I am looking for your feedback on this proposal this week. Eliot > On 6 Apr 2020, at 10:10, Eliot Lear > wrote: >=20 > Good morning, everyone, from Switzerland. >=20 > A good number of us have shown interest in trying to figure a way = forward for the RFC Editor role and the series. As you have seen, I = have been collecting these thoughts, so as to keep track of the ideas. >=20 > I am wondering if people would like the opportunity to meet virtually = in the next few weeks, perhaps several times, so that participants can = lay out their visions. This would be along the lines of the questions I = asked. Namely: >=20 > What are the big problems that need solving, or as Adrian put it, what = is one=E2=80=99s vision for where we need to be in the future? > What should be done by this group now to achieve that vision, or = things that can be left for later? >=20 > These virtual roundtables would not decisional, but just an = opportunity to articulate one=E2=80=99s views, to clarify those views = based on questions asked, and to hear the views of others. >=20 > Obviously timezones are a big issue, and I would propose several times = that are equally convenient, and calls would be recorded, and notes = taken and brought back to the mailing list. >=20 > I am suggesting that we take this one step at a time. That is, now = doesn=E2=80=99t seem to me the time to start solutions-engineering, but = rather simply to articulate vision, and to surface those issues that are = foremost on participants=E2=80=99 minds. >=20 > Also, nothing stops people from doing just what I proposed in email, = if one can=E2=80=99t make the calls. >=20 > Can I have feedback on these virtual meetings? If it is positive I = will propose dates toward the end of this week. >=20 > Eliot >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = --Apple-Mail=_32B3A717-11D9-45A3-B452-C8A532D436A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
A reminder.  I am = looking for your feedback on this proposal this week.

Eliot

On 6 Apr = 2020, at 10:10, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

Good morning, = everyone, from Switzerland.

A good number of us have shown interest in trying to figure a = way forward for the RFC Editor role and the series.  As you have = seen, I have been collecting these thoughts, so as to keep track of the = ideas.

I am = wondering if people would like the opportunity to meet virtually in the = next few weeks, perhaps several times, so that participants can lay out = their visions.  This would be along the lines of the questions I = asked.  Namely:

  • What are the big = problems that need solving, or as Adrian put it, what is one=E2=80=99s = vision for where we need to be in the future?
  • What = should be done by this group now to achieve that vision, or things that = can be left for later?

These virtual roundtables would = not decisional, but just an opportunity to articulate one=E2=80=99s = views, to clarify those views based on questions asked, and to hear the = views of others.

Obviously timezones are a big issue, and I would propose = several times that are equally convenient, and calls would be recorded, = and notes taken and brought back to the mailing list.

I am suggesting that we = take this one step at a time.  That is, now doesn=E2=80=99t seem to = me the time to start solutions-engineering, but rather simply to = articulate vision, and to surface those issues that are foremost on = participants=E2=80=99 minds.

Also, nothing stops people from doing = just what I proposed in email, if one can=E2=80=99t make the = calls.

Can I = have feedback on these virtual meetings?  If it is positive I will = propose dates toward the end of this week.

Eliot

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

= --Apple-Mail=_32B3A717-11D9-45A3-B452-C8A532D436A0-- From nobody Wed Apr 8 09:20:23 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937013A0D1C for ; Wed, 8 Apr 2020 09:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6UufBXZ1hIC for ; Wed, 8 Apr 2020 09:20:18 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69C03A0D18 for ; Wed, 8 Apr 2020 09:20:17 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jMDQq-0008OL-EY; Wed, 08 Apr 2020 12:20:04 -0400 Date: Wed, 08 Apr 2020 12:19:59 -0400 From: John C Klensin To: Joseph Touch , Larry Masinter cc: rfced-future@iab.org, Stephen Farrell Message-ID: <8FBDE9686119E7C8C8889759@PSB> In-Reply-To: <2469C4E3-72CF-4F05-AFEE-6CBCD1F5045B@strayalpha.com> References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> <001601d60be0$47172f90$d5458eb0$@acm.org> <2469C4E3-72CF-4F05-AFEE-6CBCD1F5045B@strayalpha.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Apr 2020 16:20:21 -0000 Joe, While I agree with your comments below, another piece of the answer is to have some human to whom questions can be addressed. That use of author listings with RFCs of course predates Jon Postel's taking on the RFC Editor role -- the days when "Request for Comments" was an accurate description, not just a name. Of course, for a Standards Track document, "ask the author" may be the wrong answer and it should perhaps be "ask the IETF somehow" (see below). It also interacts with our AUTH48 process because the "author" is the key person who needs to sign off on the technical content being unchanged and the editorial content and presentation being satisfactory. Neither is actually a great fit for Standards Track documents [1]. It is not an accident that, in most other SDOs, the documents "belong to" the organization and its secretariat (including editorial stuff) and the author is the SDO itself and not some individual. Even the person who held the pen during document development may be acknowledged as editor somewhere, but is never listed as author or editor when the document is cited. That is very much tied to why editing prior to voting (even if more editing needs to be done after voting and, often, the voting repeated) works for them and would not work for us. Especially for a Standards Track document whose predecessor I-Ds underwent significant change as a WG struggled with the subject matter, the question of academic credit really should be much more complicated than the way we have been treating it because, by the time the document is published, the "author(s)" may no longer be the primary technical/professional contributor(s). I think the question of whether we should re-think listing of authors on some or all IETF Stream documents is an interesting one. I hope is it out of scope for this effort if only because (i) as Larry's note, yours, this one, and a few others illustrate, it is not a simple question and (ii) the discussion would benefit from the experience of, and advice from, senior publishing professionals, not us amateurs, (iii) it is _probably_ an issue confined to that stream. best, john [1] And perhaps, with the recent change requiring community consensus for all IETF Stream documents, for all documents published in that stream... although I'm still not completely clear whether that IETF consensus means "we agree that this should be published" or "we agree with everything it says". --On Monday, April 6, 2020 08:07 -0700 Joseph Touch wrote: > > >> On Apr 5, 2020, at 11:54 PM, Larry Masinter >> wrote: >> >> Why do RFC's have Editors or Authors? Why not let the heatmap >> of the GitHub repo of the spec stand in? > > Because authorship is - or should be - determined by a policy > that can be complex and cannot be so trivially automated. > > Although USC is not a paragon of ethics by any sort, it did > have a reasonable policy on this matter that helps illustrate > why it's not merely a matter of who contributes text: > https://research.usc.edu/files/2011/07/URC_on_Authorship_and_A > ttribution_10.20111.pdf > Attribution_10.20111.pdf> > > And yes, although this matters more for bean-counting tenure > committees and deans - who paradoxically use the kind of blind > automation you suggest above - it's no less relevant here in > the IETF. The Author Overload policy only exacerbates this > effect. From nobody Wed Apr 8 09:25:19 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9D53A0F41 for ; Wed, 8 Apr 2020 09:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Oh95dBgsH_T6 for ; Wed, 8 Apr 2020 09:25:15 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F143A0F18 for ; Wed, 8 Apr 2020 09:25:15 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id y3so756494qky.8 for ; Wed, 08 Apr 2020 09:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=SwXfyR/z/sloPHMsXq9UwBtp0sUA0It4AB0vtK2Lw08=; b=xCS8tPR5m8BoXS0wqAOKCJbdajH6fqorEGdZb4yUTu19iW6xOQfM9fUZZF2avV29lI nagKUjGfPuopPB3cfmoHx+N3U2+CpLwE7lXGQCUUcpVoju+TOhJiuEwSYHIi2F45mi1A SpVbCzt7Ne568aCY9/IXk0fz1stu9tsRYnioHEWwTPOP7yL+NWaVf3A+2rl+AItqrVo2 D7avOsgcw6YaoqDsf1eaWYeJpmgZBLN1zUGHmWg2WutVY+6E9WjGbjvbNcN5QZ6OG1+k nw74nxSDyYBMQ+4sJJ5KOtV/IjDq+Lmc4jhVG9zeH7ChmQTVRF954aWxYSBn6kyuqLqV bCvA== 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=SwXfyR/z/sloPHMsXq9UwBtp0sUA0It4AB0vtK2Lw08=; b=rGg7DF5lgak/OP0TMYwdYoeukR6JG67F6UcD0G57K2McT8wg4VJuwFm/SnuHfmekYj tAWC2IEqLkmauYn4sugT5xTJ5wsn+YG+DcHvVWRHBwR+LBxDAn7Uq1a4eUuDPXvM19a8 qpMar7opoYL9B4c5Y6wU4gHTuFGdUAErYRa8tXAQbernsJamqZ9jac58S2gng77/VLVp 97ZUT3HEZN9v0OrUTZkzGtKwjg+SxxYVlmAuoDvIbk8nq0ZQJaZdl2k75z//XdHEpqrR VJ3W3kbqIQYwdme6stwJJ/5Y7dw/G2hz8yfOpcj0+tcnR2kFI+5KPk9Nni2S+nocPJFF 0VUQ== X-Gm-Message-State: AGi0PuYV3RNJYTm0cqnbOaWTiK1EQXSFyiWlzohHmDbK4hl5QdN1hU+x ci2Jri6bAEZo4ebqwMWa4g2zhmSZCWjHQQ== X-Google-Smtp-Source: APiQypKCtAFJ7C21rS4bVCcPXQdImGojaJMw5HnQrLxlxcKSJj1cWM8BuIlKkhtNBuoohyGJYNafsw== X-Received: by 2002:a37:888:: with SMTP id 130mr7846268qki.261.1586363113833; Wed, 08 Apr 2020 09:25:13 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id y9sm11753656qtc.12.2020.04.08.09.25.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 09:25:12 -0700 (PDT) To: rfced-future@iab.org References: <49DDA59C-7BCE-4591-BC7E-FF7347771491@cisco.com> <62548610-CC42-4011-855B-54527D8C50BF@cisco.com> From: Michael StJohns Message-ID: <9cea21ae-fb29-00e3-d6b8-2de96ab41d81@nthpermutation.com> Date: Wed, 8 Apr 2020 12:25:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <62548610-CC42-4011-855B-54527D8C50BF@cisco.com> Content-Type: multipart/alternative; boundary="------------FCFA8ECA931FA305E82C05D3" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] "Interm meetings" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Apr 2020 16:25:18 -0000 This is a multi-part message in MIME format. --------------FCFA8ECA931FA305E82C05D3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I don't believe it's quite time for a WG style webex.    I think we're still lacking a clear enough set of positions to make such a meeting (or meetings) productive. It's only been slightly more than a week - let's let the iron get a bit more molten before we try to pour it into molds. Mike On 4/8/2020 4:27 AM, Eliot Lear wrote: > A reminder.  I am looking for your feedback on this proposal this week. > > Eliot > >> On 6 Apr 2020, at 10:10, Eliot Lear > > wrote: >> >> Good morning, everyone, from Switzerland. >> >> A good number of us have shown interest in trying to figure a way >> forward for the RFC Editor role and the series.  As you have seen, I >> have been collecting these thoughts, so as to keep track of the ideas. >> >> I am wondering if people would like the opportunity to meet virtually >> in the next few weeks, perhaps several times, so that participants >> can lay out their visions.  This would be along the lines of the >> questions I asked.  Namely: >> >> * What are the big problems that need solving, or as Adrian put it, >> what is one’s vision for where we need to be in the future? >> * What should be done by this group now to achieve that vision, or >> things that can be left for later? >> >> >> These virtual roundtables would not decisional, but just an >> opportunity to articulate one’s views, to clarify those views based >> on questions asked, and to hear the views of others. >> >> Obviously timezones are a big issue, and I would propose several >> times that are equally convenient, and calls would be recorded, and >> notes taken and brought back to the mailing list. >> >> I am suggesting that we take this one step at a time.  That is, now >> doesn’t seem to me the time to start solutions-engineering, but >> rather simply to articulate vision, and to surface those issues that >> are foremost on participants’ minds. >> >> Also, nothing stops people from doing just what I proposed in email, >> if one can’t make the calls. >> >> Can I have feedback on these virtual meetings?  If it is positive I >> will propose dates toward the end of this week. >> >> Eliot >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > --------------FCFA8ECA931FA305E82C05D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I don't believe it's quite time for a WG style webex.    I think we're still lacking a clear enough set of positions to make such a meeting (or meetings) productive.

It's only been slightly more than a week - let's let the iron get a bit more molten before we try to pour it into molds.

Mike


On 4/8/2020 4:27 AM, Eliot Lear wrote:
A reminder.  I am looking for your feedback on this proposal this week.

Eliot

On 6 Apr 2020, at 10:10, Eliot Lear <lear=40cisco.com@dmarc.ietf.org> wrote:

Good morning, everyone, from Switzerland.

A good number of us have shown interest in trying to figure a way forward for the RFC Editor role and the series.  As you have seen, I have been collecting these thoughts, so as to keep track of the ideas.

I am wondering if people would like the opportunity to meet virtually in the next few weeks, perhaps several times, so that participants can lay out their visions.  This would be along the lines of the questions I asked.  Namely:

  • What are the big problems that need solving, or as Adrian put it, what is one’s vision for where we need to be in the future?
  • What should be done by this group now to achieve that vision, or things that can be left for later?

These virtual roundtables would not decisional, but just an opportunity to articulate one’s views, to clarify those views based on questions asked, and to hear the views of others.

Obviously timezones are a big issue, and I would propose several times that are equally convenient, and calls would be recorded, and notes taken and brought back to the mailing list.

I am suggesting that we take this one step at a time.  That is, now doesn’t seem to me the time to start solutions-engineering, but rather simply to articulate vision, and to surface those issues that are foremost on participants’ minds.

Also, nothing stops people from doing just what I proposed in email, if one can’t make the calls.

Can I have feedback on these virtual meetings?  If it is positive I will propose dates toward the end of this week.

Eliot

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



--------------FCFA8ECA931FA305E82C05D3-- From nobody Wed Apr 8 11:31:10 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065A33A1548 for ; Wed, 8 Apr 2020 11:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38jCSRJ5DC_L for ; Wed, 8 Apr 2020 11:31:03 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADFE3A1542 for ; Wed, 8 Apr 2020 11:30:57 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jMFTM-0008lI-TJ; Wed, 08 Apr 2020 14:30:48 -0400 Date: Wed, 08 Apr 2020 14:30:42 -0400 From: John C Klensin To: Brian E Carpenter , Stephen Farrell , Larry Masinter , rfced-future@iab.org Message-ID: <7D1F19EBC9E61EEBBC6B7E9C@PSB> In-Reply-To: References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> <00f401d60b7e$bcec0ea0$36c42be0$@acm.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Apr 2020 18:31:06 -0000 --On Monday, April 6, 2020 11:18 +1200 Brian E Carpenter wrote: > On 06-Apr-20 07:41, Stephen Farrell wrote: >> >> Hiya, >> >> On 05/04/2020 20:16, Larry Masinter wrote: >>> The community of interest is NOT "those who read RFCs" and >>> trying to do surveys of them a bad idea. The community of >>> interest is NOT "anyone who cares enough to sign up here" >>> although that might be convenient. >>> >>> RFCs and the RFC series and streams have a role to play in >>> assuring the robustness of the Internet. Reliability >>> (especially in an always-update-software world) means >>> avoiding vendor-lock-in as a single point of failure. The >>> RFCs have a requirement to be somehow useful to the >>> community involved in the process of specifying, producing, >>> debugging, operating, documenting, etc multiple independent >>> interoperable implementations. > > Yes. I think that's well proxied by "the people who read RFCs", > so I don't understand Larry's remark. The people who read RFCs > include coders, testers, product managers, network designers, > operators, and sometimes people writing RFPs. And certainly, > people active in other SDOs. Agreed. The last group you mentioned --which I'd expand to include those writing contracts, SLAs and other specifications associated with software acquisition and maintenance, and sometimes other people associated with hiring, procurement, and statements of work as well as occasional journalists -- may be worthy of special note for several reasons: (1) They often read RFCs using a medium that, from reading this and related discussions, many of us consider archaic [1]. Many of them even mark up those RFCs to make special notes or for incorporation in specification documents using equally archaic, pre-XML, techniques and procedures [2]. (2) In practice, their actions are often key to which products are purchased, whether those products conform to (or are held to) our standards or not, and so on. (3) While the relationships may be quite indirect, their actions often determine whether many IETF participants remain employed and how they are compensated [3]. (4) The odds of getting either a significant number or a representative sample of them to read and participate on an IETF mailing list and/or a meeting (f2f or virtual) are just about zero. However, for reasons that should be clear from the above (if they weren't already), we ignore them at our peril. If we intend to support them, we need documents that are available in forms that do not require additional processing (reformatting, changes in layout, etc.) to work with their preferred medium _and_ which are written clearly and in good English, preferably good enough English that it is reasonable to expect translators who are not expert in the subject matter (whether human or machine) to be able to render them into other languages without significant distortion of the information that is present. Hypothesis #1: If we accept the assertion that textual forms are insufficient to adequately represent the material we expect in new-generation RFCs, the PDF has better work. Really work. And, if we produce versions that do not come up to those standards with the expectation of reissuing them in better form later, they should be clearly identified as "temporary", "interim", "preliminary", "preprint" or equivalent and we should expect that standards will not really be adopted until final versions are available (many or most of the people described above are known to have a distaste for moving targets). Hypothesis #2: Producing output documents of that quality, especially given the observable writing skills (in technical, American, English) of many IETF participants can require rather significant effort to rewrite paragraphs, reorganize material, goes far beyond what is usually understood as "copy editing". There are also obvious tradeoffs between quality and time and cost in the editing process. Decisions about those tradeoffs in particular situations -- decisions that might include returning a document to a Stream and telling them they have to make it better before editing is feasible -- should be made by a skilled professional, not a bureaucrat working from a single criterion, if we want the Series to survive [4]. Hypothesis #3: An RSE, or RSE candidate, who does not thoroughly understand the above is probably unsuited for the position. Consequently, we need to capture those issues in a way that make them a part of whatever job descriptions are developed. thanks, john [1] I think it is called, or used to be called, "paper", typically paper organized into "pages" that readers expect to be carefully laid out and "paginated". [2] Examples of such ancient technology are known as "pencils" and "pens", often in a multitude of colors. Occasionally "copy and paste" techniques are used that involve "scissors" and "tape" or "glue". [3] In discussions of economics, the outcome of those relationships is sometimes known as "the bottom line". [4] And, because some of the documents in the Series are the IETF's main product as far as much of the public and those audiences are concerned, perhaps even whether the IETF survives. From nobody Wed Apr 8 11:47:54 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2A23A1585 for ; Wed, 8 Apr 2020 11:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kvfurY7svDoi for ; Wed, 8 Apr 2020 11:47:52 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933343A1584 for ; Wed, 8 Apr 2020 11:47:52 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jMFjq-0008nU-Hd; Wed, 08 Apr 2020 14:47:50 -0400 Date: Wed, 08 Apr 2020 14:47:45 -0400 From: John C Klensin To: Michael StJohns , rfced-future@iab.org Message-ID: In-Reply-To: <9cea21ae-fb29-00e3-d6b8-2de96ab41d81@nthpermutation.com> References: <49DDA59C-7BCE-4591-BC7E-FF7347771491@cisco.com> <62548610-CC42-4011-855B-54527D8C50BF@cisco.com> <9cea21ae-fb29-00e3-d6b8-2de96ab41d81@nthpermutation.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] "Interm meetings" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Apr 2020 18:47:54 -0000 --On Wednesday, April 8, 2020 12:25 -0400 Michael StJohns wrote: > I don't believe it's quite time for a WG style = webex.=C2=A0=C2=A0=C2=A0 I > think we're still lacking a clear enough set of positions to > make such a meeting (or meetings) productive. >=20 > It's only been slightly more than a week - let's let the iron > get a bit more molten before we try to pour it into molds. Eliot,=20 I tend to agree with Michael's conclusion although I have different (and complementary) reasons. =20 (1) At least some of us, as a result of the troubled times, other work going on in the IETF or elsewhere that requires attention, or simply because of the complexity of some of the issues, need time to read and think about messages and topics in the light of what we know (or think we do) to get to the point that posting anything would be really useful. The back and forth of a real-time exchange does not facilitate that kind of thinking, including getting the clear positions Mike mentions adequately described. (2) Email is an equalizer. It reduces sensitivity to time zones, it avoids the problem of having someone summarize what [they thought] someone else said that comes (especially) with holding multiple meetings to cover a single set of topics at times that are relatively convenient to everyone, it enables people who understand English better when read than when spoken and who can write more clearly than they can speak to understand and express themselves better, and so on. Let's not give that up lightly, especially before we have clearly-articulated (and written) positions we need to discuss and compare. thanks, john From nobody Wed Apr 8 11:57:10 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0168E3A0C3B for ; Wed, 8 Apr 2020 11:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp0cABoTMv7u for ; Wed, 8 Apr 2020 11:57:06 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFA43A1603 for ; Wed, 8 Apr 2020 11:56:52 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jMFsX-0008p6-52; Wed, 08 Apr 2020 14:56:49 -0400 Date: Wed, 08 Apr 2020 14:56:43 -0400 From: John C Klensin To: Eliot Lear , adrian@olddog.co.uk cc: rfced-future@iab.org Message-ID: In-Reply-To: <4EE786E5-3B24-487E-9D56-07F542736F9B@cisco.com> References: <8112b0ed-e21f-b7cf-c94c-a4ce42af3126@gmail.com> <72631d8b-4c14-e218-7ff2-8303cecd5b00@gmail.com> <146601d60b27$b11e4770$135ad650$@olddog.co.uk> <4EE786E5-3B24-487E-9D56-07F542736F9B@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 08 Apr 2020 18:57:08 -0000 --On Sunday, April 5, 2020 14:52 +0200 Eliot Lear wrote: > Hi Adrian > >> On 5 Apr 2020, at 10:53, Adrian Farrel >> wrote: >> >> Thoughts: >> >> Should this program be advertised in some way on the >> rfc-editor.org web pages? >> >> Should it be promoted through the IETF social media and press >> presences? > > Good questions, and I like Stephen's answer, but let me ask > the question this way: > > Do we want to ask the IAB to send liaisons to various places > who we know use our output? If we are discussing the form and > future of the series itself, then I would think we'd want a > broad approach. If we are talking about the internal > management and oversight of the role, and putting aside the > form and future of the series, then I don't see the benefit. > These are not binary. There's some crossover. Eliot, Drawing heavily from the note I sent in this thread a few minutes ago (but not repeating it), I think what you describe as a broad approach is needed. But liaisons to the sorts of people and groups I was describing in that note: I think pretty hopeless even if we had enough people in the IETF to fill those roles. best, john From nobody Thu Apr 9 05:48:24 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DB73A0A6A for ; Thu, 9 Apr 2020 05:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.589 X-Spam-Level: X-Spam-Status: No, score=-9.589 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, T_SPF_TEMPERROR=0.01, 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 FXF7CF86hG2V for ; Thu, 9 Apr 2020 05:48:17 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8079F3A0A69 for ; Thu, 9 Apr 2020 05:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4175; q=dns/txt; s=iport; t=1586436497; x=1587646097; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=JTZ6hTHoBKXs11Ww98m3V7aqp1bC/IStSvSiADmeoJY=; b=J45lmYgKep0dxadvRxt3+kK1NSCQrBLxOaEeHhhYNGeEsyxUAMJvhoqY nV5IzyOEumeY4eMhblb2CVN50JpIKRFA92AurNMYEcfzMohbDxluUe0LP pMZeQ4YfkIx4/n7ln0i/099hnxCpfbusOgpB6qy9MkZzcDw1d9U8FDrQv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AgBnGY9e/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuDaiASKoQciQKIEZNAiAkKAQEBDAEBLwQBAYREAoIyOBMCAwE?= =?us-ascii?q?BCwEBBQEBAQIBBQRthWKFcAEBAQECASNWBQsLBBQqAgJXBhODJoJdIK88dYE?= =?us-ascii?q?yhU6FJIE4jE2CAIE4HIJNPodgMoIsBI1ro1OCSYJjlFkdj0uMS6hEgzkCBAY?= =?us-ascii?q?FAhWBaSKBVzMaCBsVZQGCPj4SGA2fbD8DMI9IAQE?= X-IronPort-AV: E=Sophos; i="5.72,362,1580774400"; d="scan'208,217"; a="25188826" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2020 12:47:52 +0000 Received: from [10.61.205.139] ([10.61.205.139]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 039Cln1k007366 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Apr 2020 12:47:52 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D64272B6-3F86-4258-A889-9AB5C97EC21F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Apr 2020 14:47:48 +0200 In-Reply-To: <9cea21ae-fb29-00e3-d6b8-2de96ab41d81@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <49DDA59C-7BCE-4591-BC7E-FF7347771491@cisco.com> <62548610-CC42-4011-855B-54527D8C50BF@cisco.com> <9cea21ae-fb29-00e3-d6b8-2de96ab41d81@nthpermutation.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.205.139, [10.61.205.139] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] "Interm meetings" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 Apr 2020 12:48:23 -0000 --Apple-Mail=_D64272B6-3F86-4258-A889-9AB5C97EC21F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, > On 8 Apr 2020, at 18:25, Michael StJohns = wrote: >=20 > I don't believe it's quite time for a WG style webex. I think we're = still lacking a clear enough set of positions to make such a meeting (or = meetings) productive. Ok. We=E2=80=99ll delay for a while. Let=E2=80=99s perhaps think in = terms of the 2nd week of May? I think it=E2=80=99s good to have some = date on the calendar to hold these round table discussions. As a reminder, the proposed approach is just to start with people=E2=80=99= s visions for what they think good looks like (or conversely how to = avoid "bad"). I also think it would be good to use the schedule as a = little bit of a forcing function. I do not suggest that posted drafts be a requirement to articulate = one=E2=80=99s views. However, what would be nice is a one or two page = statement as a starting point, with the recognition that people are = entitled to evolve their views at any time. >=20 > It's only been slightly more than a week - let's let the iron get a = bit more molten before we try to pour it into molds. >=20 And I would add that a few people have commented to me privately along = John=E2=80=99s lines, that this isn=E2=80=99t the first thing they may = have to be dealing with. Eliot --Apple-Mail=_D64272B6-3F86-4258-A889-9AB5C97EC21F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mike,

On 8 Apr 2020, at 18:25, Michael StJohns = <msj@nthpermutation.com> wrote:

=20
I don't believe it's quite time for a WG style webex.    I think we're still lacking a = clear enough set of positions to make such a meeting (or meetings) = productive.

Ok.  We=E2=80=99ll delay for a while. Let=E2=80= =99s perhaps think in terms of the 2nd week of May?  I think it=E2=80= =99s good to have some date on the calendar to hold these round table = discussions.

As a reminder, the proposed = approach is just to start with people=E2=80=99s visions for what they = think good looks like (or conversely how to avoid "bad").  I also = think it would be good to use the schedule as a little bit of a forcing = function.

I do = not suggest that posted drafts be a requirement to articulate = one=E2=80=99s views.  However, what would be nice is a one or two = page statement as a starting point, with the recognition that people are = entitled to evolve their views at any time.


It's only been slightly more than a week - let's let the iron get a bit more molten before we try to pour it into molds.


And I would add that a few people have commented = to me privately along John=E2=80=99s lines, that this isn=E2=80=99t the = first thing they may have to be dealing with.

Eliot

= --Apple-Mail=_D64272B6-3F86-4258-A889-9AB5C97EC21F-- From nobody Mon Apr 13 04:37:23 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3073A145B for ; Mon, 13 Apr 2020 04:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DEOfPj15Yul for ; Mon, 13 Apr 2020 04:37:19 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F323A145A for ; Mon, 13 Apr 2020 04:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3013; q=dns/txt; s=iport; t=1586777839; x=1587987439; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=AFySm/NIaOINU2lH4+gYw3s2ngeNkGkeWb18SAOc1Ws=; b=LpGIKFCMZXx1OmqaZbdhRlBR3E0DPq0hgiXZpY2QPgzNSLapVuJICvWH 9Xn1yFuKCtiLtNtmgYw10MSvMQznoLYCVjnrWykiDEriSiMIH1v2zXj1e VfJI1y20BvZZQMrH5eta0ur0Qzz+Q8XzNjLr02LS23XbVaqlsB7Zv09Mf s=; X-IPAS-Result: =?us-ascii?q?A0A3AQBLTpRe/xbLJq1mGwEBAQEBAQEFAQEBEQEBAwMBA?= =?us-ascii?q?QGBe4MVVSASKoQciQKIDZtMCgEBAQwBARgLDAQBAYFQgnQCgjQ4EwIDAQEBA?= =?us-ascii?q?wIDAQEBAQUBAQECAQUEbYVWDIVwAQEBAQIBAQEhSgEEBwULCxgCAiYCAicwB?= =?us-ascii?q?hODJgGCXCAPrXJ1gTKFToRlBoEOKoxPggCBESccgk0+gk4ZAYFEAQEggxIyg?= =?us-ascii?q?iwEr0qCBoJLgmWUah2cJqhegzsCBAYFAhWBaSKBVzMaCBsVOyoBgj4+EhgNj?= =?us-ascii?q?S8XFYhPhUM/AzCPXQEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.72,378,1580774400"; d="scan'208";a="22956740" 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; 13 Apr 2020 11:37:16 +0000 Received: from ams3-vpn-dhcp906.cisco.com (ams3-vpn-dhcp906.cisco.com [10.61.67.138]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03DBbFUp012221 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Apr 2020 11:37:16 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Mon, 13 Apr 2020 13:37:15 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <27c5e9d9-7c8a-985e-2fb1-99ccb50af9a7@cs.tcd.ie> <3A5AEC71-74DB-4FDF-B849-F2343959C903@csperkins.org> <20200411114523.GB2429@sources.org> To: Niels ten Oever X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.67.138, ams3-vpn-dhcp906.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] [hrpc] The relevance of RFCs // was: Possible options for a HRPC research publication X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 Apr 2020 11:37:22 -0000 Niels, Can I encourage you to keep an eye on the RFC Editor Futures program? = That=E2=80=99s a really nice note you wrote, and it is worth someone = saying that maybe not everything is broken. Eliot > On 13 Apr 2020, at 13:06, Niels ten Oever = wrote: >=20 > Hi all, >=20 > In discussions here and on other mailinglists, some have criticized = the format of I-D and RFCs, the workings of the datatracker, the = slightly archaic nature of mailinglists and other tools that we use. I, = however, would like to shortly note how important I-D's, RFC's, = mailinglists, and the datatracker have been in my research, my = involvement in this field, and how extraordinary it is that it is = possible to find documents, notes, and presentations going back to 1969. = While there is indeed a learning curve, the reward for traveling that = curve is access to a huge wealth of highly consistent information in a = very structured archive.=20 >=20 > In many different kinds of organizations it is hardly possible to find = documents from just a few years back, let alone finding them in the same = format and context. This is true for NGOs, universities, private = corporations, governance bodies, and sadly also governments.=20 >=20 > Furthermore, RFC's for me embody a relational understanding of = infrastructure that combines hardware, software, and wetware, or in the = vernacular of another field: technological materiality, institutional = ordering, economic drivers, and epistemic communities. For me, this is = an important argument to keep on using RFCs and I-Ds (and by extension = also mailinglists and the datatrackers), to keep this practice alive, by = testing and expanding it with new, and sometimes relevant, = contributions.=20 >=20 > Best, >=20 > Niels >=20 >=20 > On 4/11/20 1:52 PM, Colin Perkins wrote: >>> On 11 Apr 2020, at 12:45, Stephane Bortzmeyer = wrote: >>> On Wed, Apr 08, 2020 at 11:06:22AM +0100, Colin Perkins = wrote a message of 352 lines which said: >>>=20 >>>> we could also work with an appropriate academic publisher to = publish >>>> archival proceedings, >>>=20 >>> A warning: many (most?) "academic publishers" actively prevent the >>> free distribution of the articles they publish. If the RG were to >>> publish anything as a group, it MUST be in a way that will allow = free >>> redistribution (as it is the case for the RFCs, see RFC 8721.) No >>> Springer-Verlag or Elsevier in the loop. >>=20 >> I=E2=80=99m well aware of these issues, but thank you for the = reminder. >>=20 >=20 > --=20 > Niels ten Oever > Researcher and PhD Candidate > DATACTIVE Research Group > University of Amsterdam >=20 > PGP fingerprint 2458 0B70 5C4A FD8A 9488 =20 > 643A 0ED8 3F3A 468A C8B3 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Tue Apr 14 07:44:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC433A0860 for ; Tue, 14 Apr 2020 07:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mtgryc-USY6d for ; Tue, 14 Apr 2020 07:44:21 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783133A0858 for ; Tue, 14 Apr 2020 07:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5062; q=dns/txt; s=iport; t=1586875461; x=1588085061; h=from:mime-version:subject:message-id:date:to; bh=6jyvH+HxePR/WF6E1XcEticH6/LBfRHUEv5otUZ2tz8=; b=mWj+/JXQkFyASwiRWxW4BF/bqi+QtpkalaxajKRKBr74UqlsE/5kvvC5 jLGTrND2vZzBDu0Kah4zbm4nUgHWr2DLma3SU634QvfiCpEPxrJgFefvJ f7WlRsPbPVG1MRa/ZpYo5sklH4nNb4zV62Z+fiA6F0o7D4yUnzKiqXg1l I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArCACDy5Ve/xbLJq1mHgELHIF9gXu?= =?us-ascii?q?BJ0YgEoRGiQKbT4gJCgEBAQwBAS8EAQGEPwOCKzkFDQIDAQELAQEFAQEBAgE?= =?us-ascii?q?FBG2FKgcxhhpRJD4ChBiCfZ8WjhF1gTKFToR+gTiMT4IAgTgcghgHAQGGBYJ?= =?us-ascii?q?FMoIsBLFXgkwEgmGUax2cKahigzsCBAYFAhWBaiGBVzMaCBsVZQGCPz0SGA2?= =?us-ascii?q?QYopUAQ6NFD8Dj3ABAQ?= X-IronPort-AV: E=Sophos; i="5.72,382,1580774400"; d="scan'208,217"; a="25256674" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Apr 2020 14:44:18 +0000 Received: from ams3-vpn-dhcp933.cisco.com (ams3-vpn-dhcp933.cisco.com [10.61.67.165]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 03EEiHB8010240 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Apr 2020 14:44:18 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_8853E93E-A53A-4268-B728-F66BCADF76CA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> Date: Tue, 14 Apr 2020 16:44:17 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.67.165, ams3-vpn-dhcp933.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 14 Apr 2020 14:44:24 -0000 --Apple-Mail=_8853E93E-A53A-4268-B728-F66BCADF76CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, As there were no objections to the work program, it is adopted. It is, = of course, subject to change, and I=E2=80=99m sure it will as we need to = get more detailed. But here it is for now: Open up =E2=80=9Cthe floor=E2=80=9D for short problem statements that = people think we need to address. We should be clear on what we see as = problems and their scope. See if we can get agreement on those. Open up =E2=80=9Cthe floor=E2=80=9D for proposals on how to solve those = problems. See if we can get agreement on those. We=E2=80=99re now in step 1. Now is your opportunity to put forth a = view in a form such as =E2=80=9Chere=E2=80=99s what good looks like" = statement or =E2=80=9Chere are the problems I am seeking to solve=E2=80=9D= , or in some way you believe will advance the discussion, but focusing = on your goals for this effort. There is no set time to move beyond this stage. Once we have a few = people=E2=80=99s visions, then I think we can worry about dates. Again, = I plan to schedule some roundtable discussions in May. It would be = desirable to have views from people in advance, but it is not required. = Again, those discussions are just an opportunity to share views and ask = questions, as a means toward getting passed step 2 over time. So.. what=E2=80=99s your vision? Eliot --Apple-Mail=_8853E93E-A53A-4268-B728-F66BCADF76CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone,

As there = were no objections to the work program, it is adopted.  It is, of = course, subject to change, and I=E2=80=99m sure it will as we need to = get more detailed.  But here it is for now:
  1. Open up =E2=80=9Cthe floor=E2=80=9D for short = problem statements that people think we need to address. We should be = clear on what we see as problems and their scope.
  2. See if we can get agreement = on those.
  3. Open up =E2=80=9Cthe floor=E2=80= =9D for proposals on how to solve those problems.
  4. See if = we can get agreement on those.
We=E2=80=99re now in = step 1.  Now is your opportunity to put forth a view in a form such as  =E2=80=9Chere=E2=80=99s what = good looks like" statement or =E2=80=9Chere are the problems I am = seeking to solve=E2=80=9D, or in some way you believe will advance the = discussion, but focusing on your goals for this = effort.

There is no set time to = move beyond this stage.  Once we have a few people=E2=80=99s = visions, then I think we can worry about dates.  Again, I plan to = schedule some roundtable discussions in May.  It would be desirable = to have views from people in advance, but it is not required. =  Again, those discussions are just an opportunity to share = views and ask questions, as a means toward getting passed step = 2 over time.

So.. what=E2=80=99s your = vision?

Eliot


= --Apple-Mail=_8853E93E-A53A-4268-B728-F66BCADF76CA-- From nobody Tue Apr 14 11:58:41 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739843A0B38 for ; Tue, 14 Apr 2020 11:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSs265EvHl-U for ; Tue, 14 Apr 2020 11:58:39 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C413A0B36 for ; Tue, 14 Apr 2020 11:58:39 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jOQlV-00083U-1E; Tue, 14 Apr 2020 14:58:33 -0400 Date: Tue, 14 Apr 2020 14:58:27 -0400 From: John C Klensin To: Eliot Lear , Niels ten Oever cc: rfced-future@iab.org Message-ID: <6D8E133CEAE711FFBF7771A7@PSB> In-Reply-To: References: <27c5e9d9-7c8a-985e-2fb1-99ccb50af9a7@cs.tcd.ie> <3A5AEC71-74DB-4FDF-B849-F2343959C903@csperkins.org> <20200411114523.GB2429@sources.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] [hrpc] The relevance of RFCs // was: Possible options for a HRPC research publication X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 14 Apr 2020 18:58:41 -0000 Eliot (and others), Niels's note, which I also appreciate, is also a reminder that the collection of issues we lump together under "archival" are important. In the next day or three, I will try to work that --and the distinctions between things I think are part of the RSE job description and qualifications-- into the problem statement form you asked for, but for the moment, I think it is worth noting. thanks, john --On Monday, April 13, 2020 13:37 +0200 Eliot Lear wrote: > Niels, > > Can I encourage you to keep an eye on the RFC Editor Futures > program? That's a really nice note you wrote, and it is > worth someone saying that maybe not everything is broken. > > Eliot > >> On 13 Apr 2020, at 13:06, Niels ten Oever >> wrote: >> >> Hi all, >> >> In discussions here and on other mailinglists, some have >> criticized the format of I-D and RFCs, the workings of the >> datatracker, the slightly archaic nature of mailinglists and >> other tools that we use. I, however, would like to shortly >> note how important I-D's, RFC's, mailinglists, and the >> datatracker have been in my research, my involvement in this >> field, and how extraordinary it is that it is possible to >> find documents, notes, and presentations going back to 1969. >> While there is indeed a learning curve, the reward for >> traveling that curve is access to a huge wealth of highly >> consistent information in a very structured archive. >> >> In many different kinds of organizations it is hardly >> possible to find documents from just a few years back, let >> alone finding them in the same format and context. This is >> true for NGOs, universities, private corporations, governance >> bodies, and sadly also governments. >> >> Furthermore, RFC's for me embody a relational understanding >> of infrastructure that combines hardware, software, and >> wetware, or in the vernacular of another field: technological >> materiality, institutional ordering, economic drivers, and >> epistemic communities. For me, this is an important argument >> to keep on using RFCs and I-Ds (and by extension also >> mailinglists and the datatrackers), to keep this practice >> alive, by testing and expanding it with new, and sometimes >> relevant, contributions. >> >> Best, >> >> Niels >> >> >> On 4/11/20 1:52 PM, Colin Perkins wrote: >>>> On 11 Apr 2020, at 12:45, Stephane Bortzmeyer >>>> wrote: On Wed, Apr 08, 2020 at >>>> 11:06:22AM +0100, Colin Perkins wrote a >>>> message of 352 lines which said: >>>> >>>>> we could also work with an appropriate academic publisher >>>>> to publish archival proceedings, >>>> >>>> A warning: many (most?) "academic publishers" actively >>>> prevent the free distribution of the articles they publish. >>>> If the RG were to publish anything as a group, it MUST be >>>> in a way that will allow free redistribution (as it is the >>>> case for the RFCs, see RFC 8721.) No Springer-Verlag or >>>> Elsevier in the loop. >>> >>> I'm well aware of these issues, but thank you for the >>> reminder. >>> >> >> -- >> Niels ten Oever >> Researcher and PhD Candidate >> DATACTIVE Research Group >> University of Amsterdam >> >> PGP fingerprint 2458 0B70 5C4A FD8A 9488 >> 643A 0ED8 3F3A 468A C8B3 >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc From nobody Tue Apr 14 12:31:16 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393C73A0D8D for ; Tue, 14 Apr 2020 12:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyC5qy4PGfqg for ; Tue, 14 Apr 2020 12:31:12 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B010A3A0D8B for ; Tue, 14 Apr 2020 12:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3946; q=dns/txt; s=iport; t=1586892671; x=1588102271; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8fzrL5TAgJrf0OUClcCiF/3DBoAiLsNkGrDRAX1Cd78=; b=bgxG808M6SIf74X0CLU9gOWTVUEhqfvQU7QudJGzVuP5nbG8JNSbGeVJ oUCgpfnuNAvTWrlzoaqTfarhq/W8+2lD0GiZkIVooBBvf/VNpM3ljVdrI dT71cCErk7YrJ4lioNb8syUMgmGbWgkBLMkUQ7j73cFO/DZF7UWwb0Nif 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BkAACxDpZe/xbLJq1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gxVVIBIqjR6IDptMCgEBAQwBARgLDAQBAYF?= =?us-ascii?q?QgnQCgic4EwIDAQELAQEFAQEBAgEFBG2FVgyFcAEBAQECAQEBODMBBAcFCws?= =?us-ascii?q?YIwsnMAYTgyYBglwgD65WgieFToUCBoE4jE+CAIERJxyCHy4+gmcBA4FBAQG?= =?us-ascii?q?DZIIsBJhFlwyCBoJMgmWUax2cKahigzsCBAYFAhWBaSKBVzMaCBsVOyoBgj4?= =?us-ascii?q?+EhgNmhsXFYhPhUM/AzACjz4BAQ?= X-IronPort-AV: E=Sophos;i="5.72,384,1580774400"; d="scan'208";a="25322533" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Apr 2020 19:31:09 +0000 Received: from ams3-vpn-dhcp933.cisco.com (ams3-vpn-dhcp933.cisco.com [10.61.67.165]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03EJV8KE017477 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Apr 2020 19:31:09 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <6D8E133CEAE711FFBF7771A7@PSB> Date: Tue, 14 Apr 2020 21:31:07 +0200 Cc: Niels ten Oever , rfced-future@iab.org Content-Transfer-Encoding: 7bit Message-Id: References: <27c5e9d9-7c8a-985e-2fb1-99ccb50af9a7@cs.tcd.ie> <3A5AEC71-74DB-4FDF-B849-F2343959C903@csperkins.org> <20200411114523.GB2429@sources.org> <6D8E133CEAE711FFBF7771A7@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.67.165, ams3-vpn-dhcp933.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] [hrpc] The relevance of RFCs // was: Possible options for a HRPC research publication X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 14 Apr 2020 19:31:14 -0000 Thanks, John. Looking forward to it. Eliot > On 14 Apr 2020, at 20:58, John C Klensin wrote: > > Eliot (and others), > > Niels's note, which I also appreciate, is also a reminder that > the collection of issues we lump together under "archival" are > important. In the next day or three, I will try to work that > --and the distinctions between things I think are part of the > RSE job description and qualifications-- into the problem > statement form you asked for, but for the moment, I think it is > worth noting. > > thanks, > john > > > --On Monday, April 13, 2020 13:37 +0200 Eliot Lear > wrote: > >> Niels, >> >> Can I encourage you to keep an eye on the RFC Editor Futures >> program? That's a really nice note you wrote, and it is >> worth someone saying that maybe not everything is broken. >> >> Eliot >> >>> On 13 Apr 2020, at 13:06, Niels ten Oever >>> wrote: >>> >>> Hi all, >>> >>> In discussions here and on other mailinglists, some have >>> criticized the format of I-D and RFCs, the workings of the >>> datatracker, the slightly archaic nature of mailinglists and >>> other tools that we use. I, however, would like to shortly >>> note how important I-D's, RFC's, mailinglists, and the >>> datatracker have been in my research, my involvement in this >>> field, and how extraordinary it is that it is possible to >>> find documents, notes, and presentations going back to 1969. >>> While there is indeed a learning curve, the reward for >>> traveling that curve is access to a huge wealth of highly >>> consistent information in a very structured archive. >>> >>> In many different kinds of organizations it is hardly >>> possible to find documents from just a few years back, let >>> alone finding them in the same format and context. This is >>> true for NGOs, universities, private corporations, governance >>> bodies, and sadly also governments. >>> >>> Furthermore, RFC's for me embody a relational understanding >>> of infrastructure that combines hardware, software, and >>> wetware, or in the vernacular of another field: technological >>> materiality, institutional ordering, economic drivers, and >>> epistemic communities. For me, this is an important argument >>> to keep on using RFCs and I-Ds (and by extension also >>> mailinglists and the datatrackers), to keep this practice >>> alive, by testing and expanding it with new, and sometimes >>> relevant, contributions. >>> >>> Best, >>> >>> Niels >>> >>> >>> On 4/11/20 1:52 PM, Colin Perkins wrote: >>>>> On 11 Apr 2020, at 12:45, Stephane Bortzmeyer >>>>> wrote: On Wed, Apr 08, 2020 at >>>>> 11:06:22AM +0100, Colin Perkins wrote a >>>>> message of 352 lines which said: >>>>> >>>>>> we could also work with an appropriate academic publisher >>>>>> to publish archival proceedings, >>>>> >>>>> A warning: many (most?) "academic publishers" actively >>>>> prevent the free distribution of the articles they publish. >>>>> If the RG were to publish anything as a group, it MUST be >>>>> in a way that will allow free redistribution (as it is the >>>>> case for the RFCs, see RFC 8721.) No Springer-Verlag or >>>>> Elsevier in the loop. >>>> >>>> I'm well aware of these issues, but thank you for the >>>> reminder. >>>> >>> >>> -- >>> Niels ten Oever >>> Researcher and PhD Candidate >>> DATACTIVE Research Group >>> University of Amsterdam >>> >>> PGP fingerprint 2458 0B70 5C4A FD8A 9488 >>> 643A 0ED8 3F3A 468A C8B3 >>> >>> _______________________________________________ >>> hrpc mailing list >>> hrpc@irtf.org >>> https://www.irtf.org/mailman/listinfo/hrpc > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Apr 15 01:52:55 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A063A077F for ; Wed, 15 Apr 2020 01:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ihwuubAxn8F6 for ; Wed, 15 Apr 2020 01:52:52 -0700 (PDT) Received: from [192.168.1.49] (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 545A63A0775 for ; Wed, 15 Apr 2020 01:52:52 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3CF427F4-2299-40A0-8B1F-5CAB78690C1B Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Message-Id: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> Date: Wed, 15 Apr 2020 20:52:49 +1200 To: rfced-future@iab.org X-Mailer: iPad Mail (17D50) Archived-At: Subject: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 08:52:54 -0000 --Apple-Mail-3CF427F4-2299-40A0-8B1F-5CAB78690C1B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =EF=BB=BF =EF=BB=BFGiven my role, before sending this I asked Eliot about both the app= ropriateness of me doing so and the content and his view is that it is very i= mportant that I send this, so here goes.=20 I have some observations regarding issues around the RSE role which have dev= eloped from my unusual position. However, I am acutely aware that I am still= very much a newcomer and so while I have tried to sanity check these with o= thers, there is a chance I may have misunderstood something and may be misre= presenting a situation, for which I apologise in advance.=20 My observations are: 1. Over the last 1-2 years the move to the v3 XML has brought with it some v= ery technical issues and as a result the RSE role is a far more technical th= an the various role specifications recognise. The RSE currently needs to be= quite technically proficient in XML and specific vocabularies such as HTML a= nd SVG; XML schemas and translators; SDLC including versioning, testing, UX a= nd more; and archival formats and methods. If the trend continues then in t= he future they may also need to be proficient in ontologies and RDF.=20 2. There have been multiple changes proposed for the v3 XML that have led t= o conflict between those tasked with implementing them and members of the co= mmunity who would do things differently. This highlights a gap - there shou= ld be a process for these proposed changes to be evaluated by a larger indep= endent group who then decide amongst the competing views on whether the chan= ge is implemented and if so how. Possibly by default that decision making a= uthority sits with the RSE but they do not appear to have exercised that aut= hority and so those implementing have done the best they can.=20 3. One of the key tasks of the RSE that has been mentioned several times ha= s been to help us end up with a strategy for the RFC Series, by whatever mea= ns are appropriate. However there does not seem to be one, nor a process to= create one (excepting this program) and there are a number of current issu= es that are clearly strategic, including: - the RFC Series is regarded by some as immutable and yet others are concern= ed that this means that implementers/researchers miss vital errata, which in= turn has significant flow on problems. The various solutions to this inclu= de versioning of RFCs, changing the presentation context to focus on an erra= ta annotated version while still maintaining immutability or just dropping i= mmutability. - there is no easy way for people to find the current set of RFCs related to= a specific technology that they wish to implement/study. - and while we understand the concept of the "official" tool to transform th= e canonical XML into a readable output (xml2rfc) the position we are in is t= hat this really is the only reliable and fully featured tool, for a variety o= f reasons and it=E2=80=99s not clear if that is understood and accepted or i= f we need to ensure diversity, say by a published detailed specification of t= he output or transformation rules so that a third party can implement an alt= ernative. I realise these are all quite practical compared to the loftier questions of= how do we ensure the RFC Series is here in 50 years. Also, to be clear I d= on=E2=80=99t have a view on any of these, other than a general goal of seein= g this all tidied up. Jay --=20 Jay Daley IETF Executive Director --Apple-Mail-3CF427F4-2299-40A0-8B1F-5CAB78690C1B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=EF=BB=BF
=EF=BB= =BF= Given my role, before sending this I asked Eliot about both the appropriaten= ess of me doing so and the content and his view is that it is very important= that I send this, so here goes. 

I have some observations regarding issues around the RSE= role which have developed from my unusual position. However, I am acutely a= ware that I am still very much a newcomer and so while I have tried to sanit= y check these with others, there is a chance I may have misunderstood someth= ing and may be misrepresenting a situation, for which I apologise in advance= . 

My observations are:

1.  Ove= r the last 1-2 years the move to the v3 XML has brought with it some very te= chnical issues and as a result the RSE role is a far more technical than the= various role specifications recognise.  The RSE currently needs to be q= uite technically proficient in XML and specific vocabularies such as HTML an= d SVG; XML schemas and translators; SDLC including versioning, testing, UX a= nd more; and archival formats and methods.  If the trend continues then= in the future they may also need to be proficient in ontologies and RDF.&nb= sp;

2.  There have bee= n multiple changes proposed for the v3 XML that have led to conflict between= those tasked with implementing them and members of the community who would d= o things differently.  This highlights a gap - there should be a proces= s for these proposed changes to be evaluated by a larger independent group w= ho then decide amongst the competing views on whether the change is implemen= ted and if so how.  Possibly by default that decision making authority s= its with the RSE but they do not appear to have exercised that authority and= so those implementing have done the best they can. 

3.  One of the key tasks of the RSE that= has been mentioned several times has been to help us end up with a strategy= for the RFC Series, by whatever means are appropriate.  However there d= oes not seem to be one, nor a process to create one (excepting this program)= and there are a number of  current issues that are clearly strategic, i= ncluding:

- the RFC Series i= s regarded by some as immutable and yet others are concerned that this means= that implementers/researchers miss vital errata, which in turn has signific= ant flow on problems.  The various solutions to this include versioning= of RFCs, changing the presentation context to focus on an errata annotated v= ersion while still maintaining immutability or just dropping immutability.

= - there is no easy way for p= eople to find the current set of RFCs related to a specific technology that t= hey wish to implement/study.




I realise these are all quite practical compared to the loftier questi= ons of how do we ensure the RFC Series is here in 50 years.  Also, to b= e clear I don=E2=80=99t have a view on any of these, other than a general go= al of seeing this all tidied up.

Jay
-- 
Jay Daley
IETF Executive D= irector

= --Apple-Mail-3CF427F4-2299-40A0-8B1F-5CAB78690C1B-- From nobody Wed Apr 15 02:40:34 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81B63A08E0 for ; Wed, 15 Apr 2020 02:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdHP2XVcVVNA for ; Wed, 15 Apr 2020 02:40:29 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F273A08DB for ; Wed, 15 Apr 2020 02:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12394; q=dns/txt; s=iport; t=1586943629; x=1588153229; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ny9ZMN/5TgzV+6clIrG5wNDle9LYau26qdPY71zrvBk=; b=g5nZutMrkbj+KOkP1AEMrxoy7gyGzFCIpcV1MecMuGwLSrQkUE+NU82E I8MvsB7I2NmEEigamFPJSf4wNq4ErsIUKCzk1d+9man8L/nwpkcHK4GUW gdj3Tc28Q7UkFTLLkEkkYGW81aba/eO1wEvRibChxsWBd7oaPTxJpFfqf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAACP1ZZe/xbLJq1gBhoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBe4ElU4EdVSASKoQciQKHaCWTRIgJCgEBAQw?= =?us-ascii?q?BARgBCgwEAQGERAKCJzgTAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQIBAQE?= =?us-ascii?q?hSwQHBQsJAhgqAgInMAYTFAeDCwGCXCAPkk6bBHWBMoVPhQQGgTiMUIIAgRE?= =?us-ascii?q?nDBCCTT6CZwGBVoMiMoItBLFhgkyCZZRuHZwuqHODPQIEBgUCFYFpIoFXMxo?= =?us-ascii?q?IGxU7KgGCPj4SGA2aX4VDPwMwj0UBAQ?= X-IronPort-AV: E=Sophos; i="5.72,386,1580774400"; d="scan'208,217"; a="25343816" 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; 15 Apr 2020 09:40:27 +0000 Received: from ams3-vpn-dhcp933.cisco.com (ams3-vpn-dhcp933.cisco.com [10.61.67.165]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03F9eP07031111 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Apr 2020 09:40:26 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0E66A6A6-3720-4D96-B9C5-723D4D556C82" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 15 Apr 2020 11:40:25 +0200 In-Reply-To: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> Cc: rfced-future@iab.org To: Jay Daley References: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.67.165, ams3-vpn-dhcp933.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 09:40:33 -0000 --Apple-Mail=_0E66A6A6-3720-4D96-B9C5-723D4D556C82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you, Jay. I agree that your perspective is very important and = very welcome. I ask program members to take Jay=E2=80=99s comments = under advisement as we go forward. He raises a number of important = points about both the job qualifications and responsibilities of the = RSE, and discusses the relationship between the RSE, the series, and the = community. Eliot > On 15 Apr 2020, at 10:52, Jay Daley wrote: >=20 > =EF=BB=BF > =EF=BB=BFGiven my role, before sending this I asked Eliot about both = the appropriateness of me doing so and the content and his view is that = it is very important that I send this, so here goes.=20 >=20 > I have some observations regarding issues around the RSE role which = have developed from my unusual position. However, I am acutely aware = that I am still very much a newcomer and so while I have tried to sanity = check these with others, there is a chance I may have misunderstood = something and may be misrepresenting a situation, for which I apologise = in advance..=20 >=20 > My observations are: >=20 > 1. Over the last 1-2 years the move to the v3 XML has brought with it = some very technical issues and as a result the RSE role is a far more = technical than the various role specifications recognise. The RSE = currently needs to be quite technically proficient in XML and specific = vocabularies such as HTML and SVG; XML schemas and translators; SDLC = including versioning, testing, UX and more; and archival formats and = methods. If the trend continues then in the future they may also need = to be proficient in ontologies and RDF.=20 >=20 > 2. There have been multiple changes proposed for the v3 XML that have = led to conflict between those tasked with implementing them and members = of the community who would do things differently. This highlights a gap = - there should be a process for these proposed changes to be evaluated = by a larger independent group who then decide amongst the competing = views on whether the change is implemented and if so how. Possibly by = default that decision making authority sits with the RSE but they do not = appear to have exercised that authority and so those implementing have = done the best they can.=20 >=20 > 3. One of the key tasks of the RSE that has been mentioned several = times has been to help us end up with a strategy for the RFC Series, by = whatever means are appropriate. However there does not seem to be one, = nor a process to create one (excepting this program) and there are a = number of current issues that are clearly strategic, including: >=20 > - the RFC Series is regarded by some as immutable and yet others are = concerned that this means that implementers/researchers miss vital = errata, which in turn has significant flow on problems. The various = solutions to this include versioning of RFCs, changing the presentation = context to focus on an errata annotated version while still maintaining = immutability or just dropping immutability. >=20 > - there is no easy way for people to find the current set of RFCs = related to a specific technology that they wish to implement/study. >=20 > - and while we understand the concept of the "official" tool to = transform the canonical XML into a readable output (xml2rfc) the = position we are in is that this really is the only reliable and fully = featured tool, for a variety of reasons and it=E2=80=99s not clear if = that is understood and accepted or if we need to ensure diversity, say = by a published detailed specification of the output or transformation = rules so that a third party can implement an alternative. >=20 >=20 > I realise these are all quite practical compared to the loftier = questions of how do we ensure the RFC Series is here in 50 years. Also, = to be clear I don=E2=80=99t have a view on any of these, other than a = general goal of seeing this all tidied up. >=20 > Jay > --=20 > Jay Daley > IETF Executive Director >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_0E66A6A6-3720-4D96-B9C5-723D4D556C82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you, Jay.  I agree that your perspective is very important and = very welcome.  I ask program members to take Jay=E2=80=99s comments = under advisement as we go forward.  He raises a number of important = points about both the job qualifications and responsibilities of the = RSE, and discusses the relationship between the RSE, the series, and the = community.

Eliot

On 15 Apr 2020, at 10:52, Jay = Daley <jay@ietf.org> = wrote:

=EF=BB=BF
=EF=BB=BFGiven my role, = before sending this I asked Eliot about both the appropriateness of me = doing so and the content and his view is that it is very important that = I send this, so here goes. 

I have some observations regarding issues around the = RSE role which have developed from my unusual position. However, I am = acutely aware that I am still very much a newcomer and so while I have = tried to sanity check these with others, there is a chance I may have = misunderstood something and may be misrepresenting a situation, for = which I apologise in advance.. 

My observations are:

1.  Over the = last 1-2 years the move to the v3 XML has brought with it some very = technical issues and as a result the RSE role is a far more technical = than the various role specifications recognise.  The RSE currently = needs to be quite technically proficient in XML and specific = vocabularies such as HTML and SVG; XML schemas and translators; SDLC = including versioning, testing, UX and more; and archival formats and = methods.  If the trend continues then in the future they may also = need to be proficient in ontologies and RDF. 

2.  There have = been multiple changes proposed for the v3 XML that have led to conflict = between those tasked with implementing them and members of the community = who would do things differently.  This highlights a gap - there = should be a process for these proposed changes to be evaluated by a = larger independent group who then decide amongst the competing views on = whether the change is implemented and if so how.  Possibly by = default that decision making authority sits with the RSE but they do not = appear to have exercised that authority and so those implementing have = done the best they can. 

3. =  One of the key tasks of the RSE that has been mentioned several = times has been to help us end up with a strategy for the RFC Series, by = whatever means are appropriate.  However there does not seem to be = one, nor a process to create one (excepting this program) and there are = a number of  current issues that are clearly strategic, = including:

- = the RFC Series is regarded by some as immutable and yet others are = concerned that this means that implementers/researchers miss vital = errata, which in turn has significant flow on problems.  The = various solutions to this include versioning of RFCs, changing the = presentation context to focus on an errata annotated version while still = maintaining immutability or just dropping immutability.

- there is no easy = way for people to find the current set of RFCs related to a specific = technology that they wish to implement/study.

- and while we = understand the concept of the "official" tool to transform the canonical = XML into a readable output (xml2rfc) the position we are in is that this = really is the only reliable and fully featured tool, for a variety of = reasons and it=E2=80=99s not clear if that is understood and accepted or = if we need to ensure diversity, say by a published detailed = specification of the output or transformation rules so that a third = party can implement an alternative.


I realise these are = all quite practical compared to the loftier questions of how do we = ensure the RFC Series is here in 50 years.  Also, to be clear I = don=E2=80=99t have a view on any of these, other than a general goal of = seeing this all tidied up.

Jay
-- 
Jay Daley
IETF = Executive Director

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

= --Apple-Mail=_0E66A6A6-3720-4D96-B9C5-723D4D556C82-- From nobody Wed Apr 15 02:55:01 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EC03A0943; Wed, 15 Apr 2020 02:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=1.496, 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 aZXYZ-Ci1R8m; Wed, 15 Apr 2020 02:54:58 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956073A093E; Wed, 15 Apr 2020 02:54:56 -0700 (PDT) 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 03F9ssux012730; Wed, 15 Apr 2020 10:54:54 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 03D962203C; Wed, 15 Apr 2020 10:54:54 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id E2DFF2203B; Wed, 15 Apr 2020 10:54:53 +0100 (BST) Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 03F9sqrL002170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Apr 2020 10:54:53 +0100 Reply-To: From: "Adrian Farrel" To: "'Jay Daley'" , References: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> In-Reply-To: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> Date: Wed, 15 Apr 2020 10:54:52 +0100 Organization: Old Dog Consulting Message-ID: <018301d6130b$e9784670$bc68d350$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0184_01D61314.4B3D71C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJCtcf0fP+e+FQ2kNfE5P5qAvDfyaegqUuQ Content-Language: en-gb X-Originating-IP: 81.174.202.163 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25356.006 X-TM-AS-Result: No--4.055-10.0-31-10 X-imss-scan-details: No--4.055-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25356.006 X-TMASE-Result: 10--4.054900-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbEsh+mzT1UnbI+eq7xVYCexUfXVYXWap+6PV muMtM5/Pyg6kqq/YldMCzawj2+r7kkPcdQi3PsbaGUlF/M3Dxp8yJlZlUbAvWOQydRUvl3QTTNx ZH+hZvXlx23r6JJGo9EBaI8OFDuv5N2+T837spRRZZYpuBxXlgBfbPFE2GHrV7LfBOpVXCgofic /Go6r8foEE5XWVA8ySAqZEnKSakVS4vpKu9/6gMUaWd/E1q2OcJVsoL7U3JcALBZEuqIL9Sk6pP lwz1wfxx5D/RIPCu5YvOsBTrWD9v27SBWE1dUMEnMRCqQzD5ecGchEhVwJY39vgL7Kv8y9BynUn YJFj6EgpAMu8zeSHTlBlcJSQo/8uR7lYkqI/pTuU2iZ1nIhYohP3Pgti+Dl54nhkC0SGkyRjEak f3HNdv1Ufg6T11JtCO/LMo3XIQl2YizZS4XBb3/lZlPYYWH6djVfykf2JO25XPwnnY5XL5Iy+Af TlDGN1hVSDyDKrGf3I1fP/DfsXMOu4vhxo9ANTA9lly13c/gFOYZ1u5ywmiQp2l9r0rJf/16igZ gQjXbcRreDEzbQSsJh3qtKX/dE/hh8XWqWW21rdfjaNBxFEbX2K69afcnwqryGlv4LWKt/jFYq3 ZPjOgMW8KKPuVLb2gUsGZzEak9WGFN7r+9GAiy8s/ULwMh46EDnDEqNPdupIMgsS03z+HxAIU3N IDnbujarGzLKPFi5Q6Tq0B4xUY1oUlRudBmAPiJwEp8weVXwujMj6uE1huSvFSzw3D/Z+Qh5NBG AiQ4bMAfwvCTW5AtRVvIPvJvSBb581EchakiOeAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg4VH0dq7wY7uPBqfGgCPibxijJDchDpuQgfSd+qmSH8sDPAB0gMU28dm/H14WfGkSlgLst85 Y1yvBL7EnPpz470N+Ixyz8R5xz83ptoGSFOztso58cSxh4zDrk7HbOy/dZ7e8y7tH8BeygHMtSW gsxu+7WmCjmPMmmZL5LL4dwMcgdALPtdUanzq+96e6e1JHkfFNzc6ioj1WClYJu9r4yY= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 09:55:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0184_01D61314.4B3D71C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jay, =20 Your =E2=80=98newcomer=E2=80=99 and =E2=80=98practical=E2=80=99 view of = this is appreciated (by me). =20 On your second point, I see the gap that, =E2=80=9CThere should be a = process for these proposed changes to be evaluated,=E2=80=9D but I = don=E2=80=99t see how you arrive at, =E2=80=9CBy a larger independent = group.=E2=80=9D I=E2=80=99m not saying that I think having a larger = group is right or wrong, but I am asking you to show your workings. For = example, why would it be wrong for the RSE to make the decision? =20 On your third point, you say, =E2=80=9CHelp us end up with a = strategy.=E2=80=9D One could argue that there has been a strategy in = place all along, and that the RSE both established and delivered that = strategy. That argument might need to be accompanied by a statement = that, =E2=80=9CIt was not obvious to all following the topic what the = strategy was nor how it was being delivered.=E2=80=9D=20 =20 Your bullet points that follow, raise a number of issues that come = around on the rinse-and-repeat cycle. Raising these points establishes = the meta point of whether the RSE sets policies / resolutions for these = and similar issues, or whether the RSE is tasked to deliver on the = wishes of the community (even when those wishes go against the = professional opinion of the RSE). This meta point cuts, I think, to the = core of the problem: whose RFC Series is it; who makes the decisions; is = the RSE the owner, a consultant, or a servant? =20 Best, Adrian =20 From: Rfced-future On Behalf Of Jay Daley Sent: 15 April 2020 09:53 To: rfced-future@iab.org Subject: [Rfced-future] Observations on issues =20 =EF=BB=BF =EF=BB=BFGiven my role, before sending this I asked Eliot about both the = appropriateness of me doing so and the content and his view is that it = is very important that I send this, so here goes.=20 =20 I have some observations regarding issues around the RSE role which have = developed from my unusual position. However, I am acutely aware that I = am still very much a newcomer and so while I have tried to sanity check = these with others, there is a chance I may have misunderstood something = and may be misrepresenting a situation, for which I apologise in = advance..=20 =20 Your strategic bullet points that follow are, indeed, questions that = come around on the=20 My observations are: 1. Over the last 1-2 years the move to the v3 XML has brought with it = some very technical issues and as a result the RSE role is a far more = technical than the various role specifications recognise. The RSE = currently needs to be quite technically proficient in XML and specific = vocabularies such as HTML and SVG; XML schemas and translators; SDLC = including versioning, testing, UX and more; and archival formats and = methods. If the trend continues then in the future they may also need = to be proficient in ontologies and RDF.=20 2. There have been multiple changes proposed for the v3 XML that have = led to conflict between those tasked with implementing them and members = of the community who would do things differently. This highlights a gap = - there should be a process for these proposed changes to be evaluated = by a larger independent group who then decide amongst the competing = views on whether the change is implemented and if so how. Possibly by = default that decision making authority sits with the RSE but they do not = appear to have exercised that authority and so those implementing have = done the best they can.=20 3. One of the key tasks of the RSE that has been mentioned several = times has been to help us end up with a strategy for the RFC Series, by = whatever means are appropriate. However there does not seem to be one, = nor a process to create one (excepting this program) and there are a = number of current issues that are clearly strategic, including: - the RFC Series is regarded by some as immutable and yet others are = concerned that this means that implementers/researchers miss vital = errata, which in turn has significant flow on problems. The various = solutions to this include versioning of RFCs, changing the presentation = context to focus on an errata annotated version while still maintaining = immutability or just dropping immutability. - there is no easy way for people to find the current set of RFCs = related to a specific technology that they wish to implement/study. - and while we understand the concept of the "official" tool to = transform the canonical XML into a readable output (xml2rfc) the = position we are in is that this really is the only reliable and fully = featured tool, for a variety of reasons and it=E2=80=99s not clear if = that is understood and accepted or if we need to ensure diversity, say = by a published detailed specification of the output or transformation = rules so that a third party can implement an alternative. I realise these are all quite practical compared to the loftier = questions of how do we ensure the RFC Series is here in 50 years. Also, = to be clear I don=E2=80=99t have a view on any of these, other than a = general goal of seeing this all tidied up. Jay --=20 Jay Daley IETF Executive Director ------=_NextPart_000_0184_01D61314.4B3D71C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Jay,

 

Your = =E2=80=98newcomer=E2=80=99 and =E2=80=98practical=E2=80=99 view of this = is appreciated (by me).

 

On your = second point, I see the gap that, =E2=80=9CThere should be a = process for these proposed changes to be evaluated,=E2=80=9D but I = don=E2=80=99t see how you arrive at, =E2=80=9CBy a larger independent = group.=E2=80=9D I=E2=80=99m not saying that I think having a larger = group is right or wrong, but I am asking you to show your workings. For = example, why would it be wrong for the RSE to make the = decision?

 

On your = third point, you say, =E2=80=9CHelp us end up with a strategy.=E2=80=9D = One could argue that there has been a strategy in place all along, and = that the RSE both established and delivered that strategy. That argument = might need to be accompanied by a statement that, =E2=80=9CIt was not = obvious to all following the topic what the strategy was nor how it was = being delivered.=E2=80=9D

 

Your bullet = points that follow, raise a number of issues that come around on the = rinse-and-repeat cycle. Raising these points establishes the meta point = of whether the RSE sets policies / resolutions for these and similar = issues, or whether the RSE is tasked to deliver on the wishes of the = community (even when those wishes go against the professional opinion of = the RSE). This meta point cuts, I think, to the core of the problem: = whose RFC Series is it; who makes the decisions; is the RSE the owner, a = consultant, or a servant?

 

Best,

Adrian

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of Jay = Daley
Sent: 15 April 2020 09:53
To: = rfced-future@iab.org
Subject: [Rfced-future] Observations on = issues

 

=EF=BB=BF

=EF=BB=BFGiven my role, before sending this I asked = Eliot about both the appropriateness of me doing so and the content and = his view is that it is very important that I send this, so here = goes. 

 

I have = some observations regarding issues around the RSE role which have = developed from my unusual position. However, I am acutely aware that I = am still very much a newcomer and so while I have tried to sanity check = these with others, there is a chance I may have misunderstood something = and may be misrepresenting a situation, for which I apologise in = advance.. 

 

Your = strategic bullet points that follow are, indeed, questions that come = around on the



My observations = are:

1.  Over the last 1-2 years the move to the v3 = XML has brought with it some very technical issues and as a result the = RSE role is a far more technical than the various role specifications = recognise.  The RSE currently needs to be quite technically = proficient in XML and specific vocabularies such as HTML and SVG; XML = schemas and translators; SDLC including versioning, testing, UX and = more; and archival formats and methods.  If the trend continues = then in the future they may also need to be proficient in ontologies and = RDF. 

2.  There have been multiple changes proposed for = the v3 XML that have led to conflict between those tasked with = implementing them and members of the community who would do things = differently.  This highlights a gap - there should be a process for = these proposed changes to be evaluated by a larger independent group who = then decide amongst the competing views on whether the change is = implemented and if so how.  Possibly by default that decision = making authority sits with the RSE but they do not appear to have = exercised that authority and so those implementing have done the best = they can. 

3.  One of the key tasks of the RSE that has = been mentioned several times has been to help us end up with a strategy = for the RFC Series, by whatever means are appropriate.  However = there does not seem to be one, nor a process to create one (excepting = this program) and there are a number of  current issues that are = clearly strategic, including:

- the RFC Series is regarded by = some as immutable and yet others are concerned that this means that = implementers/researchers miss vital errata, which in turn has = significant flow on problems.  The various solutions to this = include versioning of RFCs, changing the presentation context to focus = on an errata annotated version while still maintaining immutability or = just dropping immutability.

- there is no easy way for people to = find the current set of RFCs related to a specific technology that they = wish to implement/study.

- and while we understand the concept of = the "official" tool to transform the canonical XML into a = readable output (xml2rfc) the position we are in is that this really is = the only reliable and fully featured tool, for a variety of reasons and = it=E2=80=99s not clear if that is understood and accepted or if we need = to ensure diversity, say by a published detailed specification of the = output or transformation rules so that a third party can implement an = alternative.


I realise these are all quite practical compared = to the loftier questions of how do we ensure the RFC Series is here in = 50 years.  Also, to be clear I don=E2=80=99t have a view on any of = these, other than a general goal of seeing this all tidied = up.



Jay

-- 

Jay Daley
IETF Executive = Director



------=_NextPart_000_0184_01D61314.4B3D71C0-- From nobody Wed Apr 15 03:30:56 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63EA3A0A29 for ; Wed, 15 Apr 2020 03:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8sTZ-Dt5WrJ; Wed, 15 Apr 2020 03:30:52 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id DB57E3A0A24; Wed, 15 Apr 2020 03:30:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Jay Daley In-Reply-To: <018301d6130b$e9784670$bc68d350$@olddog.co.uk> Date: Wed, 15 Apr 2020 22:30:49 +1200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <6946BC22-8062-4519-ACEB-10979AEAF00F@ietf.org> References: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> <018301d6130b$e9784670$bc68d350$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 10:30:54 -0000 Adrian > On 15/04/2020, at 9:54 PM, Adrian Farrel wrote: >=20 > Hi Jay, >=20 > Your =E2=80=98newcomer=E2=80=99 and =E2=80=98practical=E2=80=99 view = of this is appreciated (by me). >=20 > On your second point, I see the gap that, =E2=80=9CThere should be a = process for these proposed changes to be evaluated,=E2=80=9D but I = don=E2=80=99t see how you arrive at, =E2=80=9CBy a larger independent = group.=E2=80=9D I=E2=80=99m not saying that I think having a larger = group is right or wrong, but I am asking you to show your workings. For = example, why would it be wrong for the RSE to make the decision? Yes, I have elided some steps there. Given that I only wanted to make = observations not favour a solution, it=E2=80=99s best if I don=E2=80=99t = follow-up with an explanation as to how I got there and instead leave a = solution to emerge, if that issue is indeed adopted. > On your third point, you say, =E2=80=9CHelp us end up with a = strategy.=E2=80=9D One could argue that there has been a strategy in = place all along, and that the RSE both established and delivered that = strategy. That argument might need to be accompanied by a statement = that, =E2=80=9CIt was not obvious to all following the topic what the = strategy was nor how it was being delivered.=E2=80=9D=20 Presumably it would be documented? > Your bullet points that follow, raise a number of issues that come = around on the rinse-and-repeat cycle. Raising these points establishes = the meta point of whether the RSE sets policies / resolutions for these = and similar issues, or whether the RSE is tasked to deliver on the = wishes of the community (even when those wishes go against the = professional opinion of the RSE). This meta point cuts, I think, to the = core of the problem: whose RFC Series is it; who makes the decisions; is = the RSE the owner, a consultant, or a servant? I think that last sentence significantly overcomplicates this issue. My = role is similar and I have to be the servant one day, the owner or the = consultant the next, and some day all three. If I own when I should = serve then I run the risk of upsetting people, and if I serve when I = should own then I run the risk of things never getting done. If there = are things that are sufficiently important to constrain the role then = put a process/policy in place, but otherwise let them get on with it. = Far better to focus on what the role needs to get done and what, if any, = should be the constraints and how should those be implemented than a = divisive existential question which even if it were decided, would still = not sort out the practicalities. Jay >=20 > Best, > Adrian >=20 > From: Rfced-future On Behalf Of Jay = Daley > Sent: 15 April 2020 09:53 > To: rfced-future@iab.org > Subject: [Rfced-future] Observations on issues >=20 > =EF=BB=BF > =EF=BB=BFGiven my role, before sending this I asked Eliot about both = the appropriateness of me doing so and the content and his view is that = it is very important that I send this, so here goes.=20 >=20 > I have some observations regarding issues around the RSE role which = have developed from my unusual position. However, I am acutely aware = that I am still very much a newcomer and so while I have tried to sanity = check these with others, there is a chance I may have misunderstood = something and may be misrepresenting a situation, for which I apologise = in advance..=20 >=20 > Your strategic bullet points that follow are, indeed, questions that = come around on the=20 >=20 >=20 > My observations are: >=20 > 1. Over the last 1-2 years the move to the v3 XML has brought with it = some very technical issues and as a result the RSE role is a far more = technical than the various role specifications recognise. The RSE = currently needs to be quite technically proficient in XML and specific = vocabularies such as HTML and SVG; XML schemas and translators; SDLC = including versioning, testing, UX and more; and archival formats and = methods. If the trend continues then in the future they may also need = to be proficient in ontologies and RDF.=20 >=20 > 2. There have been multiple changes proposed for the v3 XML that have = led to conflict between those tasked with implementing them and members = of the community who would do things differently. This highlights a gap = - there should be a process for these proposed changes to be evaluated = by a larger independent group who then decide amongst the competing = views on whether the change is implemented and if so how. Possibly by = default that decision making authority sits with the RSE but they do not = appear to have exercised that authority and so those implementing have = done the best they can.=20 >=20 > 3. One of the key tasks of the RSE that has been mentioned several = times has been to help us end up with a strategy for the RFC Series, by = whatever means are appropriate. However there does not seem to be one, = nor a process to create one (excepting this program) and there are a = number of current issues that are clearly strategic, including: >=20 > - the RFC Series is regarded by some as immutable and yet others are = concerned that this means that implementers/researchers miss vital = errata, which in turn has significant flow on problems. The various = solutions to this include versioning of RFCs, changing the presentation = context to focus on an errata annotated version while still maintaining = immutability or just dropping immutability. >=20 > - there is no easy way for people to find the current set of RFCs = related to a specific technology that they wish to implement/study. >=20 > - and while we understand the concept of the "official" tool to = transform the canonical XML into a readable output (xml2rfc) the = position we are in is that this really is the only reliable and fully = featured tool, for a variety of reasons and it=E2=80=99s not clear if = that is understood and accepted or if we need to ensure diversity, say = by a published detailed specification of the output or transformation = rules so that a third party can implement an alternative. >=20 >=20 > I realise these are all quite practical compared to the loftier = questions of how do we ensure the RFC Series is here in 50 years. Also, = to be clear I don=E2=80=99t have a view on any of these, other than a = general goal of seeing this all tidied up. >=20 >=20 > Jay >=20 > --=20 > Jay Daley > IETF Executive Director --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Wed Apr 15 03:58:41 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA903A0B37 for ; Wed, 15 Apr 2020 03:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr7GXy1rwmNP for ; Wed, 15 Apr 2020 03:58:38 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3143A0B2F for ; Wed, 15 Apr 2020 03:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8137; q=dns/txt; s=iport; t=1586948318; x=1588157918; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=O/HzmfLJS2NHnlFev65htrNYnkb9g43l/rvGAN5Day0=; b=G3gbacyDOUPk6vw84o+aSGGGaCZIBrlMaIPEDRQLImiGRi5jADev+RLl 2j+36ObTzb+lAXLFe48eoVdR73LNk0P3cnDCjlrp40aOmh5g670vjPG76 aDG883OxRrDOe2nSZbzwKoxQU4jutxVE66Vrj1ThlSpLe++mcz1AFOTlD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjBwAR6JZe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXsCgSOCRSASKoQciQKHaSWTRIgJCgEBAQwBAS8EAQGERAKCJzk?= =?us-ascii?q?FDQIDAQELAQEFAQEBAgEFBG2FYoVwAQEBAQIBI1YFCwsYKgICVwYTFAeDC4J?= =?us-ascii?q?dIK1rdYEyhU+EfoE4jFCCAIE4DBCCTT6HYDKCLQSOPKIqe4JMgmWUbh2cLqh?= =?us-ascii?q?zgz0CBAYFAhWBaiGBVzMaCBsVZQGCPj4SGA2gIj8DMI9FAQE?= X-IronPort-AV: E=Sophos; i="5.72,386,1580774400"; d="scan'208,217"; a="25285391" 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; 15 Apr 2020 10:58:36 +0000 Received: from ams3-vpn-dhcp933.cisco.com (ams3-vpn-dhcp933.cisco.com [10.61.67.165]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03FAwYom022494 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Apr 2020 10:58:36 GMT From: Eliot Lear Message-Id: <69F72762-B899-4203-BC78-135BC964D3FD@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BFEAB72B-9317-4E4D-8328-D139B615861C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 15 Apr 2020 12:58:34 +0200 In-Reply-To: <018301d6130b$e9784670$bc68d350$@olddog.co.uk> Cc: Jay Daley , rfced-future@iab.org To: Adrian Farrel References: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> <018301d6130b$e9784670$bc68d350$@olddog.co.uk> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.67.165, ams3-vpn-dhcp933.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 10:58:40 -0000 --Apple-Mail=_BFEAB72B-9317-4E4D-8328-D139B615861C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good afternoon Adrian, > On 15 Apr 2020, at 11:54, Adrian Farrel wrote: >=20 > Hi Jay, > =20 > Your =E2=80=98newcomer=E2=80=99 and =E2=80=98practical=E2=80=99 view = of this is appreciated (by me). > =20 > On your second point, I see the gap that, =E2=80=9CThere should be a = process for these proposed changes to be evaluated,=E2=80=9D but I = don=E2=80=99t see how you arrive at, =E2=80=9CBy a larger independent = group.=E2=80=9D I=E2=80=99m not saying that I think having a larger = group is right or wrong, but I am asking you to show your workings. For = example, why would it be wrong for the RSE to make the decision? I think this falls more on the solution side. Let=E2=80=99s capture the = problem crisply. > =20 > On your third point, you say, =E2=80=9CHelp us end up with a = strategy.=E2=80=9D One could argue that there has been a strategy in = place all along, and that the RSE both established and delivered that = strategy. That argument might need to be accompanied by a statement = that, =E2=80=9CIt was not obvious to all following the topic what the = strategy was nor how it was being delivered.=E2=80=9D=20 That=E2=80=99s nearly perfectly worded for a problem statement. > =20 > Your bullet points that follow, raise a number of issues that come = around on the rinse-and-repeat cycle. Raising these points establishes = the meta point of whether the RSE sets policies / resolutions for these = and similar issues, or whether the RSE is tasked to deliver on the = wishes of the community (even when those wishes go against the = professional opinion of the RSE). This meta point cuts, I think, to the = core of the problem: whose RFC Series is it; who makes the decisions; is = the RSE the owner, a consultant, or a servant? And that too! But Jay=E2=80=99s practical and concrete issues are = useful to help us understand the implications whatever solutions we as a = group develop. Eliot --Apple-Mail=_BFEAB72B-9317-4E4D-8328-D139B615861C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good = afternoon Adrian,

On 15 Apr 2020, at 11:54, = Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi Jay,
 
Your =E2=80=98newcomer=E2= =80=99 and =E2=80=98practical=E2=80=99 view of this is appreciated (by = me).
 
On your second point, = I see the gap that, =E2=80=9CThere should be a process for these = proposed changes to be evaluated,=E2=80=9D but I don=E2=80=99t see how = you arrive at, =E2=80=9CBy a larger independent group.=E2=80=9D I=E2=80=99= m not saying that I think having a larger group is right or wrong, but I = am asking you to show your workings. For example, why would it be wrong = for the RSE to make the decision?

I think this falls more on the solution side. =  Let=E2=80=99s capture the problem crisply.

 
On your third point, you say, =E2=80=9CHelp = us end up with a strategy.=E2=80=9D One could argue that there has been = a strategy in place all along, and that the RSE both established and = delivered that strategy. That argument might need to be accompanied by a = statement that, =E2=80=9CIt was not obvious to all following the topic = what the strategy was nor how it was being delivered.=E2=80=9D 

That=E2=80=99s nearly perfectly = worded for a problem statement.


 
Your bullet points = that follow, raise a number of issues that come around on the = rinse-and-repeat cycle. Raising these points establishes the meta point = of whether the RSE sets policies / resolutions for these and similar = issues, or whether the RSE is tasked to deliver on the wishes of the = community (even when those wishes go against the professional opinion of = the RSE). This meta point cuts, I think, to the core of the problem: = whose RFC Series is it; who makes the decisions; is the RSE the owner, a = consultant, or a servant?


And that too!  But = Jay=E2=80=99s practical and concrete issues are useful to help us = understand the implications whatever solutions we as a group = develop.


Eliot

= --Apple-Mail=_BFEAB72B-9317-4E4D-8328-D139B615861C-- From nobody Wed Apr 15 04:30:30 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9746B3A0CB0; Wed, 15 Apr 2020 04:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=1.496, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ec8wU7i4ywyt; Wed, 15 Apr 2020 04:30:27 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5CB3A0CAF; Wed, 15 Apr 2020 04:30:27 -0700 (PDT) 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 03FBULUe014942; Wed, 15 Apr 2020 12:30:21 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6FC522203C; Wed, 15 Apr 2020 12:30:21 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 5A8AB2203A; Wed, 15 Apr 2020 12:30:21 +0100 (BST) Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 03FBUJfl021905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Apr 2020 12:30:20 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" Cc: "'Jay Daley'" , References: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> <018301d6130b$e9784670$bc68d350$@olddog.co.uk> <69F72762-B899-4203-BC78-135BC964D3FD@cisco.com> In-Reply-To: <69F72762-B899-4203-BC78-135BC964D3FD@cisco.com> Date: Wed, 15 Apr 2020 12:30:19 +0100 Organization: Old Dog Consulting Message-ID: <01a301d61319$3f25cb80$bd716280$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A4_01D61321.A0EC2F50" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJCtcf0fP+e+FQ2kNfE5P5qAvDfyQFnNdMXAR+yu3anjIgzsA== Content-Language: en-gb X-Originating-IP: 81.174.202.163 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25356.007 X-TM-AS-Result: No--10.481-10.0-31-10 X-imss-scan-details: No--10.481-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25356.007 X-TMASE-Result: 10--10.480800-10.000000 X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbPHkpkyUphL9NI8g5I/uMcSZt08TfNy6OKPV muMtM5/Pyg6kqq/YldMCzawj2+r7kkPcdQi3PsbaGUlF/M3Dxp8yJlZlUbAvWOQydRUvl3QT02f VrdSBDvgAKkI9yCanY31fphr0K0usZ9cXdEbiq4Ag9zRfsFHjvcBjKtUA788t14zv7Kd6a4YAHL LzSb57gaqqX4EmAo53vBkc8w72f+3qZj5ryqFEkeCdOJAyA+r+mJHr6O9L7vVHrX2E2MkfRHPaw ziIDkeDdSXCCnuIoEMocTMtKlBcDvHh2MLptRwbzzuzg6dga4LaCn4DqCiXNoB4XybRlTmEldSY vbPAFd4pjQ3kwfC1SJhDjuh7LgqOvxs52Yum/5qqNnzrkU+2mp4YRoT55lhLyC4tIUWJ2bmwYPU 7T7BIK9hhrT/HY6VOj7K/6qmucLdFQl3KrTGbbHeV7ee//qUH9+PHtghP8GI9lFqHcAo+R4lvSo UAxubLdEzixA8RjDodKrg8vCoKeeebvkLr2VWfugvJpUjzDZeSiza26cvwNMz/SxKo9mJ4IpUOZ umEits22uoEm245flgUFTT7Y9QpYTZ2mX+nxwzfNKD9uRfMaXEONw67gSVcSnXYhdlqPHnZNpe4 t6HOM0cN36UB4MN7l+soBKtnVK3HrV1gUWkGecCxC+PryYbT6/ovm5YGTGkwMfxyID/dnfqnWOW EsAkCCh1Nj52lk1fV6RG4Qdh2Y25UVDj5nQKGnMQdNQ64xffneZhrHry3Xwwv1ZvdCH+FFXCUeF 7nROYU+O+bQPSZByqFmu/h/tw7WDbQH4TSNIOeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg1KMqIeOstiflxhPCV6M7c1+9J+wJtEZW8F8bmMyJReI0vP0gBgOPGV/+6RCBbDGG2uj7E23 H4gRSw8itavf4ZNd+qXwi8IIgxSH94FdltW6JhIO0TdhvdJ+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] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 11:30:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A4_01D61321.A0EC2F50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Good afternoon Adrian, =20 Hello to you, too. On your second point, I see the gap that, =E2=80=9CThere should be a = process for these proposed changes to be evaluated,=E2=80=9D but I = don=E2=80=99t see how you arrive at, =E2=80=9CBy a larger independent = group.=E2=80=9D I=E2=80=99m not saying that I think having a larger = group is right or wrong, but I am asking you to show your workings. For = example, why would it be wrong for the RSE to make the decision? =20 > I think this falls more on the solution side. Let=E2=80=99s capture = the problem crisply. =20 Oh, but I agree. That might have been exactly my point were I not trying = to be diplomatic with Jay whose email posited a =E2=80=9Clarger = independent group=E2=80=9D which sounds (to me) like a solution not a = statement of the problem. =20 On your third point, you say, =E2=80=9CHelp us end up with a = strategy.=E2=80=9D One could argue that there has been a strategy in = place all along, and that the RSE both established and delivered that = strategy. That argument might need to be accompanied by a statement = that, =E2=80=9CIt was not obvious to all following the topic what the = strategy was nor how it was being delivered.=E2=80=9D=20 =20 > That=E2=80=99s nearly perfectly worded for a problem statement. =20 We aim for perfection.=20 =20 I think documentation, transparency, and communication might be the = bywords. Your bullet points that follow, raise a number of issues that come = around on the rinse-and-repeat cycle. Raising these points establishes = the meta point of whether the RSE sets policies / resolutions for these = and similar issues, or whether the RSE is tasked to deliver on the = wishes of the community (even when those wishes go against the = professional opinion of the RSE). This meta point cuts, I think, to the = core of the problem: whose RFC Series is it; who makes the decisions; is = the RSE the owner, a consultant, or a servant? =20 > And that too! But Jay=E2=80=99s practical and concrete issues are = useful > to help us understand the implications whatever solutions we > as a group develop. =20 Yes, but =F0=9F=98=8A That is, as you say, solution-oriented. So maybe we leave the details = and practical issues on one side until we get as far as solutions. For now we need to try to capture the high-level scope and requirements = (and stop trying to fix problems until we know what problems we need to = fix). =20 Thanks, Adrian ------=_NextPart_000_01A4_01D61321.A0EC2F50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Good = afternoon Adrian,

 

Hello to = you, too.


On your second point, I see the gap that, = =E2=80=9CThere should be a process for these proposed changes to be = evaluated,=E2=80=9D but I don=E2=80=99t see how you arrive at, = =E2=80=9CBy a larger independent group.=E2=80=9D I=E2=80=99m not saying = that I think having a larger group is right or wrong, but I am asking = you to show your workings. For example, why would it be wrong for the = RSE to make the decision?

 

> I = think this falls more on the solution side.  Let=E2=80=99s capture = the problem crisply.

 

Oh, but I = agree. That might have been exactly my point were I not trying to be = diplomatic with Jay whose email posited a =E2=80=9Clarger independent = group=E2=80=9D which sounds (to me) like a solution not a statement of = the problem.

 

On your third point, you say, =E2=80=9CHelp us end up = with a strategy.=E2=80=9D One could argue that there has been a strategy = in place all along, and that the RSE both established and delivered that = strategy. That argument might need to be accompanied by a statement = that, =E2=80=9CIt was not obvious to all following the topic what the = strategy was nor how it was being delivered.=E2=80=9D 

 

> That=E2=80=99s nearly perfectly worded for a = problem statement.

 

We aim for perfection.

 

I think = documentation, transparency, and communication might be the = bywords.

Your bullet points that follow, raise a number of = issues that come around on the rinse-and-repeat cycle. Raising these = points establishes the meta point of whether the RSE sets policies / = resolutions for these and similar issues, or whether the RSE is tasked = to deliver on the wishes of the community (even when those wishes go = against the professional opinion of the RSE). This meta point cuts, I = think, to the core of the problem: whose RFC Series is it; who makes the = decisions; is the RSE the owner, a consultant, or a = servant?

 

> And that too!  But Jay=E2=80=99s practical = and concrete issues are useful

> = to help us understand the implications whatever solutions = we

> as a group = develop.

 

Yes, but = 😊

That is, as you say, solution-oriented. So maybe we = leave the details and practical issues on one side until we get as far = as solutions.

For now we need to try = to capture the high-level scope and requirements (and stop trying to fix = problems until we know what problems we need to fix).

 

Thanks,
Adrian

------=_NextPart_000_01A4_01D61321.A0EC2F50-- From nobody Wed Apr 15 06:14:37 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D4C3A0474 for ; Wed, 15 Apr 2020 06:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aLmZSZNRbEM for ; Wed, 15 Apr 2020 06:14:31 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA1E3A046E for ; Wed, 15 Apr 2020 06:14:31 -0700 (PDT) Received: from client-0065.vpn.uni-bremen.de (client-0065.vpn.uni-bremen.de [134.102.107.65]) (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 492N9d0Z7hz10J1; Wed, 15 Apr 2020 15:14:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> Date: Wed, 15 Apr 2020 15:14:28 +0200 Cc: rfced-future@iab.org X-Mao-Original-Outgoing-Id: 608649268.411508-2fcb84a13d940eda439d22e6ea5dda16 Content-Transfer-Encoding: quoted-printable Message-Id: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> References: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> To: Jay Daley X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 13:14:35 -0000 Hi Jay, > On 2020-04-15, at 10:52, Jay Daley wrote: >=20 >=20 > - the RFC Series is regarded by some as immutable and yet others are = concerned that this means that implementers/researchers miss vital = errata, which in turn has significant flow on problems. The various = solutions to this include versioning of RFCs, changing the presentation = context to focus on an errata annotated version while still maintaining = immutability or just dropping immutability. This opens an interesting scope discussion. Some of us perceive the RFC series as a series of archival publications. Some of us would prefer to turn this into what I=E2=80=99ll call =E2=80=9C= a website=E2=80=9D, for providing easy, low-threshold access to = up-to-date standards documents and related information. It is not clear to me at all that =E2=80=9Ca website=E2=80=9D would fall = under the purview of the RSE. It is not even clear that the RSE would need to participate in =E2=80=9Ca = website=E2=80=9D; this could exist in parallel to a series of archival = publications (actually, even multiple instances of =E2=80=9Ca website=E2=80= =9D could be created for different target audiences). Clearly, providing some mutual interfacing would facilitate the parallel = approach, so some form of participation is desirable. The IETF might have processes to channel consensus information to =E2=80=9C= a website=E2=80=9D beyond RFCs and their errata reports. > - there is no easy way for people to find the current set of RFCs = related to a specific technology that they wish to implement/study. =E2=80=9CA website=E2=80=9D, that is. > - and while we understand the concept of the "official" tool to = transform the canonical XML into a readable output (xml2rfc) the = position we are in is that this really is the only reliable and fully = featured tool, for a variety of reasons and it=E2=80=99s not clear if = that is understood and accepted or if we need to ensure diversity, say = by a published detailed specification of the output or transformation = rules so that a third party can implement an alternative. While the fact that we use XML vocabulary right now as the canonical = format does invite some desirables, I mainly view the XML format as = insurance for the future. So, again, it is not clear that the RSE needs = to be part of all those desirables, but it would be useful to provide = the interface from the archival series to =E2=80=9Ca website=E2=80=9D = that facilitates those desirables. This would ultimately also inform = the evolution of the XML vocabulary (or whatever replaces it in the long = term). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 15 10:41:01 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DF33A0CF2; Wed, 15 Apr 2020 10:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0fWdreJ2gW1; Wed, 15 Apr 2020 10:40:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4115E3A091D; Wed, 15 Apr 2020 10:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586972453; bh=RjyisTBt1rqGAZTCttB9FxvcKmh58zhvGG08i1hNGRQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=aPi/iKIbkcr86oKbm/2q1Z8yNFINcnLBYV1Ozf0U+Od+/hc1IsLMSeFRFGgHDnFnL k55E9viLN9sKkpkQI3X7Drtu4GKGaoZJ0BY6/27RTo2dZgOONmteYCVLEpd2svnd6M BLXpDXyq0EfP3L4f+y3O/N/YDPEdziaoKGSBqZxg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.159.203]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MVNB1-1jnCnC0Ks3-00SOMT; Wed, 15 Apr 2020 19:40:53 +0200 To: Jay Daley , rfced-future@iab.org References: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> From: Julian Reschke Message-ID: Date: Wed, 15 Apr 2020 19:40:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Bn+OjjpmVIIrchPhvIlvnnvJqKejsXEvUcpHkXAEiDVd7m1kwfq i8JckEMhW8gOQn6rxGkjxCQ0yj7YjQ/rbox4GemIdbVMkKfNDnorNz3ObJki2Usqt5WXYT/ dmiGai7Yj8ymoK2Tl+Pf47b8GzwZsKK5b8jLGvqW0k/opTXs/jD67mKeKB8Keixtx2jFCw4 FaJ8fat7/ZlxEmmjlsLAA== X-UI-Out-Filterresults: notjunk:1;V03:K0:d6v65wz64FE=:WVIbyyJojT22enWlGfwZ5c jegYtsQLD6m7qL3VZWsY7iEblg325jEudlVrw1m8UT6cDz9oNwQeOKblHgxrOMCAo5A7AfNCK jkwWdiJbzgLHusCdkjcOwep0vI8lSiq0pL/aOLfuzfqPEdq0IX1s6nTMICZpwbyiUAsLkP3Kt eNukylR27DKqIq7UpsuyQTK1RgNOzOj/qPP5vnmnK+qkqX7Xxf0ENqMZfTCg/CvlKu8Ir2ugE hWuayJcUTyelGr/DqMnzdV6XNkmqYNf+ksEo0MWXmCAd3+8g2CaqzIhM9WEPmbu75cqFoI9p8 s0ef9yqf3LYJfA/OWqcPxnuQc2lHeOc/f7/ajhX5ojAAx39RBLIoKwnwtekb0V5P/kj/uvftK 4HMqlBpTGXKj8kPXsvt82LWMylSeR4Lwe2CsHtZixqbzsC1GhZ6crU7/yP3nd/6vGPTUx807o j0ebwsozPz6SkOcORAbs0USI2+qE+ON2ZlRt4yDHu3+n6Z3lht5VvbJ/7PXtulEIdzVpnvkgz AdVTVjhgm/FuifblqbiqYOsXrg0arY337R6/5CiY793rkVkd4k6M8TSNhKk5/TnIg/pYh8YuU RFRwaPoqPEYPNko+qr+kX+tkto58AhOEBCUPTttOa4/rvlF/BhmcdZmha9+AK2G9pMgQ+xLa5 PTEAFdq314jofmMuRDCVjR56dX3tIGPVDoJlXaGHjZN31rapRwnIQjEEXPMqIZKg50TVJm3b4 vj6UfvHuPnodgWX/NPvzN7PGGBcY91KLH7wfEYGBj8K98P5w9E2K4qAEcUeXCZl2YfP35RUi+ vhlqBNDMAfvPBQ0lcohkmnAgy4BXUE136wjZQJpwZwD/+C8CMd9/Zhy4m3zrMhvp4juNPXEvC cC+qzXoZOGPM0vS0CaJZq9eGQ15ukHsV8utTeXJpCCc/37ysP8OBJbuHUh6+eDQcVSN6fAke/ 88X8CauAjrk/XRimh4Bvhn11vrU4sHYE0e7RuSesZUQY5GGnBqPTnhh+3ds+3xEqok+lX5zMI IRw33LevAo30qpo+jgMKae0MUr2AEBOrK+aI6cYINwq0xxYNMgf5lXSrNMAkv6QZN+B7HKV6y tfMO+c0pzr7nBMDTnp8b7q3rB2uQZH1M64jo0Tk2z2cyKRcA56X/8ZmEFheK4UL3YIuCk4CK/ N6nqkTpVRsktfiW/ioQRe1UPZEKg12Mf10/xlWxWXW52/k+pPeFKOpj/xa9AKOKA8gm/R9TGC JuprtlzCdDVH6h9u0 Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 17:40:59 -0000 On 15.04.2020 10:52, Jay Daley wrote: > =EF=BB=BF > =EF=BB=BFGiven my role, before sending this I asked Eliot about both the > appropriateness of me doing so and the content and his view is that it > is very important that I send this, so here goes. > > I have some observations regarding issues around the RSE role which have > developed from my unusual position. However, I am acutely aware that I > am still very much a newcomer and so while I have tried to sanity check > these with others, there is a chance I may have misunderstood something > and may be misrepresenting a situation, for which I apologise in advance= .. Looking at this with relatively fresh eyes is a good thing in any case. > My observations are: > > 1. =C2=A0Over the last 1-2 years the move to the v3 XML has brought with= it > some very technical issues and as a result the RSE role is a far more > technical than the various role specifications recognise. =C2=A0The RSE > currently needs to be quite technically proficient in XML and specific > vocabularies such as HTML and SVG; XML schemas and translators; SDLC > including versioning, testing, UX and more; and archival formats and > methods. =C2=A0If the trend continues then in the future they may also n= eed > to be proficient in ontologies and RDF. Absolutely, and actually this goes back more then 1-2 years. Or phrased differently, we might be further ahead in the transition if that would have been taken into account earlier on. (Also, I'm not sure about the prediction in the last sentence, but I'd love to hear more about that :-). > 2. =C2=A0There have been multiple changes proposed for the v3 XML that h= ave > led to conflict between those tasked with implementing them and members > of the community who would do things differently. =C2=A0This highlights = a gap > - there should be a process for these proposed changes to be evaluated > by a larger independent group who then decide amongst the competing > views on whether the change is implemented and if so how. =C2=A0Possibly= by > default that decision making authority sits with the RSE but they do not > appear to have exercised that authority and so those implementing have > done the best they can. > ... Indeed. I'll add a few key points (from my perspective of "a member of the community who would do things differently"): - What happens right now is that we're not working on the specification but a single implementation, and plan to describe what that does after-the-fact - but we do not really make progress with that. Having a single implementation driving things is not good; it makes it harder to come up with different implementations of the formatter later on, and also affects people who want to do *different* things with the vocabulary (such as *generating* it, or processing it for purposes other than formatting). - Having a single implementation causes certain risks, and I see that already happening: such as implementation details leaking into the "canonical vocabulary", or relying on certain libraries that might only be available for certain language ecosystems. - While it's certainly necessary to debug the vocabulary, we also have to consider the effects on related specs, such as preptool, output format specs etc. I don't see that happening at all. - What's new in the v3 world is that the RFC Style Guide now needs to exactly align with what the vocabulary can express (and what the formatters can produce). That kind of alignment was not totally necessary in the past, when xml2rfc's output could be fine tuned before publication, but it's absolutely critical now. It's good that John has taken over the ownership of the RFC Style Guide, and it would be good to clarify that he actually has the power to progress it. Finally: the longer this takes, the more documents will be published in a format which, after all, is not canonical or stable at all. > ... Best regards, Julian From nobody Wed Apr 15 13:02:10 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39043A08EB for ; Wed, 15 Apr 2020 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My6NM72c2JD1 for ; Wed, 15 Apr 2020 13:02:06 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6303A08EA for ; Wed, 15 Apr 2020 13:02:06 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 492YCw3HLLzyX0; Wed, 15 Apr 2020 22:02:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Apr 2020 22:02:03 +0200 Cc: Jay Daley , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 608673723.840704-69504af4cd51d2f1b45965a940929b33 Content-Transfer-Encoding: quoted-printable Message-Id: <4794ABBC-FA1A-4225-A652-03795E05993D@tzi.org> References: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> To: Julian Reschke X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 20:02:09 -0000 I didn=E2=80=99t want to go into that level of detail yet, but maybe = there is another scoping issue hiding here: On 2020-04-15, at 19:40, Julian Reschke wrote: >=20 > - What happens right now is that we're not working on the = specification > but a single implementation, =E2=80=A6 which in the vast majority of cases is used with an authoring = dialect of the vocabulary, and not with the publishing dialect. Most of = the authoring is done with the goal of publishing I-Ds, so different = considerations apply from authoring archival documents, but there is no = product owner here that would voice for this dominant use, so all the = voicing is done by frustrated users. The RSE could take over the job to be that product owner as well, but = that would mean that the RSE must be extraordinarily capable of juggling = the pulls of two different products at the same time. (People like that = do exist.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 15 15:07:37 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE503A0AA7 for ; Wed, 15 Apr 2020 15:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4_Pg55OswGr for ; Wed, 15 Apr 2020 15:07:33 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49EA3A0A79 for ; Wed, 15 Apr 2020 15:07:33 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id r4so618201pgg.4 for ; Wed, 15 Apr 2020 15:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=r79vxgveiOEdM2F4JR1MStxq1dtePR56carQQejojU8=; b=a85a7bWrjW6Ysc1Kj9n9g+2Bmwt/pblSUxWb8JL10JtBWxWSkywIJNO+MQr43gm+r4 YiAdVC3fCNKORukzrcM6GVi2ravz2Wnlg4CrfOUIOuALDjIknRbDl3USOUlquIY19NJ1 IrTIjDCziHERzOGEm9rRTHaAgO0wakkxv6qzrwL244YmyqRE0zl7fFmipbtWcfdAPbm3 7k3ISsDIOkm2ha/jbU5ZQk+B2Cz1qoNYS54FO8LZMlQtF8GrS+mqss3n5j1/EQRIOAzA 9Avo5vK4eDGQjDiVSGs8PJmQlohYYLcgcM4aiv4JmBHTdGPh7/oGFM/db3+QtMHvzZUi cgjA== 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=r79vxgveiOEdM2F4JR1MStxq1dtePR56carQQejojU8=; b=c//Sx8ehXbO2r/geb57+XDDeuht51Wrl5ieXBgXv65xaRTrAjuAfGY+YHDYuAKc5iC hWNoaWg71Hk/dAgH/L5rBWS58KGxu9HZTb1n3w3SSmx8d8CcbzQeebfLMEL5BYuBu6YF oLW6BDyLTmTD0mfGo3fQHYgX7Q40xmIJpoX+vNuGFWGZRun5IFbAXGWOmpR3g54gHlEH w7Ft/Ae3aJUr/4zViPsgGTH9lkpUj4GtXM0+Phh5dBvl3ekqoBKih9iXdtjnnHNpLhy9 rcWMRELOWTAinTkVsGeHk0LBeYSW/jbWvNGRNpbdz6lQjKLThCUDjcmhvegN3AjsHqtd r/Jw== X-Gm-Message-State: AGi0PuaapvUUdo97c2SiFuAeXR+/qigBZKU3J/oYet83KsYZ/1R7KA90 Tw4vhenuS/N+ALRf5UVBmgg= X-Google-Smtp-Source: APiQypISuoCDBNKyObvZwfviCMMOyOa4p29K7RZo8kfUQf/qEheUzBMEv3i9kY5fll2chN1Cn4mOZQ== X-Received: by 2002:a63:cf0d:: with SMTP id j13mr24107806pgg.379.1586988452955; Wed, 15 Apr 2020 15:07:32 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id s137sm15229388pfs.45.2020.04.15.15.07.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2020 15:07:32 -0700 (PDT) To: Eliot Lear , Adrian Farrel Cc: rfced-future@iab.org, Jay Daley References: <31852121-1A3E-4D69-8C97-A14D6F6C9F74@ietf.org> <018301d6130b$e9784670$bc68d350$@olddog.co.uk> <69F72762-B899-4203-BC78-135BC964D3FD@cisco.com> From: Brian E Carpenter Message-ID: <89771266-42d3-d9b2-c413-7fd5c0bafc93@gmail.com> Date: Thu, 16 Apr 2020 10:07:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <69F72762-B899-4203-BC78-135BC964D3FD@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Rfced-future] Principles/Charter/Strategy [was Observations on issues] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 22:07:35 -0000 On 15-Apr-20 22:58, Eliot Lear wrote: =2E..>> On your third point, you say, =E2=80=9CHelp us end up with a stra= tegy.=E2=80=9D One could argue that there has been a strategy in place al= l along, and that the RSE both established and delivered that strategy. T= hat argument might need to be accompanied by a statement that, =E2=80=9CI= t was not obvious to all following the topic what the strategy was nor ho= w it was being delivered.=E2=80=9D=C2=A0 >=20 > That=E2=80=99s nearly perfectly worded for a problem statement. It's fairly clear that there is a big difference between the technical as= pects of the RSE role, especially as complicated by the v3 roll-out, and the mo= re abstract aspects that concern the principles of the RFC series, the no= n-existent charter of the series and its editor, and the non-technical st= rategy that the principles and charter lead to. To be clear, IMHO neither RFC8729 nor RFC8728 comes close to defining suc= h principles or providing a charter for the series. That being so, no RSE= can be expected to develop a coherent strategy. Whether it's this group's job to develop those principles and the charter= is an open question, but their absence should IMHO be on the problem lis= t. Brian From nobody Wed Apr 15 19:38:24 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79D93A0985 for ; Wed, 15 Apr 2020 19:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q9wxHp4xqzU for ; Wed, 15 Apr 2020 19:38:15 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0FB3A097E for ; Wed, 15 Apr 2020 19:38:14 -0700 (PDT) Received: (qmail 61560 invoked from network); 16 Apr 2020 02:38:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f076.5e97c514.k2004; bh=nOubNjo6U5hbbUiFzwzXdpAvbE/T4lzI0177zm6FCHw=; b=h8icrna2Qt2pXfEcKb1V2Ljg4hAo4U5ZEbZAKQHgUg0qld7ZtOuOw5GJqGxkkUiof+s/PoYF5/Z9ruMmcQ9GA9GGbRWwf+CSfvM5QrMPyZapN8t0EGQffRcOFwF4SbOv7lcmOy9WBoUkXSCoD1JsI5CRhVUm6L6bul/GLq+HjJXS9JrEMkxGvZdKZMd4Ev8xaFRgmb5VY5WD7TVAtJBAb346vMVFkggLfAnkNepLs8tN6AzvdzrYxf4JN0AJzcnM Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Apr 2020 02:38:12 -0000 Received: by ary.qy (Postfix, from userid 501) id 53C3517E6D06; Wed, 15 Apr 2020 22:38:11 -0400 (EDT) Date: 15 Apr 2020 22:38:11 -0400 Message-Id: <20200416023812.53C3517E6D06@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: cabo@tzi.org In-Reply-To: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 02:38:22 -0000 In article <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> you write: >Some of us perceive the RFC series as a series of archival publications. > >Some of us would prefer to turn this into what I’ll call “a website”, for providing easy, >low-threshold access to up-to-date standards documents and related information. > >It is not clear to me at all that “a website” would fall under the purview of the RSE. I don't see any necessary conflict between making our documents more accessible and usable and making them archival. If you look at the IEEE's or ITU's publications, they use dates or version numbers, and their naming schemes are designed to make it easier to tell what's related to what, but if you have a particular version or date of a document, that unambiguously identifies an archival document. This is not to say we should emulate their standards processes , just that their numbering is a lot less opaque than ours. It is infamously difficult to find all the RFCs you need to implement any particular service. I understand the history of why that's the case but I certainly don't see it as a virtue. From nobody Wed Apr 15 20:11:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCCD3A0AA1 for ; Wed, 15 Apr 2020 20:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9miWubQuA-1l for ; Wed, 15 Apr 2020 20:11:20 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4FF3A0A9F for ; Wed, 15 Apr 2020 20:11:19 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id g14so1880782otg.10 for ; Wed, 15 Apr 2020 20:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j0j3yCrmbwHqipHoGS9XCGitdZxM4bzMFtmT4WDZZXk=; b=piB7Rl17dZQFD1FT4i1VQhFmi+QkCnwkvTYFS7szyDT6DfM/6g9JAemGSJKaAogjeI x19hHkLiQH+Yj5D+uruJcRWjZdU2GLpJwU7HGpQIne96hXLQdnIdyLoDqjKTYj1DaUxT cI0C0kk2GCJxI71xj2Rk6ByawB5ZL7USGIXLT3ZwbH6vy0oMzfJM7NMAIxTjUCuu1pVc 84usfdtJpYzxVAEEBOSLjz+AM2VOMB0vn5yWFL9HUr48jZt/BPh2OfzcPlp3TMU+o5fq 9qKkvpd8LzyGo2hEsTqEfyl+9tinTPXQQlVj6cgowY2tOTmEPdmm6PZ3+ef6wS4sXO6V S0Uw== 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=j0j3yCrmbwHqipHoGS9XCGitdZxM4bzMFtmT4WDZZXk=; b=hUEbdaQ0qF43KiKurjEbzztJ1u0RUsPSBeKTcZhb8ZK5zqzynqimDFeHX24ukLw1La Z1y9d1D3XOd1xyy05RCaSoKv9/a7ty+o3Yus2NeRh33xwsBY6mA5JN0AG0lhgA/scyS7 S1+bpI1FTuVWh2L+lgVEmVJZi5ANzJ4BJ4bGz7EurTvlyT2pG+aMfgWF+UFAgRRQ/Ffi oXQ231q75LsVQeFpjyA3MMraabQz9FBO9Pgw2P36+7k60Po9o2grzngsE3YBz+42JJfU s4BZH/HdtjbzWi0/FiKLvAdj/wf4zy9AK+JrbM42VWnDrmma260i5r77rULluCc6dVDX M3Eg== X-Gm-Message-State: AGi0PuYMoIdoELd74TlR0K2dmMYLkQ1aIoLtH5kFscivKUm4lDV8d8u+ QD6K/r1D8j24ac6vZfmusCmCBW1ZLnYi/T189nY= X-Google-Smtp-Source: APiQypK+WPjOGh6LpuAK0ZfDu9tQB1BOL/I/7PCaBui51SaU2EzjaA9l1R2IZPsQMUp1M6wtyjqxrOuAAlM7Fas/Vyg= X-Received: by 2002:a9d:620c:: with SMTP id g12mr172073otj.158.1587006679097; Wed, 15 Apr 2020 20:11:19 -0700 (PDT) MIME-Version: 1.0 References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> In-Reply-To: <20200416023812.53C3517E6D06@ary.qy> From: Tim Wicinski Date: Wed, 15 Apr 2020 23:11:08 -0400 Message-ID: To: John Levine Cc: rfced-future@iab.org, Carsten Bormann Content-Type: multipart/alternative; boundary="0000000000005d230405a35fc9b6" Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 03:11:24 -0000 --0000000000005d230405a35fc9b6 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 15, 2020 at 10:38 PM John Levine wrote: > > It is infamously difficult to find all the RFCs you need to implement > any particular service. I understand the history of why that's the > case but I certainly don't see it as a virtue. > > This statement right here I can not agree with more strenuously. I wrote a rough problem statement around making our RFCs much more living documents than the current -bis process we have now. For example, if you've watched the effort that the TCP groups have put in to produce 793bis, it's been many many years. Take 1035 for example on DNS, which has been updated by over 2 dozen RFCs. Trying to implement all the pieces is non-trivial. I've spent time trying to scope out how much time it would take to generate an updated 1035, and it appears to be a totally thankless task and not very "interesting" work. (and yes John, I'm beginning to see how I am a glutton for punishment) tim --0000000000005d230405a35fc9b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Apr 15, 2020 at 10:38 PM John Levine <= johnl@iecc.com> wrote:

It is infamously difficult to find all the RFCs you need to implement
any particular service.=C2=A0 I understand the history of why that's th= e
case but I certainly don't see it as a virtue.


This statement right here I can not agree with more strenuously= .=C2=A0
I= wrote a rough problem statement=C2=A0around making our RFCs much more
living docume= nts than the current -bis process we have now.

For example, if you've watched the ef= fort that the TCP groups have
put in to produce 793bis, it's been many many year= s.=C2=A0
= Take 1035 for example on DNS, which has been updated by over 2 dozen RFCs.= =C2=A0
Tr= ying to implement all the pieces is non-trivial.=C2=A0

I've spent time trying t= o scope out how=C2=A0much time it would take to=C2=A0
generate an updated 1035, and = it appears to be a totally thankless
task and not very "interesting" work.= =C2=A0
(and y= es John, I'm beginning to see how=C2=A0I am a glutton for punishment)

=
tim
--0000000000005d230405a35fc9b6-- From nobody Wed Apr 15 20:11:53 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8B03A0AA6 for ; Wed, 15 Apr 2020 20:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 BKwaW4eRfneg for ; Wed, 15 Apr 2020 20:11:48 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7993A0A9F for ; Wed, 15 Apr 2020 20:11:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 492klm5PHtz1nxQk; Wed, 15 Apr 2020 20:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587006708; bh=f8OYiq+ncMLt20up1Gu36deMKdaButLClkdAeIeRi4E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nOloIdGjD/55UsxV1L2vofNA4BHqJ2BFr3VOnCz/EWW52vispYC1wKEyr2UjZIUL0 01JRkxlic1osllWUCPa9RH4ZxDYAO+0t4rGhUMx52DNkHGlM2vqtsu3tLyV50rz6MB eC4j67ETwxoNUKrFShpfx1rsyDmIblYGyFFHh64s= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 492klm09Fvz1ntHV; Wed, 15 Apr 2020 20:11:47 -0700 (PDT) To: John Levine , rfced-future@iab.org References: <20200416023812.53C3517E6D06@ary.qy> From: "Joel M. Halpern" Message-ID: Date: Wed, 15 Apr 2020 23:11:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200416023812.53C3517E6D06@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 03:11:51 -0000 Please, let's be a bit careful about mixing the issue of revision with the issue of the set of RFCs that you need to implement in practice to usefully fill a certain space. We as a community have tried to address the latter. I will not rehash or misconstrue the politics, but it was not easy, pretty, nor effective. And has little or nothing to do with the numbering of our standards and the revisions thereof. Yours, Joel On 4/15/2020 10:38 PM, John Levine wrote: > In article <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> you write: >> Some of us perceive the RFC series as a series of archival publications. >> >> Some of us would prefer to turn this into what I’ll call “a website”, for providing easy, >> low-threshold access to up-to-date standards documents and related information. >> >> It is not clear to me at all that “a website” would fall under the purview of the RSE. > > I don't see any necessary conflict between making our documents more > accessible and usable and making them archival. If you look at the > IEEE's or ITU's publications, they use dates or version numbers, and > their naming schemes are designed to make it easier to tell what's > related to what, but if you have a particular version or date of a > document, that unambiguously identifies an archival document. This is > not to say we should emulate their standards processes , just that > their numbering is a lot less opaque than ours. > > It is infamously difficult to find all the RFCs you need to implement > any particular service. I understand the history of why that's the > case but I certainly don't see it as a virtue. > From nobody Wed Apr 15 22:10:49 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9913A0DE4 for ; Wed, 15 Apr 2020 22:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAQoNaabq7uW for ; Wed, 15 Apr 2020 22:10:42 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB1E3A0DDF for ; Wed, 15 Apr 2020 22:10:42 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id 201so1153640pfv.2 for ; Wed, 15 Apr 2020 22:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+2RmL8xuoecjjaz+jpghIKikRRd/MJp8OOm17WjvnqY=; b=JgABMG6rbnaJEgIuelQoZ67EwPDIpg5K4yL+0i7Cxv96khDA/NyfdAWHq0VhOYM3BG hmJ2kLw7tp/G7PXUbHeXYxCiKsPx4ssn5Ciz/ucQn6r2UHFMVS9Z+LRkI93SOTbr88p0 hnyEIQ0ttLuTD93JKUYqAGwiM7mQgvoOw5VyqDG2EWkX4NL6F4qmfiOmwCJM086jBJT6 8bfW4Q8IYy/2LWwoMbyBc+Yb95TcEvdaR42JlORpbhOCjHK56AnPpJFzNdoxg/LzkiiX P4gT3hJZAUn3FaVhrdDk7NvvmotHCn5gphoHCNkssdXLSwglqTbY7IXCFn/Mel5J81rs dJjg== 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=+2RmL8xuoecjjaz+jpghIKikRRd/MJp8OOm17WjvnqY=; b=A2FFaNqb73q78XyQ+vDDxbZrsZdn4YeO/71fHOAxl1FnMA5ByjObiwoxvdHnbOfb3z OuhpIUnQbNRw6znOdzuDmuoW26efOpoyu476thuT33JW0doRf5OA69ENZ9ff9PpNCC3s qFpH2tXJJWGIr4uZaD6X6o4BKV1P07PwB+S8p4MrOFQ4ZD0MgsPuH4rrKh9aAWD2CH9P 8iEG8VuhydodIIPfT7MKeIzpX4yRERcITCFIRtBsGtkdZOaft8L/mS4p0RPVOI1bPnTY skaJzfBdxEMHkEnoXD9ZUsW8HyB3RmhOa1gvTfufdfdKifUyEs/RjouOjwHjhDZ0c3SI 6oTQ== X-Gm-Message-State: AGi0PuaQWfcqHDBLIc9M4ArDRGhksha2GCVqS+gsrfwaqr8SERdcPu7R Nj7R+cFE8EgP6yu3YGkOp8+9Xwxt X-Google-Smtp-Source: APiQypJpPscmtbo0L9+uOCzpmJMY+9cEAtbhKqaCLWfCr+fdmWtU+I93+gFbDXmnBMyito8e4mAE3g== X-Received: by 2002:a62:ee05:: with SMTP id e5mr21024777pfi.288.1587013841787; Wed, 15 Apr 2020 22:10:41 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id q200sm14513992pgq.68.2020.04.15.22.10.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2020 22:10:41 -0700 (PDT) To: "Joel M. Halpern" , John Levine , rfced-future@iab.org References: <20200416023812.53C3517E6D06@ary.qy> From: Brian E Carpenter Message-ID: <7f76ffd7-d585-95b0-6a30-ae6c6b7a5d13@gmail.com> Date: Thu, 16 Apr 2020 17:10:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 05:10:46 -0000 On 16-Apr-20 15:11, Joel M. Halpern wrote: > Please, let's be a bit careful about mixing the issue of revision with = > the issue of the set of RFCs that you need to implement in practice to = > usefully fill a certain space. >=20 > We as a community have tried to address the latter. I will not rehash = > or misconstrue the politics, but it was not easy, pretty, nor effective= =2E=20 > And has little or nothing to do with the numbering of our standards=20 > and the revisions thereof. Exactly. And it's an *IETF* problem, so I don't see how it would be in scope here. Brian >=20 > Yours, > Joel >=20 > On 4/15/2020 10:38 PM, John Levine wrote: >> In article <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> you write: >>> Some of us perceive the RFC series as a series of archival publicatio= ns. >>> >>> Some of us would prefer to turn this into what I=E2=80=99ll call =E2=80= =9Ca website=E2=80=9D, for providing easy, >>> low-threshold access to up-to-date standards documents and related in= formation. >>> >>> It is not clear to me at all that =E2=80=9Ca website=E2=80=9D would f= all under the purview of the RSE. >> >> I don't see any necessary conflict between making our documents more >> accessible and usable and making them archival. If you look at the >> IEEE's or ITU's publications, they use dates or version numbers, and >> their naming schemes are designed to make it easier to tell what's >> related to what, but if you have a particular version or date of a >> document, that unambiguously identifies an archival document. This is= >> not to say we should emulate their standards processes , just that >> their numbering is a lot less opaque than ours. >> >> It is infamously difficult to find all the RFCs you need to implement >> any particular service. I understand the history of why that's the >> case but I certainly don't see it as a virtue. >> >=20 From nobody Wed Apr 15 23:01:13 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150F73A0F35 for ; Wed, 15 Apr 2020 23:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zqg1ldxMsrH; Wed, 15 Apr 2020 23:01:10 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id DAAF53A0F2F; Wed, 15 Apr 2020 23:01:09 -0700 (PDT) From: Jay Daley Message-Id: <7641FCB0-430D-490E-93EA-145B75AC49A5@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_D8E1DB78-9557-4C13-B4E2-349953CFBC42" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 16 Apr 2020 18:01:07 +1200 In-Reply-To: <7f76ffd7-d585-95b0-6a30-ae6c6b7a5d13@gmail.com> Cc: rfced-future@iab.org To: Brian E Carpenter References: <20200416023812.53C3517E6D06@ary.qy> <7f76ffd7-d585-95b0-6a30-ae6c6b7a5d13@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 06:01:12 -0000 --Apple-Mail=_D8E1DB78-9557-4C13-B4E2-349953CFBC42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16/04/2020, at 5:10 PM, Brian E Carpenter = wrote: >=20 > On 16-Apr-20 15:11, Joel M. Halpern wrote: >> Please, let's be a bit careful about mixing the issue of revision = with=20 >> the issue of the set of RFCs that you need to implement in practice = to=20 >> usefully fill a certain space. >>=20 >> We as a community have tried to address the latter. I will not = rehash=20 >> or misconstrue the politics, but it was not easy, pretty, nor = effective.=20 >> And has little or nothing to do with the numbering of our standards=20= >> and the revisions thereof. >=20 > Exactly. And it's an *IETF* problem, so I don't see how it would be in > scope here. The point I was making is that this is a strategic issue which should be = resolved by a strategy and AFAIK it is the role of the RSE to ensure = that said strategy is developed somehow and yet I=E2=80=99m not aware = there is such a strategy or a plan to develop one. That issue I would = suggest, is in scope. Jay --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_D8E1DB78-9557-4C13-B4E2-349953CFBC42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 16/04/2020, at 5:10 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On = 16-Apr-20 15:11, Joel M. Halpern wrote:
Please, let's be a bit careful about mixing the = issue of revision with
the issue of the set of RFCs that = you need to implement in practice to
usefully fill a = certain space.

We as a community have tried = to address the latter.  I will not rehash
or = misconstrue the politics, but it was not easy, pretty, nor effective. =
 And has little or nothing to do with the numbering = of our standards
and the revisions thereof.

Exactly. And it's an *IETF* = problem, so I don't see how it would be in
scope here.

The = point I was making is that this is a strategic issue which should be = resolved by a strategy and AFAIK it is the role of the RSE to ensure = that said strategy is developed somehow and yet I=E2=80=99m not aware = there is such a strategy or a plan to develop one.  That issue I = would suggest, is in scope.

Jay

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

= --Apple-Mail=_D8E1DB78-9557-4C13-B4E2-349953CFBC42-- From nobody Wed Apr 15 23:47:41 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE4C3A1021 for ; Wed, 15 Apr 2020 23:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=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, T_SPF_TEMPERROR=0.01, 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=y7Pqld6e; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rWgYWEfq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adXlTRLo14LR for ; Wed, 15 Apr 2020 23:47:31 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAD13A101E for ; Wed, 15 Apr 2020 23:47:31 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DCC485C0241; Thu, 16 Apr 2020 02:47:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 16 Apr 2020 02:47:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=2 8cI4hk4jaK9oYgZ/+/IO2sXGFTlQ5bYIAFrwvr7Hx8=; b=y7Pqld6eHIliIcigW fwUy3KHCGKEsfDeuB8jWniVNK+CgEW+08KN/ai2W1/G7s8rW98E1rUViA/40IGF2 hU5jAQaq8MwYRUm15HQy6PupDDC7Mos+TsL7ic7Woxtdko1FntpUEyt20IyrNJC5 ug7saEp4bwkC6Ox0GIf3ot+J3sRI79GAiV5We/c4tUqrWGVPx9qySXe1QAQovC2C gFoQ4v7R0ZVS9lW5JgiPWYDSF2XYaf+4+YnmQ1mnZJt6r0xnVy3dmKuKe3iCrXjF Gv98RB9ZmlViMRJ0J15Bv2qOSqw5BNLfBnDhwh2yyiXbMUh5c4NnESsQ8yIn7/jy RE9uw== 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=28cI4hk4jaK9oYgZ/+/IO2sXGFTlQ5bYIAFrwvr7H x8=; b=rWgYWEfqIQ5HdDwGcdF6Z6HVPXVZV+KXmbzZRBhpRbSv4laaV+yzYtDBZ uaCtuVARUhODoKhqndZkswPAk7W4Lp80WDGvxKmiYET9lveDPTFltQFsCb7bTxmQ QEFJQqPNorsmQpZ05gQwspZvMZ2+o3K8iD3NyIkiqE+hvyQoWG4MpbzWibcYw5+B 42lIZt37aCLReJ8tggtCO+QFCafjukME5rdx26rscUhdfET/UPG/jqKSnloS7FJL nfAy64QchvxEChnbcrKODqkE+QlvB33ka5tUwFbwj5AXcMcEZc5v4TIShE4FuO/h JgXcw+jJFPbXnRldrO5xkrT4W9HQg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeeggdduuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddv hedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh hnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 58C853060062; Thu, 16 Apr 2020 02:47:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Thu, 16 Apr 2020 16:47:24 +1000 Cc: "Joel M. Halpern" , Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <5E6766E9-7D7B-485C-AFE7-E70D1A606BAE@mnot.net> References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <0E6D83F8D11D8C1B9B7237B7@PSB> <73C27FFD-BD81-4CF3-9D9D-845DE9544A36@cisco.com> <097a60d7-2229-b849-1ca3-1f6d298cceed@nthpermutation.com> <16726C73-09AB-4F61-8C00-8224E3EF6F1B@mnot.net> <326aa371-82ad-da59-d873-f4e08cd6c3bb@joelhalpern.com> <0934cdca-7ff4-f43e-2e5f-66ed2939232f@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] [IAB] Welcome to the RFC Editor Future Development Program X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Apr 2020 06:47:39 -0000 Hi Brian, Sorry for the delay, things intervened. > On 1 Apr 2020, at 1:17 pm, Brian E Carpenter = wrote: >=20 >>>> My preference is that we define the job such that it is clearly the = RFC Editor's job to lead that discussion / process. >>>=20 >>> I very strongly agree with that, but to my mind that requires that = we agree on the principle that the RFC Editor is autonomous and the = series is not controlled by the IETF or, except at a very abstract = level, by the IAB. >>=20 >> I don't see how that follows. We have plenty of people who lead = discussions and processes in this community, and yet they still have = oversight, checks and balances. There may be reasons for exempting the = RSE from them, but declaring that special status as a presumption seems = odd in a program with our scope. >=20 > I won't repeat what I said in = https://www.ietf.org/archive/id/draft-carpenter-request-for-comments-01.tx= t, but I will assume you've read it. I had, but I've re-read it to refresh my memory. FWIW, I agree with much = of what you say there, but don't always share your conclusions. Happy to = discuss that when and where it's appropriate. > Of course, being autonomous shouldn't mean exemption from checks and = balances. However, in the case of the RSE (and unlike most of our = activities), it really isn't clear which community should implement = those checks and balances. And the evidence from the IAOC and the RSOC = is that we aren't very good at designing oversight functions. I think = that's our biggest challenge. Agreed regarding the challenge. Perhaps "autonomous" isn't the right = word; it just struck me as odd.=20 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Apr 16 00:15:53 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60BB3A108C for ; Thu, 16 Apr 2020 00:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.591 X-Spam-Level: X-Spam-Status: No, score=-9.591 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, T_SPF_HELO_TEMPERROR=0.01, 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 9-QZw9_WKFe2 for ; Thu, 16 Apr 2020 00:15:46 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9653A0FA9 for ; Thu, 16 Apr 2020 00:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1215; q=dns/txt; s=iport; t=1587021345; x=1588230945; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nvvyqMzjuWI+c6984fcMmTn/VIPbNo/NSrjnFsXnCjE=; b=W4nMmdEEvMprwRvTBCWTsHAunEqw11UQU3RcLfeLG213QYzisRrYG8al f3+otKoEgEAyFlqvyuav71R118vDvsXbSy7DMj+6Vvv+Qgs8L9A1xpklj a8Gr7qRGgMaD0mPma9vy1AlncHDr25zV9j/hXUxK1bY9HAUN6xQhPyVVP E=; X-IPAS-Result: =?us-ascii?q?A0DOAACpBZhe/xbLJq1mHAEBAQEBBwEBEQEEBAEBgWoEA?= =?us-ascii?q?QELAYF3gXIgEiqEHIkCiBCbTQoBAQEMAQEvBAEBhEQCgio3Bg4CAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEFBG2FYoVwAQEBAQIBI1YFCwsYAgImAgJXBhMUgxKCXSCuJ?= =?us-ascii?q?HWBMoVPhRyBDioBjE+CAIE4HIJNPoROgxIygi0EjkqjGIJMgmaUbh2CVIhGk?= =?us-ascii?q?RSodoM9AgQGBQIVgWgjgVczGggbFWUBgj4+EhgNoCI/AzCPUAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.72,390,1580774400"; d="scan'208";a="23050411" 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; 16 Apr 2020 07:15:38 +0000 Received: from ams3-vpn-dhcp6189.cisco.com (ams3-vpn-dhcp6189.cisco.com [10.61.88.44]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03G7FZKv004685 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Apr 2020 07:15:35 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Thu, 16 Apr 2020 09:15:34 +0200 Cc: John Levine , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <82AFA939-CAA5-4B66-B36B-CDA78EBF8298@cisco.com> References: <20200416023812.53C3517E6D06@ary.qy> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.88.44, ams3-vpn-dhcp6189.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 07:15:52 -0000 Hi Joel, > On 16 Apr 2020, at 05:11, Joel M. Halpern wrote: >=20 > Please, let's be a bit careful about mixing the issue of revision with = the issue of the set of RFCs that you need to implement in practice to = usefully fill a certain space. I think it=E2=80=99s good to tease these out, but in the context of the = responsibilities of the RFC Editor. Brian wrote: >> We as a community have tried to address the latter. I will not = rehash=20 >> or misconstrue the politics, but it was not easy, pretty, nor = effective.=20 >> And has little or nothing to do with the numbering of our standards=20= >> and the revisions thereof. >=20 > Exactly. And it's an *IETF* problem, so I don't see how it would be in > scope here. Let=E2=80=99s test that: are there formats that could facilitate = spotting differences between revisions, or points where updates or = references could occur? For instance, today our references point to = entire documents. Could the references point to specific tags in = documents? Now=E2=80=A6 my point in asking is not to delve further into the weeds, = but simply to see if we can find some useful delineations. Eliot= From nobody Thu Apr 16 00:43:13 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6085D3A1104 for ; Thu, 16 Apr 2020 00:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=RZfmDFyy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CRIiKZAi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RCFLxKVrPV4 for ; Thu, 16 Apr 2020 00:43:09 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681013A10E0 for ; Thu, 16 Apr 2020 00:43:09 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 955CF5C027A; Thu, 16 Apr 2020 03:43:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 16 Apr 2020 03:43:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=L TxAyO+gyJYixiUaSp6t7CTGBxlBhL59+IY/5zbodwI=; b=RZfmDFyyi2YlDSab9 ZaK/REoAnBVOfjR1sXgnfkp1NG1XFbj2aBDApuQ0dXHjQlpciAgQ5dC54eXqqGz9 y6IQHlyVpo/jPkzDTcBYcdXQMks2uy/xAu0mL7XUtDFbNrATvun7s81IlZwYOTc1 gNZXb44Iv7GyyCYUf3mVxZIsqZSL0Z6IEZwLeKLryWn+OedYgJi7O/zeROO10lv0 Js4XPw9y+n1Ls7n+LbMqFNs6SgzjM8tqPYxmvclrh7giczCjc39sSwtSFpjHl2Ma utHe4GlW9F9lHKZ7Mn9SmvhOZ64X+tfua2Vj4Xy8/VrKC3FkF+/qS9nQXOxTDsmN yxRxQ== 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=LTxAyO+gyJYixiUaSp6t7CTGBxlBhL59+IY/5zbod wI=; b=CRIiKZAiK/VflguA2tqCTiunINAPZRLqqxeEqoqjzhRJAOwkHAwh8mIOr 3d3dCPsjWA/WjDxQnGkhp868GRQbFVYdg5YgNiHVlYjKQaq+XOIQYBW89vMqQvLw pak9hfnDCP74VHRoK+OhGW2QtiAoEWUXRArzBD2flNdr8RnwLT8iBHkaxmsLl5hO dc4JkaC80R5uJpw6Bu/rdLev91NANZyUDxBGVFu5bD61VUcqy1gE7LpmilzvNfha A7905rTyH2WaiSJ/dKXtDaEzWUlaCmB4mP2JHU2CDKgridszjyyEDTEEfd0yeKNi COjiJ/KnwozS0S1vSqh6JIhY5l6uw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeeggdduvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrd hnvght X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 473193060062; Thu, 16 Apr 2020 03:43:07 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> Date: Thu, 16 Apr 2020 17:43:03 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Apr 2020 07:43:11 -0000 Hi Eliot, > On 15 Apr 2020, at 12:44 am, Eliot Lear = wrote: >=20 > We=E2=80=99re now in step 1. Now is your opportunity to put forth a = view in a form such as =E2=80=9Chere=E2=80=99s what good looks like" = statement or =E2=80=9Chere are the problems I am seeking to solve=E2=80=9D= , or in some way you believe will advance the discussion, but focusing = on your goals for this effort. With no particular ordering, problems: * The RSE currently has no direct input or insight into budgeting for = the RPC, and yet the RSE has oversight of and ultimate responsibility = for their work. This can result in mismatch between allocated resources = and needs, as well as waste of resources. Also, it's not fair to the = RSE. * We currently spend approximately US$200/page of published RFC on the = RFC Editor function, and there is no obvious mechanism to determine = whether this money is well-spent, or to control the overall cost. For = comparison, market rates for technical editing seem to range between = US$10-35/page (which is not a fair comparison, but the difference _is_ = eye-opening). * There is no back pressure mechanism on drafts that need extensive = amounts of editing or preparatory work. Note that this could be = addressed outside of the RSE's purview, but it does have a strong = influence on how we describe the role of the RFC Editor overall. * The methods that the RSE has available to the make decisions (of = various sorts) are ill-defined, to the point where it can be untenable = for both them and the community. To me, this is the heart of the matter. * The RFC Series has come to serve a wide variety of audiences, and the = perceptions about their needs often compete. For example, "lower-layer" = technical specifications often have a relatively small, specialised = implementer and academic audience, where "higher-layer" application = protocols sometimes have extremely broad, more casual audiences with = less attention to give to minutia. As a result, some people feel that = navigability of the series is an existential threat, while others = perceive it as a minor annoyance (and that's just one example). This is = a set of potential problems that could be addressed by an RSE, but = designing the role and its interface with the community -- or really, = communities -- needs to take it into account. ... and what good might look like (note again that these are not the = results of _this_ program, but of its output): * We are able to get to a documented agreement as a community (however = defined) about a strategy for the RFC Series * We're able to execute on that strategy * Over time, the RFC Series -- in some form -- becomes an even more = useful and well-understood resource for an increasing portion of the = technical community * The RFCs continue to flow Not that I'm not including things like "the RFC series needs to be a = continuously updated Web site" or "the RFC series must remain completely = archival", or even "the RFC series must use blue links." None of that is = in scope for this group, as I understand it, even if everyone has strong = opinions about many of these issues. Finally - I can't help but notice, again, that the functions of the RSE = are carried out elsewhere (e.g.,the W3C, OASIS, etc.) without a publicly = designated, autonomous figurehead. I understand there's history here, = but I feel strongly that history should inform our choices, not bind = them. As such, I'd really like to focus on what outcomes we want for our = chosen community (see my first take above), and then figure out how to = reach them, rather than pre-supposing a particular role ready for = filling. We may very well end up with an RSE-like role, but I'd = challenge us to justify doing so. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Apr 16 03:13:55 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F52A3A13AB for ; Thu, 16 Apr 2020 03:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.477 X-Spam-Level: * X-Spam-Status: No, score=1.477 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MAY_BE_FORGED=1.496, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 q_lMsm6yhAqv for ; Thu, 16 Apr 2020 03:13:51 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEF23A13AC for ; Thu, 16 Apr 2020 03:13:50 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 03GADmIU025746; Thu, 16 Apr 2020 11:13:48 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 40B2C22042; Thu, 16 Apr 2020 11:13:48 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 2AD8A22050; Thu, 16 Apr 2020 11:13:48 +0100 (BST) Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 03GADlS1029840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Apr 2020 11:13:47 +0100 Reply-To: From: "Adrian Farrel" To: "'John Levine'" , Cc: References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> In-Reply-To: <20200416023812.53C3517E6D06@ary.qy> Date: Thu, 16 Apr 2020 11:13:47 +0100 Organization: Old Dog Consulting Message-ID: <02f201d613d7$b806fb50$2814f1f0$@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: AQLSnuxG0OzQaVgFs3DKHtdtDqVq4KaCcHcg Content-Language: en-gb X-Originating-IP: 81.174.202.163 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25358.006 X-TM-AS-Result: No--3.231-10.0-31-10 X-imss-scan-details: No--3.231-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25358.006 X-TMASE-Result: 10--3.231300-10.000000 X-TMASE-MatchedRID: VfovoVrt/obxIbpQ8BhdbPHkpkyUphL99+PHtghP8GJxps32fZo2QQ92 y3TKZucE0m26OibmKjCA4etLrC96XmC5k6NopKxY5IwLEoKdzxkCC8zqHvcG2nSvE1gDT372dhx WaLl37J+L6DeNtO0Hce/EvlDYfLg2f7Ybt4amKFzQfyKEYQc1R7/oYfqyicJN0LT38zDoPaA/J5 SKnlHdbc9Gx5eVa+6SdCrVHBq+JIYM9SHmc6e0voOsh+/HtOZF5ERNofZ3BFymp+gE0amb4z7UQ YkVw9g/585VzGMOFzAgLQ6h4P+EJlOm2gN+noms2bNx1HEv7HAqtq5d3cxkNTCgjYKtDnCBsWgK QEc1rxfsta/yka8+pDOQImxRS5kBTb8GP3qhgLW7wFgJ/GHkB7RKNbNKwiYUe28muOG/Be1YGOH CXpe0RDEHFPnSvN7ap8i26iGCN+fD/c2Y8mxrik1Z+dSdugwvVNdRfR1NB08= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 10:13:53 -0000 > It is infamously difficult to find all the RFCs you need to implement > any particular service. I understand the history of why that's the > case but I certainly don't see it as a virtue. But this is so easy to solve by writing a "cook book" that one might = wonder why it isn't solved. The fact that no one writes such gazetteers might indicate that although = the problem is infamous, it is not something that actually bothers many = people. Or we might deduce that once someone has solved the puzzle they = consider the solution to be secret sauce. Or whatever. I don't believe that the solution is in metadata (which could get = multi-dimensional), but in better documentation. The need for better = documentation to explain our protocols and thinking is long-standing and = the solution lies in the community. Best, Adrian From nobody Thu Apr 16 06:49:20 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979CA3A0897 for ; Thu, 16 Apr 2020 06:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgm7eK434nZq for ; Thu, 16 Apr 2020 06:49:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB773A0893 for ; Thu, 16 Apr 2020 06:49:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4930vD46T6z1p1tl; Thu, 16 Apr 2020 06:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587044952; bh=kewCfVLl4Uy/KRHmCDtZ3Zqmpk/4fYm852TaHvPcHCE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TIHqk+51qoKEam5+Q67ZwKJD+HPO7cRrCDKowL6ingcA0pqQgV0Yo417yBq98OB3Z pXKR+yFiYZuxcKDjgHIOZEKZcBh/Cg9sZVvHdDv85LukAzLu2cyDm/XmjWDpCPMtlq 3UffkgtnxF4v3udWsJA8Caw7pdlXZ+D3RlzQS1r0= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4930vC42dTz1ny9C; Thu, 16 Apr 2020 06:49:11 -0700 (PDT) To: Eliot Lear Cc: rfced-future@iab.org References: <20200416023812.53C3517E6D06@ary.qy> <82AFA939-CAA5-4B66-B36B-CDA78EBF8298@cisco.com> From: "Joel M. Halpern" Message-ID: <2b13bb94-1bd5-cc0f-8229-f106f55500e2@joelhalpern.com> Date: Thu, 16 Apr 2020 09:48:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <82AFA939-CAA5-4B66-B36B-CDA78EBF8298@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] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 13:49:19 -0000 If we open the whole numbering / structuring of the series issue on this list, my personal guess is that we will never converge. While my guess may be wrong, I am VERY confident that if we dive into that topic, we will not come up in the kind of time frame we have claimed we want to address the structure and responsibility of the RFC Series Editor. Saying that we want an editor who can determine what community could / should have such a discussion, and whether the relevant community does want to have such a discussion, seems appropriate. Personally, I even like saying that the RSE should lead such discussion (although that is a separable question.) Yours, Joel On 4/16/2020 3:15 AM, Eliot Lear wrote: > Hi Joel, > >> On 16 Apr 2020, at 05:11, Joel M. Halpern wrote: >> >> Please, let's be a bit careful about mixing the issue of revision with the issue of the set of RFCs that you need to implement in practice to usefully fill a certain space. > > I think it’s good to tease these out, but in the context of the responsibilities of the RFC Editor. > > Brian wrote: > >>> We as a community have tried to address the latter. I will not rehash >>> or misconstrue the politics, but it was not easy, pretty, nor effective. >>> And has little or nothing to do with the numbering of our standards >>> and the revisions thereof. >> >> Exactly. And it's an *IETF* problem, so I don't see how it would be in >> scope here. > > Let’s test that: are there formats that could facilitate spotting differences between revisions, or points where updates or references could occur? For instance, today our references point to entire documents. Could the references point to specific tags in documents? > > Now… my point in asking is not to delve further into the weeds, but simply to see if we can find some useful delineations. > > Eliot > From nobody Thu Apr 16 06:56:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3EB3A08B5 for ; Thu, 16 Apr 2020 06:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzMsdTq_m2Ui for ; Thu, 16 Apr 2020 06:56:21 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343CC3A0486 for ; Thu, 16 Apr 2020 06:56:20 -0700 (PDT) Received: (qmail 1167 invoked from network); 16 Apr 2020 13:56:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=48a.5e986403.k2004; i=johnl-iecc.com@submit.iecc.com; bh=LXuN/n6qz6kDJQD850bTfSDbQ8fJCV/uAzKld2g+I3Y=; b=f/2o1yM2CXSwQWeBNdYqLOQItmnFbC2Rc227ADjLG4cb9ixrt0O1uWnFZqCODOEUkBP6wZ0Q1RfKKxOwXTfDDKb4eWE6BR5pqS/PvWADp8EfyKSk6vJrYOS0i6nuAL+CqgnLizOHt/wTtXloPWSQdoEfa2yQD9I+zGMJDa1XoR1/xGarQgXwDeqA+ZyhveOwbYQSqQbb7iT9xDkh0mnF99xv8stEm3EIA3HHmWXdo9Q8aDMwOheO9YKbFl/gJhjP Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 16 Apr 2020 13:56:19 -0000 Date: 16 Apr 2020 09:56:18 -0400 Message-ID: From: "John R. Levine" To: "Adrian Farrel" , rfced-future@iab.org Cc: cabo@tzi.org In-Reply-To: <02f201d613d7$b806fb50$2814f1f0$@olddog.co.uk> References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> <02f201d613d7$b806fb50$2814f1f0$@olddog.co.uk> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 13:56:23 -0000 >> It is infamously difficult to find all the RFCs you need to implement >> any particular service. I understand the history of why that's the >> case but I certainly don't see it as a virtue. > > But this is so easy to solve by writing a "cook book" that one might wonder why it isn't solved. > > The fact that no one writes such gazetteers might indicate that although the problem is infamous, it is not something that actually bothers many people. Or we might deduce that once someone has solved the puzzle they consider the solution to be secret sauce. Or whatever. Or it might tell us that it's so hard that it's impossible. I can tell you from recent experience that we can't even figure out how to collect the ABNF for the syntax of an Authentication-Results e-mail header, because it is spread across a dozen documents, some of which are wrong. I can't imagine trying to write an accurate cookbook for implementing a DNS server. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Apr 16 07:01:40 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E04F3A08E5 for ; Thu, 16 Apr 2020 07:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSULP3cAOGMv for ; Thu, 16 Apr 2020 07:01:37 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0ED03A08DB for ; Thu, 16 Apr 2020 07:01:37 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id h11so1378584plr.11 for ; Thu, 16 Apr 2020 07:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=6PBp1MeWv1ntZ1nj+YVa9ziZ4pOCI4lnyXTC4IVBP8w=; b=oLZ2UNfoZrIH5oMizuemmmbyH+/LfKff7xQZ0kRMnEo0zhgTmaxtXhV0Ja84trSINZ cqIiI/dkwGKdtwRsq6cUdjOWoTRIu4YytZNpT99JwAEy6Mn5dKrNNFxmua0rn83tweuU XPCzVccG77KVdner1pGvKWiDO/OKIwutvu1KusrrAVmdM42pHemgXj5NhguM2c4ERSJR DA9tfI+pvUs5ygMiVpa9OqfKIQwU0reQ/f/F6PuvnZKA7MAWUA6jBxd+p/1kbZQ/w858 6kFcFsgi/juEIH1MZWKXDZKW9RLkt8C0/vXUAyQqJ5p4Puzi/jTc/eZH52LRlV7MdwjZ CTcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=6PBp1MeWv1ntZ1nj+YVa9ziZ4pOCI4lnyXTC4IVBP8w=; b=Z2VaACSw2Ly8bhXlzW0pO0N3N8YsOas5uXID2ySxInsbWCBFrqSPur6p2/Zi9B3YBR tbGXlIAS7I4rrzr5s3mAqR6C5o/tMHV+FVXaxrEOu2yuusD8ivGc7rPFdaP/g1ACyuDJ aqX4s6Pl8dpko1BYaPfmrZ3sWO8ew7JRmu94+p9nWLguL3IKEtdsWQlEwtqoDtlANzpl hu41xM/Sb8/jEfsv+1vpMr4O0i99wDvhAiwViePHdzbyOW3q8UZoucpT5ABk0Ymq/mV+ BtAubMlqsYBigfh0Lyof2ZHDr2Al40Sjojbq9j4dPHgVB4eqgLLwnJARMnmXkIsyLsWd r3zA== X-Gm-Message-State: AGi0PuYV3l/7+L1nkIzjKegJiJPv08lAFVf/oHYW710GFN/Fsc6I3fET 8snENaAl0zFh/LHZkY2D9llhd/nHc4e3v3M= X-Google-Smtp-Source: APiQypLQiGsf4TeSgk3ZRMoh//yr5CIXjv+1SKZmIqp9TyhvOdD2GKFWIb7jGkJEDMxKhm/oavGj1w== X-Received: by 2002:a17:902:cb97:: with SMTP id d23mr10105648ply.232.1587045696183; Thu, 16 Apr 2020 07:01:36 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id e12sm16709973pfn.194.2020.04.16.07.01.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2020 07:01:34 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> <02f201d613d7$b806fb50$2814f1f0$@olddog.co.uk> Organization: http://SoftwareAndServices.NET Message-ID: Date: Thu, 16 Apr 2020 08:01:33 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <02f201d613d7$b806fb50$2814f1f0$@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] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 14:01:39 -0000 On 4/16/20 4:13 AM, Adrian Farrel wrote: >> It is infamously difficult to find all the RFCs you need to implement >> any particular service. I understand the history of why that's the >> case but I certainly don't see it as a virtue. > But this is so easy to solve by writing a "cook book" that one might wonder why it isn't solved. > > The fact that no one writes such gazetteers might indicate that although the problem is infamous, it is not something that actually bothers many people. Or we might deduce that once someone has solved the puzzle they consider the solution to be secret sauce. Or whatever. > > I don't believe that the solution is in metadata (which could get multi-dimensional), but in better documentation. The need for better documentation to explain our protocols and thinking is long-standing and the solution lies in the community. When your trying to implement a new product, it is very important. When you have already implemented, your busy and often do not reply to those questions. If it is not built into the release of the documents, it will never happen. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Thu Apr 16 07:01:48 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFB83A08E8 for ; Thu, 16 Apr 2020 07:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-N9wp5eFCUV for ; Thu, 16 Apr 2020 07:01:46 -0700 (PDT) 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 203F53A08DB for ; Thu, 16 Apr 2020 07:01:46 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id k18so1392291pll.6 for ; Thu, 16 Apr 2020 07:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=6PBp1MeWv1ntZ1nj+YVa9ziZ4pOCI4lnyXTC4IVBP8w=; b=TmM0HUinyb1PR+wKhAI6KMrRKSVfh2h85w75/rWUH5dKSbDBw9oUQLfxilZcGQ5XLJ j68rKtm99fDBvWpEOmK2CqXo2aZusyJrry4EpiJsCczZ2r8xxUwTx0l9WqMbpeO8smJe VkSpar8LO5HnilroI3VSB2uQjY0QxhiwDZPTxSOuaWdVMHGkd6dqMjHHxUTwvuJclsBq 4wQCJs6cDBqlnqv/F7prflrNMBNzPrdusF1z/kMnsIdoFVquPFRjxWyAlLEanblhGebS OxaOQdoop40xrQAnivMulYQnbPkMIebwyxHtm/Em98sTe1lxthc9EBjWrxuLkUAijbCH DZBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=6PBp1MeWv1ntZ1nj+YVa9ziZ4pOCI4lnyXTC4IVBP8w=; b=iNcl2LRqMSvmZ7o7AMX7uFdPM7K/RiWyj+41Rqj6Jl7o44uAOpAdlQz0MX8gOe5egO 3HHKMUth2PvHsUI0nHc/Nu0XLt3HPOpX2bjf6DSVdgui7fl6zx43jGaBhde0WCn2TXNp 8QQCxNCh4gk2vGEBXVS6SlbrLschGO+mxnWTjrJkWQVYTv0WprJb86Kay0z88/KATiZZ nYklmZy/oFUlIufs6clGzxAijfJtF3qArLK3SE9e+MU0LOds/PdUnAqv1Cv4gdaa1JTm eMjATS9jtvcUdxSQVYxuvDRIcw/pahK1gxwcN2dm8UGVP0mDCriYoqiICAZtcwEcx51F IE2g== X-Gm-Message-State: AGi0PubNFWwV6u3jaSr6QWailP2m/0CVBamlAjrbtOTcvCHmdWDp9aB7 6LkhqnbH7q/AwWFaffodpjPBkLMsRLo6nH0= X-Google-Smtp-Source: APiQypKozuMjy+1sIGTkxecKqRWxS82Er9t2xJBR44/YB5h1y2nCLDv+GARo/MD51gfujYsvHh8Mkg== X-Received: by 2002:a17:90a:20a8:: with SMTP id f37mr5287747pjg.148.1587045704920; Thu, 16 Apr 2020 07:01:44 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id x4sm16882866pfa.191.2020.04.16.07.01.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2020 07:01:44 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> <02f201d613d7$b806fb50$2814f1f0$@olddog.co.uk> Organization: http://SoftwareAndServices.NET Message-ID: <9ec9a82e-ccba-f950-4b2b-51a93d566065@gmail.com> Date: Thu, 16 Apr 2020 08:01:43 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <02f201d613d7$b806fb50$2814f1f0$@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] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 14:01:47 -0000 On 4/16/20 4:13 AM, Adrian Farrel wrote: >> It is infamously difficult to find all the RFCs you need to implement >> any particular service. I understand the history of why that's the >> case but I certainly don't see it as a virtue. > But this is so easy to solve by writing a "cook book" that one might wonder why it isn't solved. > > The fact that no one writes such gazetteers might indicate that although the problem is infamous, it is not something that actually bothers many people. Or we might deduce that once someone has solved the puzzle they consider the solution to be secret sauce. Or whatever. > > I don't believe that the solution is in metadata (which could get multi-dimensional), but in better documentation. The need for better documentation to explain our protocols and thinking is long-standing and the solution lies in the community. When your trying to implement a new product, it is very important. When you have already implemented, your busy and often do not reply to those questions. If it is not built into the release of the documents, it will never happen. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Thu Apr 16 07:05:46 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967FD3A08FF for ; Thu, 16 Apr 2020 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs1iWYMMzGJw for ; Thu, 16 Apr 2020 07:05:43 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA783A08FE for ; Thu, 16 Apr 2020 07:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=950; q=dns/txt; s=iport; t=1587045942; x=1588255542; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aOCQ0oX5j0+zAJgniCX0mXgSpRq9dh5oHtgYxZdjHNY=; b=PC32W8OrjItFnQArEAklvLVCs8eRRdTaO2q7/UpglAxsnNWesXItFvbU ODfOjn+Mky2h+uBj+wxjV5XI3thWcbUo+tMihwzDChmLipq4rR71ThkhK OAnuwmSyL5lgdpAckd79sDre9FdQopYQzgS0Ms2pdaoA67/zex+7d0ir5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAAB3ZZhe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkFAQELAYNpIBIqhByJAodjJZlTgXsKAQEBDAEBLwQBAYREAoI?= =?us-ascii?q?uNgcOAgMBAQsBAQUBAQECAQUEbYVihXEBAQEBAgEjVgULCxgCAiYCAlcGExS?= =?us-ascii?q?DEoJdIK5RdYEyhU+FHYEOKgGMT4IAgTgMEIJNPoROgxIygi0EsWqCToJmlHk?= =?us-ascii?q?dj16MV6kGgz4CBAYFAhWBWQMvgVczGggbFTsqAYI+PhIYDaAiPwMwj0YBAQ?= X-IronPort-AV: E=Sophos;i="5.72,391,1580774400"; d="scan'208";a="25386168" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Apr 2020 14:05:38 +0000 Received: from [10.61.247.32] ([10.61.247.32]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03GE5b5d024955 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Apr 2020 14:05:38 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <2b13bb94-1bd5-cc0f-8229-f106f55500e2@joelhalpern.com> Date: Thu, 16 Apr 2020 16:05:37 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <49162608-8E0A-4E0D-827E-42A1AB616369@cisco.com> References: <20200416023812.53C3517E6D06@ary.qy> <82AFA939-CAA5-4B66-B36B-CDA78EBF8298@cisco.com> <2b13bb94-1bd5-cc0f-8229-f106f55500e2@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.247.32, [10.61.247.32] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 14:05:45 -0000 Joel, > On 16 Apr 2020, at 15:48, Joel M. Halpern wrote: >=20 > If we open the whole numbering / structuring of the series issue on = this list, my personal guess is that we will never converge. While my = guess may be wrong, I am VERY confident that if we dive into that topic, = we will not come up in the kind of time frame we have claimed we want to = address the structure and responsibility of the RFC Series Editor. I don=E2=80=99t think we should try to do the work on this list, I = agree. I think that=E2=80=99s the general feel of the room, as it were. >=20 > Saying that we want an editor who can determine what community could / = should have such a discussion, and whether the relevant community does = want to have such a discussion, seems appropriate. Personally, I even = like saying that the RSE should lead such discussion (although that is a = separable question.) Ok Eliot= From nobody Thu Apr 16 07:08:49 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FB43A092A for ; Thu, 16 Apr 2020 07:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRUA3mhfA06w for ; Thu, 16 Apr 2020 07:08:46 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B724D3A0A31 for ; Thu, 16 Apr 2020 07:08:33 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id q16so1197903pje.1 for ; Thu, 16 Apr 2020 07:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=MmZBtz2NUzstgBJT3LBsvyuUxqixqn3HwgZKsRHvyW4=; b=SSfMkaPK0JR/omuk9aq2KANC5W4Jb4FuZywkraoprlv3exT6r5FlRK6/Fa3qsPAqTs SVV9Woj/FLTEw3ImGO0SAP/UO5dIxXJPyzaUqZFoNC+etJuzBxeOCDn2bBkzKdOzaK+G prJH7sX9mXzNNFS19Zk/+yeNA9OFhmPL6fE8WadeDOokRZME3dbNC+3qbcm+w19pjQBq 3lxHpWJSO76v+uytitaw0B2ajmdRT2xoLCNVKzWYu7C+g1qUmJeBP2atXxjX84Lpp0Jk YFKpEdF7sxOdhtSw6IfbA6ZqOQNpwH0wmWXB2ly0zbqRAJoMYghozlhVjer4n52GPhsd DkLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=MmZBtz2NUzstgBJT3LBsvyuUxqixqn3HwgZKsRHvyW4=; b=f90omP/3WDsbd1cn9GCsYx3fc4Q0tv/nAygB/Bmvts4gQ9t3BkT/1Q/XJ7GfNGjWIU wl8MCu5a9auT+RdhkY8yA9raOkFpdoFdCWnbDzaPIUgY2ZMeHhEw498jtmmiH5MkBqQu yN2xTlHp08uiNt+FAoJ5BG7Ic16gtaGPZGoUVgE5ejEDO0h35FTiBgNk5RpwVAOYatTW IpvLbxbnjkS09pf8k3RwqDJq6WH+VmEFmxD310REJoxv+GFhKpSm8Rtr7R+8L3S/VcBg IPcxfRjTXl/6BAJHkDs0ffVBbnbhEDWMeOlxLTjxWJiUuS+u5wy6VEIdRybAUi9gOdrr T0WA== X-Gm-Message-State: AGi0PuY3FGaxj9OkmRu8m2lxWcLWl0/BZZ7U02ZygI1Ugw6Qk+1clWnI G0z9Y+U2g/0q9NC8COOaH9Q1S+D2nFEKz5c= X-Google-Smtp-Source: APiQypKPfybNxl5HdetaJvEBAI4Qag6sYZUksIlVWJ1NDDh3a6OLyJCYJ25aP3+uYXtBmtKdovm3zw== X-Received: by 2002:a17:90a:290f:: with SMTP id g15mr5347866pjd.93.1587046112844; Thu, 16 Apr 2020 07:08:32 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id bt19sm2876298pjb.3.2020.04.16.07.08.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2020 07:08:32 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> <02f201d613d7$b806fb50$2814f1f0$@olddog.co.uk> Organization: http://SoftwareAndServices.NET Message-ID: <632a6ce4-a5b1-4735-d26b-0e35c88274e0@gmail.com> Date: Thu, 16 Apr 2020 08:08:30 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 14:08:49 -0000 On 4/16/20 7:56 AM, John R. Levine wrote: >>> It is infamously difficult to find all the RFCs you need to implement >>> any particular service.  I understand the history of why that's the >>> case but I certainly don't see it as a virtue. >> >> But this is so easy to solve by writing a "cook book" that one might wonder why it isn't solved. >> >> The fact that no one writes such gazetteers might indicate that although the problem is infamous, it is not something that actually bothers many people. Or we might deduce that once someone has solved the puzzle they consider the solution to be secret sauce. Or whatever. > > Or it might tell us that it's so hard that it's impossible.  I can tell you from recent experience that we can't even figure out how to collect the ABNF for the syntax of an Authentication-Results e-mail header, because it is spread across a dozen documents, some of which are wrong. > > I can't imagine trying to write an accurate cookbook for implementing a DNS server. As this continues, it would seem fair to say that the IETF does not release standards, it just releases seemingly related comments. DNS and VoIP have become like trying to put fallen leaves back on the original place on a tree, only to find out later that someone cut of that branch. It might be out of scope for this list. I think it will be very valuable over time to more protocols. > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. https://jl.l -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Thu Apr 16 10:06:19 2020 Return-Path: X-Original-To: rfced-future@iab.org Delivered-To: rfced-future@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFAB3A03EC; Thu, 16 Apr 2020 10:06:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF Announcement List" Cc: rfc-interest@rfc-editor.org, rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: iab-chair@iab.org, execd@iab.org Message-ID: <158705677668.7047.15450219213491357501@ietfa.amsl.com> Date: Thu, 16 Apr 2020 10:06:17 -0700 Archived-At: Subject: [Rfced-future] Call for nominations: RFC Editor Future Development Program Chair(s) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:06:17 -0000 As previously discussed, the IAB is seeking an additional chair or chairs for the RFC Editor Future Development Program [1]. This program is modeled on an IETF working group, and will use its mailing list (rfced-future@iab.org) to develop and validate consensus among the participants. The program currently has one chair, Eliot Lear. The current IAB has received significant feedback from the community that a second chair needs to be selected, and the IAB is eager to fill that position with a great candidate as soon as is practical. The IAB is now seeking at least one additional chair from outside the IAB to join Eliot. Together, these chairs will set the detailed agenda, manage the program, and call consensus among the participants. The program also has two liaisons from the IAB to assist with logistical matters, Wes Hardaker and Jared Mauch. If you are interested in serving in this role, please send a short email message to iab-chair@iab.org and execd@iab.org with your motivation and information concerning your familiarity with IETF working groups or similar processes. The deadline for volunteering is Tuesday, 2020-05-12 at 2359 UTC. The IAB will then solicit public comments on the candidates before making a decision. Best regards, Cindy Morgan, for the IAB [1] From nobody Thu Apr 16 11:24:27 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C353A0B04 for ; Thu, 16 Apr 2020 11:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.398, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIqZNRFlNYgR for ; Thu, 16 Apr 2020 11:24:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA2F3A0AEA for ; Thu, 16 Apr 2020 11:24:24 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 03GIOLe6082954 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Apr 2020 13:24:22 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1587061463; bh=0TA7ZfZNgSxNPaeO6s2eTlH95pm4vk7qdQGE+UWzLYU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=s8phmoHCOkDZdgT5I2+x1QeoJ7l/0zEX8HT8R+4xa0A/Nem/Kpnh0SeMFQmQ+ryBT lA/je427BTfIluQByjI2vsInxulajrIXX27HOjzx8tli/l4u8qZSm/rY9kiIF/kXA+ Rwr4TMaU8PpxvnxyVV1Wmk0/HXmTFHozNhkILLas= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: adrian@olddog.co.uk, "'John Levine'" , rfced-future@iab.org Cc: cabo@tzi.org References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> <02f201d613d7$b806fb50$2814f1f0$@olddog.co.uk> From: Adam Roach Message-ID: <94d40f8b-782b-2e5b-acf5-bf75ee510253@nostrum.com> Date: Thu, 16 Apr 2020 13:24:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <02f201d613d7$b806fb50$2814f1f0$@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] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 18:24:26 -0000 On 4/16/2020 5:13 AM, Adrian Farrel wrote: >> It is infamously difficult to find all the RFCs you need to implement >> any particular service. I understand the history of why that's the >> case but I certainly don't see it as a virtue. > But this is so easy to solve by writing a "cook book" that one might wonder why it isn't solved. > > The fact that no one writes such gazetteers might indicate that although the problem is infamous, it is not something that actually bothers many people. RFC 5411 did exactly this, but it's bound by the very issues that have come up in this thread about how we deal with revising the content of RFCs. /a From nobody Thu Apr 16 13:33:28 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA673A101E for ; Thu, 16 Apr 2020 13:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI36TWCCPP7M for ; Thu, 16 Apr 2020 13:33:24 -0700 (PDT) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3E33A101D for ; Thu, 16 Apr 2020 13:33:24 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id g2so60488plo.3 for ; Thu, 16 Apr 2020 13:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fI4uB+AJ/QuzX3zsxhPiFvWwF+/EBFX/g4XlkG9PbnE=; b=Z3f5IKFvVQ2kthB1EnB8nMPtfiagtOP6ZYFLnoIH9OQCzQngBapJLy0aNh/goyx7uU UOXfmx0l7zrroC8rCymD+dxvTZsOUaWDE/ROkdJ2Bs8v0X1pCbjVRJf/W5F+r2PtKx4B OPE815vABsgGFAko1+i/CKFdcivGiiEYo1rO+7lpkXoBVt1AkhGQ4NaReTwiVeJlY1BE JUlCcriv+nj3Xw0AWEpw4MSabvDb8pJO9lqJNPnqtD97Z2mpdQ8RL0Guja6DQFmpfQsq HUbof0eMlWfuHhgLRYaLmWTiiwqp/xTLL33sXZtDcWI062I+MIq26HQG1QgIvdky+GdS i1aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=fI4uB+AJ/QuzX3zsxhPiFvWwF+/EBFX/g4XlkG9PbnE=; b=S7aoEky4x+M6Hq/OHGjGGFPaHeFmlK9MOjJqtIs23wJO9F+XS52nfSxjfnyjL0e33W 8u9qnemkKp6RIMOlrt1kiV3VQrxWlDCSYx4Fex2w3jcKAVpvyh4AYtmjR6XwDelOdyTn llnJw/NXeglMwDExxj6cpvaBJoLfSvaR9I2ib5+vTA0lYJ33Oda2Yo3pTr9ugQ0QvmZN a/i83zSc9ub4DkeEyQkIGX1LVixF/wLn+70T4jJQVXlCUuxSVRMK9w+RNCDTDYdOQ3nR lrIK11McjhelTEcqPGTg7diaJ2LlwBuxJw0M7yx9LhH/HPS2T7ag75oW3yVrE76IQMSV M/Pw== X-Gm-Message-State: AGi0PuYzGEMZvXzKRb+MBpBqIXt3ryXGl5HgO/d5aakY112GQ/D3Lgmd nAVAxV5iADeejNvQKXqvH+4= X-Google-Smtp-Source: APiQypLsy07jq/1fKd8+doOLKkJverA9AxyOlzdeXw97tf1lVBtSH3Anmy/2bQI/BRDtNdc27g/VfQ== X-Received: by 2002:a17:902:8c88:: with SMTP id t8mr42215plo.176.1587069203879; Thu, 16 Apr 2020 13:33:23 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id c190sm17161591pfa.66.2020.04.16.13.33.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2020 13:33:23 -0700 (PDT) To: rfced-future@iab.org, rfc-interest@rfc-editor.org References: <158705677668.7047.15450219213491357501@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <34dce524-37c5-3004-ae06-d9dcc7e845d1@gmail.com> Date: Fri, 17 Apr 2020 08:33:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <158705677668.7047.15450219213491357501@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Call for nominations: RFC Editor Future Development Program Chair(s) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Apr 2020 20:33:27 -0000 Speaking as one who is definitely not going to volunteer for this, for several reasons, I really want to encourage everybody who cares about the RFC series to consider doing so. There were good candidates the last time, but mainly from the "old guard". This time, it would be great to have some new and different names too. Regards Brian Carpenter On 17-Apr-20 05:06, IAB Executive Administrative Manager wrote: > As previously discussed, the IAB is seeking an additional chair or > chairs for the RFC Editor Future Development Program [1]. > > This program is modeled on an IETF working group, and will use its > mailing list (rfced-future@iab.org) to develop and validate consensus > among the participants. > > The program currently has one chair, Eliot Lear. The current IAB has > received significant feedback from the community that a second chair > needs to be selected, and the IAB is eager to fill that position with a > great candidate as soon as is practical. The IAB is now seeking at least > one additional chair from outside the IAB to join Eliot. Together, these > chairs will set the detailed agenda, manage the program, and call > consensus among the participants. The program also has two liaisons from > the IAB to assist with logistical matters, Wes Hardaker and Jared Mauch. > > If you are interested in serving in this role, please send a short email > message to iab-chair@iab.org and execd@iab.org with your motivation and > information concerning your familiarity with IETF working groups or > similar processes. The deadline for volunteering is Tuesday, 2020-05-12 > at 2359 UTC. The IAB will then solicit public comments on the candidates > before making a decision. > > Best regards, > Cindy Morgan, for the IAB > > [1] > From nobody Thu Apr 16 13:35:19 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965EE3A102C for ; Thu, 16 Apr 2020 13:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyDbHwFzJzAk for ; Thu, 16 Apr 2020 13:35:14 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C74B3A102B for ; Thu, 16 Apr 2020 13:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2307; q=dns/txt; s=iport; t=1587069313; x=1588278913; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Gf/g25TNWBVoTTIHwNSiR0kkRhLlJSRjQY14MD8B87Y=; b=FjYNPKbe/Gv/2qjDGlPPxaPbsjgyBRYnkJ5O9OCjyixlYB0e48zmIIXs 9vExKr8YoY6nGA5Gqyg1WBbAElP4r4VAWBVRz/GutyRZfiyBCUOFnX8Zh 9qPIAsvrwjFlMN0GiFExzikLrgCq0NMRXIYgThfKyFvbhx8uoc/hWZU50 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAADgwJhe/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBaQQBAQELAYMUVSASKo0eh2IliXKPYRSBZwoBAQEMAQE?= =?us-ascii?q?YDQoEAQGERAKCMDYHDgIDAQELAQEFAQEBAgEFBG2FVgyFcQEBAQECAQEBGx0?= =?us-ascii?q?0CwULCxguIQYwBhMUgxIBgksDDiAPrxeCJ4VPgkcNghwGgTgBjE+CAIE4DBC?= =?us-ascii?q?BT34+gh5JAYExARIBIYNEgi0EsSFJgk6CZpA2hEMdglSISoRAjFebX40ngz4?= =?us-ascii?q?CBAYFAhWBWQIwZ3AzGggbFTsqAYIKATM+EhgNV5E5iE+FQz8DMAKNAS2CFgE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.72,392,1580774400"; d="scan'208";a="25334227" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Apr 2020 20:35:09 +0000 Received: from [10.61.247.32] ([10.61.247.32]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03GKZ8ce022385 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Apr 2020 20:35:09 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <34dce524-37c5-3004-ae06-d9dcc7e845d1@gmail.com> Date: Thu, 16 Apr 2020 22:35:08 +0200 Cc: rfced-future@iab.org, rfc-interest@rfc-editor.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158705677668.7047.15450219213491357501@ietfa.amsl.com> <34dce524-37c5-3004-ae06-d9dcc7e845d1@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.247.32, [10.61.247.32] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] [rfc-i] Call for nominations: RFC Editor Future Development Program Chair(s) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Apr 2020 20:35:17 -0000 +1. > On 16 Apr 2020, at 22:33, Brian E Carpenter = wrote: >=20 > Speaking as one who is definitely not going to volunteer for this, > for several reasons, I really want to encourage everybody who cares > about the RFC series to consider doing so. There were good candidates > the last time, but mainly from the "old guard". This time, it would > be great to have some new and different names too. >=20 > Regards > Brian Carpenter >=20 > On 17-Apr-20 05:06, IAB Executive Administrative Manager wrote: >> As previously discussed, the IAB is seeking an additional chair or=20 >> chairs for the RFC Editor Future Development Program [1]. >>=20 >> This program is modeled on an IETF working group, and will use its=20 >> mailing list (rfced-future@iab.org) to develop and validate consensus=20= >> among the participants.=20 >>=20 >> The program currently has one chair, Eliot Lear. The current IAB has=20= >> received significant feedback from the community that a second chair=20= >> needs to be selected, and the IAB is eager to fill that position with = a=20 >> great candidate as soon as is practical. The IAB is now seeking at = least=20 >> one additional chair from outside the IAB to join Eliot. Together, = these=20 >> chairs will set the detailed agenda, manage the program, and call=20 >> consensus among the participants. The program also has two liaisons = from=20 >> the IAB to assist with logistical matters, Wes Hardaker and Jared = Mauch. >>=20 >> If you are interested in serving in this role, please send a short = email=20 >> message to iab-chair@iab.org and execd@iab.org with your motivation = and=20 >> information concerning your familiarity with IETF working groups or=20= >> similar processes. The deadline for volunteering is Tuesday, = 2020-05-12=20 >> at 2359 UTC. The IAB will then solicit public comments on the = candidates=20 >> before making a decision. >>=20 >> Best regards, >> Cindy Morgan, for the IAB >>=20 >> [1] = >>=20 > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest From nobody Thu Apr 16 15:14:00 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEF03A1216 for ; Thu, 16 Apr 2020 15:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBCO6z6i-vkN for ; Thu, 16 Apr 2020 15:13:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B073A1215 for ; Thu, 16 Apr 2020 15:13:55 -0700 (PDT) Received: (qmail 92382 invoked from network); 16 Apr 2020 22:13:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=168dc.5e98d8a2.k2004; bh=Ydz0g1sY1MRbpXkWr5RxHbqI2Ybz9M6talAg+8f28Ls=; b=N/73sXGUOwj3sFWtRY9jPZSCdGljS23zIBqlpkXcT4QLkGwL8bgRdcteZL7jt26WoTBlohC5QJt+7QPTErsC4rtc9Xjc7BpVrP9noLBzfcGkgPO4jOWI4XWGdNtEVZBqBMC4mfrI0orC60z6cdgHWOEi0xAPJOZ7sSXw+Od2xuPtOVFYMK0tFXJ2WqZHBDiv6sbPHa8hucC6dzll38XFa4dGyDUUp4WqWDsRb5OGZXcV0SeMZfF7Qh5VjmT++sNg Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Apr 2020 22:13:54 -0000 Received: by ary.qy (Postfix, from userid 501) id 2D00A17EF88A; Thu, 16 Apr 2020 18:13:53 -0400 (EDT) Date: 16 Apr 2020 18:13:53 -0400 Message-Id: <20200416221354.2D00A17EF88A@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: mnot@mnot.net In-Reply-To: <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Apr 2020 22:13:58 -0000 In article <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> you write: >* We currently spend approximately US$200/page of published RFC on the RFC Editor function, and there is no >obvious mechanism to determine whether this money is well-spent, or to control the overall cost. For >comparison, market rates for technical editing seem to range between US$10-35/page (which is not a fair >comparison, but the difference _is_ eye-opening). My wife does tech editing, and the kind of stuff that she does is only a very small part of what the RPC does. There is no spec for what the RPC does beyond "what the RPC does." Back in 2006 when we put it out for bid, I believe that every bidder talked to the existing key employees to be sure they could keep them on, since otherwise we would have to invent a whole lot from scratch. (I was involved in one of the losing bids.) I think that AMS and its employees are doing a good job, and I expect they will continue to do so, but it's a significant risk if some of them were to quit or get sick. From nobody Thu Apr 16 16:06:50 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D8C3A12E5 for ; Thu, 16 Apr 2020 16:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=QW8gTnRq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QkziFWZW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hyd4XQ7imle for ; Thu, 16 Apr 2020 16:06:46 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A253A12E3 for ; Thu, 16 Apr 2020 16:06:45 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 0351F784; Thu, 16 Apr 2020 19:06:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 16 Apr 2020 19:06:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=h d7n80PxhHiMHTnKbN3fcIxWcIjnm5FJLsCQtCJtXKo=; b=QW8gTnRqnECnv6RuU XvdUy8FaQK5R0bk4JQlgEr4WV1wOmFyO8R0uBFdfZ0ruPvqh9Ws8wHV68xk2H+0J d3y+lAYJnM+BCh2+mbjk+Mtj9FpJfGiAbrg1FwU9qxfdb1xS5OJ4JiAN6Nb/qYSR 3fkC7Q3HDNFcMvPwtG9tmfa+MuxXnoSSoEVhk9mQNCBqvRJOYRSF7p+BYnzt7lO1 C/WmS69glVaBZD3nUFHE3V+scnzxRblxCyL7yL7JAUCGQ/Vq7ZqVJugyCKI5zsSS gSlDBOXT0/O6TZ2B/mmQ9LvZocbPybf2xT21bg4LSyiFKBE7ijEVYVJAek/tDHni Aqfiw== 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=hd7n80PxhHiMHTnKbN3fcIxWcIjnm5FJLsCQtCJtX Ko=; b=QkziFWZW+F2hylqLW/u2+03cl8QcGDkTvuTUGNk575b3B870BFs+jIu2z nSARf5807YEvuUWvhJ3xpSQHGn8SKnegdKD9whqJSHfRsqZ4tyb46b3ldg+rzOGy 6janAjH3lba4o5Otx27SnzmGnDguWUd7snblQa1xSw6DrJtPMfJAcskDkiVZFh4E CJuqpV+3sMloEovaqS/XiWkOkleDCKOI5NAYobGF/2m0EI1jEZ99TXwFJh2sXJYz /JHNhA0HjvlFXWznecErmdbEcliU1N5VSK6KZg5hV3Cw60E8oQ0mSZ5BKPVjIMMF MEN0+RkdbJoY4IH7djG+OnQ8J3IwQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeeigddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnh gvth X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 605C03060064; Thu, 16 Apr 2020 19:06:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <20200416221354.2D00A17EF88A@ary.qy> Date: Fri, 17 Apr 2020 09:06:39 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200416221354.2D00A17EF88A@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 16 Apr 2020 23:06:48 -0000 > On 17 Apr 2020, at 8:13 am, John Levine wrote: >=20 > In article <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> you write: >> * We currently spend approximately US$200/page of published RFC on = the RFC Editor function, and there is no >> obvious mechanism to determine whether this money is well-spent, or = to control the overall cost. For >> comparison, market rates for technical editing seem to range between = US$10-35/page (which is not a fair >> comparison, but the difference _is_ eye-opening). >=20 > My wife does tech editing, and the kind of stuff that she does is only > a very small part of what the RPC does. >=20 > There is no spec for what the RPC does beyond "what the RPC does." > Back in 2006 when we put it out for bid, I believe that every bidder > talked to the existing key employees to be sure they could keep them > on, since otherwise we would have to invent a whole lot from scratch. > (I was involved in one of the losing bids.) >=20 > I think that AMS and its employees are doing a good job, and I expect > they will continue to do so, but it's a significant risk if some of > them were to quit or get sick. I do too. But not having what the RPC does written down seems pretty = broken. -- Mark Nottingham https://www.mnot.net/ From nobody Thu Apr 16 16:15:10 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F933A130A for ; Thu, 16 Apr 2020 16:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPj0TNm0kszH for ; Thu, 16 Apr 2020 16:15:05 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A5F3A1307 for ; Thu, 16 Apr 2020 16:15:04 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id c138so118474pfc.0 for ; Thu, 16 Apr 2020 16:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=htKWtKzq8BCYv4woi8VUaE+Fs6oXWDIwiH83NdjinSY=; b=qzQfm5rjJ5BqJ4rQWM/A22qQKvQU3MHR80r0TiHxTHDOFTuYqKsK9gdVPO11J/jY+f 8bl7Pb6tDs76icK5PnYAvXXosSZ3WGF/tN2x+AwLM7oJMvbRnOwnm6amYhUcaS+wy+sO ehMWcjVEziiIHhs1xc4gaetx/xxm3Bg0kTdiMujugfzx+q2WarCX0y0AQHtVaP4Mi/ok gfu5U937T2NJAtroeq50Wq2ag0g314skDqtuIaHBWTjqnb6MBO4JstbM2hWfLvWqU8v+ iNvyBzr88sqB0Yu8LX+8CdTWO6Jsla8P4WDEd2OO9HGgzezd9KOn6kn8o5KT7gLvQ83c ogJg== 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=htKWtKzq8BCYv4woi8VUaE+Fs6oXWDIwiH83NdjinSY=; b=rH2wOg2/cyKX8wtr3LoIB8Rw1dWQIahiDNJu7SqmrCdf1fJFRDOlMTaqKDvH+Vg1PF p9GDcL/pZ/2GvVfUt/c17r0WbJUiASXIBN1d1HUyVj6mNTA2ibdiIc2AR3K23Ck+4lOJ g924pliJx/spRU+EMICyocGikWYcGcufmLYG0eQwR6oArN69QKjZnPQb1A/fjNEYIoVi SKE9BKjpxZQ2wM0aBZ1JlwxePhDnDyWacV4Uz0QNe1C/njutP13hLDKRbVw25qEsxBzE 9NMhYHxVfvEvN4UiSqFUVJYOl7XAwtlApZiwwlgorWr4Ur33IhKyHct7S36ET1gO/X26 wtnw== X-Gm-Message-State: AGi0PuYf9RKykAq90TWlMy4iGe6DUyGLeXUtE4MtJNk2pLNeVdEAIHXF oiSd8coepQMqkZW9b/iJ8px6UkVS X-Google-Smtp-Source: APiQypKedEw9NpoLcBXosuPE090qkktB52Kuk6JAZ1B63175/uiW0MZJ8eSsEWbu7JVL2I2upLRLcg== X-Received: by 2002:a63:754f:: with SMTP id f15mr124752pgn.89.1587078903803; Thu, 16 Apr 2020 16:15:03 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id w3sm2685194pfn.115.2020.04.16.16.15.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2020 16:15:03 -0700 (PDT) To: Eliot Lear , "Joel M. Halpern" Cc: John Levine , rfced-future@iab.org References: <20200416023812.53C3517E6D06@ary.qy> <82AFA939-CAA5-4B66-B36B-CDA78EBF8298@cisco.com> From: Brian E Carpenter Message-ID: <6ac1e2e9-3050-cf06-f631-17bd99c80672@gmail.com> Date: Fri, 17 Apr 2020 11:15:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <82AFA939-CAA5-4B66-B36B-CDA78EBF8298@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 23:15:08 -0000 On 16-Apr-20 19:15, Eliot Lear wrote: > Hi Joel, >=20 >> On 16 Apr 2020, at 05:11, Joel M. Halpern wrote:= >> >> Please, let's be a bit careful about mixing the issue of revision with= the issue of the set of RFCs that you need to implement in practice to u= sefully fill a certain space. >=20 > I think it=E2=80=99s good to tease these out, but in the context of the= responsibilities of the RFC Editor. >=20 > Brian wrote: >=20 >>> We as a community have tried to address the latter. I will not rehas= h=20 >>> or misconstrue the politics, but it was not easy, pretty, nor effecti= ve.=20 >>> And has little or nothing to do with the numbering of our standards = >>> and the revisions thereof. >> >> Exactly. And it's an *IETF* problem, so I don't see how it would be in= >> scope here. >=20 > Let=E2=80=99s test that: are there formats that could facilitate spotti= ng differences between revisions, or points where updates or references c= ould occur? For instance, today our references point to entire documents= =2E Could the references point to specific tags in documents? >=20 > Now=E2=80=A6 my point in asking is not to delve further into the weeds,= but simply to see if we can find some useful delineations. Certainly, useful features could be added to the authoring toolkit, if on= ly the IETF (an SDO that happens to use the RFC Series) would tell us (th= e friends of the RSE) what it wants. BTW we already have direct section references. For example, look just bel= ow the figure at https://www.rfc-editor.org/rfc/rfc8754.html#name-segment= -routing-header I think this is an example of where the system worked. Brian From nobody Thu Apr 16 17:49:02 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E24F3A1496 for ; Thu, 16 Apr 2020 17:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rrg0eiuor0Ea for ; Thu, 16 Apr 2020 17:48:59 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CC03A1494 for ; Thu, 16 Apr 2020 17:48:59 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id t11so264066pgg.2 for ; Thu, 16 Apr 2020 17:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=h09ICagjfAhh8dSUTIkSoj2p6dnSbmkGHuG0/km49jc=; b=CCxw7J6TJ6yw6OUGbXOw4QIL+3zMkEz/ijP1N14hcgwxzc5wrGCva2I2w3sKuP8BqI H3fRR/kHWyxTg+d6BSECFgoOySztTjgweuVYKMfwhK8oZQmAmuHcxWZg36TUEReWGzEk o7jsOydNtofRZhqVXPZukEGuJQe4ctVxTwNnzi5ww+VvRAoWb1yMCsBpkjOQyJ9BE6Pm Om3e0jWmR/mbDsUW0bkKEUMSaJwujyiIWNxaA/nwKtB7aBtHafGFP2V8ZeeL2ne6qQJs BEQ5Oddvz0/ArawCP2SXYoUZH0eoZCwmHMAqh8cc+k/ek9uDJ5XUYIaJHaxYcgGGr4I7 aOTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=h09ICagjfAhh8dSUTIkSoj2p6dnSbmkGHuG0/km49jc=; b=BhLkJhGLdjdUetD/sZ9hU67XAWoPHFSPqjBjXarPF3CgdflMvIkPVIRzyj8OKplTxR LOZy/yV6ciY2k6NaofODZUmM1Zc0hZvS974pYHsIMuJLKyYDdjSXumf7WH0veK32O9uv z897+OthzntS/Y9YPIs0EX0TjwyurreTN/z0HnXS6n8w9n4pKQTGLUnvRK1IIzio7NSU 2JrQaTbSAg7MD+DWcjGXL6nK6AOgEZZNcIGHwchB/2fs8vmyE087UWKbpr0NW0XNHeU/ v2tJLWXgqAZ+kPc9xJrjrpZYN31rNiQbUkSGT6tpLWENvtYk7koQpDYWSIdXai0m/wTY YIYQ== X-Gm-Message-State: AGi0PuaQeZMXdowDnrF8LHTCp5F6jKUilaIYG/cZ2qKEfbEY+TbcXPEX b93DwXl6JnplbgvnpEIpVwy1L29c X-Google-Smtp-Source: APiQypIDc239ICcTAk74Ay1cgxrvgzFefO11WeijSNi65lb9zaw+aNRRD9c9OrIi3n8Ob/namjlcsQ== X-Received: by 2002:a65:428a:: with SMTP id j10mr449916pgp.272.1587084538306; Thu, 16 Apr 2020 17:48:58 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id 1sm3879455pjc.32.2020.04.16.17.48.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2020 17:48:57 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'John Levine'" , Cc: References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> In-Reply-To: <20200416023812.53C3517E6D06@ary.qy> Date: Thu, 16 Apr 2020 17:48:56 -0700 Message-ID: <01a501d61451$fa4216b0$eec64410$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLSnuxG0OzQaVgFs3DKHtdtDqVq4KaDYI6A Content-Language: en-us Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 00:49:01 -0000 I think some of the work of envisioning how a more up-to-date = specifications could happen,=20 https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration-07 doesn't presume changes to the RFC series per se, but might provide = better input to the archival series as well as interim dated records of = (rough) consensus. GitHub isn't "a website" because it implies a complete history of edits = and versions and issues and disagreements. -- https://LarryMasinter.net https://going-remote.info From nobody Thu Apr 16 18:33:37 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B36F3A1560 for ; Thu, 16 Apr 2020 18:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJMwAbbL3dOD for ; Thu, 16 Apr 2020 18:33:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297493A1559 for ; Thu, 16 Apr 2020 18:32:25 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 493JVc1n33z1006; Fri, 17 Apr 2020 03:32:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <94d40f8b-782b-2e5b-acf5-bf75ee510253@nostrum.com> Date: Fri, 17 Apr 2020 03:32:23 +0200 Cc: adrian@olddog.co.uk, John Levine , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 608779943.817227-eef93dca3abe3fe7013c1e9a80455530 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> <02f201d613d7$b806fb50$2814f1f0$@olddog.co.uk> <94d40f8b-782b-2e5b-acf5-bf75ee510253@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 01:33:35 -0000 On 2020-04-16, at 20:24, Adam Roach wrote: >=20 > RFC 5411 did exactly this, but it's bound by the very issues that have = come up in this thread about how we deal with revising the content of = RFCs. Yes, we have had a few roadmap documents (RFC 4614/7414 comes to mind, = or RFC 6071). The TCP roadmap is the only example I can find where such a roadmap was = actually published again as revised RFC. Because of the immense effort needed to generate a consensus RFC with = this information, some roadmaps never were pushed to RFC (e.g., = draft-bormann-6lo-6lowpan-roadmap-00.txt, = draft-bormann-core-roadmap-05.txt); others were just published as = articles (the ultimate fate of the latter roadmap was = https://DOI.org/10.1109/MIC.2012.29). We never developed roadmapping into an element of our culture, but we = could. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 16 18:34:10 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA60A3A1543 for ; Thu, 16 Apr 2020 18:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3WomOHYaUij for ; Thu, 16 Apr 2020 18:34:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1983A3A1540 for ; Thu, 16 Apr 2020 18:33:58 -0700 (PDT) Received: (qmail 29802 invoked from network); 17 Apr 2020 01:33:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7468.5e990785.k2004; i=johnl-iecc.com@submit.iecc.com; bh=3aX3GoNADRQ9Zg3Wf3pFT9xhwILrbZQfp30KSEIobts=; b=YXC7yQ8Q1O5egSAQRvP8dpmznXMdh+jE2IORiqqm4DqeprtGN9Nw2Iu1MILvUvtvmjgs/PHnLJCSGGdE35mHfjSMJWCZ7vXsiBeOwmAKz97bkkVUb1hC/XgRZiAj2nAM5UN8fI8ymNni2oMnoZcmUqGfHQ7+SzitytuS/Fdzbjeyc6dSRXna3N0boruMyFdZnF8Nwfcvk8oYbpqL8Ji86B3gtySlUQlakv4yndpFjbumFIqzq6tYcgIUJu3hzCVs Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 17 Apr 2020 01:33:57 -0000 Date: 16 Apr 2020 21:33:57 -0400 Message-ID: From: "John R. Levine" To: "Larry Masinter" , rfced-future@iab.org Cc: cabo@tzi.org In-Reply-To: <01a501d61451$fa4216b0$eec64410$@acm.org> References: <21C3BA6B-25E3-4D1D-80F4-A2A459479237@tzi.org> <20200416023812.53C3517E6D06@ary.qy> <01a501d61451$fa4216b0$eec64410$@acm.org> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Rfced-future] Observations on issues X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 01:34:09 -0000 > I think some of the work of envisioning how a more up-to-date specifications could happen, > https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration-07 > doesn't presume changes to the RFC series per se, but might provide better input to the archival series as well as interim dated records of (rough) consensus. This is fine for tracking the development of I-Ds, but there is a big difference between an I-D and an RFC. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 17 00:43:18 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989FD3A0FB9 for ; Fri, 17 Apr 2020 00:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3DZUCHFVytQ for ; Fri, 17 Apr 2020 00:43:16 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377803A0FB6 for ; Fri, 17 Apr 2020 00:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=518; q=dns/txt; s=iport; t=1587109396; x=1588318996; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=iVArzVXI/K0qzU/PYdRQx3qkLMIEkaO/tshNERasKPo=; b=PN/vegF54yftBo66HFTg9H9vXywkzbYiPAdBYZFSIGzPpbHGmjFuZ3iK cmwK1XwrCLyUS4BFwd2g2TUDmeNvtDkjXU49uETtPHj07g/J2VDUovepA vvjpk2qch6yin1dJ5+np0t5mGxDte0mqikjvH8cMjuSKv4o3ijtH9xxod g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AAAbW5le/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoEAQELAYNoASASjUmjVgoBAQEMAQEvBAEBhEQCgjA3Bg4CAwE?= =?us-ascii?q?BCwEBBQEBAQIBBQRthWKFcgY6PxALDjhXBieDEoJ9rjmCJ4VPhSOBOAGMUII?= =?us-ascii?q?AgTgcgh8uPoROg0SCLQSxbIJOgmaUeR2CQ40bjFipBoM+AgQGBQIVgWgjgVc?= =?us-ascii?q?zGggbFWUBgj89EhgNoCI/A49zAQE?= X-IronPort-AV: E=Sophos;i="5.72,394,1580774400"; d="scan'208";a="25408944" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Apr 2020 07:43:13 +0000 Received: from [10.61.247.32] ([10.61.247.32]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03H7hDG2017888 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Apr 2020 07:43:13 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> Date: Fri, 17 Apr 2020 09:43:13 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <5059D78F-3C4D-47BE-9EB3-592B6A975C09@cisco.com> References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.247.32, [10.61.247.32] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 17 Apr 2020 07:43:18 -0000 Hi Mark and thanks very much for your note. I have one clarifying = question: >=20 > * The methods that the RSE has available to the make decisions (of = various sorts) are ill-defined, to the point where it can be untenable = for both them and the community. To me, this is the heart of the matter. Since this is an important issue for you, would you care to elaborate a = bit more about what sort of decisions the RSE makes, their impact, and = what you think good looks like at a high level? Eliot From nobody Fri Apr 17 08:41:36 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654363A0E7E for ; Fri, 17 Apr 2020 08:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZCOyofuGinLg for ; Fri, 17 Apr 2020 08:41:33 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FE03A0E6A for ; Fri, 17 Apr 2020 08:41:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7993B300AEE for ; Fri, 17 Apr 2020 11:41:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id i_BTovGGj-4p for ; Fri, 17 Apr 2020 11:41:29 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id E409B300A02; Fri, 17 Apr 2020 11:41:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> Date: Fri, 17 Apr 2020 11:41:30 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 17 Apr 2020 15:41:35 -0000 Mark: I agree with many of your thoughts, but I want to share some thoughts = that came to me as I read your message. They are not in order. > * Over time, the RFC Series -- in some form -- becomes an even more = useful and well-understood resource for an increasing portion of the = technical community Yes, indeed. The influence of the RFC series over the last 50 years is = quite amazing. > * There is no back pressure mechanism on drafts that need extensive = amounts of editing or preparatory work. Note that this could be = addressed outside of the RSE's purview, but it does have a strong = influence on how we describe the role of the RFC Editor overall. There ought to be a straightforward mechanism for the RFC Editor to say = that a document is not written well enough tor admittance to the queue. = The should shame the approving stream. Today, the RFC Editor is = reluctant to send documents back. I would like to see the stream = manager hold the authors to a higher bar. Too often I hear, "That's = okay, the RFC Editor will fix it." > * The methods that the RSE has available to the make decisions (of = various sorts) are ill-defined, to the point where it can be untenable = for both them and the community. To me, this is the heart of the matter. I do not know if it is the hear of the matter, but it certainly overlaps = with the above. > * The RFC Series has come to serve a wide variety of audiences, and = the perceptions about their needs often compete. For example, = "lower-layer" technical specifications often have a relatively small, = specialised implementer and academic audience, where "higher-layer" = application protocols sometimes have extremely broad, more casual = audiences with less attention to give to minutia. As a result, some = people feel that navigability of the series is an existential threat, = while others perceive it as a minor annoyance (and that's just one = example). This is a set of potential problems that could be addressed by = an RSE, but designing the role and its interface with the community -- = or really, communities -- needs to take it into account. In the broadest terms, the audience is the implementer. That said, the = characteristics of the routing protocol implementer are somewhat = different than the characteristics of the codec implementer and so on. = I am not sure there would be a huge value in enumerating those = characteristics. They are not static. Russ From nobody Fri Apr 17 12:03:14 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D303A07BD for ; Fri, 17 Apr 2020 12:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkSgnOyT9Rt5 for ; Fri, 17 Apr 2020 12:03:12 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26963A0CD8 for ; Fri, 17 Apr 2020 12:02:20 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id m13so2311382otf.6 for ; Fri, 17 Apr 2020 12:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U3gigeOqqi0CWCPHTZ6sW0mQ4f50mDDgfH23XIC2uW0=; b=WnZiGqWdCWHuUZlQD/PDdcAavYpuqtaoizA4I2b0l4RWjnhVTZy4sD053lST7hZhVg arQGvMVOhKdVcn9Oux2A6KzkVoPzYJG0Aq1yuBbrflnoSaOT4uwNgrElYmbbGiHNm6Mr CwRrA9msFDpwgop2StfoN50FiKNwBnowToNHU3of1EklYZ56B6FSl0ueXH+KLFgYFNJM DnRdYArstD6USAybTkjscThNZJasPkL+GGHx0slqC2YQJhRsqKwz5zm9PzA+ssG2i/Ej B70gSucaivb7grYgQgor5aQBHYfy7oKhxPA4G8djvEREgmXkkJsksrgiWFDrOiC6fFi1 56/w== 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=U3gigeOqqi0CWCPHTZ6sW0mQ4f50mDDgfH23XIC2uW0=; b=JjlFrHTvtmHE54OtqPUs9ctKmXEi/9ADoKrw0ZwxXczLopoeRhJnN/7JKGWZNhdvQ5 M4bb3WM1Ag+7EBdWeJwvhPL6lv4w+W879Qo0n8XP9AAJAY4HAhV4llmx3CRaOTljn7c9 jRg+q/77WdkPtZVn/XXJ6nr3iVkVdp7KrlmXw5bQ7H+4khq9PeTOcHik7lX/AmfYMofy Aq/26KjGt7bQKYJLPBN2CxN0nQXEeNUP5/CRZlHuUEt4BzLP2lOHI7orUvbN7F+1xSkY bJF8iHX6JAvqGLTsUOCz660O/1Bx1f+PYJkDvQqKqmUkkYwIaSbrjaX9wr7sTfDoh2h9 P+rg== X-Gm-Message-State: AGi0PuaYF0HdNdm7Zo8lBCEpjr089iqJpoNjYKelrLyeHeVHeWmpiOhp uZKn6NDVHSKz+FB4vB2Ij0Ttt5EH5gLlh+HgqBg= X-Google-Smtp-Source: APiQypKaHxNkp2d5+Xcg6ur888S8x00vwpnDV4ilrNd0hxAES8ZlYcnRDnBCbBJez0jdFNZHw95Z+IF2zfOwt4jh7JE= X-Received: by 2002:a9d:634f:: with SMTP id y15mr219155otk.41.1587150140065; Fri, 17 Apr 2020 12:02:20 -0700 (PDT) MIME-Version: 1.0 References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> In-Reply-To: <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> From: Tim Wicinski Date: Fri, 17 Apr 2020 15:02:09 -0400 Message-ID: To: Russ Housley Cc: Mark Nottingham , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000004dcc3405a381304d" Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 17 Apr 2020 19:03:14 -0000 --0000000000004dcc3405a381304d Content-Type: text/plain; charset="UTF-8" On Fri, Apr 17, 2020 at 11:41 AM Russ Housley wrote: > > > There ought to be a straightforward mechanism for the RFC Editor to say > that a document is not written well enough tor admittance to the queue. > The should shame the approving stream. Today, the RFC Editor is reluctant > to send documents back. I would like to see the stream manager hold the > authors to a higher bar. Too often I hear, "That's okay, the RFC Editor > will fix it." > > I've always felt that one of the jobs I have as a working group chair/shepherd is to hand over the best possible document to the IESG and the RFC Editor. The better the document is, the better the IESG understands it, and the easier it is for the RFC Editor to get it published. I would welcome feedback from the RFC editor on our WG documents, as I think it can be done in a way to improve the quality of our product. These type of discussions on document quality, etc should be part of the new working chair re-education orientation process. tim --0000000000004dcc3405a381304d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 17, 2020 at 11:41 AM Russ Housley= <housley@vigilsec.com> w= rote:


There ought to be a straightforward mechanism for the RFC Editor to say tha= t a document is not written well enough tor admittance to the queue.=C2=A0 = The should shame the approving stream.=C2=A0 Today, the RFC Editor is reluc= tant to send documents back.=C2=A0 I would like to see the stream manager h= old the authors to a higher bar.=C2=A0 Too often I hear, "That's o= kay, the RFC Editor will fix it."


<= div class=3D"gmail_default" style=3D"font-family:monospace">I've always= felt that one of the jobs I have as a working group chair/shepherd is to h= and over the best possible document to the IESG and the RFC Editor.=C2=A0 T= he better the document is, the better the IESG understands it, and the easi= er it is for the RFC Editor to get it published. I would welcome feedback f= rom the RFC editor on our WG documents, as I think it can be done in a way = to improve the quality of our product.

These type of discussions on document quality, e= tc should be part of the new working chair re-education=C2= =A0orientation process.=C2=A0

tim
--0000000000004dcc3405a381304d-- From nobody Fri Apr 17 13:55:33 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A263A0061 for ; Fri, 17 Apr 2020 13:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJTVc6aBWC-4 for ; Fri, 17 Apr 2020 13:55:30 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105B33A003D for ; Fri, 17 Apr 2020 13:55:11 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id n24so1375112plp.13 for ; Fri, 17 Apr 2020 13:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dYagON2SebkuMV5UKxgWb47nbtwjqtcrf1ddp5zhyFQ=; b=YGJZkcXz6U/I9cls5E1LvqgT+C67k1akO9OAAA6a1GpxNvVHtTSVet60KR3aRek2F7 lxZnSI5u4J+SSeVl0dR7fvk5LSz162AGs5lQ4MTZj2mTgDAYtMj8yfoOLnRJEeyaF/Kd gZ8HcpEsKKbA+pXVjlpO+fD5NDY3fiCyk770BXqUTasqzfSdYsz7UcbV3eZvTWDEgKMS OFnIv5dA1P0kmsVTWWjEcqztgf+Ua1oB2GUuWZ9AZh7oiXJ4HaAgy12xc1Efvq0vYZo9 BPqG+6KzxpFuf1C+DnYO+2IdUHYi2X+xEm+5pY5sArksRQSxYjYFhem1H2HuBm1V2xlq JCog== 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=dYagON2SebkuMV5UKxgWb47nbtwjqtcrf1ddp5zhyFQ=; b=XOkGRarRJisuu5lrZNgQD9iulNbmRzClyXZ4fYvsdezgxJpC2hC++miRU69rSp5A9B 96nmQYnOofv2QxJN2uqnsxFZ8Z3RLhq8rEbAvg1thwSc00/slrr1F77/JudO6MakIPD0 dbOYrmqCe61gdS0qhp0bVzzLPt9U4/vAZyK3pdL0pTEvmFOsfGpO6O9JmmDDduHaSzMS o0sluMHdW9hl3Vt3N+fc6ZgJUqOJHPtrI9BHvEemRtwshju9XoCqrFXDFYc3ueR2jvca FxsAaKqYSWtgK4sDtStjnpSPKu2fMbxkvN6EJWlWxdft65sW5UR/012XlPf5/NsNmmAP MDzw== X-Gm-Message-State: AGi0Puad08ePM1RnDIFKPUH42KjsnuPa2vHQ5KOL92XUXjlt8g5Cu1kh K676qsCAHFH0NSVjeVGahMw= X-Google-Smtp-Source: APiQypKkcUXGPeCXg+dT/zPz3gg9qZaUVvCYooE6v3sI1yPDG3u+OxDqRaL+EVmcZzNMRlNG5HFS4g== X-Received: by 2002:a17:902:8b8a:: with SMTP id ay10mr5233941plb.172.1587156910174; Fri, 17 Apr 2020 13:55:10 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id e196sm10549451pfh.43.2020.04.17.13.55.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 13:55:09 -0700 (PDT) To: Tim Wicinski , Russ Housley Cc: rfced-future@iab.org, Mark Nottingham References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> From: Brian E Carpenter Message-ID: Date: Sat, 18 Apr 2020 08:55:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 17 Apr 2020 20:55:32 -0000 On 18-Apr-20 07:02, Tim Wicinski wrote: >=20 >=20 > On Fri, Apr 17, 2020 at 11:41 AM Russ Housley > wrote: >=20 >=20 >=20 > There ought to be a straightforward mechanism for the RFC Editor to= say that a document is not written well enough tor admittance to the que= ue.=C2=A0 The should shame the approving stream.=C2=A0 Today, the RFC Edi= tor is reluctant to send documents back.=C2=A0 I would like to see the st= ream manager hold the authors to a higher bar.=C2=A0 Too often I hear, "T= hat's okay, the RFC Editor will fix it." >=20 >=20 > I've always felt that one of the jobs I have as a working group chair/s= hepherd is to hand over the best possible document to the IESG and the RF= C Editor.=C2=A0 The better the document is, the better the IESG understan= ds it, and the easier it is for the RFC Editor to get it published. I wou= ld welcome feedback from the RFC editor on our WG documents, as I think i= t can be done in a way to improve the quality of our product. >=20 > These type of discussions on document quality, etc should be part of th= e new working chair re-education=C2=A0orientation process.=C2=A0 Nevertheless, there's a gap today. We have (and this is a good thing) man= y authors, WG chairs and document shepherds who are not of English mother= tongue. Often they simply *cannot* detect errors in the English, and cer= tainly cannot fix them. Are we willing to pay to fix this earlier in the = process, rather than paying the RFC Editor to fix it after document appro= val? I'm trying to imagine drafting an RFC in French, a language that I can re= ad and speak quite well, if the IETF's publication language was French. T= he result would be horrible, and my writing speed would be at least 10 ti= mes slower. Brian From nobody Fri Apr 17 13:59:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6873A0101 for ; Fri, 17 Apr 2020 13:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZutKv4t1Pvri for ; Fri, 17 Apr 2020 13:59:22 -0700 (PDT) Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6123A00D9 for ; Fri, 17 Apr 2020 13:59:22 -0700 (PDT) Received: by mail-oo1-xc32.google.com with SMTP id r1so761621oog.7 for ; Fri, 17 Apr 2020 13:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yf64FztBbFTboBqplQIULLdoLEP5nJmsT+Qtj+iydho=; b=EEfSzD1dlYFanMqYS9QHWMeBba3W94aKFJqUp75sZCUCSihRpaBjuTMiTUfLbX1klT /udPGJJlPIyXTtoSTPeIxo8nsK0s0+hBiLeCV9/o8SneX0hdNlF3r2looRskIXINNw/D 2nIhi4YLz5RKqwaEaR3trN6ichn928ppVeGW0H4gS6DgQ0o92xK838rRds+lx+Vqr9Qh 3jngR1mhJBakWV3l+sh/UiijRPGvFG2EQ0HDBY+8ByOlzS8QCnWnHuUK+MwHDumybwqL EyQXUCdbL+r7RXgYelO0W9erT6rZw1uedrbIlz4UZUXqMwDn1nq9UzcKjhrwPFlhL+i+ B6hQ== 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=Yf64FztBbFTboBqplQIULLdoLEP5nJmsT+Qtj+iydho=; b=qwdkFDgE3qXnLBA20PYkYUNyR79KcN9hbyebhzq2T9hlpPbNcOR0dAd/Fk+Yh0opmx uGqQkqTYwap1ccOBa8jHyfpa0Ua/B5h9GHzqNfZ0pxO/cBYd/2btztlz0uT3UUKyw33+ DkN+jzHVq/VQ8LogG/qXIeen0CZbcqZAeAWBuL47VeNPreLWLwQaMPVipVCICukii6jM ipXwr7b/B0s7OCW3j3DpogzflXsCjPPdm2kOOaTlVeGvRNTbiX+3TGbTR7teErffNA+/ ueZgyfxZsUTUe14dDvuBSBm+xJdwxdU4VvK+rq3sf1NYyX84v8gWGLvIuT4fSA1JU2oW iXhQ== X-Gm-Message-State: AGi0PubsYa5eUTw5rv67LDa7395cEPuiUic81WWD7BzEM3J8Tb7XHpTe xzZent8atlY9NJWRFfaeBvzTXEvxH0dAJ88jltY= X-Google-Smtp-Source: APiQypJVtGv6JVfHH0TwZesisg9dOs2mwOkwXvgeojx/JGZHCUzZLX49UHENyrOfqAVpbESu7qmkZkQQYx46jH5E30A= X-Received: by 2002:a4a:d4d2:: with SMTP id r18mr4150828oos.14.1587157161233; Fri, 17 Apr 2020 13:59:21 -0700 (PDT) MIME-Version: 1.0 References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> In-Reply-To: From: Tim Wicinski Date: Fri, 17 Apr 2020 16:59:10 -0400 Message-ID: To: Brian E Carpenter Cc: Russ Housley , rfced-future@iab.org, Mark Nottingham Content-Type: multipart/alternative; boundary="000000000000cc51dc05a382d237" Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 17 Apr 2020 20:59:24 -0000 --000000000000cc51dc05a382d237 Content-Type: text/plain; charset="UTF-8" I agree on the language barriers, but those can be worked with by pairing folks up. perhaps we can have a method to engage the RFC editor earlier in the process much we do for area reviews and IANA ? Some guidance on perhaps organization, etc could save a lot of pain down the road. On Fri, Apr 17, 2020 at 4:55 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 18-Apr-20 07:02, Tim Wicinski wrote: > > > > > > On Fri, Apr 17, 2020 at 11:41 AM Russ Housley > wrote: > > > > > > > > There ought to be a straightforward mechanism for the RFC Editor to > say that a document is not written well enough tor admittance to the > queue. The should shame the approving stream. Today, the RFC Editor is > reluctant to send documents back. I would like to see the stream manager > hold the authors to a higher bar. Too often I hear, "That's okay, the RFC > Editor will fix it." > > > > > > I've always felt that one of the jobs I have as a working group > chair/shepherd is to hand over the best possible document to the IESG and > the RFC Editor. The better the document is, the better the IESG > understands it, and the easier it is for the RFC Editor to get it > published. I would welcome feedback from the RFC editor on our WG > documents, as I think it can be done in a way to improve the quality of our > product. > > > > These type of discussions on document quality, etc should be part of the > new working chair re-education orientation process. > > Nevertheless, there's a gap today. We have (and this is a good thing) many > authors, WG chairs and document shepherds who are not of English mother > tongue. Often they simply *cannot* detect errors in the English, and > certainly cannot fix them. Are we willing to pay to fix this earlier in the > process, rather than paying the RFC Editor to fix it after document > approval? > > I'm trying to imagine drafting an RFC in French, a language that I can > read and speak quite well, if the IETF's publication language was French. > The result would be horrible, and my writing speed would be at least 10 > times slower. > > Brian > > --000000000000cc51dc05a382d237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree on the language barriers, but those can be worked with by pairin= g folks up.

p= erhaps we can have a method to engage the RFC editor earlier in the process= much we do=C2=A0
for area reviews and IANA ?=C2=A0 Some guidance on perhaps organiz= ation, etc could save a
lot of pain down the road.=C2=A0=C2=A0


On Fri, Apr 17, 2020= at 4:55 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 18-Apr-20 07:02, Tim Wicinski wrote: >
>
> On Fri, Apr 17, 2020 at 11:41 AM Russ Housley <housley@vigilsec.com <mailto:<= a href=3D"mailto:housley@vigilsec.com" target=3D"_blank">housley@vigilsec.c= om>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0There ought to be a straightforward mechanism for t= he RFC Editor to say that a document is not written well enough tor admitta= nce to the queue.=C2=A0 The should shame the approving stream.=C2=A0 Today,= the RFC Editor is reluctant to send documents back.=C2=A0 I would like to = see the stream manager hold the authors to a higher bar.=C2=A0 Too often I = hear, "That's okay, the RFC Editor will fix it."
>
>
> I've always felt that one of the jobs I have as a working group ch= air/shepherd is to hand over the best possible document to the IESG and the= RFC Editor.=C2=A0 The better the document is, the better the IESG understa= nds it, and the easier it is for the RFC Editor to get it published. I woul= d welcome feedback from the RFC editor on our WG documents, as I think it c= an be done in a way to improve the quality of our product.
>
> These type of discussions on document quality, etc should be part of t= he new working chair re-education=C2=A0orientation process.=C2=A0

Nevertheless, there's a gap today. We have (and this is a good thing) m= any authors, WG chairs and document shepherds who are not of English mother= tongue. Often they simply *cannot* detect errors in the English, and certa= inly cannot fix them. Are we willing to pay to fix this earlier in the proc= ess, rather than paying the RFC Editor to fix it after document approval?
I'm trying to imagine drafting an RFC in French, a language that I can = read and speak quite well, if the IETF's publication language was Frenc= h. The result would be horrible, and my writing speed would be at least 10 = times slower.

=C2=A0 =C2=A0 Brian

--000000000000cc51dc05a382d237-- From nobody Fri Apr 17 14:22:30 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8BA3A082B for ; Fri, 17 Apr 2020 14:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Bq3LmWP7vq3c for ; Fri, 17 Apr 2020 14:22:20 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376AB3A0828 for ; Fri, 17 Apr 2020 14:22:15 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id b10so3242254qtt.9 for ; Fri, 17 Apr 2020 14:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=EBXQ+COUVOHubL695WuMNlq6NDeaYX/osjQboXn/5ok=; b=Imle/lNEGwGbwqjv+QDA6Dz4/+Qs4DShXYuZJZnDjrmqscJG3T5xS9TuYpdWcMinW4 WxbKkg9UksZflugbAmGPJRwb8XlzDDRFpTWYtmmztc22Nblohvp00bXYC8QToqMwwuJ3 YKCzuOa0exOXup/ccD00cwSZ3ngcmrtFtLvINWkmG1sD9myHJ45CuJGfLlIJjLXKELIA rXQISQnS/YwWeXV8em8hCW6z4CBNR86tvOHqYVmEfcLx5Tjk5sq+GtQKlRsU/yWviQgz nnKIq9fedtgqU/unT50FNb3iRii1ngJgAguFBtaaDmKjqyRpInLzEpUL9tSWF3IDWXSG g2Kw== 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=EBXQ+COUVOHubL695WuMNlq6NDeaYX/osjQboXn/5ok=; b=dwlomuryosdoyGfDfcdX2be5XoRUk/+GZoAvQKIkmXDkJrCXF6K2BhYkmWutDZ/mdG ajMGNQJP4SSciuD6ID5LZU/zXBExF9xt+Taks8CLOIil5+daXOUY7cyuI4qjGOcrVARf txljbyw5MPk3BSOiW8YfCbQ5i2TEE8wEhrmaDh6O5660GymrN0pkoQUpEhTzj2pcQkYw r0XypfPRctOR/2P/fUW8ZE1KM+sl7zxbEqapqSUIl9IDlSpo+46/8JGCwDvdf5NTQoFF eCY3P1SEcg8eNwOKZtPeOo8vzK8jX2fK/2WzedukaykHAFODeEhlQosvtqm1FLHtTI/4 J35g== X-Gm-Message-State: AGi0PubturzrQy2uADRDfNZpkX4Rp78um54xp84KCWfKqbPya5r70D9a lyi4PXS5VUmG2W10Luw9lPhXgAr+U9WRxg== X-Google-Smtp-Source: APiQypKc1VW1Q81YjQBuVwNLMHBOSKy1j7dW7L2mjV+gB958/PFKwOfDwHOOVJX++/DQdokFwh85Aw== X-Received: by 2002:ac8:1bb8:: with SMTP id z53mr5285079qtj.132.1587158534614; Fri, 17 Apr 2020 14:22:14 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id c41sm15128641qta.96.2020.04.17.14.22.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Apr 2020 14:22:14 -0700 (PDT) To: rfced-future@iab.org References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> From: Michael StJohns Message-ID: <8cc4914e-4f41-880e-e066-76624be7eff2@nthpermutation.com> Date: Fri, 17 Apr 2020 17:22:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------09C3BA3944CDE4231D8F1A23" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 17 Apr 2020 21:22:29 -0000 This is a multi-part message in MIME format. --------------09C3BA3944CDE4231D8F1A23 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/17/2020 4:59 PM, Tim Wicinski wrote: > I agree on the language barriers, but those can be worked with by > pairing folks up. > > perhaps we can have a method to engage the RFC editor earlier in the > process much we do > for area reviews and IANA ?  Some guidance on perhaps organization, > etc could save a > lot of pain down the road. > It may be worthwhile to have John L (as Temp RFC Program guy) chime in with sort of a summary of what things get fixed by the RPC/RFC Editor/ISE and in which proportions.  Maybe there's a simple fix? Generally, I don't see the editing team getting into the process earlier than they already are unless there's a specific cost savings to the process for doing so.  (And yes, I'm ignoring the author/doc editor time here).  Maybe we get them to do an adjunct to the "how to write an RFC" tutorials entitled "How not to get your RFC rejected by the Editors"? Mike > > On Fri, Apr 17, 2020 at 4:55 PM Brian E Carpenter > > wrote: > > On 18-Apr-20 07:02, Tim Wicinski wrote: > > > > > > On Fri, Apr 17, 2020 at 11:41 AM Russ Housley > > >> wrote: > > > > > > > >     There ought to be a straightforward mechanism for the RFC > Editor to say that a document is not written well enough tor > admittance to the queue.  The should shame the approving stream.  > Today, the RFC Editor is reluctant to send documents back.  I > would like to see the stream manager hold the authors to a higher > bar.  Too often I hear, "That's okay, the RFC Editor will fix it." > > > > > > I've always felt that one of the jobs I have as a working group > chair/shepherd is to hand over the best possible document to the > IESG and the RFC Editor.  The better the document is, the better > the IESG understands it, and the easier it is for the RFC Editor > to get it published. I would welcome feedback from the RFC editor > on our WG documents, as I think it can be done in a way to improve > the quality of our product. > > > > These type of discussions on document quality, etc should be > part of the new working chair re-education orientation process. > > Nevertheless, there's a gap today. We have (and this is a good > thing) many authors, WG chairs and document shepherds who are not > of English mother tongue. Often they simply *cannot* detect errors > in the English, and certainly cannot fix them. Are we willing to > pay to fix this earlier in the process, rather than paying the RFC > Editor to fix it after document approval? > > I'm trying to imagine drafting an RFC in French, a language that I > can read and speak quite well, if the IETF's publication language > was French. The result would be horrible, and my writing speed > would be at least 10 times slower. > >     Brian > > --------------09C3BA3944CDE4231D8F1A23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/17/2020 4:59 PM, Tim Wicinski wrote:
I agree on the language barriers, but those can be worked with by pairing folks up.

perhaps we can have a method to engage the RFC editor earlier in the process much we do 
for area reviews and IANA ?  Some guidance on perhaps organization, etc could save a
lot of pain down the road.  

It may be worthwhile to have John L (as Temp RFC Program guy) chime in with sort of a summary of what things get fixed by the RPC/RFC Editor/ISE and in which proportions.  Maybe there's a simple fix?

Generally, I don't see the editing team getting into the process earlier than they already are unless there's a specific cost savings to the process for doing so.  (And yes, I'm ignoring the author/doc editor time here).  Maybe we get them to do an adjunct to the "how to write an RFC" tutorials entitled "How not to get your RFC rejected by the Editors"? 

Mike



On Fri, Apr 17, 2020 at 4:55 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 18-Apr-20 07:02, Tim Wicinski wrote:
>
>
> On Fri, Apr 17, 2020 at 11:41 AM Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
>
>
>
>     There ought to be a straightforward mechanism for the RFC Editor to say that a document is not written well enough tor admittance to the queue.  The should shame the approving stream.  Today, the RFC Editor is reluctant to send documents back.  I would like to see the stream manager hold the authors to a higher bar.  Too often I hear, "That's okay, the RFC Editor will fix it."
>
>
> I've always felt that one of the jobs I have as a working group chair/shepherd is to hand over the best possible document to the IESG and the RFC Editor.  The better the document is, the better the IESG understands it, and the easier it is for the RFC Editor to get it published. I would welcome feedback from the RFC editor on our WG documents, as I think it can be done in a way to improve the quality of our product.
>
> These type of discussions on document quality, etc should be part of the new working chair re-education orientation process. 

Nevertheless, there's a gap today. We have (and this is a good thing) many authors, WG chairs and document shepherds who are not of English mother tongue. Often they simply *cannot* detect errors in the English, and certainly cannot fix them. Are we willing to pay to fix this earlier in the process, rather than paying the RFC Editor to fix it after document approval?

I'm trying to imagine drafting an RFC in French, a language that I can read and speak quite well, if the IETF's publication language was French. The result would be horrible, and my writing speed would be at least 10 times slower.

    Brian



--------------09C3BA3944CDE4231D8F1A23-- From nobody Fri Apr 17 14:30:34 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC603A0811 for ; Fri, 17 Apr 2020 14:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-iGJzcpRcHc for ; Fri, 17 Apr 2020 14:30:32 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1153A07E7 for ; Fri, 17 Apr 2020 14:30:30 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id 8so3339215oiy.6 for ; Fri, 17 Apr 2020 14:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D4KRj0/kOmF7ieAc0L0002piYHr675rXhm5uIl5gTfQ=; b=HNPxDb2rniCbXg40SI+jAuNMpBWHZY+YF/K73Rx7R9aJBeYjt+BlzVl+qmy8Ws8BFY /NshM/rTVGv1ZXEpojQT0mnOaaSio55yZDcbN0etwceQqOJLK2K+N8A6ebOq0uUoxPrz IXtiThd+b4vydZg+CPnI8xUH0dnj8BDEcweZzSEQ8iZr5TL3AnocMHo/72+h221LL7ss 5mp2dxk0XGhCp2/QUBsgQiMtdhN0tX0g/EOHh5RrheMrcsTUxtt5S0FVUml6kivKB2gH m1JpcZovU4Q2XKbDZAj0g97Ycz8qvXC/zWPk8yuA13wlndg1c8xQ16VKwlFReubcENpa OKtA== 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=D4KRj0/kOmF7ieAc0L0002piYHr675rXhm5uIl5gTfQ=; b=fm2dqKVW/1MnxmWU5ms5mmTc7NxqCHwyeoBPpkw3GSGqGC5st6OcS148bmJxbMgvrU /dLwBRlPusjqQ3phtHSzzuf5bp56MMbIKqsOFLpEq/rgX7ZFmjc6ppb8FRCyDPNgudQe +EmVpnn0JsJ1x6NJN/XhcWsH5pOpAzOKytRJKIRnakq4AG1GLBRNYloop8rD9+z5ymuX O5offFhMrV/b4Tg4c4QA0N1+2EOqReLjS4eNdw7SVXEkFlsZg//D8+IbS6f6DL70MEti MRllAUaBshIF4SANY+evle30pw+INm+2kPxi7VeMg4Ynp6Za/oJ1GAyxU5M70lfdS/10 ZhOw== X-Gm-Message-State: AGi0PubUM+YFYE+NT+lB2dUknNMUFSu3oUVNDxpLVIruD2027mfyM2sm xZGW+3f7x56vx/e3iEu9WNThkjxzHA2bpUVKi1rSYA== X-Google-Smtp-Source: APiQypKoUzxtiWsGveTbyHu6VXyb3pRAiEze0srgQrn6HUnU9alKZ9Na173JpUDNXMcvxPzh/+jagCvVaCgn2dSxzrw= X-Received: by 2002:aca:5f8a:: with SMTP id t132mr3736853oib.132.1587159029420; Fri, 17 Apr 2020 14:30:29 -0700 (PDT) MIME-Version: 1.0 References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> <8cc4914e-4f41-880e-e066-76624be7eff2@nthpermutation.com> In-Reply-To: <8cc4914e-4f41-880e-e066-76624be7eff2@nthpermutation.com> From: Tim Wicinski Date: Fri, 17 Apr 2020 17:30:18 -0400 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000026958b05a383426b" Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 17 Apr 2020 21:30:33 -0000 --00000000000026958b05a383426b Content-Type: text/plain; charset="UTF-8" On Fri, Apr 17, 2020 at 5:23 PM Michael StJohns wrote: > On 4/17/2020 4:59 PM, Tim Wicinski wrote: > > I agree on the language barriers, but those can be worked with by pairing > folks up. > > perhaps we can have a method to engage the RFC editor earlier in the > process much we do > for area reviews and IANA ? Some guidance on perhaps organization, etc > could save a > lot of pain down the road. > > It may be worthwhile to have John L (as Temp RFC Program guy) chime in > with sort of a summary of what things get fixed by the RPC/RFC Editor/ISE > and in which proportions. Maybe there's a simple fix? > > Generally, I don't see the editing team getting into the process earlier > than they already are unless there's a specific cost savings to the process > for doing so. (And yes, I'm ignoring the author/doc editor time here). > Maybe we get them to do an adjunct to the "how to write an RFC" tutorials > entitled "How not to get your RFC rejected by the Editors"? > > Mike > > > All valid points Michael and much more coherent than mine. >From checking, it seems I've shepherded over 2 dozen document (yikes!) and we have some editing work, but it's never felt excessive. Though now I would not mind a review to find out if I can do better. tim --00000000000026958b05a383426b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 17, 2020 at 5:23 PM Michael StJoh= ns <msj@nthpermutation.com= > wrote:
=20 =20 =20
On 4/17/2020 4:59 PM, Tim Wicinski wrote:
=20
I agree on the language barriers, but those can be worked with by pairing folks up.

perhaps we can have a method to engage the RFC editor earlier in the process much we do=C2=A0
for area reviews and IANA ?=C2=A0 Some guidance on perhaps organization, etc could save a
lot of pain down the road.=C2=A0=C2=A0

It may be worthwhile to have John L (as Temp RFC Program guy) chime in with sort of a summary of what things get fixed by the RPC/RFC Editor/ISE and in which proportions.=C2=A0 Maybe there's = a simple fix?

Generally, I don't see the editing team getting into the process earlier than they already are unless there's a specific cost savings to the process for doing so.=C2=A0 (And yes, I'm ignoring= the author/doc editor time here).=C2=A0 Maybe we get them to do an adjunc= t to the "how to write an RFC" tutorials entitled "How n= ot to get your RFC rejected by the Editors"?=C2=A0

Mike



All valid points Michael and much more c= oherent than mine.=C2=A0=C2=A0

From checking, it seems I've shepherded over 2 dozen = document (yikes!) and we have some editing work, but it's never felt ex= cessive.=C2=A0
Though now I would not mind a review to find out if I can do better.= =C2=A0
tim

<= div class=3D"gmail_default" style=3D"font-family:monospace">
--00000000000026958b05a383426b-- From nobody Fri Apr 17 16:23:47 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076D73A09AA for ; Fri, 17 Apr 2020 16:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=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_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] 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 XsnCNl1BU75N for ; Fri, 17 Apr 2020 16:23:36 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D003A09A9 for ; Fri, 17 Apr 2020 16:23:31 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id a22so1675579pjk.5 for ; Fri, 17 Apr 2020 16:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kjYoHnnPEEzm6O7LQHwpiKIhWxABLnQJnWXLDA7wPEQ=; b=LsqO3xr1rE0ZIVHjHFFBRTHwqt9MapSHeP/z/iP1bL6iKWULphZ2enJPt7UUFAC3+0 H7jKkuvRezQrF7WT42gHp3VoAAH0cYYyPVoO4hFfwt9B/9IAa7hDL5su78vjiaxYKEOG 1aOBhJYj3Ly8hujrk5m2wGY+TBAygvfbfWzzcqfk1vgrDiFYHTtvEcZyaCxHsv0LeIWO pVjBHk1KrTU6gUpabxBZwJP6VkD5tRFGMTY+nmJoaC+gLJcPUf6xl+Ywn+h9KGc6yEyy crZQF/KVQeUa6XaxVR8yqu1f14pTD0THIYe+e1MB5LCx7vLUiQ3pUQBeGKOpskrO9a0o 7OZw== 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=kjYoHnnPEEzm6O7LQHwpiKIhWxABLnQJnWXLDA7wPEQ=; b=KMsTRXAjm8OjY9RAr7XTHd3q3YlrTfGvQpLDJNX89X8l4LaxSBa9OAhFAHanEQ4l61 W0+7t1hwvS6FzJSXR+hz9Ktgpr4as6Gq9HShqvG81IE+A4+glx6kgidgF1B1Om+ayzUT 8MaBB/bwV9g1tv6Wn9RDuGlZ5noMYABahVR8qNxwqoDB4VEg6ZWJ/rsKSPGXPNPocfRq 8RJl6IqfskM/HSs5Xoa26ZHTmXx9UmrmbhmdEJTD02ElVimqogz7v+hwRXqG4AQKKXla 3IvADDj6TP4x+oZfCpanZDAJ8g0ampGxI14cbvus+/Z8itCzHGIuhARObcWUgOGN36qA su7w== X-Gm-Message-State: AGi0PuaZ12/9eT9DsD9oo87AGcWOcHQPu1p2/c0/A1/oaCzbPPx8MIat g3M45zTNrrMjYqFXR+iuW/Q= X-Google-Smtp-Source: APiQypKQ2RMDTDpTOln7TrToFBcIqC7Nixh9W8VEeOvsofRvOsnZqy15z7tu3n1oiYW6tSzrn9xcXQ== X-Received: by 2002:a17:902:b108:: with SMTP id q8mr6086355plr.214.1587165800289; Fri, 17 Apr 2020 16:23:20 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id d5sm20684663pfa.59.2020.04.17.16.23.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 16:23:19 -0700 (PDT) To: Tim Wicinski Cc: Russ Housley , rfced-future@iab.org, Mark Nottingham References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> From: Brian E Carpenter Message-ID: Date: Sat, 18 Apr 2020 11:23:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Rfced-future] Prevalence of editorial issues [Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 17 Apr 2020 23:23:46 -0000 I agree that it would be useful to have some estimates from the editors a= bout the prevalence of seriously bad English. I have just grepped the ~200 GenART Last Call reviews that I've made sinc= e 2007. A bit surprisingly, there are only about 15 where I logged seriou= s editorial concerns, above the level of nits. That's a random sample, si= nce the reviews are assigned by round-robin. Of course, the RFC Editor is more strict and follows the Chicago Manual o= f Style. Regards Brian On 18-Apr-20 08:59, Tim Wicinski wrote: > I agree on the language barriers, but those can be worked with by pairi= ng folks up. >=20 > perhaps we can have a method to engage the RFC editor earlier in the pr= ocess much we do=C2=A0 > for area reviews and IANA ?=C2=A0 Some guidance on perhaps organization= , etc could save a > lot of pain down the road.=C2=A0=C2=A0 >=20 >=20 > On Fri, Apr 17, 2020 at 4:55 PM Brian E Carpenter > wrote: >=20 > On 18-Apr-20 07:02, Tim Wicinski wrote: > > > > > > On Fri, Apr 17, 2020 at 11:41 AM Russ Housley >> wrote: > > > > > > > >=C2=A0 =C2=A0 =C2=A0There ought to be a straightforward mechanism = for the RFC Editor to say that a document is not written well enough tor = admittance to the queue.=C2=A0 The should shame the approving stream.=C2=A0= Today, the RFC Editor is reluctant to send documents back.=C2=A0 I would= like to see the stream manager hold the authors to a higher bar.=C2=A0 T= oo often I hear, "That's okay, the RFC Editor will fix it." > > > > > > I've always felt that one of the jobs I have as a working group c= hair/shepherd is to hand over the best possible document to the IESG and = the RFC Editor.=C2=A0 The better the document is, the better the IESG und= erstands it, and the easier it is for the RFC Editor to get it published.= I would welcome feedback from the RFC editor on our WG documents, as I t= hink it can be done in a way to improve the quality of our product. > > > > These type of discussions on document quality, etc should be part= of the new working chair re-education=C2=A0orientation process.=C2=A0 >=20 > Nevertheless, there's a gap today. We have (and this is a good thin= g) many authors, WG chairs and document shepherds who are not of English = mother tongue. Often they simply *cannot* detect errors in the English, a= nd certainly cannot fix them. Are we willing to pay to fix this earlier i= n the process, rather than paying the RFC Editor to fix it after document= approval? >=20 > I'm trying to imagine drafting an RFC in French, a language that I = can read and speak quite well, if the IETF's publication language was Fre= nch. The result would be horrible, and my writing speed would be at least= 10 times slower. >=20 > =C2=A0 =C2=A0 Brian >=20 From nobody Sat Apr 18 02:34:44 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7220D3A076E for ; Sat, 18 Apr 2020 02:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YND5Ng2tfWo3 for ; Sat, 18 Apr 2020 02:34:38 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1B83A076C for ; Sat, 18 Apr 2020 02:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=367; q=dns/txt; s=iport; t=1587202478; x=1588412078; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4j1jy7e0sB/mWQBVGJOyDZgz8xfVbrEtjB2jxROxUoU=; b=Aix2WRRNNgsx6bTUJLWBnuwP6rnKbxPJECNasZmloHi3XVa6zYuccAw4 BX3KydmjcM4ZPDRQ6xTY+akfpmJjoHHXzAUkSrSrSkb7g8U5vhvpoGQFw lZhYxQTg2EY6oo5vrQdHhyjQ7Ef8UgcUmtdKt0w0x20p5PmsVJKbgYlH/ s=; X-IPAS-Result: =?us-ascii?q?A0AkAQCMyJpe/xbLJq1mGwEBAQEBAQEFAQEBEQEBAwMBA?= =?us-ascii?q?QGBe4NqIBIqhB2JAogLiXKGDYtPCgEBAQwBAS8EAQGERAKCMzgTAgMBAQEDA?= =?us-ascii?q?gMBAQEBBQEBAQIBBQRthWKFcQEBAQECASNWBQsLGAICJgICITYGE4MmgkwDD?= =?us-ascii?q?iCuP3WBMohEDYIigQ4qjFOCAIE4HIIfLj6CHoIwgxIygi0EsSdJgk6CZ5A3h?= =?us-ascii?q?EUdgkUBjR6MW5tjjSmDPwIEBgUCFYFpIoFXMxoIGxVlAYI+PhIYDZIQjhI/A?= =?us-ascii?q?zACjy8BAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.72,398,1580774400"; d="scan'208";a="23113877" 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 Apr 2020 09:34:34 +0000 Received: from [10.61.239.22] ([10.61.239.22]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03I9YWMg017788 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Apr 2020 09:34:33 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Sat, 18 Apr 2020 11:34:32 +0200 Cc: Tim Wicinski , rfced-future@iab.org, Mark Nottingham , Russ Housley Content-Transfer-Encoding: quoted-printable Message-Id: <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.239.22, [10.61.239.22] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Prevalence of editorial issues [Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Apr 2020 09:34:42 -0000 > On 18 Apr 2020, at 01:23, Brian E Carpenter = wrote: >=20 > I agree that it would be useful to have some estimates from the = editors about the prevalence of seriously bad English. >=20 Before I ask Jay or John for these I would like to understand the answer = would impact this group=E2=80=99s decision making. Eliot From nobody Sat Apr 18 02:51:36 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2943A07F0 for ; Sat, 18 Apr 2020 02:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NgsI5SXJt7e for ; Sat, 18 Apr 2020 02:51:33 -0700 (PDT) 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 DC8C13A07ED for ; Sat, 18 Apr 2020 02:51:33 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id h69so2385644pgc.8 for ; Sat, 18 Apr 2020 02:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YygucebUBbhJXgBZ2qhWwnPXALldipUDMYVqb84qBXY=; b=kBkZrILdLWs+SeWwxA7Qh4jyd/KfRWp4ASNMmzaXRdCyPgYcA/KjZEdhrm6JWr3w4T ZDTb64PKy1LaQWCBtUMzEF8s/pWyc/JvZLCBJK2ttpauBN7Mcz7cZVNqF/UeauoqsTGA JrIvb3HA8xqs3KLNb02RwNINbDmqBHqneXCVtomvFmtC+PRDQsUkdt6NVKjFJHdOPGOO aNhMGqPRC0BvEj1dF/BCYhXx+qwWG9m+5k9SBI9g5LQwZLN+LR8aprSBRCZ9NU+X52nu CuLS/26JKN34YLS4ECV0wSptxEs54fSdc71lQbtkfM6fp8mucUo7kpJ4hqCJYnekgEUr 0vUw== 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=YygucebUBbhJXgBZ2qhWwnPXALldipUDMYVqb84qBXY=; b=YZdzrCoeOODDQv9eCWGjGaWDDuRoHCx7ssbSUMlcuLRFQg3C8bO0FOW77kNIWIlp0q WqAaEoLveE+m1PQ8ZC6YEmoUf3Dys9Hixom8tfFqqHSNy2X8ffy0DzfzQfcEZmezvGXZ rfKX28f+Y+YuhuvfnvRatW5ATkaex0DmcE3EhUNpXqR1kkx3IAtd5XI+eQckWFmiGPy/ HA5hhRocncjPgf2CIBox3jHZPYVZezHuK8BoOpexYtMMqiKrgEuI6FLNGAJ40FWGuRZU A/N79bIuuiIUzBpKX8hdN4MBO+piSB4Hstg+3WzGebseOXHHBAtoTAXk2/ru2Ehz4faa 3ahg== X-Gm-Message-State: AGi0PuajOmAQOBo+x/GZ2vdZ/cgWTmQdYEFOknPHlHTJU+d8ciCHREqU QgtgGGKzzfqUuO0Ta25g7FE= X-Google-Smtp-Source: APiQypJzCEQkH4fEMnJpAPo6xKZGZmjgPrK47MQ4//jig+dKmIn4pgrX3MmCOb173JFz6BU73tGtlQ== X-Received: by 2002:a62:5289:: with SMTP id g131mr7600085pfb.210.1587203493315; Sat, 18 Apr 2020 02:51:33 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id u15sm7769519pjm.47.2020.04.18.02.51.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Apr 2020 02:51:32 -0700 (PDT) To: Eliot Lear Cc: Tim Wicinski , rfced-future@iab.org, Mark Nottingham , Russ Housley References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> From: Brian E Carpenter Message-ID: Date: Sat, 18 Apr 2020 21:51:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Prevalence of editorial issues [Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Apr 2020 09:51:35 -0000 On 18-Apr-20 21:34, Eliot Lear wrote: >=20 >=20 >> On 18 Apr 2020, at 01:23, Brian E Carpenter wrote: >> >> I agree that it would be useful to have some estimates from the editor= s about the prevalence of seriously bad English. >> >=20 > Before I ask Jay or John for these I would like to understand the answe= r would impact this group=E2=80=99s decision making. I'm not sure that it would. I think it would be worth knowing in terms of= the IETF's own housekeeping, but that's not what this list is about, is = it? Brian From nobody Sat Apr 18 15:39:33 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A200C3A1341 for ; Sat, 18 Apr 2020 15:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTiP525T9OQe for ; Sat, 18 Apr 2020 15:39:30 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FD53A11F4 for ; Sat, 18 Apr 2020 15:39:29 -0700 (PDT) Received: (qmail 76773 invoked from network); 18 Apr 2020 22:39:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12be2.5e9b819f.k2004; bh=IKPLKhRgkzd4jtmTS+X7NPiTjWIOvkWBDNAiL+HWvHA=; b=WhYkLfcfpXG9YCiGeWYjTK6Ul+p01sOqgwKxrEmy1J+HH+hDe0sZEvkg5so1sJyisxDj3DMi8ruWDunWQGUjrhJC0UjSRUTtPAt57e2q4teQSZh1482i0qb7uhxT/xU5FMi7qMOpPQ2z7wyLWz1m+aeMU0yLImS1n3wEh3+1Jg4rx5cRUNwVq7+k3MRHWmC4A2+RE9dysUz6Q9YtHvrJs/mqYVJ1Fg3JVXZaHe/jFx9BsroE164hEpDO8WiOuD8j Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 18 Apr 2020 22:39:27 -0000 Received: by ary.qy (Postfix, from userid 501) id 30DEA17FDAFC; Sat, 18 Apr 2020 18:39:26 -0400 (EDT) Date: 18 Apr 2020 18:39:26 -0400 Message-Id: <20200418223927.30DEA17FDAFC@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: lear@cisco.com In-Reply-To: <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Prevalence of editorial issues [Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Apr 2020 22:39:32 -0000 In article <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> you write: > > >> On 18 Apr 2020, at 01:23, Brian E Carpenter wrote: >> >> I agree that it would be useful to have some estimates from the editors about the prevalence of seriously >bad English. > >Before I ask Jay or John for these I would like to understand the answer would impact this group’s decision making. At the moment I can tell you I have no idea. I can easily ask the RPC for an informal estimate if you want. R's, John From nobody Sat Apr 18 15:41:19 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F593A134A for ; Sat, 18 Apr 2020 15:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d_e7L_IEdwT for ; Sat, 18 Apr 2020 15:41:16 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CD53A1348 for ; Sat, 18 Apr 2020 15:41:16 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id b10so5372900qtt.9 for ; Sat, 18 Apr 2020 15:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=b/VYj5P5cPge7qjjLFc5o99fWOFOYNog/yGhjwghiu0=; b=kNl6YSLAZfTJyLD0R9FTfYWH1zVJy3nF8M+VEl3iAnovqu4HzeEVIqLNRdBwfsAyHb kAdHokClBKGqFYHwRY/QNojy2guVPIrPqdOACtHDIOxm9hPU4ssX5X0KHJAYtR+hhkau e/HmD1dUnskGJ97aure8hP3OjyQr7VpO06vhzPSYS/RiOqhZsibp1j8u8vJNssECN6wP fmS1xwbCR/2xp+Nj746Dlb1z+wQuocTNTA28FGPTgl+a8YwHim+b3DBOUUQUldCGO0nH BRs2q8RNGT7viTL3Kvo3Dyw2IuQA2urx1CLCCzfpn98YS4rptV+MrwRvz8A7682zt7Sk CVYw== 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=b/VYj5P5cPge7qjjLFc5o99fWOFOYNog/yGhjwghiu0=; b=uKcnLGbO1dfNkLGEKW8qG3veBk9SLk5q8Wcq4Jdgz8d/FGX6f1fsKh1spsXcUUnORd uqUmESS2rvYfBAlqAWzCVhsAX5rbqGnXDay328P8oJSI08LD6zs4lGh37dukHUdoywKC 7je8nmV6+sdtaImk9+CEezTDlVRxksEHfp/l3W2/Je7yh4Z91+8F3ufDxyVLiBn8nKap hYOB5CAledwHdiw4AmSky5kw+sJyK11Os5hlGbDzT9sUpkNTCe+0v5CitTRL0qlT8WVl 4bVZXNBXynhW5OjGFoYooLtPjS8RPP9aXQAAmHh2nEAcjSrlqCCKQO2t8KN+xg+f6GLy U8XA== X-Gm-Message-State: AGi0PuaSD5acfX/3G4ASmwmN6cqgIMoBf6klcdat60Z/l/z59DstaCFJ TXhrG2A0gNZsb+h/Qzkjbvv2s/tGrGJjKA== X-Google-Smtp-Source: APiQypKAofHICnw2PcB0XOt22E33YEI5185oXH2lAV1J+jpOawu4NBbdLxeefp5BdbYECQrXYDyX6A== X-Received: by 2002:ac8:690e:: with SMTP id e14mr9485748qtr.391.1587249675025; Sat, 18 Apr 2020 15:41:15 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id u35sm7824863qtd.88.2020.04.18.15.41.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Apr 2020 15:41:14 -0700 (PDT) To: rfced-future@iab.org References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> From: Michael StJohns Message-ID: <5c00e7df-5ff9-c340-78eb-a8a3ef0d833a@nthpermutation.com> Date: Sat, 18 Apr 2020 18:41:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@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] Prevalence of editorial issues [Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 Apr 2020 22:41:18 -0000 On 4/18/2020 5:34 AM, Eliot Lear wrote: > >> On 18 Apr 2020, at 01:23, Brian E Carpenter wrote: >> >> I agree that it would be useful to have some estimates from the editors about the prevalence of seriously bad English. >> > Before I ask Jay or John for these I would like to understand the answer would impact this group’s decision making. > > Eliot > Hi Eliot - I'm sure you didn't mean to imply that we had to have your approval to ask Jay or John for information as the language above seems to indicate?  My understanding of your role is that of moderator, not mediator or have I got that wrong? In any event,  while it may seem off topic, knowing what types of things are taking up the RPC's time in the documents could help to scope the general remit for the RSE.  So far I've heard anecdotally that the RPC has been reluctant to push back on authors for basic editorial issues and authors and WG chairs have in some cases said "let the RFC editors fix it".   I don't know how prevalent that is, getting the information about types of problems and interactions with the WGs might give us a better handle on whether to scope the job as "well defined, do what your told" or "RFC editor has discretion on what it accepts and has the right to hold the IETF inbound documents to a higher standard" or some range between. It also may mean that we need to add some explicit add-on support for NN English to Standard English editing  in the RFC process which may fragment the RSE's job slightly.  It may also be the case that we can ask for community support from various language communities to enable something like that. I don't think he information pull is an immediate need, but not all of us are completely familiar with how the current RFC tasks are broken up and what the current contracts consider in and out of scope.  I expect other questions of the form "Please explain x" will need to be answered by the RPC or John during this process. Later, Mike From nobody Sat Apr 18 17:13:33 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3FE3A14B2 for ; Sat, 18 Apr 2020 17:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH-IrkNzYDTz for ; Sat, 18 Apr 2020 17:13:30 -0700 (PDT) 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 665293A14B1 for ; Sat, 18 Apr 2020 17:13:30 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id a23so2530294plm.1 for ; Sat, 18 Apr 2020 17:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=34rWxsjAFI743MpNBEVvBzxJcbgdcmXEI/QMHr9gy5M=; b=a+ryTJG0/se6yGHfG76s/wCFcW6HgTLwbEuOLVlY1sDJw56wWChP8E4Cy+T3GU0eZi nfc9jdxhMpxck/fO8t6t3gx5Lw5waFASpxBUfxEJ841lL+Mi0OJ8BWLTgUyeE7DyC+dz 0/gTYt4/FjRg6O34wpUuAJcd3KCThpXRivvWr2js0RMqHMSc90E7uvgc8izORP2EG8GC LAOyeHeNZLSuiCH3a8zPldBJQvQG/C1J1YsdQwpC/Esy4/BO6HeTt/boWdyFuotVSiVz ywVpmUzlKK2p873uX/5cDCa2y3+asLpoF6pLWp3cZIFs7EZ/b3eFtx5hchmHaecfc6UH R89A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding:content-language; bh=34rWxsjAFI743MpNBEVvBzxJcbgdcmXEI/QMHr9gy5M=; b=fGvoRndfauSGAZLSzA7xwm3n+z8Oe9vYDaSBe+MHvEbqSocqSaWIOPecwT0Wd1a/Vm CnEmPDg3oFZe5tibB1mksxj2N1oJ0abis+/+6MdQ00HFmCYUleMRyFIeFn6mDdLC8Lob j1vzo+th7rkhGgQIUOqhXV4gtCBCtgNZLDlKf7tzFdYdNcwkj7NeBwG/gvA4+uT4n/ID UMRM4ouefAig0iaEnJ1brsFsLLYCDcYztDtn2+nv2p7DrfUeAthfZc+nKUmmHJrQPpsy 4hrTKuicphe+3eacsfvsac7vEwtvQkKE/D5DWLj5q99Dn8AqTDgUPwexbd66zoVxmP44 JaIQ== X-Gm-Message-State: AGi0PuaRwdaqPJpoCpkntsqxmfVxkh85MEWYX3HxtJiE4QoY4ox5iZcv vRsBd/0w3ORi5NKLmLJdEQPN0BkWWwBsaIs= X-Google-Smtp-Source: APiQypJpaZ5R0AWSSER0x34EUrOgZNZueiMjnkDo73ZV4qn36BONK47gOHNLmC4dC8xtox0NL83ITA== X-Received: by 2002:a17:902:7586:: with SMTP id j6mr3720487pll.76.1587255208917; Sat, 18 Apr 2020 17:13:28 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id s4sm8663426pfm.200.2020.04.18.17.13.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Apr 2020 17:13:28 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org Organization: http://SoftwareAndServices.NET Message-ID: <059f9b0b-082c-e279-8c28-856c6a537996@gmail.com> Date: Sat, 18 Apr 2020 18:13:27 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Rfced-future] Do the editors themselves have an issue list? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 00:13:32 -0000 Do the people that do the editing have a list of issues, problems, or suggested fixes? . It would be nice to know if there is something that, so far, has not been mentioned. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Sat Apr 18 19:33:40 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA463A16AB for ; Sat, 18 Apr 2020 19:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc6oDVgO-CD4 for ; Sat, 18 Apr 2020 19:33:37 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEC83A16A7 for ; Sat, 18 Apr 2020 19:33:36 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id i22so2255777uak.6 for ; Sat, 18 Apr 2020 19:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5vHKokG+mdWjiPYPD0HQK+/sSjG+nQj8/hriBq9mTwc=; b=V+XIuC0sWccm01DMCu28fBIj45+2oa0WrqJl72hJIGoJETh8c6Nh1PcZ9ZamJQVeTY IvKFHv3M4RO3jhlusTOFtZB+ywJACTwfobVwWCoobABOv8TlO8XqVleU+49szRiTSD8V sDuhOz8WpZkefGKcEXks0bNPQdYAyWGuZXltYFgc/stzDn3z2eSApK2hqCUkBstveis9 QAIbUcWPdPF36SzAdr6/MCAPp/Hm/sgk2LNil5mcwlgfFBGGHE1RWdxJu0KZY9S+Bj5b yGMLjeuWeqAndN4uoUCJftxKdQqd2xook/GGXyLloBkv0VwmFYGL0hj7xf5hVl+gtdYD S2yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5vHKokG+mdWjiPYPD0HQK+/sSjG+nQj8/hriBq9mTwc=; b=oCH6JnasfRq1l2YwZpNePAtHYfzdoEcxCm0nzW2Xb8QnOyNCZMmtBYUzQnbBeqrPZP 22+ip4/b9mMh3WB7dKu2Yg5HSE2Us5hhujVOvoLRt9DesIr8n5CP/MOl6MJEDSMO2i3S UT3u2cUojo3n7qSQPLkUfmWW7vy0JfrMOcGrNeNEwMSeu9lmhZrRqJago6729zhqROtg ST6iKXmSAz1Ym+MnEQJTFpj/2c71GEysk2SNE9P3nZoOGdTHNRxh5VHGiweesTRTWZt2 hnN+Pv+1FJ4BfWfJlLZDPRD0P5AvBeXjhbluXabY1XWIBXYsHKtdFJ1TYiFEOQD/gtYd LpYA== X-Gm-Message-State: AGi0PuYyeXMSR2lG8wNsYAEqDNAhxoUHgr2A0wW+tGqPlnwaGTdauRqQ 3i5oCEKxctTFZNNABBnowFO5XB3xLdYNJzz5TE19lD7TIW0= X-Google-Smtp-Source: APiQypIGV45rSZXpnEysHSKhnDXcnNw5NdemlgxXlX/WShO+7x6jEl8H+3iQMrSWcRl/hgwA/LDEMptqv7Dj8C+b85I= X-Received: by 2002:ab0:7392:: with SMTP id l18mr1955412uap.90.1587263615623; Sat, 18 Apr 2020 19:33:35 -0700 (PDT) MIME-Version: 1.0 From: Nevil Brownlee Date: Sun, 19 Apr 2020 14:33:24 +1200 Message-ID: To: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000f9657805a39b9b03" Archived-At: Subject: [Rfced-future] More points to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 02:33:39 -0000 --000000000000f9657805a39b9b03 Content-Type: text/plain; charset="UTF-8" Hi all: Here are a few concerns I have about the RFC Series and the RSE: 1. Should we reconsider the goals of the RFC series, i.e. (mostly) a historical record of consensi reached about protocols? I believe that the archival nature of teh RFCs is one of their most important features. However, there's always room for improvements or changes, so it is important that we discuss - and agree on - how such changes should be suggested, discussed, and (if consensus is reached) implemented. 2. RSE relationships: where does the RFC Editor fit into IETF wrt the IAB, RSOC and the RPC (RFC Publication Centre)? Several posts to this lists have already touched on this, it's certainly one of the most important topics for the rfced-futures program. 3. IETF streams are the source of RFCs to be published. We currently have four streams (IESG, IRTF, Independent and IAB), each stream is responsible for developing Internet Drafts, deciding when consensus on them is reached, and when they've reached a state which will not cause lots of avoidable work for the RPC. At each IETF meeting since 2011 there's been a meeting of the Stream Managers. Those meetings discussed whether each stream had any problems in its interactions with the RSE and RPC, and whether they had any suggestions for any changes in the way RFCs were published. Clearly the Stream Managers meetings are already the obvious setting for such discussions. The notion of producing 'overview' documents for various protocols (e.g. TCP and DNS) appears fairly often. I believe that such documents should be produced (and maintained) by the Managers of the relevant Stream -for IETF protocols that would be the IESG. Concerning non-native English writers, during the mid-2010s the RPC ran workshops for the authors of such Drafts. They were much appreciated, but the RPC Staff involved reported that they required a lot of one-to-one discussion, and took a _lot_ ot time. 4. From time to time the RSE publishes RFCs, e.g. 8153 "Digital Preservation Considerations for the RFC Series," and the set of xml2rfc v3 RFCs. These were published in the IAB Stream, however, would it make sense to consider the RFC Series as a new (fifth) Stream? Cheers, Nevil ----------------------------------- Nevil Brownlee, Taupo, NZ --000000000000f9657805a39b9b03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all:

Here are a few concerns I have about the RF= C Series and the RSE:

1. Should we reconsider the goals of the RFC s= eries,
=C2=A0 =C2=A0 =C2=A0i.e. (mostly) a historical record of consensi= reached about protocols?
=C2=A0 =C2=A0 =C2=A0I believe that the archiva= l nature of teh RFCs is one of their
=C2=A0 =C2=A0 =C2=A0most important = features.
=C2=A0 =C2=A0However, there's always room for improvements= or changes, so it is
=C2=A0 =C2=A0 =C2=A0important that we discuss - an= d agree on - how such changes should
=C2=A0 =C2=A0 =C2=A0be suggested, d= iscussed, and (if consensus is reached) implemented.

2. RSE relation= ships: where does the RFC Editor fit into IETF
=C2=A0 =C2=A0 =C2=A0wrt t= he IAB, RSOC and the RPC (RFC Publication Centre)?
=C2=A0 =C2=A0 =C2=A0S= everal posts to this lists have already touched on this,
=C2=A0 =C2=A0 = =C2=A0it's certainly one of the most important topics for the
=C2=A0= =C2=A0 =C2=A0rfced-futures program.

3. IETF streams are the source = of RFCs to be published.
=C2=A0 =C2=A0 =C2=A0We currently have four stre= ams (IESG, IRTF, Independent and IAB),
=C2=A0 =C2=A0 =C2=A0each stream i= s responsible for developing Internet Drafts, deciding
=C2=A0 =C2=A0 =C2= =A0when consensus on them is reached, and when they've reached a state<= br>=C2=A0 =C2=A0 =C2=A0which will not cause lots of avoidable work for the = RPC.
=C2=A0 =C2=A0At each IETF meeting since 2011 there's been a mee= ting of the
=C2=A0 =C2=A0 =C2=A0Stream Managers.=C2=A0 Those meetings di= scussed whether each stream
=C2=A0 =C2=A0 =C2=A0had any problems in its = interactions with the RSE and RPC,
=C2=A0 =C2=A0 =C2=A0and whether they = had any suggestions for any changes in the
=C2=A0 =C2=A0 =C2=A0way RFCs = were published.=C2=A0 Clearly the Stream Managers meetings
=C2=A0 =C2=A0= =C2=A0are already the obvious setting for such discussions.
=C2=A0 The = notion of producing 'overview' documents for various protocols
= =C2=A0 =C2=A0 (e.g. TCP and DNS) appears fairly often.=C2=A0 I believe that= such
=C2=A0 =C2=A0 documents should be produced (and maintained) by the= Managers
=C2=A0 =C2=A0 of the relevant Stream -for IETF protocols that = would be the IESG.
=C2=A0 Concerning non-native English writers, during = the mid-2010s
=C2=A0 =C2=A0 the RPC ran workshops for the authors of suc= h Drafts.=C2=A0 They were
=C2=A0 =C2=A0 much appreciated, but the RPC St= aff involved reported that they
=C2=A0 =C2=A0 required a lot of one-to-o= ne discussion, and took a _lot_ ot time.

4. From time to time the RS= E publishes RFCs, e.g. 8153 "Digital Preservation
=C2=A0 =C2=A0 =C2= =A0Considerations for the RFC Series," and the set of xml2rfc v3 RFCs.=
=C2=A0 =C2=A0 =C2=A0These were published in the IAB Stream, however, wo= uld it make sense
=C2=A0 =C2=A0 =C2=A0to consider the RFC Series as a ne= w (fifth) Stream?

Cheers, Nevil
-----------------------------------
Nevil= Brownlee, Taupo, NZ
--000000000000f9657805a39b9b03-- From nobody Sun Apr 19 02:16:00 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417E23A08F3 for ; Sun, 19 Apr 2020 02:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MAY_BE_FORGED=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 GuOj_CDqVnpx for ; Sun, 19 Apr 2020 02:15:56 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C943A08F4 for ; Sun, 19 Apr 2020 02:15:55 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 03J9Frpf012992 for ; Sun, 19 Apr 2020 10:15:53 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0875222137 for ; Sun, 19 Apr 2020 10:15:53 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id E745522136 for ; Sun, 19 Apr 2020 10:15:52 +0100 (BST) Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 03J9FqxK032272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 19 Apr 2020 10:15:52 +0100 Reply-To: From: "Adrian Farrel" To: References: In-Reply-To: Date: Sun, 19 Apr 2020 10:15:51 +0100 Organization: Old Dog Consulting Message-ID: <05a801d6162b$1f62ecf0$5e28c6d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05A9_01D61633.8128B480" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIrzks85n5gxDHYwvsveuRMcT5wNafUsg0Q Content-Language: en-gb X-Originating-IP: 81.174.202.163 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25364.006 X-TM-AS-Result: No--26.662-10.0-31-10 X-imss-scan-details: No--26.662-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25364.006 X-TMASE-Result: 10--26.661700-10.000000 X-TMASE-MatchedRID: Rp71wniPtoPxIbpQ8BhdbPVY7U3NX8Jgh4A8KRmrGe2qvcIF1TcLYHsm Ebb/mVvOaMuvj4ppOlU5RAH8bsa+95mvObnpEDjcUPktDdOX0ftTga7Q9sNX6SNGK7UC7ElMBUU cEdE+uFFL+nDUy5QSWu+PXTCjpVVrbD6kpO8sVRDgnTiQMgPq/vQgumef66zLg8vHe9ji82IgQQ l12QYRNfxOHs3gpw/e9aot7S1gcZBKz05ReTB3MfgAhuaFie7SUs+Do/NeuKx7ABphZE0C13HSr nofi8PHVpnST5jfQ9aT6vi2Zm9YD6nbp+rDGuF/8UIP9c6qlJs5iooXtStiHjuwTDpX8ii0xDm9 zIKPPUhm14cgS0Q7GwKZK6bT2O148SpLYZNPsRODZKoW138gYuDTYjejIZTwF2PoDU7mzkATK+6 4jmBO59AwT74/nSUrxxSvowV0AJzcpMpw0IGbdZCB65RjRY3s31asM/gsp2kYDu7Ahk0dDVxfz1 0OsXj5iZmfBZYgGr+/LUPnfvvbV2H39wOZ1o5GIf0TE1VduNsZ8RJ4fqmXhkdmDSBYfnJR2jgVm hKlDxgWtSCqtMvi9nX9QQJ3FAwHn0UoIZ374hfmuecNOZVsqvxeH3fk9hIOkgLgI79LRf7kakAM W1g/fuLzNWBegCW21WdIO+NJS/kEs/H1wMyspis3zPQeiEbeRRgndEtDQrKdOJJtrJCj7X/tiG1 xu6mei72oX57MoAzMHECgFqAvkb7rweoAIK8o X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] More points to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 09:15:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05A9_01D61633.8128B480 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Nevil, =20 I think that is helpful. =20 Just to clarify two points=E2=80=A6 =20 >3. IETF streams are the source of RFCs to be published. > We currently have four streams (IESG, IRTF, Independent and IAB), > each stream is responsible for developing Internet Drafts, = deciding > when consensus on them is reached, and when they've reached a = state > which will not cause lots of avoidable work for the RPC. > At each IETF meeting since 2011 there's been a meeting of the > Stream Managers. Those meetings discussed whether each stream > had any problems in its interactions with the RSE and RPC, > and whether they had any suggestions for any changes in the > way RFCs were published. Clearly the Stream Managers meetings > are already the obvious setting for such discussions. =20 I agree that communication between the stream managers is important for = identifying and resolving issues before they become critical, and are = helpful for setting direction. =20 These meetings were, I think, driven by the RSE and as far as I am aware = the last time the stream managers met was by telechat in February 2019. =20 Of course, the stream managers have continued to communicate about = various issues as necessary, there being no need to wait for a meeting = in order to talk. =20 > Concerning non-native English writers, during the mid-2010s > the RPC ran workshops for the authors of such Drafts. They were > much appreciated, but the RPC Staff involved reported that they > required a lot of one-to-one discussion, and took a _lot_ ot time. Some working groups attempted to address this by setting up = =E2=80=9Clanguage review teams=E2=80=9D to assist non-native speakers. = The MPLS WG is an example. This had mixed success. Other document shepherds, WG chairs, and ADs took responsibility to = perform or commission reviews focussing on readability and language use. And some ADs have taken it upon themselves to return documents to = working groups, pronouncing them =E2=80=9Cnot good enough, yet,=E2=80=9D = and remembering that the documents are the product of the working group, = not just the authors. =20 A ------=_NextPart_000_05A9_01D61633.8128B480 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks = Nevil,

 

I think = that is helpful.

 

Just to = clarify two points=E2=80=A6

 

>3. IETF streams are the source of RFCs to be = published.
>     We currently have four streams = (IESG, IRTF, Independent and IAB),
>     each = stream is responsible for developing Internet Drafts, = deciding
>     when consensus on them is reached, = and when they've reached a state
>     which will = not cause lots of avoidable work for the RPC.
>   At = each IETF meeting since 2011 there's been a meeting of the
>  =    Stream Managers.  Those meetings discussed whether = each stream
>     had any problems in its = interactions with the RSE and RPC,
>     and = whether they had any suggestions for any changes in the
>  =    way RFCs were published.  Clearly the Stream Managers = meetings
>     are already the obvious setting for = such discussions.

 

I agree that = communication between the stream managers is important for identifying = and resolving issues before they become critical, and are helpful for = setting direction.

 

These = meetings were, I think, driven by the RSE and as far as I am aware the = last time the stream managers met was by telechat in February = 2019.

 

Of course, the stream managers have continued to = communicate about various issues as necessary, there being no need to = wait for a meeting in order to talk.

 

> = Concerning non-native English writers, during the = mid-2010s
>    the RPC ran workshops for the authors of = such Drafts.  They were
>    much appreciated, but = the RPC Staff involved reported that they
>    required = a lot of one-to-one discussion, and took a _lot_ ot = time.

Some working groups = attempted to address this by setting up =E2=80=9Clanguage review = teams=E2=80=9D to assist non-native speakers. The MPLS WG is an example. = This had mixed success.

Other = document shepherds, WG chairs, and ADs took responsibility to perform or = commission reviews focussing on readability and language = use.

And some ADs have taken it upon = themselves to return documents to working groups, pronouncing them = =E2=80=9Cnot good enough, yet,=E2=80=9D and remembering that the = documents are the product of the working group, not just the = authors.

 

A

------=_NextPart_000_05A9_01D61633.8128B480-- From nobody Sun Apr 19 02:47:54 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670E83A0974 for ; Sun, 19 Apr 2020 02:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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, 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 I7PkQysB3e7D for ; Sun, 19 Apr 2020 02:47:50 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E9D3A07A0 for ; Sun, 19 Apr 2020 02:47:50 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 03J9lmrt019219; Sun, 19 Apr 2020 10:47:48 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E09DB22040; Sun, 19 Apr 2020 10:47:47 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id CBB082203D; Sun, 19 Apr 2020 10:47:47 +0100 (BST) Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 03J9ll8T011700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Apr 2020 10:47:47 +0100 Reply-To: From: "Adrian Farrel" To: "'Michael StJohns'" , References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> <8cc4914e-4f41-880e-e066-76624be7eff2@nthpermutation.com> In-Reply-To: <8cc4914e-4f41-880e-e066-76624be7eff2@nthpermutation.com> Date: Sun, 19 Apr 2020 10:47:46 +0100 Organization: Old Dog Consulting Message-ID: <05b901d6162f$94c21670$be464350$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05BA_01D61637.F6867E70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFwZMnJQb0tvaNGMOhRruNSdUrbqgI354TrArtHunoB83uWrQF0Y66RAbi4jecB0y9etajsV2wQ Content-Language: en-gb X-Originating-IP: 81.174.202.163 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25364.006 X-TM-AS-Result: No--16.994-10.0-31-10 X-imss-scan-details: No--16.994-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25364.006 X-TMASE-Result: 10--16.994200-10.000000 X-TMASE-MatchedRID: Ync95tbzDRnxIbpQ8BhdbPhavVZP5tTaJuJX9LfoIjivW5VplQp1rxTs wTCIjpWSQa/h2edydo5TMlllQTFW8chRrnTBJDGYRkQWWFH99Hso87U/OjAbQm933pK2DkkP/pE 4pKve7n8NZJ5D/7oOHbpGA2fNCPFo7ui7oT3V2HC5xbPXEl8dZn2K69afcnwq2glZ6NySUl9A0x oF2eaxiCTYEpZg/ApAbZzzMiFsLrdzfeCSt9MtiG1rAlJKwOBJmPfanlBBWuCZt08TfNy6OFDi9 MIkZm8s34zNQElke75+V3i1WWdqSSVZDx+o0Dr6eVvLRtud2Eeo/fxTzbTF8LC4oAwPxab1u4Bh kW8f8iLPCIU6ZABSS3RlvYzAbkhFLawou7sjG8O7B1QwzOcQD+DTYjejIZTwRQgyInUyrWKhKc8 m2YMAUj5DsQhGicUuCscCcCCBPmUOzP220JI38Zqvoi7RQmPSiFhr30/WaYwS39b8+3nDx7+oU5 nKiOEUUJFtPQDCCPOJH/iVsT1tl+BA+U0FMvWNtKV49RpAH3vfVqwz+CynaRgO7sCGTR0NXF/PX Q6xePmJmZ8FliAav78tQ+d++9tXYff3A5nWjkYh/RMTVV242xnxEnh+qZeGR2YNIFh+clHaOBWa EqUPGBa1IKq0y+L2df1BAncUDAefRSghnfviF+a55w05lWyqAcGk+q40InSsxvTCCnhvxr09Sxv /wt66FgAjka/bKsrxezVOZrckwHT3K3VineCfL4+sB3yBscnVWJXkRYrtO5soi2XrUn/JlR1cT9 YafQVKWdTfwsJjy9CpCFLDTHZUOwBXM346/+w9m+iPYOu8U6vojaNISDaZaMo8JgwateH6UmE0p 9TBzt3Ig0shdPAM X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 09:47:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05BA_01D61637.F6867E70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree on the language barriers, but those can be worked with by = pairing folks up. =20 perhaps we can have a method to engage the RFC editor earlier in the = process much we do=20 for area reviews and IANA ? Some guidance on perhaps organization, etc = could save a lot of pain down the road. It may be worthwhile to have John L (as Temp RFC Program guy) chime in = with sort of a summary of what things get fixed by the RPC/RFC = Editor/ISE and in which proportions. Maybe there's a simple fix? Generally, I don't see the editing team getting into the process earlier = than they already are unless there's a specific cost savings to the = process for doing so. (And yes, I'm ignoring the author/doc editor time = here). Maybe we get them to do an adjunct to the "how to write an RFC" = tutorials entitled "How not to get your RFC rejected by the Editors"? =20 Mike, Anecdotal, but=E2=80=A6 As ISE I find the drafts presented on the Independent Stream to be very = mixed. My reviewers address technical points and major issues of = clarity, but don=E2=80=99t focus on smaller issues of language usage. I = try to polish the documents myself (working with the authors) and = sometimes ask the authors to go away and find a friend who can help with = the issues of language. >From time to time one gets through the net. A recent document came back = from the RPC with more than 90 questions (recall that the RPC simply fix = small issues, so questions reflect something that needs author input for = resolution), and on this document the RPC had abandoned work before they = got to the bottom of the document. In my opinion that should not happen = and it was an ISE error. In fact, I would have been very happy for the RPC to bounce this = document as soon as it was obvious that it was going to be a problem. = But what measures should they use to make that judgement? I think it = should be something like the number of questions per page, perhaps = averaged over the first ten pages. More than two questions per page = seems excessive, to me. Best, Adrian (who is also rfc-ise@rfc-editor.org) =20 ------=_NextPart_000_05BA_01D61637.F6867E70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I agree on = the language barriers, but those can be worked with by pairing folks = up.

 

perhaps we can have a method to = engage the RFC editor earlier in the process much we = do 

for area reviews and IANA ?  = Some guidance on perhaps organization, etc could save = a

lot of pain down the = road.

It may be = worthwhile to have John L (as Temp RFC Program guy) chime in with sort = of a summary of what things get fixed by the RPC/RFC Editor/ISE and in = which proportions.  Maybe there's a simple = fix?

Generally, I don't see the editing team getting = into the process earlier than they already are unless there's a specific = cost savings to the process for doing so.  (And yes, I'm ignoring = the author/doc editor time here).  Maybe we get them to do an = adjunct to the "how to write an RFC" tutorials entitled = "How not to get your RFC rejected by the Editors"?  =

Mike,

Anecdotal, = but=E2=80=A6

As = ISE I find the drafts presented on the Independent Stream to be very = mixed. My reviewers address technical points and major issues of = clarity, but don=E2=80=99t focus on smaller issues of language usage. I = try to polish the documents myself (working with the authors) and = sometimes ask the authors to go away and find a friend who can help with = the issues of language.

From time to time one gets through the net. A = recent document came back from the RPC with more than 90 questions = (recall that the RPC simply fix small issues, so questions reflect = something that needs author input for resolution), and on this document = the RPC had abandoned work before they got to the bottom of the = document. In my opinion that should not happen and it was an ISE = error.

In fact, I = would have been very happy for the RPC to bounce this document as soon = as it was obvious that it was going to be a problem. But what measures = should they use to make that judgement? I think it should be something = like the number of questions per page, perhaps averaged over the first = ten pages. More than two questions per page seems excessive, to = me.

Best,
Adrian (who is also = rfc-ise@rfc-editor.org)

 

------=_NextPart_000_05BA_01D61637.F6867E70-- From nobody Sun Apr 19 03:24:00 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053F23A0A53 for ; Sun, 19 Apr 2020 03:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsrm2K5UGZ3j for ; Sun, 19 Apr 2020 03:23:57 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F0B3A0A52 for ; Sun, 19 Apr 2020 03:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2611; q=dns/txt; s=iport; t=1587291837; x=1588501437; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6EpXdLmlu/tk/fMwRmIGNlpz63DQqtnIEtruKWp3Bs8=; b=QF755g+88xK1EsTrXdwTNsJhfTL40/n9tBAm+zIJvYt6PrL09v/T9l/f dnhfbjKSfDFrfIgE6/Il4s4NC1sE1KUVGfp8sLPsWVizAYtGXkhedhQZu UHC0Cu/OgWD0As3rGyScVTRo8TMxMuRRvZN8p4SlMmk2zJbDOg+qJKZH6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzAADfJZxe/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4F4BYFtIBIqhB2JAogKiXKRXAoBAQEMAQEvBAEBhEQ?= =?us-ascii?q?CgjM4EwIDAQELAQEFAQEBAgEFBG2FYoVxAQEBAQIBI1YFCwsYAgImAgIhNgY?= =?us-ascii?q?TFIJHS4JMAw4grkd1gTKFT4JVDYIigQ4qjFOCAIE4HIIfLj6CHoIwgxIygi0?= =?us-ascii?q?EjiCjF0qCToJpkD2ERR2PbogDhGGbbI0tgz8CBAYFAhWBaSKBVzMaCBsVZQG?= =?us-ascii?q?CPj4SGA2RZBcVjhI/AzACj1IBAQ?= X-IronPort-AV: E=Sophos;i="5.72,402,1580774400"; d="scan'208";a="25456226" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Apr 2020 10:23:55 +0000 Received: from [10.61.239.22] ([10.61.239.22]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03JANrXL011251 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Apr 2020 10:23:54 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <5c00e7df-5ff9-c340-78eb-a8a3ef0d833a@nthpermutation.com> Date: Sun, 19 Apr 2020 12:23:52 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> <5c00e7df-5ff9-c340-78eb-a8a3ef0d833a@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.239.22, [10.61.239.22] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Prevalence of editorial issues [Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 10:23:59 -0000 Hi Mike, > On 19 Apr 2020, at 00:41, Michael StJohns = wrote: >=20 > On 4/18/2020 5:34 AM, Eliot Lear wrote: >>=20 >>> On 18 Apr 2020, at 01:23, Brian E Carpenter = wrote: >>>=20 >>> I agree that it would be useful to have some estimates from the = editors about the prevalence of seriously bad English. >>>=20 >> Before I ask Jay or John for these I would like to understand the = answer would impact this group=E2=80=99s decision making. >>=20 >> Eliot >>=20 >=20 > Hi Eliot - I'm sure you didn't mean to imply that we had to have your = approval to ask Jay or John for information as the language above seems = to indicate? My understanding of your role is that of moderator, not = mediator or have I got that wrong? I believe my role to be that similar to a WG chair. I would ask = questions on behalf of this group when I see that they further our = purposes. That doesn=E2=80=99t stop you or anyone else of asking = questions. However, see below. >=20 > In any event, while it may seem off topic, knowing what types of = things are taking up the RPC's time in the documents could help to scope = the general remit for the RSE. So far I've heard anecdotally that the = RPC has been reluctant to push back on authors for basic editorial = issues and authors and WG chairs have in some cases said "let the RFC = editors fix it". I don't know how prevalent that is, getting the = information about types of problems and interactions with the WGs might = give us a better handle on whether to scope the job as "well defined, do = what your told" or "RFC editor has discretion on what it accepts and has = the right to hold the IETF inbound documents to a higher standard" or = some range between. >=20 > It also may mean that we need to add some explicit add-on support for = NN English to Standard English editing in the RFC process which may = fragment the RSE's job slightly. It may also be the case that we can = ask for community support from various language communities to enable = something like that. >=20 In this case, would we want to say, no matter the answer to an = information request we would make, that someone (RPC/RSE/IAB/community) = should have the authority to set minimal editorial standards prior to = processing? That would presumably leave to the stream owners how they = choose to meet that standard. (We can fill in the role later) If nobody answers no to that question, perhaps we can move on. = Otherwise we may indeed need some data. Eliot From nobody Sun Apr 19 03:26:43 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827F83A0A5D for ; Sun, 19 Apr 2020 03:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8myxwxH9qU4 for ; Sun, 19 Apr 2020 03:26:40 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3A23A0A5B for ; Sun, 19 Apr 2020 03:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=494; q=dns/txt; s=iport; t=1587292000; x=1588501600; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DxrntJCZY4LaEs3Wc+0nF0DMQn0Fy3n75573StgC8ZA=; b=ExA6+/CXLLaWgwdKIiGNVS/512lm46vKyMxY2DSNJ290+t14JAN64igx edsLTlBXRZa4TRBU90qBpu5tv3atXztssUpbl+n6o8hUiUAQLwWR2nctK 8PPsKACzIfBr9DTIz1y0Yn3qu7ws/0N0gEz4LoS6/OoQMZ9IBq1+0SZG5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAADyJpxe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkFAQELAYNpIBIqjR+HZSWJco9hgXsKAQEBDAEBLwQBAYREAoI?= =?us-ascii?q?zNgcOAgMBAQsBAQUBAQECAQUEbYVihXEBAQEBAgE6PwULCxguITYGE4Mmgkw?= =?us-ascii?q?DDiCuTYInhU+CVQ2CIoE4AYxSggCBOAwQgh8uPoIegjCDRIItBLE3SoJOgmm?= =?us-ascii?q?QPYRFHYJFjSmMZJtsjS2DPwIEBgUCFYFZAy+BVzMaCBsVOyoBgj4+EhgNoCI?= =?us-ascii?q?/AzCPVAEB?= X-IronPort-AV: E=Sophos;i="5.72,402,1580774400"; d="scan'208";a="25456243" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Apr 2020 10:26:38 +0000 Received: from [10.61.239.22] ([10.61.239.22]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03JAQbYq017615 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Apr 2020 10:26:38 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <059f9b0b-082c-e279-8c28-856c6a537996@gmail.com> Date: Sun, 19 Apr 2020 12:26:36 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D8D4E53-6741-48D7-A13D-417B596A0EEB@cisco.com> References: <059f9b0b-082c-e279-8c28-856c6a537996@gmail.com> To: Doug Royer X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.239.22, [10.61.239.22] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Do the editors themselves have an issue list? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 10:26:41 -0000 Hi Doug > On 19 Apr 2020, at 02:13, Doug Royer wrote: >=20 >=20 > Do the people that do the editing have a list of issues, problems, or = suggested fixes? . It would be nice to know if there is something that, = so far, has not been mentioned. With respect to each RFC, when an author gets a document back in AUTH48, = one can see all the issues that the RPC has discovered, and one must = respond. Are there other issues you are thinking of? Eliot From nobody Sun Apr 19 07:52:05 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554DF3A0AFA for ; Sun, 19 Apr 2020 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iSWWeloVfb3 for ; Sun, 19 Apr 2020 07:52:02 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABE33A0AF7 for ; Sun, 19 Apr 2020 07:52:02 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id 145so1394578pfw.13 for ; Sun, 19 Apr 2020 07:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Rt1r4SPR1uAxl1bMq3vQo5QtdM6xSVeDW6YLVHgr4DU=; b=PMvTu9+VTvpeLxo1ary3LHdcQ9uucl+TPJ2Lj1pTA10tki8cCe4u4zFAMW0wvmAPYj qGNLBTLggK2Da++l8yij5ZGtA1OGnIpjS/wjvpN2sxkdm5wT1mSjDsuMVXoexTFQTlWz mWEjENv8dqW8O7o2IAAjXCXQYy2TIDf7EygpXrVW6UJ+X9qIJxADKIWIX9nl3n0/Iqvg O3VpFXUiS5JguIELsLweT5Pzay640RBfTT0uwvtybt4t27BZlm7A4v5Ph43sRMMM0IYk 09Um5T3JMKD+FAJMXuKWE9m6L7g2+MGWo1x/c2LbFdA+wVDz0gSxZH04PGqgtBzAFX0Y 88HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=Rt1r4SPR1uAxl1bMq3vQo5QtdM6xSVeDW6YLVHgr4DU=; b=eokf3R9+EGvXmJ9doG8H8/efo3CIbmId2mUB2dq9c1LLdX70snutYcU8wvbOTxr9bb 1emWLa4v71b6Qm6yyuI20RCkvLaVJJFKMxHdI5+9nuTwaUZWYUhD5yvEec6/2rrumgnE 4CUGawGvlP2UJewfz+mTHXsgYRXfxlnO9p9Sq3lHDvBi4YnN+ZBVCJq45+s0WXGPTEr0 Z1TcpeSlY3c6AkjlksxDCLv87mmWn6opE3oeJTY/OpuBWIFL3UPxRsaxCxzQXDb6U/Ex hNR2yJZG9pLIPGELhqP9hxU2n9DfBHMVBbJWo+yPssNkgwGg2FudjTPR76z3wlgYRj48 j5PA== X-Gm-Message-State: AGi0Pub7Gzpsi0NXuUFBCfVLp77Rpoi9G7wtOIYJr/nqtVZHhd1vH2Jg aqg8muXqEBxuZDGK6M3CDNJHATvv3xp4Rq4= X-Google-Smtp-Source: APiQypJ46ouHSMWpM8NcRCTJ+FzyxXpB1d9Ik5Lr+sZ0cVnFNyN3b4YAOe0K3eZyyn94aH/aIlvOYQ== X-Received: by 2002:a63:fb14:: with SMTP id o20mr8878617pgh.144.1587307920755; Sun, 19 Apr 2020 07:52:00 -0700 (PDT) Received: from [192.168.1.7] ([174.27.79.225]) by smtp.googlemail.com with ESMTPSA id y22sm24934569pfr.68.2020.04.19.07.51.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 07:52:00 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org References: <059f9b0b-082c-e279-8c28-856c6a537996@gmail.com> <1D8D4E53-6741-48D7-A13D-417B596A0EEB@cisco.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Sun, 19 Apr 2020 08:51:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <1D8D4E53-6741-48D7-A13D-417B596A0EEB@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Do the editors themselves have an issue list? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 14:52:03 -0000 On 4/19/20 4:26 AM, Eliot Lear wrote: > Hi Doug > >> On 19 Apr 2020, at 02:13, Doug Royer wrote: >> >> >> Do the people that do the editing have a list of issues, problems, or suggested fixes? . It would be nice to know if there is something that, so far, has not been mentioned. >> >> >> With respect to each RFC, when an author gets a document back in AUTH48, one can see all the issues that the RPC has discovered, and one must respond. Are there other issues you are thinking of? I am talking about the process. They must have ideas. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Sun Apr 19 18:12:12 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525683A0B46 for ; Sun, 19 Apr 2020 18:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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 5wYJAtMdd6tw for ; Sun, 19 Apr 2020 18:12:08 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320091.outbound.protection.outlook.com [40.107.132.91]) (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 6EA393A0B44 for ; Sun, 19 Apr 2020 18:12:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N2/FddJ8khDYElpPksRJTmUoDmndJYTG8CITaFVRnmZB/9nkFx62ENWiwnadW6m9viqusVGdJNBrPuS8ytpqOmixCyWHjL1dgYECMY7vcoJiaxukI6RuAZVtgbwrirPhhRF5M1BKQuxTx+xq4yRqoFY+kln1UXZ5cUykWkgehXIK0xVthQasaH+ux3SILR/wqXuquNGetRN6dfMUMdMi37Otyq47Yz6cS936791wHl5JpYA1EbsXknz1GMel4SO7nZi0QyMJVeSwyY3hDUw7lt94hgfrR397AYKCrtjJ9lfwsLnHrdg5E3zToID+ACAVX5/ZW2bYFvnXwPDg6wgtJQ== 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=vVpZYLHw1FXhJboPqLxD/1bVVnDkuUAnNdDcwipTn9A=; b=UAhuQz52EaxIN69ScZEuf19cKssH+p52F5Ogon2lI1XlNeSj7pTrOfCSnPw2XHl7UepKzYD+8Xvz/7YR4S1t/VuB6y2XYVaO/bjTMuwo5Lw3/piERSJT/rvjVb5YsGVyGjF+SOXdFNH93lqti3Y7yU1zp1SrzUs//l50kfGB7I1bmVe5w35i/6/Wi0HOOBP5SP+JYZq6QFKGlh9Qhy34gjiTCuzoqwJYEqVUQUbJ4eutRSXXfjkFIUtrPOKAlCWbPctxVgdM6ClJVkZItlzgVTFajF4UlZtBUFhK0LJ40PJW8DUE/jhWkb0JPH8c+KaHFbUZszdURJ2XT40Abwi11w== 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=vVpZYLHw1FXhJboPqLxD/1bVVnDkuUAnNdDcwipTn9A=; b=nQ0wgiBLoHoky6U/fM3ut3U3LQrUh3b+oESaW0DmFFS0wxemXyvLXCl9h1fBwPZr3bV40yPA6jEGmRz0ZyBPZuaC9I5qP/bqCEhMoY6mMEtLlLszL25wyCeow27AVahupZp1GC3p+iUyWmHTwbsWoHAsyrZPaeccjnavNji8AHQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from TY2PR01MB2780.jpnprd01.prod.outlook.com (20.177.98.11) by TY2PR01MB2137.jpnprd01.prod.outlook.com (52.133.184.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Mon, 20 Apr 2020 01:12:05 +0000 Received: from TY2PR01MB2780.jpnprd01.prod.outlook.com ([fe80::554:c050:5760:350]) by TY2PR01MB2780.jpnprd01.prod.outlook.com ([fe80::554:c050:5760:350%5]) with mapi id 15.20.2921.027; Mon, 20 Apr 2020 01:12:05 +0000 To: Nevil Brownlee , rfced-future@iab.org References: From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <47f2159a-8055-d563-1d2b-a439878c9755@it.aoyama.ac.jp> Date: Mon, 20 Apr 2020 10:12:04 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TY2PR04CA0005.apcprd04.prod.outlook.com (2603:1096:404:f6::17) To TY2PR01MB2780.jpnprd01.prod.outlook.com (2603:1096:404:72::11) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (220.108.163.24) by TY2PR04CA0005.apcprd04.prod.outlook.com (2603:1096:404:f6::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Mon, 20 Apr 2020 01:12:05 +0000 X-Originating-IP: [220.108.163.24] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 782b02b0-a431-4e06-cc57-08d7e4c7d711 X-MS-TrafficTypeDiagnostic: TY2PR01MB2137: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 03793408BA X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TY2PR01MB2780.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(136003)(376002)(346002)(396003)(366004)(39840400004)(2906002)(186003)(6486002)(16576012)(8676002)(316002)(52116002)(786003)(66556008)(53546011)(956004)(2616005)(508600001)(36916002)(31686004)(66476007)(8936002)(66946007)(81156014)(4744005)(31696002)(5660300002)(16526019)(86362001)(26005); DIR:OUT; SFP:1102; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rrP5c+u79t1SW3QayIemdXlX26Qoo0zdcFNKhPjL8NHudsSexyXOuM7UISPtiwQdSCY9eXs1YOLySuWwTtm/v7EzosPfSOQzcDP0OH8tz6D9UJiEEpLFGcXTr9kw1kmrh5m8QBVJMcr4iUZ+CDuDLCfs/HexMh62SJf8l6kvX6yn+kdAzCdIx4GSssAi64yJ5EF5J3ySERy4oh+PUtIRjYZdD7hCVA3wTrPSfp6YGSN9ohLtdWUQqRQTZfDb8Lpro8LxJN57+gO2ED9nEi9rFxZpPGb843nb1XDRwcuua+GvBhKWRKWVMaIDO3kG0gz6lunt2mDL1lzyp0RhBwhNbotSj+7j9KF5qBRN59qPl7g/EfEP37HIPZM0rpPY0YEw2eoF4qPK5Ocg7zUWiQpIpqvrzZ5JkuZ/MTmmzS2RH+UL6f0D6qgCLMlwjB6OpkxU X-MS-Exchange-AntiSpam-MessageData: 5FGmNAPDohO9ceSS12yygA5vg8vgh3EZDj1HgjQUEzBdU+BiX0FJmbHX86SEk8d+vWIoldDYLI8csVQ41+gRKUki5lzGS++jAsG4BW7JVK57QA6bHoG+8cuBSBLaxQ/F8bNe00Neez0Ga0MIaCCE6Q== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 782b02b0-a431-4e06-cc57-08d7e4c7d711 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2020 01:12:05.6795 (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: u75E83LYX8hE8O+btZKGvVGrpa6818IJBvxYdrY/5aGlHzrcCH24E6364tg7pjEHh16jh5oeGCZGl0Gjzjy+tw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2137 Archived-At: Subject: Re: [Rfced-future] More points to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 01:12:10 -0000 On 19/04/2020 11:33, Nevil Brownlee wrote: > Hi all: > > Here are a few concerns I have about the RFC Series and the RSE: > 2. RSE relationships: where does the RFC Editor fit into IETF > wrt the IAB, RSOC and the RPC (RFC Publication Centre)? > Several posts to this lists have already touched on this, > it's certainly one of the most important topics for the > rfced-futures program. The mention of the RSOC here let me come up with a question: For the discussions here, is the RSOC in scope for discussion/proposals in this project or not? And to what extent? Sorry if I overlooked something obvious. Regards, Martin. From nobody Sun Apr 19 18:17:15 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3423A0B6C for ; Sun, 19 Apr 2020 18:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=2GVVdvGg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kisgwSz/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBbuYo05dp9k for ; Sun, 19 Apr 2020 18:17:11 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3F33A0B6B for ; Sun, 19 Apr 2020 18:17:11 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7D7FB5C0049; Sun, 19 Apr 2020 21:17:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 19 Apr 2020 21:17:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=b m1nb6Ajm5nmiB7PMSLoIa/GyHOoxKoMYrkv5jlDxCQ=; b=2GVVdvGg6SudipkbS HXTQag+e0d2ZsfA7HbfI0xfS+voOcms7rZSG4lS87w1dpVvJOtKg/JNIm184Mpet ceG7yWp6WhjvvMsdoPBglx4cbag4KZ77WqqHZkUSqb3xTg3HMR/TNW9EMMf0386B PB84gVfyWnKPJpdPUqKH0TF/tzlZGxps2fqmrFwp+YoRlMV8doZDszgzkp7wy1D3 8F6UDoVIKyOlEcbSzOzkwQK8Nq6+WM5whzkZ76JXA0cCpaP9SyGDYKWC+2NydUT0 VdXk8VBsZ+uvE0W71WWfhuSmE/UA4hjs1DMzjVhWTuvu4wmiPmMi2kKJTDiibmOU 90Xrw== 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=bm1nb6Ajm5nmiB7PMSLoIa/GyHOoxKoMYrkv5jlDx CQ=; b=kisgwSz/PnJ1yQ8/IfNAS8pc8639CKj10nhUW8c9KqPca24sKlOTLd/7+ uoo+YvgFuGzPZ3mDuYxvvWoMqt7iusYdsnb0Eg4KspseFruAak0Nm8uJH4ovqjY5 o1SNwHL2zASVXxkbLVB8JW8lVCjdB1IFdvm7fJ4fICWvb5gEZ3eQ4ekK+V2WUIs/ T6k7FwNLyaK4jtQhXIvpKxgsO8QJb21o52JJhtnMfKha8xMycU3iQ9EeaN9h8t39 mzkgffd7Ef+3pgWkTtG2Sg9MXTOQoGVAQMRt0nWMm/CtexqPSQCvSMAvDYpMkPYF JKc2NgVrxtfll8bvTfCrNzX/HvfbA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedvgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hirggsrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedu necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnoh htsehmnhhothdrnhgvth X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id D03253064CA3; Sun, 19 Apr 2020 21:17:08 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <47f2159a-8055-d563-1d2b-a439878c9755@it.aoyama.ac.jp> Date: Mon, 20 Apr 2020 11:17:08 +1000 Cc: Nevil Brownlee , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <6F61B60B-72D2-43FB-86BF-10974F359F46@mnot.net> References: <47f2159a-8055-d563-1d2b-a439878c9755@it.aoyama.ac.jp> To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] More points to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 01:17:13 -0000 I'd hope it is. > On 20 Apr 2020, at 11:12 am, Martin J. D=C3=BCrst = wrote: >=20 > On 19/04/2020 11:33, Nevil Brownlee wrote: >> Hi all: >> Here are a few concerns I have about the RFC Series and the RSE: >=20 >> 2. RSE relationships: where does the RFC Editor fit into IETF >> wrt the IAB, RSOC and the RPC (RFC Publication Centre)? >> Several posts to this lists have already touched on this, >> it's certainly one of the most important topics for the >> rfced-futures program. >=20 > The mention of the RSOC here let me come up with a question: For the = discussions here, is the RSOC in scope for discussion/proposals in this = project or not? And to what extent? >=20 > Sorry if I overlooked something obvious. >=20 > Regards, Martin. >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Sun Apr 19 20:19:08 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5663A0DA1 for ; Sun, 19 Apr 2020 20:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=LC3ORsxB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=inxE6H1F Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUrDIowA90eE for ; Sun, 19 Apr 2020 20:19:04 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5A03A0D9F for ; Sun, 19 Apr 2020 20:19:04 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7386C48E; Sun, 19 Apr 2020 23:19:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 19 Apr 2020 23:19:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=H UhFwDLCKiHoA7r84I5i620TR72DS76AwLwJCUQqM0Y=; b=LC3ORsxBbhUJmA38Z OWvBpj/HPI9O5qFzJSXcZAw3WiyVni69QpqDSQiZtuBcPeqEpD87NQPVCfpcvxLS d6XZxc4PrO90TewccpqBmo8m41NoRu8LstJTyEsmWt8KXS1Wj4h2aHlQ+9hscz7G Sb4nAlsTXMJ7VKG1tgAgJMqq6s480/k+26sr27sBMaGYki7Qt5TergZZayhoWw5O DmwXBo08sMptXefkFa941eivD5FESyOnNSU3EUQjjQsIasjx62iB4KgWRe7LoRDv Ejyb8lvFIYopSseoJ6SxPWe9vZWO8GFugII7nn40p6x/MZwarP/fjoP0tLKxv4c9 G6pVg== 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=HUhFwDLCKiHoA7r84I5i620TR72DS76AwLwJCUQqM 0Y=; b=inxE6H1FfNdilD1aHFAZ5FABdiJYi2b55MhhqMhA3L2RMyJcwHbJPTmM6 s6mI10baXCyvkIzHOq+NrjRvEZhqNcx7OJcDnzmA3R38BhvsppDWqRohptBLKj3w VoloMXnZ9gDWggeZqfWdBAbARM4+GZ7ajucuz4Nv5bMeIw5YzNCx/H63f3w8Lf2a WZbO5+me0FEi/rBw4lFlAtqtlB+ZCTes8X17EI4WKrb2NTQlPc4JANZwUw2pCe1Z hlqii8p7nWnLGrdYBwe/alHW2xurskDvlmvmTqZQPklL6IIXLdaUwShwXyzxHsS8 AqGPoG2MrIrtoQsZnh6gudKP1HGhw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedvgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnh gvth X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id D6BFD30655BA; Sun, 19 Apr 2020 23:18:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <5059D78F-3C4D-47BE-9EB3-592B6A975C09@cisco.com> Date: Mon, 20 Apr 2020 13:18:57 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <5059D78F-3C4D-47BE-9EB3-592B6A975C09@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Apr 2020 03:19:07 -0000 Hi Eliot, Sorry for the delay, I had a busy weekend. On 17 Apr 2020, at 5:43 pm, Eliot Lear = wrote: >=20 > Hi Mark and thanks very much for your note. I have one clarifying = question: >=20 >>=20 >> * The methods that the RSE has available to the make decisions (of = various sorts) are ill-defined, to the point where it can be untenable = for both them and the community. To me, this is the heart of the matter. >=20 > Since this is an important issue for you, would you care to elaborate = a bit more about what sort of decisions the RSE makes, their impact, and = what you think good looks like at a high level? Sure.=20 RFC 8728 s 2.1.4. documents the responsibilities of the RSE, and calls = out the evolution of the RFC Series explicitly. One might imagine this = includes things like the format of RFCs, the editorial style used, = creating resources for editors to use, the archival nature of the = series, the RFC identifiers themselves, and so forth. There are a variety of decisions that could be made -- or not made -- = about these things. Because of the diverse nature of not only the IETF = community but the larger RFC-producing and consuming community, some are = bound to be contentious.=20 8728 vests these responsibilities in the RSE with the expectation that = they will 'engage with the Internet technical community in a process of = articulating and refining a vision for the series and its continuous = evolution.' Conspicuously missing is the word consensus, which would = imply the extensive guidance we give the IESG and WG chairs about = decision-making.=20 Appeal is also central to the IETF's concept of consensus. However, 8728 = does not contain that word; instead, it only says 'the RSE cooperates = closely with the community, and operates under oversight of the RSOC: = thus, ultimately, under oversight of the IAB.' More guidance is provided by RFC 8729, in the various Process Change = subsections. For example, s 4.4.3. regarding series-wide guidelines and = rules says '[w]hen additions or changes are needed to series-wide = definitions, the IAB will work with the RFC Editor and stream = stakeholders to get community input and review. The IAB will approve = changes by validating appropriate consideration of community = requirements.' This supports the view that the only practical check on the RSE is IAB = approval of specific actions; approval that is rarely withheld = (especially after recent events, I'd suspect). That, in turn, is = somewhat muddied by the ill-defined role of RSOC. RSOC is, according to 8729, 'responsible for ensuring that the RFC = Series is run in a transparent and accountable manner.' However, 8728 = does not enact how this is done; it only says that RSOC 'will approve = consensus policy and vision documents as developed by the RSE...', along = with 'decisions that affect the RSE individually.' It would be = interesting to hear whether the IAB thinks it has delegated its = 'validating appropriate consideration' powers to the RSOC, and what the = RSOC thinks about that (and I sit on both). I think our primary task is exploring whether this arrangement results = in what's best for the community and the Series. For example, let's imagine that our next RSE talks to parts of the = community and determines that the archival requirement was no longer = necessary, and so they should start updating in-place RFCs. Others in = the community would be very unhappy about this. The IAB could = 'validate[e] appropriate consideration of community requirements' and = determine that the RSE hadn't done so, but this could get heated; = 'appropriate consideration' is a value judgment, and the IAB's = questioning could be seen as interfering with the autonomy of the RSE. = In the end, no matter what decision was made, there would likely be = parts of the community who felt that they were not listened to, an RSE = with burnt fingers, and an IAB (or is it RSOC?) having to make a = decision without clear criteria. That example may not be realistic, because a good RSE would convene some = body to make that decision, and establish ground rules that look an = awful lot like the IETF's consensus guidance. Perhaps the lack of doing = so would be enough for the IAB to use as evidence that 'appropriate = consideration' did not take place. I'm not certain of either of these = things happening, however, because they're not written down. For a second example, replace the obviously contentious change with a = more subtle one; perhaps one that it would be reasonable to think that = most people wouldn't care about, and so is a 'production' issue (e.g., a = detail of the XML format). For a third example, use the lack of a change or other action as the = impetus to conflict. I believe the latter two are realistic examples. What we have now is effectively a system whereby the RSE makes decisions = with little guidance regarding how they should go about consulting the = community. Importantly, the examples above do not just illustrate the = dangers to the community of an RSE running amok (or even just slightly = out of sync); they also illustrate dangers to the RSE, who is vulnerable = the the effects of mismatched expectations.=20 I'm not yet sure what "good" looks like, but I think it's reasonable to = ask why the consensus process hasn't been explicitly invoked (possibly = with modifications like a different appeal chain). Yes, there are = clearly aspects of this role that are operational and shouldn't be = nit-picked to death (but still need _some_ form of oversight); however, = there are many that are not. In that manner, it's very interesting to = think about parallels with the discussion on the LLC's role currently = happening on ietf@. Other changes might help too; for example, a regular rfc-dispatch = meeting for ideas and changes related to the series could be a good way = to socialise proposals for change (both from the community and the RFC = Editor) in a more transparent, accountable fashion.=20 More than anything else, though, we need to write things down, and do so = clearly. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Apr 19 20:37:08 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA66B3A0DE9 for ; Sun, 19 Apr 2020 20:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1Bz3cQ7CurU for ; Sun, 19 Apr 2020 20:37:04 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AF43A0DEA for ; Sun, 19 Apr 2020 20:37:04 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id ay1so3450787plb.0 for ; Sun, 19 Apr 2020 20:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aLbE1Jz9SSkfqClQ1R0xY64dfP6alQuYNzVyy6ZqLyk=; b=cgdtGXaTQFkT5RyHhEVZjAdfE5Yv95ucfPCDPBWJy3g9fS/dxz3/NiFZL11Or01Cvq pk/3nSdxvaIxBxZj1j3EddVcCtjtUXvW9bh/6H1d/ub/DyfCMTDCkuJZGtxMumtA9YE2 tB9farL+lmLYDox71r5Tjz8BEVCufaop1/anDffmPHFlodGyzsw++68p5MpXEjW8k0jC axRIUiGLjA2gRYVVolacUMR9DbpL/NH0PAkA4SbqoWekycnn6Gu2urYJFVKr5zmf3GIq oT7y1z4PxPC2lCDe/ubYzOOfse8xjr4Di3xnH/PMvRHZGOhGTGWBk8+R3oZb/UuLY6v2 wIWg== 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=aLbE1Jz9SSkfqClQ1R0xY64dfP6alQuYNzVyy6ZqLyk=; b=dRdryDu2Qlr/YCYcGKTSCvcJ7Hj4yWGe+SaVm7W7tMH3+L+F12ey9UdIeF1xblDur0 CWFsg2tXXK78nsK0deLBPM8WmaF5E0/COXBJ/nnXZIpYNnMwp/MyyYC4HBzSneEKA+J/ w2biroIXHJ1573ZzFPzWgC6L226kOO10p3vLt16uzWDzLnJAaCMplz/aWuBhSFCoC8q/ vLHxypBPhFkT9P2NsF4qyVjxNPBkYykUJNrrZXH3GNHGbOBnZFsIc8fXMO6gUDUYghn4 wWrDN/UlQanOOgaZhAtgU7H7rR/K/kiTxmbyb4Uz3B55eStFHmszCcibT48XOQ6aG6Kx tksg== X-Gm-Message-State: AGi0PuarjH6dW0n1fyY8Mr2DpKTLgVyXRuPYn0KxpOYMwQFoI35v9PdG m6t1rhZdBqix5wWOyumXTkU= X-Google-Smtp-Source: APiQypKAUe6Tq55MeMAdAadwQAsS1qHLhoM7nap4ycd/jnJQD26X8qodJbsgCZutyCNMXkOjC2E3Uw== X-Received: by 2002:a17:90a:ce02:: with SMTP id f2mr19541724pju.144.1587353823957; Sun, 19 Apr 2020 20:37:03 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id g6sm41029368pja.2.2020.04.19.20.37.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2020 20:37:03 -0700 (PDT) To: Mark Nottingham , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Cc: rfced-future@iab.org, Nevil Brownlee References: <47f2159a-8055-d563-1d2b-a439878c9755@it.aoyama.ac.jp> <6F61B60B-72D2-43FB-86BF-10974F359F46@mnot.net> From: Brian E Carpenter Message-ID: <6fdebbb6-585f-5092-9fdf-f2fd35c8c8b3@gmail.com> Date: Mon, 20 Apr 2020 15:36:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6F61B60B-72D2-43FB-86BF-10974F359F46@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] More points to consider X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 03:37:06 -0000 On 20-Apr-20 13:17, Mark Nottingham wrote: > I'd hope it is. It must be. The whole question of oversight of the RFC Series, and how we= prevent it descending into micro-management, is part of defining the rol= e. Brian >=20 >> On 20 Apr 2020, at 11:12 am, Martin J. D=C3=BCrst wrote: >> >> On 19/04/2020 11:33, Nevil Brownlee wrote: >>> Hi all: >>> Here are a few concerns I have about the RFC Series and the RSE: >> >>> 2. RSE relationships: where does the RFC Editor fit into IETF >>> wrt the IAB, RSOC and the RPC (RFC Publication Centre)? >>> Several posts to this lists have already touched on this, >>> it's certainly one of the most important topics for the >>> rfced-futures program. >> >> The mention of the RSOC here let me come up with a question: For the d= iscussions here, is the RSOC in scope for discussion/proposals in this pr= oject or not? And to what extent? >> >> Sorry if I overlooked something obvious. >> >> Regards, Martin. >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Sun Apr 19 20:37:51 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DCE3A0DE9 for ; Sun, 19 Apr 2020 20:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ne391Ruy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=2h9J41t6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP_60InaURBF for ; Sun, 19 Apr 2020 20:37:48 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EB83A0B5F for ; Sun, 19 Apr 2020 20:37:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 273CC573 for ; Sun, 19 Apr 2020 23:37:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 19 Apr 2020 23:37:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :date:references:to:in-reply-to:message-id; s=fm2; bh=K3Z+CMcfVb j770EBBW7PhZoY3+cnchEJ038rwqrpfko=; b=ne391RuyZfJBsKP22aBrwYO4dU FUoTOKBvRNJZ2FXy4CbMkD7uR7vSOG6GTSKZ9aoMf7FaRsMyXILQKTSQQ5Kr7e9z lB6QmuLwS3hb7GDdylN/YyUhx7lvUrAnVbT8I9OwzmGj0yOxsVWRows3n1Rm+7Rf coSj61BW4MXPBNCpSL0BvMdz1DOLL0QpWIoHA8yKA19OvvDqvTtNglYSnarq5y7J kI4+sx2mf+JDZA+qXZB5fP4w9y00m0SLcu2PlYKVptBHMXnoCSzTzP0RFNqalLx0 93qgsa+C+Uw3WMKMHCRXEGLlXPtdEo8s/dr2XrNALLlSHLyWYRw1alDH7epg== 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=K3Z+CMcfVbj770EBBW7PhZoY3+cnchEJ038rwqrpf ko=; b=2h9J41t67+86pFaUwj57mT8BdWkRAWKHxj96vzsOJA2nxFGs5XntPn7hS +g8ZtLkjJUQoa5xQvwZ5jZjoX1PoMWrrj2fDUgfSPLSWRW28K68XsetFDtgIv0Kx 5O6J0i8wWD+Z38XKZTkiZFsFHnIRVH6napwRViHM1bUuSJSFwngCV+SDi3jh6hsD f2G4AA8dB0eLcROFfwjFH3B7VMFe8g4ymES4RtKX+QFnmDClaEc/sVo+wBJqyS/I BuZGX1+Sv7UPc2LElalBrEAb6MJPKRcqZEZ4jegL8/Bo98URUueWD2H4DDsYnenB lVG8VZs1j6jE0qCWDnVGA9vLiEzkw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedvgdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtgfgguffffhfvjgfkofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrdduje drudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 3A57A3280064 for ; Sun, 19 Apr 2020 23:37:45 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 20 Apr 2020 13:37:44 +1000 References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> <5c00e7df-5ff9-c340-78eb-a8a3ef0d833a@nthpermutation.com> To: rfced-future@iab.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Prevalence of editorial issues [Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Apr 2020 03:37:50 -0000 I can see a number approaches we as a community (broadly read) could = take to this general issue: 1. We fund the RFC Editor (as a function) to do the editorial work so = the document editors don't have to worry too much -- i.e., the RPC doing = significant editorial work is expected. This seems to be the status quo. 2. We fund the RSE to create resources that help the community as much = as possible with editorial work, but the RPC still serves as a backstop = to assure editorial consistency -- i.e., we should encourage editors to = take on responsibility, but still help them with the work. 3. We "crowdsource" from within (perhaps using IETF WG-like processes = overseen by the RSE) to create resources that help the community edit, = but the RPC still serves as a backstop -- same as #2, but with a = different source of advice. 4. We "crowdsource", with no backstop (effectively, this is what the W3C = does) -- a more radical change from the status quo. There are of course many variations, and I'd be surprised if I didn't = miss at least a few alternatives. I don't think exploring those options is in scope for this group. I'm = also a little surprised to see how eager this group is to dig into the = fine details of these sorts of things, because AFAICT that implies that = we're defining the RSE role so closely that it effectively cements in = our current understanding of how things work -- turning the RSE into a = job that *could* "just be done by a contractor." I think what's in scope here is structuring the RFC Editor function in = such a way that the community (broadly read) is able to come to = consensus about issues like this in a way that's accountable, = transparent, and representative, so that they can execute whatever = approach we agree to -- again, in an accountable, transparent way.=20 In other words, there needs to be a defined role that demonstrates = leadership, and its occupant(s) need both the appropriate resources to = fill that function, `and the appropriate oversight, checks and balances = as well as responsibilities to be successful in doing so.=20 I sometimes fear this group mistakes itself for that leadership (e.g., = most of the messages on this list have tried to debug AUTH48 and the = editorial process). While it's important to understand the past to help = us plan the future that our program aspires to define, we should not try = to troubleshoot its problems. Cheers, >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sun Apr 19 20:40:51 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F7A3A0DF2 for ; Sun, 19 Apr 2020 20:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_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 8oXgoQV_aw_4 for ; Sun, 19 Apr 2020 20:40:47 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0BC3A0DF1 for ; Sun, 19 Apr 2020 20:40:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 495CCM1HGLz1nt1V; Sun, 19 Apr 2020 20:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587354047; bh=7p9TlAkbsjXj+XYuFICeI/MWbyc0YE6JAK9mtWyOFmw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=O48Ktm4taTpRYv/WW0pGjBqMHDSeOuSFPakF7+xH67BAn76eBvozwyoOdXSCRZ71X c/HZOaDnTZPZcg6zluxSQHEYff/ofh3G2mplthmvKxJJOpfdcZT0pE9ADpvJ5b9tHT eyd+2Lo+XJ487OR0uTNeEIexPi0C+m8TwkHich94= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 495CCL4ncmz1nsjJ; Sun, 19 Apr 2020 20:40:46 -0700 (PDT) To: Mark Nottingham Cc: rfced-future@iab.org References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <5059D78F-3C4D-47BE-9EB3-592B6A975C09@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 19 Apr 2020 23:40:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Apr 2020 03:40:49 -0000 The primary reason that the existing documents do not point to a consensus process, as I understand the history, is that it was and is unclear whose consensus would be judged and where / how. Note also the IAB documents, including IAB process documents, are not IETF consensus documents. The IAB for all of its work consults the community, but is not bound by community consensus. Maybe we want to change that, but that would be a MUCH larger change. Unless we choose to change it drastically, the RSE is under the oversight of the IAB> (The RSOC is the currently agreed means for performing that oversight.) Could there be other ways of structuring this? Presumably. That is after all a part of why we have this list. I do have to say thought that most of the concerns I see it your note do not resonate with me. There are practical constraints and limitations that help significantly. (And any job description has to recognize those constraints in some fashion.) Trying to make those too formal and it seems to me we end up with a job that becomes both ineffective and impossible. Yours, Joel On 4/19/2020 11:18 PM, Mark Nottingham wrote: > Hi Eliot, > > Sorry for the delay, I had a busy weekend. > > On 17 Apr 2020, at 5:43 pm, Eliot Lear wrote: >> >> Hi Mark and thanks very much for your note. I have one clarifying question: >> >>> >>> * The methods that the RSE has available to the make decisions (of various sorts) are ill-defined, to the point where it can be untenable for both them and the community. To me, this is the heart of the matter. >> >> Since this is an important issue for you, would you care to elaborate a bit more about what sort of decisions the RSE makes, their impact, and what you think good looks like at a high level? > > Sure. > > RFC 8728 s 2.1.4. documents the responsibilities of the RSE, and calls out the evolution of the RFC Series explicitly. One might imagine this includes things like the format of RFCs, the editorial style used, creating resources for editors to use, the archival nature of the series, the RFC identifiers themselves, and so forth. > > There are a variety of decisions that could be made -- or not made -- about these things. Because of the diverse nature of not only the IETF community but the larger RFC-producing and consuming community, some are bound to be contentious. > > 8728 vests these responsibilities in the RSE with the expectation that they will 'engage with the Internet technical community in a process of articulating and refining a vision for the series and its continuous evolution.' Conspicuously missing is the word consensus, which would imply the extensive guidance we give the IESG and WG chairs about decision-making. > > Appeal is also central to the IETF's concept of consensus. However, 8728 does not contain that word; instead, it only says 'the RSE cooperates closely with the community, and operates under oversight of the RSOC: thus, ultimately, under oversight of the IAB.' > > More guidance is provided by RFC 8729, in the various Process Change subsections. For example, s 4.4.3. regarding series-wide guidelines and rules says '[w]hen additions or changes are needed to series-wide definitions, the IAB will work with the RFC Editor and stream stakeholders to get community input and review. The IAB will approve changes by validating appropriate consideration of community requirements.' > > This supports the view that the only practical check on the RSE is IAB approval of specific actions; approval that is rarely withheld (especially after recent events, I'd suspect). That, in turn, is somewhat muddied by the ill-defined role of RSOC. > > RSOC is, according to 8729, 'responsible for ensuring that the RFC Series is run in a transparent and accountable manner.' However, 8728 does not enact how this is done; it only says that RSOC 'will approve consensus policy and vision documents as developed by the RSE...', along with 'decisions that affect the RSE individually.' It would be interesting to hear whether the IAB thinks it has delegated its 'validating appropriate consideration' powers to the RSOC, and what the RSOC thinks about that (and I sit on both). > > I think our primary task is exploring whether this arrangement results in what's best for the community and the Series. > > For example, let's imagine that our next RSE talks to parts of the community and determines that the archival requirement was no longer necessary, and so they should start updating in-place RFCs. Others in the community would be very unhappy about this. The IAB could 'validate[e] appropriate consideration of community requirements' and determine that the RSE hadn't done so, but this could get heated; 'appropriate consideration' is a value judgment, and the IAB's questioning could be seen as interfering with the autonomy of the RSE. In the end, no matter what decision was made, there would likely be parts of the community who felt that they were not listened to, an RSE with burnt fingers, and an IAB (or is it RSOC?) having to make a decision without clear criteria. > > That example may not be realistic, because a good RSE would convene some body to make that decision, and establish ground rules that look an awful lot like the IETF's consensus guidance. Perhaps the lack of doing so would be enough for the IAB to use as evidence that 'appropriate consideration' did not take place. I'm not certain of either of these things happening, however, because they're not written down. > > For a second example, replace the obviously contentious change with a more subtle one; perhaps one that it would be reasonable to think that most people wouldn't care about, and so is a 'production' issue (e.g., a detail of the XML format). > > For a third example, use the lack of a change or other action as the impetus to conflict. > > I believe the latter two are realistic examples. > > What we have now is effectively a system whereby the RSE makes decisions with little guidance regarding how they should go about consulting the community. Importantly, the examples above do not just illustrate the dangers to the community of an RSE running amok (or even just slightly out of sync); they also illustrate dangers to the RSE, who is vulnerable the the effects of mismatched expectations. > > I'm not yet sure what "good" looks like, but I think it's reasonable to ask why the consensus process hasn't been explicitly invoked (possibly with modifications like a different appeal chain). Yes, there are clearly aspects of this role that are operational and shouldn't be nit-picked to death (but still need _some_ form of oversight); however, there are many that are not. In that manner, it's very interesting to think about parallels with the discussion on the LLC's role currently happening on ietf@. > > Other changes might help too; for example, a regular rfc-dispatch meeting for ideas and changes related to the series could be a good way to socialise proposals for change (both from the community and the RFC Editor) in a more transparent, accountable fashion. > > More than anything else, though, we need to write things down, and do so clearly. > > Cheers, > > > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Sun Apr 19 20:46:07 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53FC3A0E06 for ; Sun, 19 Apr 2020 20:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_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 RnTonXpA9Te8 for ; Sun, 19 Apr 2020 20:46:04 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A003A0E07 for ; Sun, 19 Apr 2020 20:46:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 495CKS3LMxz1p2qY; Sun, 19 Apr 2020 20:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587354364; bh=kmItv3gPntm7ZIO30eO7u3752dNI4qLIvujZ665OObc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LufKGWF3VfqhfNN6R5BCyx8HG5ziY8ptnYWdZHdiVjAPchruHq/mHAbSBRF3h1+6f HwQ3ilCjj8MrAv04q8EHRqIa9EWGbhs3zW4K9CQAXmnpwRBZSUCRS2G6CjmSwXsHHm 0Sv6NK8/Q10CDeQ56CjDHjcygL/zfRymYZXhneLU= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 495CKR6tF1z1ntPH; Sun, 19 Apr 2020 20:46:03 -0700 (PDT) To: Mark Nottingham , rfced-future@iab.org References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> <5c00e7df-5ff9-c340-78eb-a8a3ef0d833a@nthpermutation.com> From: "Joel M. Halpern" Message-ID: <2f025f43-ee9f-8e45-c165-087e211dcb56@joelhalpern.com> Date: Sun, 19 Apr 2020 23:45:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Prevalence of editorial issues [Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Apr 2020 03:46:06 -0000 Since I just disagreed with Mark's previous message, I want to say that meat of this message (the second half), and the goals of this work it describes (at least as I understand what I read) seems right to me. Yours, Joel On 4/19/2020 11:37 PM, Mark Nottingham wrote: > I can see a number approaches we as a community (broadly read) could take to this general issue: > > 1. We fund the RFC Editor (as a function) to do the editorial work so the document editors don't have to worry too much -- i.e., the RPC doing significant editorial work is expected. This seems to be the status quo. > 2. We fund the RSE to create resources that help the community as much as possible with editorial work, but the RPC still serves as a backstop to assure editorial consistency -- i.e., we should encourage editors to take on responsibility, but still help them with the work. > 3. We "crowdsource" from within (perhaps using IETF WG-like processes overseen by the RSE) to create resources that help the community edit, but the RPC still serves as a backstop -- same as #2, but with a different source of advice. > 4. We "crowdsource", with no backstop (effectively, this is what the W3C does) -- a more radical change from the status quo. > > There are of course many variations, and I'd be surprised if I didn't miss at least a few alternatives. > > I don't think exploring those options is in scope for this group. I'm also a little surprised to see how eager this group is to dig into the fine details of these sorts of things, because AFAICT that implies that we're defining the RSE role so closely that it effectively cements in our current understanding of how things work -- turning the RSE into a job that *could* "just be done by a contractor." > > I think what's in scope here is structuring the RFC Editor function in such a way that the community (broadly read) is able to come to consensus about issues like this in a way that's accountable, transparent, and representative, so that they can execute whatever approach we agree to -- again, in an accountable, transparent way. > > In other words, there needs to be a defined role that demonstrates leadership, and its occupant(s) need both the appropriate resources to fill that function, `and the appropriate oversight, checks and balances as well as responsibilities to be successful in doing so. > > I sometimes fear this group mistakes itself for that leadership (e.g., most of the messages on this list have tried to debug AUTH48 and the editorial process). While it's important to understand the past to help us plan the future that our program aspires to define, we should not try to troubleshoot its problems. > > Cheers, > >> > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Sun Apr 19 20:46:52 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DAA3A0E07 for ; Sun, 19 Apr 2020 20:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=J2odyNLj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rKMYzzFl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS6JhHOEW8wW for ; Sun, 19 Apr 2020 20:46:46 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA203A0E08 for ; Sun, 19 Apr 2020 20:46:46 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B45965CC; Sun, 19 Apr 2020 23:46:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 19 Apr 2020 23:46:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=A A13eYITcl1FESXrs0ediqq2co1imOf1Rts7rJj6Db4=; b=J2odyNLjSXmIRDE8i T+yW1i714gAPeKtdsn4hM1Svrx3AgPNSrd7/7lpTYLLykF9DfSZMxrmGmR+keNvw 6yHsZYJl27uZzAcuNptAJRPUK5tR6pkk2ovszeflt6aOw2RMB1FwZHKRCjnW23qb 0py2Gw/qR7KsvaivRqBUDMy2pHFzAG44Y1hT9iaMCaFnsDMjbw7ek8etDeSsZ7zl 0njEifjFCmzAz9oLLh6sxdtVO5rlFQWrUnVZgmTm+t49DxaMxPW3AAcfilVpCB4N piFLMgk25cvrAlTYHGhOKtbSfOhjnJsiJozKpd9gP8C1yv6b7CZZnuG52PvMTQxu FkfPg== 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=AA13eYITcl1FESXrs0ediqq2co1imOf1Rts7rJj6D b4=; b=rKMYzzFlt1Ifw4WcbwriyIRf5YOPkHcZWmddVa3WOEJpSB3TjQuHMMvwT kFCbPmWuYYnu9E2yVMfyo1WgfOxojhVgKJBqEuUl9FqaykOdULCWbIhR0IMWbysJ za1zKga9szEcR/IOc4+Nj+UaJs+jc0/o7E49XQwXrKaQU82/eiQFlMf92l//+mxv UscGlT3P1yoAaYzJKljdgg51I3d3HsGWgYZeLVDMHlzsZj6ynT2PknIlO38Os9AU JxNxhvj5+YWbSa3mC6YFQGmGFZOo2uGg5ms8NGpz2EaAb5PrHkJochKEeSjUgpVO R4YOnGD1FXFvkoulDLq/wRqgDIfJg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedvgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucffohhmrghinhepmhhnohhtrdhnvghtpdhirggsrdhorhhgnecukf hppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 0CF1C3065784; Sun, 19 Apr 2020 23:46:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Mon, 20 Apr 2020 13:46:40 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <10807CD0-58FF-416A-9C02-1E5D367D78A8@mnot.net> References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <5059D78F-3C4D-47BE-9EB3-592B6A975C09@cisco.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Apr 2020 03:46:51 -0000 > On 20 Apr 2020, at 1:40 pm, Joel M. Halpern = wrote: >=20 > The primary reason that the existing documents do not point to a = consensus process, as I understand the history, is that it was and is = unclear whose consensus would be judged and where / how. Yes, I've heard that asserted in various ways. I always find it puzzling = that we say it's difficult to find a community affected by a change and = judge its consensus, and yet the IETF does this all the time. We = explicitly say that there is no membership, and that anyone can = contribute (without even showing up at a meeting). Do we not really = believe that? > Note also the IAB documents, including IAB process documents, are not = IETF consensus documents. The IAB for all of its work consults the = community, but is not bound by community consensus. Maybe we want to = change that, but that would be a MUCH larger change. > Unless we choose to change it drastically, the RSE is under the = oversight of the IAB> (The RSOC is the currently agreed means for = performing that oversight.) >=20 > Could there be other ways of structuring this? Presumably. That is = after all a part of why we have this list. >=20 > I do have to say thought that most of the concerns I see it your note = do not resonate with me. There are practical constraints and = limitations that help significantly. (And any job description has to = recognize those constraints in some fashion.) Trying to make those too = formal and it seems to me we end up with a job that becomes both = ineffective and impossible. Of course we can go too far, as in all things. > Yours, > Joel >=20 > On 4/19/2020 11:18 PM, Mark Nottingham wrote: >> Hi Eliot, >> Sorry for the delay, I had a busy weekend. >> On 17 Apr 2020, at 5:43 pm, Eliot Lear = wrote: >>>=20 >>> Hi Mark and thanks very much for your note. I have one clarifying = question: >>>=20 >>>>=20 >>>> * The methods that the RSE has available to the make decisions (of = various sorts) are ill-defined, to the point where it can be untenable = for both them and the community. To me, this is the heart of the matter. >>>=20 >>> Since this is an important issue for you, would you care to = elaborate a bit more about what sort of decisions the RSE makes, their = impact, and what you think good looks like at a high level? >> Sure. >> RFC 8728 s 2.1.4. documents the responsibilities of the RSE, and = calls out the evolution of the RFC Series explicitly. One might imagine = this includes things like the format of RFCs, the editorial style used, = creating resources for editors to use, the archival nature of the = series, the RFC identifiers themselves, and so forth. >> There are a variety of decisions that could be made -- or not made -- = about these things. Because of the diverse nature of not only the IETF = community but the larger RFC-producing and consuming community, some are = bound to be contentious. >> 8728 vests these responsibilities in the RSE with the expectation = that they will 'engage with the Internet technical community in a = process of articulating and refining a vision for the series and its = continuous evolution.' Conspicuously missing is the word consensus, = which would imply the extensive guidance we give the IESG and WG chairs = about decision-making. >> Appeal is also central to the IETF's concept of consensus. However, = 8728 does not contain that word; instead, it only says 'the RSE = cooperates closely with the community, and operates under oversight of = the RSOC: thus, ultimately, under oversight of the IAB.' >> More guidance is provided by RFC 8729, in the various Process Change = subsections. For example, s 4.4.3. regarding series-wide guidelines and = rules says '[w]hen additions or changes are needed to series-wide = definitions, the IAB will work with the RFC Editor and stream = stakeholders to get community input and review. The IAB will approve = changes by validating appropriate consideration of community = requirements.' >> This supports the view that the only practical check on the RSE is = IAB approval of specific actions; approval that is rarely withheld = (especially after recent events, I'd suspect). That, in turn, is = somewhat muddied by the ill-defined role of RSOC. >> RSOC is, according to 8729, 'responsible for ensuring that the RFC = Series is run in a transparent and accountable manner.' However, 8728 = does not enact how this is done; it only says that RSOC 'will approve = consensus policy and vision documents as developed by the RSE...', along = with 'decisions that affect the RSE individually.' It would be = interesting to hear whether the IAB thinks it has delegated its = 'validating appropriate consideration' powers to the RSOC, and what the = RSOC thinks about that (and I sit on both). >> I think our primary task is exploring whether this arrangement = results in what's best for the community and the Series. >> For example, let's imagine that our next RSE talks to parts of the = community and determines that the archival requirement was no longer = necessary, and so they should start updating in-place RFCs. Others in = the community would be very unhappy about this. The IAB could = 'validate[e] appropriate consideration of community requirements' and = determine that the RSE hadn't done so, but this could get heated; = 'appropriate consideration' is a value judgment, and the IAB's = questioning could be seen as interfering with the autonomy of the RSE. = In the end, no matter what decision was made, there would likely be = parts of the community who felt that they were not listened to, an RSE = with burnt fingers, and an IAB (or is it RSOC?) having to make a = decision without clear criteria. >> That example may not be realistic, because a good RSE would convene = some body to make that decision, and establish ground rules that look an = awful lot like the IETF's consensus guidance. Perhaps the lack of doing = so would be enough for the IAB to use as evidence that 'appropriate = consideration' did not take place. I'm not certain of either of these = things happening, however, because they're not written down. >> For a second example, replace the obviously contentious change with a = more subtle one; perhaps one that it would be reasonable to think that = most people wouldn't care about, and so is a 'production' issue (e.g., a = detail of the XML format). >> For a third example, use the lack of a change or other action as the = impetus to conflict. >> I believe the latter two are realistic examples. >> What we have now is effectively a system whereby the RSE makes = decisions with little guidance regarding how they should go about = consulting the community. Importantly, the examples above do not just = illustrate the dangers to the community of an RSE running amok (or even = just slightly out of sync); they also illustrate dangers to the RSE, who = is vulnerable the the effects of mismatched expectations. >> I'm not yet sure what "good" looks like, but I think it's reasonable = to ask why the consensus process hasn't been explicitly invoked = (possibly with modifications like a different appeal chain). Yes, there = are clearly aspects of this role that are operational and shouldn't be = nit-picked to death (but still need _some_ form of oversight); however, = there are many that are not. In that manner, it's very interesting to = think about parallels with the discussion on the LLC's role currently = happening on ietf@. >> Other changes might help too; for example, a regular rfc-dispatch = meeting for ideas and changes related to the series could be a good way = to socialise proposals for change (both from the community and the RFC = Editor) in a more transparent, accountable fashion. >> More than anything else, though, we need to write things down, and do = so clearly. >> Cheers, >> -- >> Mark Nottingham https://www.mnot.net/ >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Sun Apr 19 21:44:13 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FE53A0F43 for ; Sun, 19 Apr 2020 21:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zjWkQYgzS5W for ; Sun, 19 Apr 2020 21:44:08 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D4C3A0F41 for ; Sun, 19 Apr 2020 21:44:08 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id nu11so3905285pjb.1 for ; Sun, 19 Apr 2020 21:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vcdHbDJ66W160hpNUfv6xpSbyFPlq5nm30xsiknumyM=; b=Y+3hX1wb/EdCQy5RPhyXV+F4uo+3ohUYmCnuI7usQzLeHe/Qy1zwZN4qbEVFE5Wjd+ WCCpRRZwenndPzURdqf6M/SvaM+Bv6xTopVCGgUNn6XAiqewhOilfsRNShFBvPbyHT1S NoMItGJnUv/KhuMgNC+FyYowF7DnlVg1sBDj7vEHbIpHNx+EIg+efuTtIrXhkdEwZ9hZ b7qoqYJOYCFzDe3jdUlz5NauS47+jD2BjNSnzVL0Ba1YVexVqS2M3xiMIHzb3WZaJyRS gBUsVPsTc8rFUM+BXfDCii1bE6wK1tdu0DcYAEfZf1O1o4SYaW9IdHI0S3hnVi2Dub2i TqWQ== 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=vcdHbDJ66W160hpNUfv6xpSbyFPlq5nm30xsiknumyM=; b=h2xX0Rf4YeYMqzcinTz8u08bFgEBG1NF1t3kn8iW/FqLSoIYwD6hocxdfLGBISrerI t5o7l3mAJ6+zHUhMJ6cFs4cpoAxvgj9zjxiU31gwFoilXTiIYgE2XU32S3SLKDMXkMTK 1irIHrDUMlH0OuCY3K2Idgu+LbgtTA9aH4MSUo2VZWeknbXEmEctHXRfu/nPtZGYFWHY SG5Fz7V8Hgs3YzRVgWS2vtHUeUwE7yKp5vfkh97TgcitrwQyklw1c20aKAI6K7/Vz3d3 aVv6Fr20KtZEtl4sGJro9PM6W9ZeO5nbJAB9oPrgGompAePhpVsdOpALujL0K1T3Cnm0 uk4w== X-Gm-Message-State: AGi0PubBKeDt344gEBdIpTYqGM7hRr7IAacFc606dQJSIYJAWdsBhlTn NSS0EBcZWheJJZarQk4sI3wO6Xl+ X-Google-Smtp-Source: APiQypJ3lWURbcGEhZrVD0TwYaBC9Y3FQXndIQWagrzzT7vld75XQoyVyG+5IK5cJiBXxTyiVifjIQ== X-Received: by 2002:a17:90a:be12:: with SMTP id a18mr18748307pjs.162.1587357847610; Sun, 19 Apr 2020 21:44:07 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id o187sm25842747pfb.12.2020.04.19.21.44.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2020 21:44:06 -0700 (PDT) To: Mark Nottingham , "Joel M. Halpern" Cc: rfced-future@iab.org References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <5059D78F-3C4D-47BE-9EB3-592B6A975C09@cisco.com> <10807CD0-58FF-416A-9C02-1E5D367D78A8@mnot.net> From: Brian E Carpenter Message-ID: <44d2d207-3a27-dc8c-da60-490653e9a140@gmail.com> Date: Mon, 20 Apr 2020 16:44:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <10807CD0-58FF-416A-9C02-1E5D367D78A8@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] Community [was Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Apr 2020 04:44:11 -0000 On 20-Apr-20 15:46, Mark Nottingham wrote: > > >> On 20 Apr 2020, at 1:40 pm, Joel M. Halpern wrote: >> >> The primary reason that the existing documents do not point to a consensus process, as I understand the history, is that it was and is unclear whose consensus would be judged and where / how. > > Yes, I've heard that asserted in various ways. I always find it puzzling that we say it's difficult to find a community affected by a change and judge its consensus, and yet the IETF does this all the time. We explicitly say that there is no membership, and that anyone can contribute (without even showing up at a meeting). Do we not really believe that? Let's be specific, because it does need a mechanism: Strawman #1: Define the community as everybody who finds RFCs to be useful. How does somebody (say, the RSE) discover and judge the rough consensus of that community? Strawman #2: We define the community as "everybody who bothers to join the rfc-interest list", and the RSE could indeed use IETF-like rough consensus. Strawman #3: Convert that mailing list into the "RFC Association" with its own Articles of Incorporation etc. Strawman #4: Use ISOC membership as a proxy for the RFC community. I'm sure there are other options, but we'd have to pick one or another to talk about consensus. Brian >> Note also the IAB documents, including IAB process documents, are not IETF consensus documents. The IAB for all of its work consults the community, but is not bound by community consensus. Maybe we want to change that, but that would be a MUCH larger change. >> Unless we choose to change it drastically, the RSE is under the oversight of the IAB> (The RSOC is the currently agreed means for performing that oversight.) >> >> Could there be other ways of structuring this? Presumably. That is after all a part of why we have this list. >> >> I do have to say thought that most of the concerns I see it your note do not resonate with me. There are practical constraints and limitations that help significantly. (And any job description has to recognize those constraints in some fashion.) Trying to make those too formal and it seems to me we end up with a job that becomes both ineffective and impossible. > > Of course we can go too far, as in all things. > > > > > >> Yours, >> Joel >> >> On 4/19/2020 11:18 PM, Mark Nottingham wrote: >>> Hi Eliot, >>> Sorry for the delay, I had a busy weekend. >>> On 17 Apr 2020, at 5:43 pm, Eliot Lear wrote: >>>> >>>> Hi Mark and thanks very much for your note. I have one clarifying question: >>>> >>>>> >>>>> * The methods that the RSE has available to the make decisions (of various sorts) are ill-defined, to the point where it can be untenable for both them and the community. To me, this is the heart of the matter. >>>> >>>> Since this is an important issue for you, would you care to elaborate a bit more about what sort of decisions the RSE makes, their impact, and what you think good looks like at a high level? >>> Sure. >>> RFC 8728 s 2.1.4. documents the responsibilities of the RSE, and calls out the evolution of the RFC Series explicitly. One might imagine this includes things like the format of RFCs, the editorial style used, creating resources for editors to use, the archival nature of the series, the RFC identifiers themselves, and so forth. >>> There are a variety of decisions that could be made -- or not made -- about these things. Because of the diverse nature of not only the IETF community but the larger RFC-producing and consuming community, some are bound to be contentious. >>> 8728 vests these responsibilities in the RSE with the expectation that they will 'engage with the Internet technical community in a process of articulating and refining a vision for the series and its continuous evolution.' Conspicuously missing is the word consensus, which would imply the extensive guidance we give the IESG and WG chairs about decision-making. >>> Appeal is also central to the IETF's concept of consensus. However, 8728 does not contain that word; instead, it only says 'the RSE cooperates closely with the community, and operates under oversight of the RSOC: thus, ultimately, under oversight of the IAB.' >>> More guidance is provided by RFC 8729, in the various Process Change subsections. For example, s 4.4.3. regarding series-wide guidelines and rules says '[w]hen additions or changes are needed to series-wide definitions, the IAB will work with the RFC Editor and stream stakeholders to get community input and review. The IAB will approve changes by validating appropriate consideration of community requirements.' >>> This supports the view that the only practical check on the RSE is IAB approval of specific actions; approval that is rarely withheld (especially after recent events, I'd suspect). That, in turn, is somewhat muddied by the ill-defined role of RSOC. >>> RSOC is, according to 8729, 'responsible for ensuring that the RFC Series is run in a transparent and accountable manner.' However, 8728 does not enact how this is done; it only says that RSOC 'will approve consensus policy and vision documents as developed by the RSE...', along with 'decisions that affect the RSE individually.' It would be interesting to hear whether the IAB thinks it has delegated its 'validating appropriate consideration' powers to the RSOC, and what the RSOC thinks about that (and I sit on both). >>> I think our primary task is exploring whether this arrangement results in what's best for the community and the Series. >>> For example, let's imagine that our next RSE talks to parts of the community and determines that the archival requirement was no longer necessary, and so they should start updating in-place RFCs. Others in the community would be very unhappy about this. The IAB could 'validate[e] appropriate consideration of community requirements' and determine that the RSE hadn't done so, but this could get heated; 'appropriate consideration' is a value judgment, and the IAB's questioning could be seen as interfering with the autonomy of the RSE. In the end, no matter what decision was made, there would likely be parts of the community who felt that they were not listened to, an RSE with burnt fingers, and an IAB (or is it RSOC?) having to make a decision without clear criteria. >>> That example may not be realistic, because a good RSE would convene some body to make that decision, and establish ground rules that look an awful lot like the IETF's consensus guidance. Perhaps the lack of doing so would be enough for the IAB to use as evidence that 'appropriate consideration' did not take place. I'm not certain of either of these things happening, however, because they're not written down. >>> For a second example, replace the obviously contentious change with a more subtle one; perhaps one that it would be reasonable to think that most people wouldn't care about, and so is a 'production' issue (e.g., a detail of the XML format). >>> For a third example, use the lack of a change or other action as the impetus to conflict. >>> I believe the latter two are realistic examples. >>> What we have now is effectively a system whereby the RSE makes decisions with little guidance regarding how they should go about consulting the community. Importantly, the examples above do not just illustrate the dangers to the community of an RSE running amok (or even just slightly out of sync); they also illustrate dangers to the RSE, who is vulnerable the the effects of mismatched expectations. >>> I'm not yet sure what "good" looks like, but I think it's reasonable to ask why the consensus process hasn't been explicitly invoked (possibly with modifications like a different appeal chain). Yes, there are clearly aspects of this role that are operational and shouldn't be nit-picked to death (but still need _some_ form of oversight); however, there are many that are not. In that manner, it's very interesting to think about parallels with the discussion on the LLC's role currently happening on ietf@. >>> Other changes might help too; for example, a regular rfc-dispatch meeting for ideas and changes related to the series could be a good way to socialise proposals for change (both from the community and the RFC Editor) in a more transparent, accountable fashion. >>> More than anything else, though, we need to write things down, and do so clearly. >>> Cheers, >>> -- >>> Mark Nottingham https://www.mnot.net/ >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Sun Apr 19 21:58:44 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204703A0F8D for ; Sun, 19 Apr 2020 21:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=n7MU1Ck0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JrK0xLpM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ukiq79ZgLaU for ; Sun, 19 Apr 2020 21:58:41 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FE93A0F8B for ; Sun, 19 Apr 2020 21:58:41 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 4A4DC5A5 for ; Mon, 20 Apr 2020 00:58:41 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Mon, 20 Apr 2020 00:58:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=P/cI0A88pGAysPjQbKflO2HhIQxMk+o P2Cnj6JJbX+s=; b=n7MU1Ck0o9USgd4xH0VQALqruxxi5wk4vFur/7wqYN+BVYb wz6kHoji16hz9CVYxeFRc1fVaoYJzen14dyw5b2jpEn4LoGIRcYu9ztTFZlJjv/h N7zRBpuw4Ik7LSNEMO2L7uI2wkWeyocQtbBf9ELZmWmAuQXQDK1yF661O/vbzRv1 lVs++Yd4UoRiH9d+Ula4qXzvmz06ZKt9tSV6TjlnkvmnKy88QV6zJJCxnORLTdEZ LnpDquuRF4SePEG0XDtUocJe40b+Dmu+sINCVPTamao+MoAWpPwCPPOeMkEPFP/N Sfg/P2eWyvrE4G0sy4xIGIDY+tz9omt+ux/8z5Q== 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=P/cI0A 88pGAysPjQbKflO2HhIQxMk+oP2Cnj6JJbX+s=; b=JrK0xLpMwbXtQgz9s7wEir Pi6P0S6tMVH04i2esJZX2Jeb9K2Mvr7IibLueeZyNtLD0QnNeKBdmEOtO20rodtO rv9TA98VOZevVRW/EbP18Kh16ylA3djOoM9JDD/MYe7nN9PG93S+mfeGjsYu90eh uKhTHWxwvZQCEULgorFhFGgn99vTVDWKFD5iW00UNwlCpXkxgmEKCeRTtRkIu4Ns 3h/6WyAmX0Zd8m4jlAQgRLFlGHzeKuDwXGHNEiAW1ZO2TR2MtNJ/ixhZ4XllE0RF KehpNume0vs8uag7B7bh66p2VmNDtX90A8cZLigyXNIrTH8tMQUYfxz+04hmCn4g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedvgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6E710180091; Mon, 20 Apr 2020 00:58:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1152-g08c8976-fmstable-20200420v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <44d2d207-3a27-dc8c-da60-490653e9a140@gmail.com> References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <5059D78F-3C4D-47BE-9EB3-592B6A975C09@cisco.com> <10807CD0-58FF-416A-9C02-1E5D367D78A8@mnot.net> <44d2d207-3a27-dc8c-da60-490653e9a140@gmail.com> Date: Mon, 20 Apr 2020 14:58:20 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Community_=5Bwas_Work_plan_and_next_ste?= =?utf-8?q?ps_for_this_group=5D?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Apr 2020 04:58:43 -0000 On Mon, Apr 20, 2020, at 14:44, Brian E Carpenter wrote: > Strawman #1: > Define the community as everybody who finds RFCs to be useful. > [...] > Strawman #2: > We define the community as "everybody who bothers to join the > rfc-interest list", and the RSE could indeed use IETF-like rough > consensus. I don't know how to make #1 work at all. But we have worked examples of #2 that demonstrate some degree of efficacy. And we know at least some of us are comfortable operating in that mode. I would be leery of any attempt to define some sort of membership (#3+), though I know those schemes can work (for some definition of "work"), though details matter in terms of what emergent biases appear. Any system will have its quirks, biases, and exposure to attacks of various kinds. But I would suggest that similarity to existing systems will reduce the potential for unpleasant surprises. From nobody Mon Apr 20 00:55:07 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D083A1401 for ; Mon, 20 Apr 2020 00:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmkCN2iFXkIQ for ; Mon, 20 Apr 2020 00:55:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A521A3A13FF for ; Mon, 20 Apr 2020 00:55:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E430BBE2F; Mon, 20 Apr 2020 08:55:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1utRSBiAYLyE; Mon, 20 Apr 2020 08:54:59 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 60364BE2C; Mon, 20 Apr 2020 08:54:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1587369299; bh=QW3mcZ9kR0sS6Hx0swCdYr5dx00ptJsZzmVY2p/Fiww=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AiXXe/MIzZgpSSaqlwXHRve5uzBj9b0yGPkN8pZFrJcYPbiuxSE6EGyBKaWho0NtB IwxEZncOgg6TgSJh5xbaWxA168eA8aehpDfxIhl/MOQD2QAnbhe+G09CVJX6bd0gaU /ZIaJ48zK6hXrGEFY5JWz7gKW8SUIwCFcRIv/+wg= To: Brian E Carpenter Cc: rfced-future@iab.org References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <5059D78F-3C4D-47BE-9EB3-592B6A975C09@cisco.com> <10807CD0-58FF-416A-9C02-1E5D367D78A8@mnot.net> <44d2d207-3a27-dc8c-da60-490653e9a140@gmail.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Mon, 20 Apr 2020 08:54:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <44d2d207-3a27-dc8c-da60-490653e9a140@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4Eq1v3jKNVXNChnF2RoosfoFi0cpIKhkQ" Archived-At: Subject: Re: [Rfced-future] Community [was Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Apr 2020 07:55:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4Eq1v3jKNVXNChnF2RoosfoFi0cpIKhkQ Content-Type: multipart/mixed; boundary="QHEXydXpXPZgGAgwBG4nRWNsPtXiYmyXO"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter Cc: rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Community [was Work plan and next steps for this group] References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <5059D78F-3C4D-47BE-9EB3-592B6A975C09@cisco.com> <10807CD0-58FF-416A-9C02-1E5D367D78A8@mnot.net> <44d2d207-3a27-dc8c-da60-490653e9a140@gmail.com> In-Reply-To: <44d2d207-3a27-dc8c-da60-490653e9a140@gmail.com> --QHEXydXpXPZgGAgwBG4nRWNsPtXiYmyXO Content-Type: multipart/mixed; boundary="------------95F777D0D2E88B0B592C383C" Content-Language: en-US This is a multi-part message in MIME format. --------------95F777D0D2E88B0B592C383C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 20/04/2020 05:44, Brian E Carpenter wrote: > Strawman #1: Define the community as everybody who finds RFCs to be > useful. >=20 > How does somebody (say, the RSE) discover and judge the rough > consensus of that community? >=20 > Strawman #2: We define the community as "everybody who bothers to > join the rfc-interest list", and the RSE could indeed use IETF-like > rough consensus. Strawman #2.5: Define the community as anyone who reads RFCs. Publish an RFC that says "if you care about the operation and future of the series, get yourself active on the rfc-interest list." Go from there with an expectation that the RSE follow the rough consensus of that list as needed. Cheers, S. --------------95F777D0D2E88B0B592C383C Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------95F777D0D2E88B0B592C383C-- --QHEXydXpXPZgGAgwBG4nRWNsPtXiYmyXO-- --4Eq1v3jKNVXNChnF2RoosfoFi0cpIKhkQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6dVVIACgkQWrL68XsX K+q6ZRAAxweCRTc3+LV2onJ4UxO/OXlOGkf0Py1pFkV8fAewqcEURqEtEMX9cRdP kGnQur6rw+hruyx8zd7OW0WiAj8fJKj0xq+WZXk3yc5EXWLmUDNQm6SFM+hAl1A7 rKWZNGs8Mw6M/+MR7CkGGvKDXCKD2LGOX56nU9WZqmvMBJCPdYrNbwUNwF9uPfjW MyMkZblet2BKmpOtILJsmYqKL8fgdXdfIBkUF/Gd/QS77E2zytDoUAn1hfEXrma4 cIY5rPTUPAC9h5D8Tm1t/mOoi/FMOJhm1gOHfFOK6wJhkd9Rg+IL7YnJj1eKjTmo lYh+GwKzKnpEcDs08tTVr+07S/cUIM2wupdYEh50LVvio2qnfyK+8SoefiQXUVG6 GjAcUOfn7G9yoMYHydCL001q26Ytf9qvW6XgfRaF9HsBl+dTSBMAgYIgTziyjsIC +XFRXTZJRVkTHoyKbaf+stmInjKe8oAvZek1rhNM8k/5RygIYumC+w5RzhUL/6/S Q/Soxa7JGAvvSBl4frK1k4+MOvHvrmekX2vdzAmDC4zqC2jI+rjpWsjaW6G4VoWL yq2o2wA1tPd9+QhI0XRxUiIblaSz/nwfrTPUjHJ5ufuIxSK2T4uEXySUi31qN9rg P21IvWiEzP9Z9gSZUV/+VJYbPPaOLMjzmX0bye/Z0kgUENvDJOg= =FXL8 -----END PGP SIGNATURE----- --4Eq1v3jKNVXNChnF2RoosfoFi0cpIKhkQ-- From nobody Mon Apr 20 02:40:20 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FE73A0921 for ; Mon, 20 Apr 2020 02:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaVMgUZeFuve for ; Mon, 20 Apr 2020 02:40:15 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEAE3A091F for ; Mon, 20 Apr 2020 02:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3038; q=dns/txt; s=iport; t=1587375615; x=1588585215; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fDvkO6LnNWUifBDo/R9zw0xzp5XsdsmKzRkyI9/FZLg=; b=iluiCGZTbmVqBjlugQvSv0v0B4ZcfSK7hl0TWFNzBLXnyK21ydSCBAUE t4ESoS6u2/pOv1kbJIJa31BUYDF+dcgIsnuPTkeWupeG7cXg5uimDWXig sGAYMe9JQmqYXQPtTPieRSmVhrnSDxLkLoh7d+jT4MRZO3ruDL5WI0TDV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAwCnbJ1e/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuDayASKoQdiQKHZiWbTgoBAQEMAQEvBAEBhEQCgjM4EwIDAQE?= =?us-ascii?q?LAQEFAQEBAgEFBG2FYoVxAQEBAQIBI0kKAwULCw4KAgImAgJXBhMUB4MLgl0?= =?us-ascii?q?grhB1gTKFT4UXgQ4qjFOCAIERJwwQgh8uPoROgxIygi0EjhKjb4JOgmmVAh2?= =?us-ascii?q?CVo0YJ4w9qRmDPwIEBgUCFYFpIoFWMxoIGxVlAYI+PhIYDZIQjhI/AzCPVAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.72,406,1580774400"; d="scan'208";a="25479619" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Apr 2020 09:40:13 +0000 Received: from [10.61.218.226] ([10.61.218.226]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03K9eBKA010765 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Apr 2020 09:40:12 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Mon, 20 Apr 2020 11:40:11 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <055D94F6-EEB5-48F3-8169-5DEC0CA085A2@cisco.com> References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> <7A2B76A4-309B-4ADD-A746-3E0E410FED0F@cisco.com> <5c00e7df-5ff9-c340-78eb-a8a3ef0d833a@nthpermutation.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.218.226, [10.61.218.226] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Prevalence of editorial issues [Work plan and next steps for this group] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Apr 2020 09:40:20 -0000 Good evening, Mark. > On 20 Apr 2020, at 05:37, Mark Nottingham wrote: >=20 > I can see a number approaches we as a community (broadly read) could = take to this general issue: >=20 > 1. We fund the RFC Editor (as a function) to do the editorial work so = the document editors don't have to worry too much -- i.e., the RPC doing = significant editorial work is expected. This seems to be the status quo. > 2. We fund the RSE to create resources that help the community as much = as possible with editorial work, but the RPC still serves as a backstop = to assure editorial consistency -- i.e., we should encourage editors to = take on responsibility, but still help them with the work. > 3. We "crowdsource" from within (perhaps using IETF WG-like processes = overseen by the RSE) to create resources that help the community edit, = but the RPC still serves as a backstop -- same as #2, but with a = different source of advice. > 4. We "crowdsource", with no backstop (effectively, this is what the = W3C does) -- a more radical change from the status quo. >=20 > There are of course many variations, and I'd be surprised if I didn't = miss at least a few alternatives. >=20 > I don't think exploring those options is in scope for this group. I'm = also a little surprised to see how eager this group is to dig into the = fine details of these sorts of things, because AFAICT that implies that = we're defining the RSE role so closely that it effectively cements in = our current understanding of how things work -- turning the RSE into a = job that *could* "just be done by a contractor." I read things a little differently. I think people are trying to = understand the implications of decisions that we make now in terms of = structure, and are working =E2=80=9Cbottom up=E2=80=9D as it were. = Start with a problem and see what it means in terms of decision process = as it trickles through the system. And so that leads us a bit into the = weeds, but then we=E2=80=99ll surface as people gain their footing. = What=E2=80=99s important is that people explicitly relate these = exercises to decisions we think we have to make as a group. >=20 > I think what's in scope here is structuring the RFC Editor function in = such a way that the community (broadly read) is able to come to = consensus about issues like this in a way that's accountable, = transparent, and representative, so that they can execute whatever = approach we agree to -- again, in an accountable, transparent way. You are articulating requirements for the solution here (good!): = transparency and accountability. The general thrust of your messages is = that we could do a better job with those with this role. As to the = options above, it seems to me a question as to whether the community = decides the four options, the IAB decides those options, the RSE decides = those options, or someone else like RSOC decides those options. This = group should decide who decides. Eliot From nobody Mon Apr 20 21:19:20 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2E23A07F9 for ; Mon, 20 Apr 2020 21:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0chLFcuKZEsq for ; Mon, 20 Apr 2020 21:19:14 -0700 (PDT) Received: from mr85p00im-ztdg06021801.me.com (mr85p00im-ztdg06021801.me.com [17.58.23.195]) (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 CFD7F3A07F7 for ; Mon, 20 Apr 2020 21:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1587442753; bh=oVOAEVa4M9W7kc6PeyNEDPLB1v6s7FrFWwxIQq2MsRQ=; h=From:Message-Id:Content-Type:Subject:Date:To; b=k5wiv1ibLGOfcFx+8sSVT2c4XWhN9sxi+GDo0vY5M9TrycHM5dqG0zl8Q+kTa2R8v gPsHa3S+9uoLI+NyufmyrAsZEHIlWA375y2UvYewG00vSKX9RSMqhusdEDfjMszsTR ZbU2miX6xA0K+YN+ox+m+Z1oc3OFzSw76BjDxRzjjinc4vSVlLhJ4+60a04esqMJf6 oxH3AfkiRu87DdpIhj7EhRXb6JxPTKDwE5Wp5+2fJoR1upEpgeUJKit2+LK77W5I23 Q4EkpoVbmGcXjioJ36iRdAyj4MfWxUvU793vmYOyfHklR3K/xCcfIIjcL8wXksd4IX y+ZP1xg0NgbTg== Received: from [192.168.1.2] (212.sub-174-194-198.myvzw.com [174.194.198.212]) by mr85p00im-ztdg06021801.me.com (Postfix) with ESMTPSA id 078A71806FA; Tue, 21 Apr 2020 04:19:12 +0000 (UTC) From: Greg Skinner Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1CB1309B-9C30-486E-B196-5ED997E30BCC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 20 Apr 2020 21:19:11 -0700 In-Reply-To: Cc: rfced-future@iab.org To: Brian E Carpenter References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-21_01:2020-04-20, 2020-04-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004210035 Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 21 Apr 2020 04:19:17 -0000 --Apple-Mail=_1CB1309B-9C30-486E-B196-5ED997E30BCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Comments inline > On Apr 17, 2020, at 1:55 PM, Brian E Carpenter = wrote: >=20 > On 18-Apr-20 07:02, Tim Wicinski wrote: >>=20 >>=20 >> On Fri, Apr 17, 2020 at 11:41 AM Russ Housley > wrote: >>=20 >>=20 >>=20 >> There ought to be a straightforward mechanism for the RFC Editor = to say that a document is not written well enough tor admittance to the = queue. The should shame the approving stream. Today, the RFC Editor is = reluctant to send documents back. I would like to see the stream = manager hold the authors to a higher bar. Too often I hear, "That's = okay, the RFC Editor will fix it." >>=20 >>=20 >> I've always felt that one of the jobs I have as a working group = chair/shepherd is to hand over the best possible document to the IESG = and the RFC Editor. The better the document is, the better the IESG = understands it, and the easier it is for the RFC Editor to get it = published. I would welcome feedback from the RFC editor on our WG = documents, as I think it can be done in a way to improve the quality of = our product. >>=20 >> These type of discussions on document quality, etc should be part of = the new working chair re-education orientation process.=20 >=20 > Nevertheless, there's a gap today. We have (and this is a good thing) = many authors, WG chairs and document shepherds who are not of English = mother tongue. Often they simply *cannot* detect errors in the English, = and certainly cannot fix them. Are we willing to pay to fix this earlier = in the process, rather than paying the RFC Editor to fix it after = document approval? >=20 Brian, do you (or anyone else) have any ideas why this is so? Do they = (the authors, chairs, etc.) know about the Style Guide = ? Are there other issues? > I'm trying to imagine drafting an RFC in French, a language that I can = read and speak quite well, if the IETF's publication language was = French. The result would be horrible, and my writing speed would be at = least 10 times slower. >=20 I would have problems drafting an RFC in languages that I know (less = than fluently) also. But even when writing in English, reviewing drafts = (I have never authored or co-authored one, although I have initiated two = status changes), I refer to the Style Guide and other guidelines as = needed. Perhaps it is not a bad thing if the rate of RFC publication is lower = because the quality is higher. Arguably, it could reduce the number of = editorial errata. Regards, Greg --Apple-Mail=_1CB1309B-9C30-486E-B196-5ED997E30BCC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Comments inline

On Apr 17, 2020, at 1:55 PM, = Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On = 18-Apr-20 07:02, Tim Wicinski wrote:


On Fri, Apr 17, = 2020 at 11:41 AM Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:



=    There ought to be a straightforward mechanism for the = RFC Editor to say that a document is not written well enough tor = admittance to the queue.  The should shame the approving = stream.  Today, the RFC Editor is reluctant to send documents = back.  I would like to see the stream manager hold the authors to a = higher bar.  Too often I hear, "That's okay, the RFC Editor will = fix it."


I've always felt = that one of the jobs I have as a working group chair/shepherd is to hand = over the best possible document to the IESG and the RFC Editor.  = The better the document is, the better the IESG understands it, and the = easier it is for the RFC Editor to get it published. I would welcome = feedback from the RFC editor on our WG documents, as I think it can be = done in a way to improve the quality of our product.

These type of discussions on document quality, etc should be = part of the new working chair re-education orientation = process. 

Nevertheless, = there's a gap today. We have (and this is a good thing) many authors, WG = chairs and document shepherds who are not of English mother tongue. = Often they simply *cannot* detect errors in the English, and certainly = cannot fix them. Are we willing to pay to fix this earlier in the = process, rather than paying the RFC Editor to fix it after document = approval?


Brian, do you (or anyone else) have any ideas why this = is so?  Do they (the authors, chairs, etc.) know about the Style = Guide?
Are there other issues?

I'm trying to imagine drafting an RFC in French, a language = that I can read and speak quite well, if the IETF's publication language = was French. The result would be horrible, and my writing speed would be = at least 10 times slower.


I =  would have problems drafting an RFC in languages that I know (less = than fluently) also.  But even when writing in English, reviewing = drafts (I have never authored or co-authored one, although I have = initiated two status changes), I refer to the Style Guide and other = guidelines as needed.

Perhaps it is = not a bad thing if the rate of RFC publication is lower because the = quality is higher.  Arguably, it could reduce the number of = editorial errata.

Regards, = Greg


= --Apple-Mail=_1CB1309B-9C30-486E-B196-5ED997E30BCC-- From nobody Tue Apr 21 06:00:59 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EBF3A0BB4 for ; Tue, 21 Apr 2020 06:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY55pHWSfvRF for ; Tue, 21 Apr 2020 06:00:55 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CAB3A0BB2 for ; Tue, 21 Apr 2020 06:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5025; q=dns/txt; s=iport; t=1587474055; x=1588683655; h=from:mime-version:subject:message-id:date:to; bh=oPTgoqOl1lJKFH+qztHrgMbZhZGtvfuPEcTxztnIvfU=; b=hrclrklH9GN3fZ3x6lv28vB+tRpPRpDJzfP93ggWw2lwa6snqpmNszIP iUpyQ2XtIrY+sctP2pxLEf99G9ZLUK61cHn642KmEZOM0RyS7ARa/wUZI JzgMGPrrdm8m6VYWJNdMHaAP4ygwburzF43qoB6vrBhsqTlSXNoBs+RRk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxBgCs7Z5e/xbLJq1mHgELHIMgAYF?= =?us-ascii?q?wVSASKoQeiQKbVYgKCgEBAQwBAR4RBAEBhwA4EwIDAQELAQEFAQEBAgEFBG2?= =?us-ascii?q?FVgyGG08mPgKEGAGCfA+iFY4RdYEyhFAYZ4UXBoE4jFOCAIE4HIVyAgKCMIJ?= =?us-ascii?q?FMoItBLIIgk4EgmaFIY9nHYJWjRwnjESZM49vg0ACBAYFAhWBaSKBQwwHMxo?= =?us-ascii?q?IGxVlAYI/PRIYDZFkF4NQilg/AzCPRwEB?= X-IronPort-AV: E=Sophos; i="5.72,410,1580774400"; d="scan'208,217"; a="25455929" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2020 13:00:53 +0000 Received: from [10.61.222.215] ([10.61.222.215]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03LD0pSE029621 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 21 Apr 2020 13:00:52 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_87DE70C6-05BD-481C-973E-63832AD50176" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Tue, 21 Apr 2020 15:00:51 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.222.215, [10.61.222.215] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Trying to summarize what I've heard in pithy little bullet points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 21 Apr 2020 13:00:57 -0000 --Apple-Mail=_87DE70C6-05BD-481C-973E-63832AD50176 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Based on what I=E2=80=99ve read, I want to try to summarize some of the = questions in various categories. These categories could be All Wrong. = You can if you like summarize and present your own views. In fact, I = would love if others did this too... The role(s) Sets strategy? Having an understanding of archival tools is important for the role What technical capabilities should the RFC Editor be expected to have Responsibility for the RPC and its budget? Authority to impose minimum standards for editing of docs Tooling responsibility? Responsibility to set publishing standards? Compliance with publication standards? = Relationships and lines of responsibility, and transparency = What we want from the series Record agreements? Timely publication? Copy editing can slow that process? Role should fit existing organizational structure? Bespoke tooling is a bug not a feature? Should we worry about legacy? What happens to the series if the IETF disappears? What happens to the IETF if the series disappears? Ease of navigation? I=E2=80=99ve attempted to keep these pretty high level. Every single = point ends in a ?. We do not have to solve for all of these issues. Eliot= --Apple-Mail=_87DE70C6-05BD-481C-973E-63832AD50176 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Based on what I=E2=80=99ve read, I want to try to = summarize some of the questions in various categories. =  These categories could be All Wrong.  You can if you = like summarize and present your own views.  In fact, I would love = if others did this too...

The role(s)

  • Sets strategy?
  • Having an understanding of archival tools is important = for the role
  • What technical capabilities should the RFC Editor be = expected to have
  • Responsibility for the RPC and its budget?
  • Authority to impose minimum standards for editing of = docs
  • Tooling responsibility?
  • Responsibility to set publishing standards?
  • Compliance with publication standards?

Relationships and lines of responsibility, and = transparency

What we want from the series

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

I=E2=80=99ve attempted to keep these = pretty high level.  Every single point ends in a ?.  We do not = have to solve for all of these issues.

Eliot
= --Apple-Mail=_87DE70C6-05BD-481C-973E-63832AD50176-- From nobody Tue Apr 21 09:14:36 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1F23A0E27 for ; Tue, 21 Apr 2020 09:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 EJni4qQp7njT for ; Tue, 21 Apr 2020 09:14:24 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0283A0DF2 for ; Tue, 21 Apr 2020 09:14:21 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id o19so15091511qkk.5 for ; Tue, 21 Apr 2020 09:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=D8ytDfB4sIULW1EBfX/COjuNGNO6OrIRPbQReQj0k5A=; b=1Qr4W7XJ7bez6QSg5X0Yo1neOrMn/wZ+2CPwizup06FWZVRnu2d4rshoKR9IXMN+2Y HdEcVDZgwFiRuxl5kn8NbSA+TNtdlU1e1CEJU8w8IXKy5sxnT3Fr9vmMJOl0JwRbDvV6 iqiASctn40KfHuADb57I7WkfQNVaVU5du9PYZKh+BW6Kbl8TM0TlROxx9em6hfboZnhM x9Jv5SaO+RPV28XDo6Uw0dr1ql/joBx85RQo82Y9Bif5CGFf08gtXDO9juHass0IuF+p gKZHZ33OD1cg0HDRWU71jIk3lLdJU5kxOZBFNntVVRQWWNfZATUxxzeD1MMnkt9UiZMg cwwA== 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=D8ytDfB4sIULW1EBfX/COjuNGNO6OrIRPbQReQj0k5A=; b=WY1UQjr61R5MmXy8/xCUb33/zFIIXXlmmj2Pq7WCkDMHhAltRtrapaoBSOdarxoElj oNY4blVDYka6iVNCFyE77o385tMrD9hSygf0xRqab9zFvB66Lu9obTbep4BRSp0NDWNb MfioTpCZIurrfbdwlTjReqoYH8myvP7+E/Bg7Xj1tcM4DNRARgp9cTXkb8qhsBnItlBg ofhxYcPOf1MnGVUwo36VYW+q0AVJGw6oZ+KQyhixoMtmkIrEtYnulEUtmOBSiacZ3z3z 7gvx+YMWOfDb5Cvm6QgMWQr1JzvUaWleAv61u1p63LdML2iJlbKeENY2cY9wKXKg9BxO h87w== X-Gm-Message-State: AGi0PuaSMbYMQx5Ee+ZhWNpwHeiqixRxSU3lBZ7HJcLa0oq9fq83eQBG uSBnKdsyZxqNHzgZtd6Ts2C93hxLEgSrjA== X-Google-Smtp-Source: APiQypJPIeFYTNByOO4UyIyPRimvTZEGSFp/i0KUHXmJa29oZQeaXeMMB+wwJm0Q57QhOhBl+ywovA== X-Received: by 2002:a37:9dd6:: with SMTP id g205mr23105513qke.9.1587485659001; Tue, 21 Apr 2020 09:14:19 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id x5sm1979823qtm.81.2020.04.21.09.14.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Apr 2020 09:14:17 -0700 (PDT) To: rfced-future@iab.org References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> From: Michael StJohns Message-ID: <714fb262-381a-9525-492d-1b872e73bcab@nthpermutation.com> Date: Tue, 21 Apr 2020 12:14:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------77C3B44DE0DE6CD3ECC3D235" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 21 Apr 2020 16:14:34 -0000 This is a multi-part message in MIME format. --------------77C3B44DE0DE6CD3ECC3D235 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 4/21/2020 12:19 AM, Greg Skinner wrote: >> >> Nevertheless, there's a gap today. We have (and this is a good thing) >> many authors, WG chairs and document shepherds who are not of English >> mother tongue. Often they simply *cannot* detect errors in the >> English, and certainly cannot fix them. Are we willing to pay to fix >> this earlier in the process, rather than paying the RFC Editor to fix >> it after document approval? >> > > Brian, do you (or anyone else) have any ideas why this is so? Do they > (the authors, chairs, etc.) know about the Style Guide > ? > Are there other issues? > Greg - Brian, I think, was referring to English fluency: https://en.wikipedia.org/wiki/ILR_scale. Nothing to do with the IETF, everything to do with their knowledge and experience in English. My personal experience is that non-native speakers in the IETF range from a mid-range L2 all the way up to L5 with many sitting somewhere in the L3 range. A few decades back I was asked to review/edit an internet text book written by a non-native speaker and I stopped after about 4 chapters because the sentence structure was so jarring. I passed the book back to the author with a recommendation that it be handed to a professional editor who worked with non-native speakers for a pass to clean up the basics. The structure was problematic enough that simple technical points were getting lost. In any event, I'm impressed with anyone who actually learns another language even at the lowest levels. It's something I've never had the aptitude for. Mike --------------77C3B44DE0DE6CD3ECC3D235 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/21/2020 12:19 AM, Greg Skinner wrote:

Nevertheless, there's a gap today. We have (and this is a good thing) many authors, WG chairs and document shepherds who are not of English mother tongue. Often they simply *cannot* detect errors in the English, and certainly cannot fix them. Are we willing to pay to fix this earlier in the process, rather than paying the RFC Editor to fix it after document approval?


Brian, do you (or anyone else) have any ideas why this is so? Do they (the authors, chairs, etc.) know about theStyle Guide?
Are there other issues?

Greg - Brian, I think, was referring to English fluency: https://en.wikipedia.org/wiki/ILR_scale. Nothing to do with the IETF, everything to do with their knowledge and experience in English. My personal experience is that non-native speakers in the IETF range from a mid-range L2 all the way up to L5 with many sitting somewhere in the L3 range.

A few decades back I was asked to review/edit an internet text book written by a non-native speaker and I stopped after about 4 chapters because the sentence structure was so jarring. I passed the book back to the author with a recommendation that it be handed to a professional editor who worked with non-native speakers for a pass to clean up the basics. The structure was problematic enough that simple technical points were getting lost.

In any event, I'm impressed with anyone who actually learns another language even at the lowest levels. It's something I've never had the aptitude for.

Mike

--------------77C3B44DE0DE6CD3ECC3D235-- From nobody Tue Apr 21 13:59:19 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12A33A0A67 for ; Tue, 21 Apr 2020 13:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTk-_k5Jg1Ai for ; Tue, 21 Apr 2020 13:59:16 -0700 (PDT) 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 EBED13A0A5F for ; Tue, 21 Apr 2020 13:59:15 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id d24so5727048pll.8 for ; Tue, 21 Apr 2020 13:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YHDpuSq96HMwmngEtn3obzI3srcUKnoZ4IfWdVe2tVc=; b=holYWUTA1jXpLm1zREEVrsOcOy/knTxpD1LMr0V4sIWjFzIVrbdRIOBTzNan89YgEc 3Uwggog39xF2MI2YJrTFiXfnSY+prlzw5Kwwf+YUba3S3LmM1k+9UU4YdhssX0V2AgbY SOwB1iPulWssfpxHnncXAq1ktTr7xJFnoJPisoExGWDMx/BQwNeOvVNzgEEhLEvXdlZa hth3UiGyu3t/lhLxDMOvITUpNhAOUxijwHyFo52yhQ6Vha8g4n/rrqJesM5nkl+UDUI8 jHhsItvgS3OlyySrOo2zFQlCWDGhybXSElWbpYoMs6yWJCblHX4OE9jZQXnsNekoLcY3 NBaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YHDpuSq96HMwmngEtn3obzI3srcUKnoZ4IfWdVe2tVc=; b=f2SsOS9ty56TNIP+5yfBYXk3bNIF1MwdJYn8n4TgDFJpx6f6oxBA/Lh1QMGZUibGZE 6l/Q+odH3IU5+R1XArxPpwI6ppEFDLQpKt9zA6TcDYk0BL2C34i0md8OsjYgqk+O0jBr oIFU5XII5PzU24yWW2pBeTAFA2PQhdbZ6ka+c5cFro4iQp/zvXOMqKx72kE/ADjmxczk M7eWkgjb/C2GtNtzqm7eg+yHrVe+EW/BEk8dZfgpsHXplvZLD0qjjJ2JSP9IVvFSVsLv BP3UYx/qDYJRZ2A8iCTlCj5QhWQU7l/E6qjKaoezi1IiXW5ycgbFh4jb/KidppESQrMk eCpQ== X-Gm-Message-State: AGi0PubERIMkz+n43eCKSJlyrGgEeblofVGN/moY7V6YnRzWF40CcdSI KV8fo5PcFswzYcfauCrvy9o= X-Google-Smtp-Source: APiQypJec7wynq6HmIWivJMdH3VES2zayULBvpUNLd9D6JdH93n9h/8LYZwODPGtli4vwA1qC2/jdg== X-Received: by 2002:a17:902:ab90:: with SMTP id f16mr22777716plr.291.1587502755291; Tue, 21 Apr 2020 13:59:15 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id 135sm3280642pfx.58.2020.04.21.13.59.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 13:59:14 -0700 (PDT) To: rfced-future@iab.org References: <9AE84DE3-EA28-4ACC-908F-4DA3B5154ABA@cisco.com> <9692FDB2-DDF9-4461-861F-D212BDDD8425@mnot.net> <76E899EB-7677-4495-959F-67AE3A06C7C4@vigilsec.com> <714fb262-381a-9525-492d-1b872e73bcab@nthpermutation.com> From: Brian E Carpenter Cc: Greg Skinner Message-ID: Date: Wed, 22 Apr 2020 08:59:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <714fb262-381a-9525-492d-1b872e73bcab@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Work plan and next steps for this group X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 21 Apr 2020 20:59:18 -0000 On 22-Apr-20 04:14, Michael StJohns wrote: > On 4/21/2020 12:19 AM, Greg Skinner wrote: >>> >>> Nevertheless, there's a gap today. We have (and this is a good thing)= many authors, WG chairs and document shepherds who are not of English mo= ther tongue. Often they simply *cannot* detect errors in the English, and= certainly cannot fix them. Are we willing to pay to fix this earlier in = the process, rather than paying the RFC Editor to fix it after document a= pproval? >>> >> >> Brian, do you (or anyone else) have any ideas why this is so? =C2=A0Do= they (the authors, chairs, etc.) know about the=C2=A0Style Guide ? >> Are there other issues? >> > Greg - Brian, I think,=C2=A0 was referring to English fluency:=C2=A0 ht= tps://en.wikipedia.org/wiki/ILR_scale.=C2=A0=C2=A0=C2=A0 Nothing to do wi= th the IETF, everything to do with their knowledge and experience in Engl= ish.=C2=A0 My personal experience is that non-native speakers in the IETF= range from a mid-range L2 all the way up to L5 with many sitting somewhe= re in the L3 range. Correct. I don't want to name and shame anybody, so no examples, but when= you see a draft in which almost every sentence has incorrect or simply u= gly syntax - misuse of words, wrong word order, errors of tense, case, nu= mber, even gender, etc. - that should (IMHO) never get near WG LC, let al= one the RFC queue, until it has been fixed. Why? Because such errors can = and do create technical misunderstandings. Therefore, declaring a consens= us on the text is risky. There is also the opposite problem: fluent English writers using complex = or subtle syntax that confuses non-native English readers. That is very h= ard to detect, especially in one's own writing. I think my paragraph abov= e is an example. My own rule, when I remember to apply it, is this: if somebody misunderst= ands what I write, that is *my* fault, not theirs. I should correct my wr= iting, not their reading. Brian >=20 > A few decades back I was asked to review/edit an internet text book wri= tten by a non-native speaker and I stopped after about 4 chapters because= the sentence structure was so jarring.=C2=A0 I passed the book back to t= he author with a recommendation that it be handed to a professional edito= r who worked with non-native speakers for a pass to clean up the basics.=C2= =A0=C2=A0=C2=A0 The structure was problematic enough that simple technica= l points were getting lost.=C2=A0 >=20 > In any event, I'm impressed with anyone who actually learns another lan= guage even at the lowest levels.=C2=A0 It's something I've never had the = aptitude for. >=20 > Mike >=20 >=20 From nobody Wed Apr 22 12:36:54 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA143A0414 for ; Wed, 22 Apr 2020 12:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Vlb1PoZ4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VrvjZqCk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diOUuk-701yZ for ; Wed, 22 Apr 2020 12:36:50 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24ED13A0408 for ; Wed, 22 Apr 2020 12:36:50 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A1B525C0080; Wed, 22 Apr 2020 15:36:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 22 Apr 2020 15:36:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=fm2; bh=kN3QpSX+uEs7nfg5M/vaALE3DPccaVuUq 03RwGxZsUs=; b=Vlb1PoZ4Z2HnweUTVyiJOkjQSJG7EFQMbmae7RCHkynb5GuWx J1wG5jSLGvjohSKjp6cbxWYNSdpsQqflnawRWLt8IUNOA5yPUDVQwqStVQrhe6tV xZTTXZDTm17Kr7+3v3wXGfG1GqPMR+J3XwcqY+S7ZdHAdPBkK0Y+jz2VFusD+Egm MURlhCF/vwvNxanHhr5l/iR0EzJ62eRvS634cDhTddyhKYWFf5QWbyzDUBGwa/T8 ibpdiIOxbEcbGEEAt9Jc1AqkNEnEgBjq6vEuQIo4DMStgEYj1PrFMgjIdJBih3rM UZ+PwKnYD3ToPIYnKj/MC61u3ItZfWgyE3+oA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=kN3QpS X+uEs7nfg5M/vaALE3DPccaVuUq03RwGxZsUs=; b=VrvjZqCkjMffdN88yinRbP c8rUbRFulDbbCWQXTsdr9xRQtpctr6o3vP/bsAQvdWmODGycBJdJPV6HsaYxWS5R PUCjIS/mciCF942s8JX/i6lVar9mPhB+DPZNkmHoBTw6IjIySjIu1kxKw8xFwaES xemOF76WkjxEX2I23hhiESrV8sSsXvWvbUEVEJ1ltwq0dZjeCuLec6KKVEuHTysA pCiIyQuK5TSH5QgQC8BHTys7PRHwt2990ypbGUNyseuxqUq+KCCBlMOLeXd6tMLh XvRwX6gXSvVzAewU6jRbInmJYlT9jG05uD7bUbDX1mxRvJhvh23EWNDTd02Mcalw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtjeenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepudejfe drfeekrdduudejrdejkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id F3D21328005D; Wed, 22 Apr 2020 15:36:47 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Message-Id: <869ED7EA-85D0-4C25-9B6C-74D2F8D1501C@cooperw.in> Date: Wed, 22 Apr 2020 15:36:46 -0400 To: "Eliot Lear (elear)" , rfced-future@iab.org X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: [Rfced-future] A few thoughts on problem definition X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 22 Apr 2020 19:36:53 -0000 Hi Eliot, all, I have a few thoughts to offer below about problems to be solved. In = general I do not plan to engage much in this program but figured I would = throw these out there during the problem definition phase in case they = resonate with anyone else who does plan to engage more. There has been mention of the absence of both a strategy for the RFC = series and a process to create one. Together with that, but worthy of = its own emphasis I think, is the absence of a process for determining = how well the series is meeting its objectives and serving the wide = variety of audiences it is intended to serve. There are so many = different communities that make use of RFCs =E2=80=94 implementers, = operators, architects, researchers, students, product managers, = procurement officers, regulators, other SDOs, etc. As far as I=E2=80=99m = aware there is no body of knowledge about how these audiences use RFCs = and no established and rigorous method for understanding the role of = RFCs in the world. This makes it difficult to make informed decisions = about the future of the series and to measure the impact of changes to = it. Having a wholistic picture isn=E2=80=99t impossible but we don=E2=80=99= t have it now. Given that lack of information, my next point is admittedly based on = intuition: it seems like it should be much easier to understand the = contours of the series as a reader than it is today. For example, the 3D = matrix of streams, maturity levels, and routes to publication yields = numerous combinations where the subleties matter but are likely lost on = anyone who hasn=E2=80=99t been an active IETF participant for a very = long time. The fact that RFCs are (quasi-)officially hosted in at least = three places on the web and the path for someone to discover the = document they=E2=80=99re looking for could land them in any of these = places (without any data collection on the RSE/IETF side to really know) = means that different readers of the same document have different user = experiences and access to different representations of document = metadata. There is no coherent, consistent, and readily available = experience to help readers understand the context and process that = produced a given RFC they may be reading. The series also lacks a sound technology change management process. We = are into the seventh year of the transition from format v2 to v3, I = believe. Some of that time was spent on IETF-style consensus processes, = and we all know those are not time-bound, and some of that time was = spent on other things. For decisions that are essentially choices about = what technology RFC readers and writers will use, though, using a change = process that is unbounded in time doesn=E2=80=99t make a lot of sense, = because the pace of technological change is rapid. Technology choices = made three or five or seven years ago could be out-of-date before they = even get implemented. Somehow, there needs to be a way to be able to = manage change in the underlying technologies that are used to produce = and consume RFCs that combines solicitation of input from interested = parties with the ability to evolve in time frames consistent with = technological change. These three problems come to mind in part because they speak to some = competencies that would be good to have at hand if attempts were to be = made at solving them: market research, communications, data analysis, = user experience/design, program management. They also demonstrate the = extent to which the management of the RFC series straddles basically = every function that already exists to support the IETF itself: community = consensus processes, tools, IT, admin, communications, finance. It = creates a challenging situation to have a function that is operationally = deeply intertwined with all of these other functions, but conceptually = meant to exist basically independent from them. =20 Alissa From nobody Wed Apr 22 15:43:10 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E943A0CD5 for ; Wed, 22 Apr 2020 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hsijD6_HKye for ; Wed, 22 Apr 2020 15:42:59 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8943A0C6C for ; Wed, 22 Apr 2020 15:42:59 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id x15so1906719pfa.1 for ; Wed, 22 Apr 2020 15:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=ZrOA3m39rr11X1MhFGUwdj8OpFIAOxb9zjE4njYGClU=; b=lpBLBvWIv7cGWh56aikH4JeKNgJ9M597+YtGIPbu4W9JL26QtrFlxn1XGccOfHpeQW I+xXg7txdBRD7fLEv3e8ctWSpNAJvBj6lUE62ig3/A+KK414e+94pIQ1urw+RCcaX6kj +lXnv7QoNm802KuT3gonoxTiw05H8gytrqaih8+1VytYUVUJvr31rKBI9cARAhedXbig q1SYSqJa7qh1vYUTkWj6MZt6TRCNxNW/AfhijWCDh6LIcOurA9iPXnaExyXfEFRwh/RH 90LpQpuaIVKKqdAHekD5VdjeyelwxEzZgkgUgpRDHSkw2/H3jjpgHlyH4HUWBkLQHLfF kbgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=ZrOA3m39rr11X1MhFGUwdj8OpFIAOxb9zjE4njYGClU=; b=fLIP9Oan9T1gfVV5N8dwZuMu4SRaHKStQ4UoT7SKL2WOqrtJCXJPRt+ZDC1K/82Zcp 3z8dQRbtzeQ7D8AKOJw7dAxzJilMflFc3xmeX8jx1m+53IXNkpgRyqEtCXEK3SPfmrju kxRY51N+4bTzbkBkJjI+vKSkAH+sD7jSMkCCUk189lAoggvbzLaPSMHzdThd8n8sBf73 2KDbvpmai6WiVZOJXx5k6V0nU1LfZNU0BBNzgtSMUZVrOrwI5gtX2bpOCvDE0v8KkjX2 JNkddcD8B2tZX21lVt8C/xiAqtUmHKpW92+aYgGe1y4ptT79I3GFFROGQFsK3NYLnzZu RbCw== X-Gm-Message-State: AGi0PuZIu8So2y67Enghg4i1BkwZdPYyZzlqSRcP+H0pWif/NE7Xkv3v jXWkRZQkXTmmQWzaT7arEMo= X-Google-Smtp-Source: APiQypI/MvHvkP7p02k7NBMabasnTAdvcBHM5Cj2Bz6nPwdUplzWz/3LXmSJp4pW+A9xx62/P1V+ig== X-Received: by 2002:aa7:9491:: with SMTP id z17mr799175pfk.264.1587595378491; Wed, 22 Apr 2020 15:42:58 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id b1sm512794pfa.202.2020.04.22.15.42.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2020 15:42:57 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Alissa Cooper'" , "'Eliot Lear \(elear\)'" , References: <869ED7EA-85D0-4C25-9B6C-74D2F8D1501C@cooperw.in> In-Reply-To: <869ED7EA-85D0-4C25-9B6C-74D2F8D1501C@cooperw.in> Date: Wed, 22 Apr 2020 15:42:57 -0700 Message-ID: <01b501d618f7$5f17c3b0$1d474b10$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHWDs2muwkQ7AX5FaG3gLsOCjap9qiFv4PQ Archived-At: Subject: Re: [Rfced-future] A few thoughts on problem definition X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 22 Apr 2020 22:43:08 -0000 > ... There are so many different communities = that make > use of RFCs =E2=80=94 implementers, operators, architects, = researchers, students, > product managers, procurement officers, regulators, other SDOs, etc. = As far > as I=E2=80=99m aware there is no body of knowledge about how these = audiences use > RFCs and no established and rigorous method for understanding the role = of > RFCs in the world.=20 But there IS a body of knowledge about standards in general and technical specifications and their quality and utility. There are courses on it. Books about it. Courses on standards in engineering curricula. Papers about it* While there might be some reasons why IETF processes are different from those of other SDOs, the RFC series has to exist in the context of an evolving non-RFC environment. -- * = https://docs.google.com/document/d/1aEaOvS3rKret7IwyYeawL8rCby8b7erNEZTYX= clDBbU/edit?usp=3Dsharing=20 https://LarryMasinter.net https://going-remote.info=20 From nobody Thu Apr 23 00:49:13 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F9B3A166D for ; Thu, 23 Apr 2020 00:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 ALVX-6PDWdGP for ; Thu, 23 Apr 2020 00:49:09 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FF13A166C for ; Thu, 23 Apr 2020 00:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4350; q=dns/txt; s=iport; t=1587628149; x=1588837749; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dKZwkwaPgL74epB/x/oYb5wumFCfGaZ/xX9TAj82WJM=; b=X3iYchALjvIR0ZF+f9/s/abvHxtcYRClK/aV1/U8wF+K3uuxzO8m2fbX GuyDmcbSZgE9wrGarPvdaI1QOotWzjAqz61RofvGurrHDX8tneloTrjgL Lu0NzKNH3ZORjnP75US/8jUicImL6BTkfmDdAlqqdrX/s3uurV/tDaiBs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKBAACSKFe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBeIEeVSASKoQeiQKHciWbVQoBAQEMAQElCgQBAYREAoJCOBM?= =?us-ascii?q?CAwEBCwEBBQEBAQIBBQRthVYMhXEBAQEBAgEjVgULCxgCAiYCAlcGExSDEgG?= =?us-ascii?q?CXCAPr3B1gTKFT4NngToGgQ4qjFOBQT+BOAwQgh0wPoJnAoFlgxIygi0Ejl2?= =?us-ascii?q?JCZkwfIJOiAuPaB2PdIxtmTOPc4NCAgQGBQIVgWkigVYzGggbFWUBgj4+Ehg?= =?us-ascii?q?NmSOKWD8DMI9vAQE?= X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="25574524" 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 Apr 2020 07:49:06 +0000 Received: from [10.61.218.10] ([10.61.218.10]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03N7n6XL025557 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Apr 2020 07:49:06 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <869ED7EA-85D0-4C25-9B6C-74D2F8D1501C@cooperw.in> Date: Thu, 23 Apr 2020 09:49:05 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <99EB9D58-4475-4412-8731-F9700FAB453B@cisco.com> References: <869ED7EA-85D0-4C25-9B6C-74D2F8D1501C@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.218.10, [10.61.218.10] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] A few thoughts on problem definition X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 23 Apr 2020 07:49:11 -0000 Alissa, Thank you for these comments. I have adjusted the summary I am keeping = on GitHub at = https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandP= ointsMade.md accordingly. Eliot > On 22 Apr 2020, at 21:36, Alissa Cooper wrote: >=20 > Hi Eliot, all, >=20 > I have a few thoughts to offer below about problems to be solved. In = general I do not plan to engage much in this program but figured I would = throw these out there during the problem definition phase in case they = resonate with anyone else who does plan to engage more. >=20 > There has been mention of the absence of both a strategy for the RFC = series and a process to create one. Together with that, but worthy of = its own emphasis I think, is the absence of a process for determining = how well the series is meeting its objectives and serving the wide = variety of audiences it is intended to serve. There are so many = different communities that make use of RFCs =E2=80=94 implementers, = operators, architects, researchers, students, product managers, = procurement officers, regulators, other SDOs, etc. As far as I=E2=80=99m = aware there is no body of knowledge about how these audiences use RFCs = and no established and rigorous method for understanding the role of = RFCs in the world. This makes it difficult to make informed decisions = about the future of the series and to measure the impact of changes to = it. Having a wholistic picture isn=E2=80=99t impossible but we don=E2=80=99= t have it now. >=20 > Given that lack of information, my next point is admittedly based on = intuition: it seems like it should be much easier to understand the = contours of the series as a reader than it is today. For example, the 3D = matrix of streams, maturity levels, and routes to publication yields = numerous combinations where the subleties matter but are likely lost on = anyone who hasn=E2=80=99t been an active IETF participant for a very = long time. The fact that RFCs are (quasi-)officially hosted in at least = three places on the web and the path for someone to discover the = document they=E2=80=99re looking for could land them in any of these = places (without any data collection on the RSE/IETF side to really know) = means that different readers of the same document have different user = experiences and access to different representations of document = metadata. There is no coherent, consistent, and readily available = experience to help readers understand the context and process that = produced a given RFC they may be reading. >=20 > The series also lacks a sound technology change management process. We = are into the seventh year of the transition from format v2 to v3, I = believe. Some of that time was spent on IETF-style consensus processes, = and we all know those are not time-bound, and some of that time was = spent on other things. For decisions that are essentially choices about = what technology RFC readers and writers will use, though, using a change = process that is unbounded in time doesn=E2=80=99t make a lot of sense, = because the pace of technological change is rapid. Technology choices = made three or five or seven years ago could be out-of-date before they = even get implemented. Somehow, there needs to be a way to be able to = manage change in the underlying technologies that are used to produce = and consume RFCs that combines solicitation of input from interested = parties with the ability to evolve in time frames consistent with = technological change. >=20 > These three problems come to mind in part because they speak to some = competencies that would be good to have at hand if attempts were to be = made at solving them: market research, communications, data analysis, = user experience/design, program management. They also demonstrate the = extent to which the management of the RFC series straddles basically = every function that already exists to support the IETF itself: community = consensus processes, tools, IT, admin, communications, finance. It = creates a challenging situation to have a function that is operationally = deeply intertwined with all of these other functions, but conceptually = meant to exist basically independent from them. =20 >=20 > Alissa >=20 >=20 From nobody Thu Apr 23 16:37:07 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BFF3A0A40 for ; Thu, 23 Apr 2020 16:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UtlM8HCqiKL for ; Thu, 23 Apr 2020 16:37:04 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364FF3A0A3E for ; Thu, 23 Apr 2020 16:37:04 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id r4so3708701pgg.4 for ; Thu, 23 Apr 2020 16:37:04 -0700 (PDT) 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=IiOPK0Xd0JIk86Wc6nJLJv+pffqvSacE3BGy6NcbORA=; b=d87Hf3E4mndTBidVAjWW7XEBleR+YhDkYOxbt2Kbcq9E04WBRpCMHKaWQ+Ol8JVqbU hk3y6pRSnI4Fdm9NMRihlXf8SvvSHntqJlGp+vT2CtkMzcsfy3fnrPmNr0D8Ef7ETnw6 35W8HAEySprO3TZSGvdcTyPODvJA9McrEAZO50A9fBWcDjUi4bII3nWKf86+l675TKpI q0ajfSpge9mqRJORgcRTMea/O/YsusyMpa3nRUose50rRriIrlVYT6EV95C7sq25t9be mfV5wCWoKHkl+NvgC6v+suoDGD1ADOq90wC4xMoEJD30mOMfbo05sQrE5a+CyPRm2jwc PoZg== 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=IiOPK0Xd0JIk86Wc6nJLJv+pffqvSacE3BGy6NcbORA=; b=QAewTlADMe9wnitLpNJNTc7Z2KsQvc1Qn6BOhHePTNyRoL+VY8YlWtCFi3cdiiukNs ANIpannrrgYBy4I4YgApf0Z+G1aTpy29O3HzMRKADzS4aVyDQFQ5VmM2006a+8f9muqf F7TaaLklAUwEoq0OIDzgwfTQuoazK/ni44LtrLONS7CYwVQsWIF+spMxicJcun3mPFxV TMhwrt+zuoaj4yyhNUjr732u5p25wdb6HWM/xhum9ukQ8t2LPGqDhJQbXPI8laRoXmTw 7MMH4ItAtEfcviyAtuzAzjYU0H81JDs60p+K0FgXKahexcR06hRemD5x/dsGSmZDdCUn UxBQ== X-Gm-Message-State: AGi0PuataeT5s5H5Qsplve1GSSI1FitPE0SswD6F/RvH1rf7pKhg9GMt 7I877XxIMA3OVoXWoJ6op1UBmKJn5t0= X-Google-Smtp-Source: APiQypLDBIbpBhWBG6X3q647IsvCGkr/UloytuLtQ86PxJnt5WYZbJ80vnqGKWoK/o6vatNOIR8How== X-Received: by 2002:a63:d806:: with SMTP id b6mr6064740pgh.72.1587685023151; Thu, 23 Apr 2020 16:37:03 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id h31sm3474814pjb.33.2020.04.23.16.37.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2020 16:37:02 -0700 (PDT) To: Eliot Lear , Alissa Cooper Cc: rfced-future@iab.org References: <869ED7EA-85D0-4C25-9B6C-74D2F8D1501C@cooperw.in> <99EB9D58-4475-4412-8731-F9700FAB453B@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <44b16ed1-badf-80a7-88ca-0a900254986d@gmail.com> Date: Fri, 24 Apr 2020 11:36:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <99EB9D58-4475-4412-8731-F9700FAB453B@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] A few thoughts on problem definition X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 23 Apr 2020 23:37:06 -0000 Thanks for the summary record, Eliot. It's useful. I do want to comment o= n one item: > Focus on the role; Don't focus on what we want the series to be - a gre= at many people Certainly the RSE role is the immediate problem. But as I said earlier, t= he lack of an agreed high level charter/mission/strategy for the RFC seri= es actively hampers us in defining the role. It's as if the job ad said "= Wanted: a senior, experienced person to run an operation whose mission is= to do the right thing." I exaggerate to make my point, but there is a re= al gap here (and not a new one). Regards Brian On 23-Apr-20 19:49, Eliot Lear wrote: > Alissa, >=20 > Thank you for these comments. I have adjusted the summary I am keeping= on GitHub at https://github.com/intarchboard/rfced-future/blob/master/Po= ssibleGoalsandPointsMade.md accordingly. >=20 > Eliot >=20 >> On 22 Apr 2020, at 21:36, Alissa Cooper wrote: >> >> Hi Eliot, all, >> >> I have a few thoughts to offer below about problems to be solved. In g= eneral I do not plan to engage much in this program but figured I would t= hrow these out there during the problem definition phase in case they res= onate with anyone else who does plan to engage more. >> >> There has been mention of the absence of both a strategy for the RFC s= eries and a process to create one. Together with that, but worthy of its = own emphasis I think, is the absence of a process for determining how wel= l the series is meeting its objectives and serving the wide variety of au= diences it is intended to serve. There are so many different communities = that make use of RFCs =E2=80=94 implementers, operators, architects, rese= archers, students, product managers, procurement officers, regulators, ot= her SDOs, etc. As far as I=E2=80=99m aware there is no body of knowledge = about how these audiences use RFCs and no established and rigorous method= for understanding the role of RFCs in the world. This makes it difficult= to make informed decisions about the future of the series and to measure= the impact of changes to it. Having a wholistic picture isn=E2=80=99t im= possible but we don=E2=80=99t have it now. >> >> Given that lack of information, my next point is admittedly based on i= ntuition: it seems like it should be much easier to understand the contou= rs of the series as a reader than it is today. For example, the 3D matrix= of streams, maturity levels, and routes to publication yields numerous c= ombinations where the subleties matter but are likely lost on anyone who = hasn=E2=80=99t been an active IETF participant for a very long time. The = fact that RFCs are (quasi-)officially hosted in at least three places on = the web and the path for someone to discover the document they=E2=80=99re= looking for could land them in any of these places (without any data col= lection on the RSE/IETF side to really know) means that different readers= of the same document have different user experiences and access to diffe= rent representations of document metadata. There is no coherent, consiste= nt, and readily available experience to help readers understand the conte= xt and process that produced a given RFC they may be reading. >> >> The series also lacks a sound technology change management process. We= are into the seventh year of the transition from format v2 to v3, I beli= eve. Some of that time was spent on IETF-style consensus processes, and w= e all know those are not time-bound, and some of that time was spent on o= ther things. For decisions that are essentially choices about what techno= logy RFC readers and writers will use, though, using a change process tha= t is unbounded in time doesn=E2=80=99t make a lot of sense, because the p= ace of technological change is rapid. Technology choices made three or fi= ve or seven years ago could be out-of-date before they even get implement= ed. Somehow, there needs to be a way to be able to manage change in the u= nderlying technologies that are used to produce and consume RFCs that com= bines solicitation of input from interested parties with the ability to e= volve in time frames consistent with technological change. >> >> These three problems come to mind in part because they speak to some c= ompetencies that would be good to have at hand if attempts were to be mad= e at solving them: market research, communications, data analysis, user e= xperience/design, program management. They also demonstrate the extent to= which the management of the RFC series straddles basically every functio= n that already exists to support the IETF itself: community consensus pro= cesses, tools, IT, admin, communications, finance. It creates a challengi= ng situation to have a function that is operationally deeply intertwined = with all of these other functions, but conceptually meant to exist basica= lly independent from them. =20 >> >> Alissa >> >> >=20 From nobody Thu Apr 23 23:05:04 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF69C3A0CA4 for ; Thu, 23 Apr 2020 23:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-ru1sF4rWMF for ; Thu, 23 Apr 2020 23:04:58 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595013A0CA6 for ; Thu, 23 Apr 2020 23:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3359; q=dns/txt; s=iport; t=1587708298; x=1588917898; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=42L0RDmcy6//eObchbNQwrkRO09P00vEE39oFY5d5hk=; b=ieUWNVHgFbkleU37mtL/KKstckbbdwadcX2UHz+DLCEPTmlpxl3XIspc 0hcffJxA/RIC7lyEswScehlYG/9ywgqVxgAYcBsFMIIsSMRC6ZXkFlGfr zTOhO04ngZt0aE51HNA+ejFRzMi9XQFOJBgHSZUhWYVqeubOgi+aI2i0D A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAADEgKJe/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBZwYBAQELAYF8LYFBIBIqhB+IImCHcSWJdYlYhhGBewo?= =?us-ascii?q?BAQEMAQEvBAEBhEQCgko0CQ4CAwEBCwEBBQEBAQIBBQRthSoGMoVxAQEBAQI?= =?us-ascii?q?BI1YFCwsEFCoCAiE2BhODJoJMAw4gsH11gTKFT4JfDWKBQIE4AYxSgUE/gTg?= =?us-ascii?q?MEIIfLj6CHoVCMoItBI4OMIt+lxVKgk+TMYRGHZxrm3mNM4NCAgQGBQIVgVI?= =?us-ascii?q?5gVYzGggbFWUBgj4+EhgNj0+BcReBBAEBjSI/AzACj0ABAQ?= X-IronPort-AV: E=Sophos; i="5.73,310,1583193600"; d="scan'208,217"; a="25604716" 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; 24 Apr 2020 06:04:56 +0000 Received: from dhcp-10-61-109-59.cisco.com (dhcp-10-61-109-59.cisco.com [10.61.109.59]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03O64tEP005429 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Apr 2020 06:04:56 GMT From: Eliot Lear Message-Id: <2925BC7E-F2F6-4195-B427-A69282DA6499@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6106C2B1-F137-4C0E-A6E1-536BC662E69B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 24 Apr 2020 08:04:55 +0200 In-Reply-To: <44b16ed1-badf-80a7-88ca-0a900254986d@gmail.com> Cc: Alissa Cooper , rfced-future@iab.org To: Brian E Carpenter References: <869ED7EA-85D0-4C25-9B6C-74D2F8D1501C@cooperw.in> <99EB9D58-4475-4412-8731-F9700FAB453B@cisco.com> <44b16ed1-badf-80a7-88ca-0a900254986d@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.109.59, dhcp-10-61-109-59.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] A few thoughts on problem definition X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 24 Apr 2020 06:05:01 -0000 --Apple-Mail=_6106C2B1-F137-4C0E-A6E1-536BC662E69B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good evening, Brian. > On 24 Apr 2020, at 01:36, Brian E Carpenter = wrote: >=20 > Thanks for the summary record, Eliot. It's useful. I do want to = comment on one item: >=20 >> Focus on the role; Don't focus on what we want the series to be - a = great many people >=20 > Certainly the RSE role is the immediate problem. But as I said = earlier, the lack of an agreed high level charter/mission/strategy for = the RFC series actively hampers us in defining the role. It's as if the = job ad said "Wanted: a senior, experienced person to run an operation = whose mission is to do the right thing." I exaggerate to make my point, = but there is a real gap here (and not a new one). >=20 Two points: To be clear, these were points others made and I captured. I may have = overstated them slightly in my summary (the hazards of summaries). I believe we have enough discussion points that it may be time to go = through each of them in a bit more detail. I=E2=80=99ll write more = about that in a follow-up message. Eliot --Apple-Mail=_6106C2B1-F137-4C0E-A6E1-536BC662E69B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good = evening, Brian.

On 24 Apr 2020, at 01:36, Brian = E Carpenter <brian.e.carpenter@gmail.com> wrote:

Thanks= for the summary record, Eliot. It's useful. I do want to comment on one = item:

Focus on the role; Don't focus on what we want the series to = be - a great many people

Certainly the RSE role is the immediate problem. But as I = said earlier, the lack of an agreed high level charter/mission/strategy = for the RFC series actively hampers us in defining the role. It's as if = the job ad said "Wanted: a senior, experienced person to run an = operation whose mission is to do the right thing." I exaggerate to make = my point, but there is a real gap here (and not a new one).


Two points:

  • To be clear, these were points = others made and I captured.  I may have overstated them slightly in = my summary (the hazards of summaries).
  • I believe we = have enough discussion points that it may be time to go through each of = them in a bit more detail.  I=E2=80=99ll write more about that in a = follow-up message.

Eliot

= --Apple-Mail=_6106C2B1-F137-4C0E-A6E1-536BC662E69B-- From nobody Thu Apr 23 23:21:04 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5B3A0CEE for ; Thu, 23 Apr 2020 23:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1S6nGnul3HN for ; Thu, 23 Apr 2020 23:21:01 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F903A0CEC for ; Thu, 23 Apr 2020 23:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1408; q=dns/txt; s=iport; t=1587709253; x=1588918853; h=from:content-transfer-encoding:mime-version:subject: message-id:date:to; bh=YJbLYeUhsRBwS6bodiUK2zmrV/jmmF7WlPK1d4rusCc=; b=X29/gKnmPpvWGDdD3bDiNku/TfTDs0QV1pxutCSWeFtpMSRv4nKb0swZ nhPSM3Ryw+hhfnoHrQRh1T8T/TjHzyBR3ihBWJeb7FfaNJH8JNvVUePCD 0c7jkNOUxf6Po5wxF13MFVkM6ygyGXb/p0jraQdcJ0483Mhu+lKaVY813 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjBAA8hKJe/xbLJq1mHgELHIFwC4I?= =?us-ascii?q?qgUEgEoRJiQKjbgoBAQEMAQEvBAEBhxA3Bg4CAwEBCwEBBQEBAQIBBQRthWK?= =?us-ascii?q?GG0UqHAImAoENgwuCfZV1jHOOEXWBMoVPhH6BDiqMU4IAgTgciCaCRTKCLQS?= =?us-ascii?q?yG4JPgmqVDR2ca6ksg0ICBAYFAhWBaCOBVjMaCBsVZQGCPz0SGA2LEYYvF44?= =?us-ascii?q?oPwOPcgEB?= X-IronPort-AV: E=Sophos;i="5.73,310,1583193600"; d="scan'208";a="25544604" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2020 06:20:51 +0000 Received: from dhcp-10-61-109-59.cisco.com (dhcp-10-61-109-59.cisco.com [10.61.109.59]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03O6KoHD008107 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 24 Apr 2020 06:20:51 GMT From: Eliot Lear Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> Date: Fri, 24 Apr 2020 08:20:50 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.109.59, dhcp-10-61-109-59.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Summary points, tracking, discussing, etc X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 24 Apr 2020 06:21:03 -0000 Hi everyone, After a healthy start to the discussion, as I mentioned previously = I=E2=80=99ve tried to boil things down a bit. I am attaching the = summary points below again, for people to see. And as I wrote = previously, they each have a =E2=80=9C?=E2=80=9D at the end. It seems = to me these are all good points to at least address in discussion. = It=E2=80=99s been suggested to me privately that it may be useful to = rank these. That way, we can get a notion of what people would like to = work on first. I am also thinking that these are our first =E2=80=9Cissue= s" to track. These issues also help form the contours of a problem = statement. As we begin to zero in on that, we can start to also think = about solutions. Moving forward on this part, therefore, helps us get = toward the meat of our work. A word or two about modalities (again), it seems to me that having some = cadence of web conferences will help move things along. Therefore, I = propose to set up two meetings per month, with varying times to = accommodate different locales (spreading the pain), starting in mid-May, = arranging around the IETF plenary meeting (either f2f or virtually). My = preference is that the meetings run somewhat informally. By participant = count we=E2=80=99re not that large a group, and I would rather we not = get too =E2=80=9Cover processed=E2=80=9D. Eliot From nobody Thu Apr 23 23:21:56 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12703A0CF0 for ; Thu, 23 Apr 2020 23:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESWC5j2NR-un for ; Thu, 23 Apr 2020 23:21:51 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475793A0CEC for ; Thu, 23 Apr 2020 23:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8373; q=dns/txt; s=iport; t=1587709290; x=1588918890; h=from:mime-version:subject:date:references:to:in-reply-to: message-id; bh=3msNqXaD826V9dCZJloJbVOOn24QNQRFw9G/GG9IAVE=; b=X7Mo2E+vUCJtKV31JhKlUmJjKmpudwpOl2mCjWGE39XCkb1QG54bq3h3 Ql+t7LGqgiOjvko/0re07oOZk4qEVNk39GMR7WxfI2g+7LT8CcvSg422w 95w3vWE284TMOt3bu4CLGXe4T5u55JfNAoUG7wY7yNXiMdUDoNdonlkX2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZAAA8hKJe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkFAQELAYF3BS1sVSASKoQfiQKIFZNNhhGBewoBAQEMAQEeEQQ?= =?us-ascii?q?BAYREAoJKNgcOAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAQIBI0UKDAsJAhg?= =?us-ascii?q?qAgJXGRuDCwGCXCAPlWabBHWBMoRQGIVfBoE4AYxSggCBOByCTT6CZwIChHU?= =?us-ascii?q?ygi0EshuCT4JqhSKPax2ca5k2j3aDQgIEBgUCFYFZAjCBQwwHMxoIGxVlAYI?= =?us-ascii?q?+PhIYDYsRhi8XgQQBDoI9ilg/AzCPQgEB?= X-IronPort-AV: E=Sophos; i="5.73,310,1583193600"; d="scan'208,217"; a="25544670" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2020 06:21:28 +0000 Received: from dhcp-10-61-109-59.cisco.com (dhcp-10-61-109-59.cisco.com [10.61.109.59]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03O6KoHE008107 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 24 Apr 2020 06:21:28 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_F40E8A34-3DC5-42D2-9165-2D8E015034DA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 24 Apr 2020 08:21:28 +0200 References: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> To: rfced-future@iab.org In-Reply-To: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.109.59, dhcp-10-61-109-59.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 24 Apr 2020 06:21:54 -0000 --Apple-Mail=_F40E8A34-3DC5-42D2-9165-2D8E015034DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And this time with the summary points at the bottom... > On 24 Apr 2020, at 08:20, Eliot Lear wrote: >=20 > Hi everyone, >=20 > After a healthy start to the discussion, as I mentioned previously = I=E2=80=99ve tried to boil things down a bit. I am attaching the = summary points below again, for people to see. And as I wrote = previously, they each have a =E2=80=9C?=E2=80=9D at the end. It seems = to me these are all good points to at least address in discussion. = It=E2=80=99s been suggested to me privately that it may be useful to = rank these. That way, we can get a notion of what people would like to = work on first. I am also thinking that these are our first =E2=80=9Cissue= s" to track. These issues also help form the contours of a problem = statement. As we begin to zero in on that, we can start to also think = about solutions. Moving forward on this part, therefore, helps us get = toward the meat of our work. >=20 > A word or two about modalities (again), it seems to me that having = some cadence of web conferences will help move things along. Therefore, = I propose to set up two meetings per month, with varying times to = accommodate different locales (spreading the pain), starting in mid-May, = arranging around the IETF plenary meeting (either f2f or virtually). My = preference is that the meetings run somewhat informally. By participant = count we=E2=80=99re not that large a group, and I would rather we not = get too =E2=80=9Cover processed=E2=80=9D. >=20 > Eliot >=20 = The role(s) Sets strategy? Having an understanding of archival tools is important for the role What technical capabilities should the RFC Editor be expected to have Responsibility for the RPC and its budget? Authority to impose minimum standards for editing of docs Tooling responsibility? Responsibility to set publishing standards? Compliance with publication standards? Establishing/overseeing formal processes to determine the value of RFCs = to societies? Provides recommendations to make series more accessible to the various = audiences? = Relationships and lines of responsibility, and transparency Where does the role fit in? What are the roles? = What we want from the series Record agreements Timely publication Copy editing can slow that process Role should fit existing organizational structure Bespoke tooling is a bug not a feature Should we worry about legacy? What happens to the series if the IETF disappears What happens to the IETF if the series disappears Ease of navigation? --Apple-Mail=_F40E8A34-3DC5-42D2-9165-2D8E015034DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And = this time with the summary points at the bottom...

On 24 = Apr 2020, at 08:20, Eliot Lear <lear@cisco.com> wrote:

Hi = everyone,

After a healthy start to the = discussion, as I mentioned previously I=E2=80=99ve tried to boil things = down a bit.  I am attaching the summary points below again, for = people to see.  And as I wrote previously, they each have a =E2=80=9C= ?=E2=80=9D at the end.  It seems to me these are all good points to = at least address in discussion.  It=E2=80=99s been suggested to me = privately that it may be useful to rank these.  That way, we can = get a notion of what people would like to work on first.  I am also = thinking that these are our first =E2=80=9Cissues" to track.  These = issues also help form the contours of a problem statement.  As we = begin to zero in on that, we can start to also think about solutions. =  Moving forward on this part, therefore, helps us get toward the = meat of our work.

A word or two about = modalities (again), it seems to me that having some cadence of web = conferences will help move things along.  Therefore, I propose to = set up two meetings per month, with varying times to accommodate = different locales (spreading the pain), starting in mid-May, arranging = around the IETF plenary meeting (either f2f or virtually).  My = preference is that the meetings run somewhat informally. By participant = count we=E2=80=99re not that large a group, and I would rather we not = get too =E2=80=9Cover processed=E2=80=9D.

Eliot


The role(s)

  • Sets strategy?
  • Having an understanding of archival tools is important = for the role
  • What technical capabilities should the RFC Editor be = expected to have
  • Responsibility for the RPC and its budget?
  • Authority to impose minimum standards for editing of = docs
  • Tooling responsibility?
  • Responsibility to set publishing standards?
  • Compliance with publication standards?
  • Establishing/overseeing formal processes to determine the = value of RFCs to societies?
    • Provides recommendations to make series more accessible = to the various audiences?

Relationships and = lines of responsibility, and transparency

  • Where does the role fit in?
  • What are the roles?

What we = want from the series

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

= --Apple-Mail=_F40E8A34-3DC5-42D2-9165-2D8E015034DA-- From nobody Fri Apr 24 17:20:16 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817643A1146 for ; Fri, 24 Apr 2020 17:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=IP6ZooDo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=acxtxCC/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y30-2ggbCmWA for ; Fri, 24 Apr 2020 17:20:13 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78533A1141 for ; Fri, 24 Apr 2020 17:20:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 871E12CA for ; Fri, 24 Apr 2020 20:20:11 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 24 Apr 2020 20:20:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=e1tBvV8 7IPcC+ZZ+V7nhvHEjGC4QlJJOqd5gbKjhvFA=; b=IP6ZooDo5Ea7659zH3zybRb jHtNPNyfo6m3hdVd3SOB0StDEwnH5oJqvMKbIxj4/dqEoe27xI+2ltn7JsC+4JYg kLwW3sR3BPnIF5Op64Ai4koGsAV5AxMPOhK1LTIVJDn/ZxFF/dQYUE+6Clm0OD+v mbSyzSxuwkhPWh9oglSIUUD9rWfmAu/0AfJees955m8UlZvHs60moQLHHqnK95i8 i1YxVI77+l55XZXQzzyLN4kT0Zgq+MO+55HMqDTWY/rDuBsEVXgZXn88kr4iesiI bXkaf5StJFx1YgRhIQAwtkFJkp9B/zPobOy17xJOaDvttpzBOVr+3UQsWy5DscA= = 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=e1tBvV 87IPcC+ZZ+V7nhvHEjGC4QlJJOqd5gbKjhvFA=; b=acxtxCC/lzScD2pcA3YnuJ 5ONoARwz2wtw9GSPiCpummDis99E7LN6uC9iVeD5tqQt9RNzgOceZxEzFM+aZlXV lfVaX5mVkH7TPQoSYYsRjgKx9minFSUWnr/Yiz8NZzlhHuzsr5zXjv1mcQO/n7VS BEGGKoPYevznCtC5jG1Zzm3/9WlQC3FgHd001YIeBsrLKhhfAknU+ve2AA03c+v0 /+OJFQw3D+w1X2ZZHSc4xCJj9rb/X6fmiKVquBGik8f32ehDdK14sCH9SqPTM1S+ FLskAC7qI385EhVZwshHoedMrfA18pBhzfe5wjAtMbEqvwQ+h28LlKWCYxu0tdmQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedvgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C054B180091; Fri, 24 Apr 2020 20:20:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> In-Reply-To: References: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> Date: Sat, 25 Apr 2020 10:19:49 +1000 From: "Bron Gondwana" To: rfced-future@iab.org Content-Type: multipart/alternative; boundary=c901af3e228248b9bde104c99d4d08c7 Archived-At: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Apr 2020 00:20:15 -0000 --c901af3e228248b9bde104c99d4d08c7 Content-Type: text/plain On Fri, Apr 24, 2020, at 16:21, Eliot Lear wrote: > * What happens to the series if the IETF disappears > * What happens to the IETF if the series disappears These two are really interesting questions, but they're only half the thing to consider here. I'm part of volunteer organisation which has existed for over 50 years, and during the past 20 years that I've been a member I've seen multiple things which were definitely not "disappears" but have been pretty bad sicknesses - for example there is a bank account which nobody was able to access for about 10 years because the signatories served out their terms and then went radio silence or became obstinate about handing them on to the next elected because of queries over the governance of the organisation and the validity of elections. It's not like this organisation has "disappeared" - parts of it are still running effectively, but other parts really aren't very well. So I'd say that rather than just disappear - we need to consider all of this triple: * What if X disappears entirely in a way that it can't be effectively forked/restarted. * What if X evolves so fast that it no longer serves the needs of Y * What if X becomes so {dysfunctional/slow/mired in internal process} that it no longer serves the needs of Y in a timely manner All of those apply both ways to the quoted questions :) Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --c901af3e228248b9bde104c99d4d08c7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Fri, Apr 24, 2020, at 16:21, Eliot Lear wrote:
  • What happens to the series if the IETF disappears
  • What happens to the IETF if the series disappears

These two are really interesting questions, bu= t they're only half the thing to consider here.  I'm part of volunt= eer organisation which has existed for over 50 years, and during the pas= t 20 years that I've been a member I've seen multiple things which were = definitely not "disappears" but have been pretty bad sicknesses - for ex= ample there is a bank account which nobody was able to access for about = 10 years because the signatories served out their terms and then went ra= dio silence or became obstinate about handing them on to the next electe= d because of queries over the governance of the organisation and the val= idity of elections.

It's not like this organisation has "= disappeared" - parts of it are still running effectively, but other part= s really aren't very well.
So I'd say that rather than ju= st disappear - we need to consider all of this triple:
* What if X disappears entirely in a way that = it can't be effectively forked/restarted.
* What if X evolves so fast that it no longer serves the ne= eds of Y
* What if X becomes = so {dysfunctional/slow/mired in internal process} that it no longer serv= es the needs of Y in a timely manner

All of those apply b= oth ways to the quoted questions :)

Cheers,

Bron.<= br>

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


--c901af3e228248b9bde104c99d4d08c7-- From nobody Fri Apr 24 17:33:55 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF83A11F6 for ; Fri, 24 Apr 2020 17:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq69PZJN3xAW for ; Fri, 24 Apr 2020 17:33:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F33F3A11F5 for ; Fri, 24 Apr 2020 17:33:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 51776BE2C; Sat, 25 Apr 2020 01:33:50 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYiujn0bPeDK; Sat, 25 Apr 2020 01:33:42 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1F7ABBE20; Sat, 25 Apr 2020 01:33:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1587774822; bh=rwq5gb3F4nvQj5BUMAN5xsAJUFXuxAGCyxJe4JK+9nA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Y3uNi9j5NEWC9IZ2P+tRUa18uZ5sqmq5qF+Lx25QwKZVKlM+9/MpY0EiYkSl5jjyN Xb+Wkm2VmtRCF5/h0H1k2Kqo779rpNtYbVdWDgmNmvZRFj+qUxs1wR6jDacdkFmqEy CjZZuU3svTHebm2aJ5r64k7Pldi6bfkM6m3E33xs= To: Bron Gondwana , rfced-future@iab.org References: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <7c77c0ac-f167-a2fd-bc03-09850a69fc29@cs.tcd.ie> Date: Sat, 25 Apr 2020 01:33:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ttZ7z2fMXQpnKVVxpdg7dyHzOkWH7nBMW" Archived-At: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Apr 2020 00:33:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ttZ7z2fMXQpnKVVxpdg7dyHzOkWH7nBMW Content-Type: multipart/mixed; boundary="8GWITFfDFNkUzvCal7MiJlW3HGKI6Nh29"; protected-headers="v1" From: Stephen Farrell To: Bron Gondwana , rfced-future@iab.org Message-ID: <7c77c0ac-f167-a2fd-bc03-09850a69fc29@cs.tcd.ie> Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc References: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> In-Reply-To: <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> --8GWITFfDFNkUzvCal7MiJlW3HGKI6Nh29 Content-Type: multipart/mixed; boundary="------------27CC560AA6C856B900379127" Content-Language: en-US This is a multi-part message in MIME format. --------------27CC560AA6C856B900379127 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 25/04/2020 01:19, Bron Gondwana wrote: > So I'd say that rather than just disappear - we need to consider all of= this triple: > * What if X disappears entirely in a way that it can't be effectively f= orked/restarted. > * What if X evolves so fast that it no longer serves the needs of Y > * What if X becomes so {dysfunctional/slow/mired in internal process} t= hat it no longer serves the needs of Y in a timely manner >=20 > All of those apply both ways to the quoted questions :) FWIW, I think that's an improvement on the questions Eliot posed. I don't know if it gets us to to a useful enough set of questions though. Maybe we ought wonder more concretely: "the RSE can be more or less independent of the IETF - what's the best level of (in)dependence?" Cheers, S. --------------27CC560AA6C856B900379127 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------27CC560AA6C856B900379127-- --8GWITFfDFNkUzvCal7MiJlW3HGKI6Nh29-- --ttZ7z2fMXQpnKVVxpdg7dyHzOkWH7nBMW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6jhWUACgkQWrL68XsX K+qn6A/+IOSXGRC9VX3h2HMx4xB1czMf84RYgPFywDOoZAUfF2w7hPOTJqZNQglw J5FgXAWqJY4diOZZGOBhzESlS8GvALB/Pxl0hAHEp3D3CY+XuEI+ZGEwGQY8ykX5 vp/74zoYfTU1d5FYjHIFpZofGJiLKS+PZJKsNCHcOAlVxtM4M9u8mqb/ceVlo0xd FdTYlUyOjrhiNzqiUuyXDd8vNEyNkdde8fGdiAEvOTaFvkwWgOUBHofkCpDHO+eI OoYgqJTzAt9xpTdyhuefSeTjovaN08fOhfbuqfsy89STSSs/bPDCMrKfWCOz6SMd X9E7VvJMLvny1hhvNVhB1HCO+pm2UUt1xr7Ii6UZWVsHiuOqVPveqZTkZ8/qk8PG B5V/kRt0SKxyiw71M0jM5NFFlCNdmd7efual5R3Nq+i8ZhGoc5A8WN/W32IJyHOS 4/Yg2QaCaUnsRqKSzLbipLTfKGIphUZ0ERTTK1fvRa+HoOcVaZoJ6h7If9cqd2VQ c+xyjoiV5/SzxcYt8N6QOonSxqvjHGKYElDDcF2ky8LxxNxUZeSqcybF8cZCkfHQ /nBkiPvZz125gjomqGEuqGSzmYwpWxCTOekB4J7j8Fm3fRDC59yVSL4by06DhaoM 1qFLM5MeYPJhcjUNcMgWmzNES6on4BcxNxNTp9K/8w+E3Ymu94U= =/Scj -----END PGP SIGNATURE----- --ttZ7z2fMXQpnKVVxpdg7dyHzOkWH7nBMW-- From nobody Fri Apr 24 22:49:18 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5473B3A099D for ; Fri, 24 Apr 2020 22:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2pWDcfDchmB; Fri, 24 Apr 2020 22:49:15 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 705F33A0999; Fri, 24 Apr 2020 22:49:14 -0700 (PDT) From: Jay Daley Message-Id: <78920F4E-E153-4A03-BE05-B7710ADF4A22@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF91F8FB-86BD-40C6-9F92-D3170949FCC7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 25 Apr 2020 17:49:11 +1200 In-Reply-To: <7c77c0ac-f167-a2fd-bc03-09850a69fc29@cs.tcd.ie> Cc: Bron Gondwana , rfced-future@iab.org To: Stephen Farrell References: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> <7c77c0ac-f167-a2fd-bc03-09850a69fc29@cs.tcd.ie> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Apr 2020 05:49:16 -0000 --Apple-Mail=_FF91F8FB-86BD-40C6-9F92-D3170949FCC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Stephen > On 25/04/2020, at 12:33 PM, Stephen Farrell = wrote: >=20 > Maybe we ought wonder more concretely: "the RSE can be > more or less independent of the IETF Can you explain why you think that is a given rather than something to = be assessed by analysis? thanks Jay > - what's the best > level of (in)dependence?" >=20 > Cheers, > S. >=20 >=20 > <0x5AB2FAF17B172BEA.asc>--=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_FF91F8FB-86BD-40C6-9F92-D3170949FCC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Stephen

On 25/04/2020, at 12:33 PM, = Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Maybe = we ought wonder more concretely: "the RSE can be
more or = less independent of the IETF

Can you explain why you think that is a given = rather than something to be assessed by analysis?

thanks
Jay

- what's the = best
level of (in)dependence?"

Cheers,
S.


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

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

= --Apple-Mail=_FF91F8FB-86BD-40C6-9F92-D3170949FCC7-- From nobody Sat Apr 25 07:33:32 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32293A0776 for ; Sat, 25 Apr 2020 07:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 PUXVUXRah48Y for ; Sat, 25 Apr 2020 07:33:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5ADE3A047D for ; Sat, 25 Apr 2020 07:33:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DB61BBE2F; Sat, 25 Apr 2020 15:33:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAx8UvYJpZi7; Sat, 25 Apr 2020 15:33:21 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B0DADBE2C; Sat, 25 Apr 2020 15:33:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1587825201; bh=cxizPGyZcplwMpthIdZ7w0FPPJM1ZbF9szch6X7fYn0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WVXqxryEdOkrezh3pXo1W3dYKYnWNkwBdHXOYjsSKnBJ9+dsr2l5qxyreEilejAxq lnp+n+nebTdLs+XlVenYD84bphTBkJ7rq7V4cobDmrCOfku5hVmgcDMYvcDSWsPW09 xWZUueUk/fvpznTwk+St4IVfHLPIKZkbD+54KrbY= To: Jay Daley Cc: rfced-future@iab.org, Bron Gondwana References: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> <7c77c0ac-f167-a2fd-bc03-09850a69fc29@cs.tcd.ie> <78920F4E-E153-4A03-BE05-B7710ADF4A22@ietf.org> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sat, 25 Apr 2020 15:33:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <78920F4E-E153-4A03-BE05-B7710ADF4A22@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ALYkFzB4Dn3MMbtGHdAwklqAmqHCrVSOv" Archived-At: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Apr 2020 14:33:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ALYkFzB4Dn3MMbtGHdAwklqAmqHCrVSOv Content-Type: multipart/mixed; boundary="THhkTI220sLhiSBy3MMVNXm7xCxNRSebt"; protected-headers="v1" From: Stephen Farrell To: Jay Daley Cc: rfced-future@iab.org, Bron Gondwana Message-ID: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc References: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> <7c77c0ac-f167-a2fd-bc03-09850a69fc29@cs.tcd.ie> <78920F4E-E153-4A03-BE05-B7710ADF4A22@ietf.org> In-Reply-To: <78920F4E-E153-4A03-BE05-B7710ADF4A22@ietf.org> --THhkTI220sLhiSBy3MMVNXm7xCxNRSebt Content-Type: multipart/mixed; boundary="------------326BB2A96CE4A4FB0A2BBD5E" Content-Language: en-US This is a multi-part message in MIME format. --------------326BB2A96CE4A4FB0A2BBD5E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 25/04/2020 06:49, Jay Daley wrote: > Stephen >=20 >> On 25/04/2020, at 12:33 PM, Stephen Farrell >> wrote: >>=20 >> Maybe we ought wonder more concretely: "the RSE can be more or less >> independent of the IETF >=20 > Can you explain why you think that is a given rather than something > to be assessed by analysis? I must be missing something because the part of my statement quoted above seems like a tautology to me. Maybe rephrasing it will make that clearer: the level of independence the RSE has from the IETF could vary. (That's the tautological bit.) The community, however defined, (*) should discuss what's the best level of independence. (That bit isn't a tautology.) Does that help? If so, my reason for suggesting the latter bit is that I think non-crazy members of the IETF community have wildly different ideas about the right thing here. This particular discussion might be better earlier or later in the process though, I'm not sure, but that's what Eliot gets the big bucks for;-) Cheers, S. (*) As we've seen the definition of community is a separate topic of discussion, and of course, none of the discussions here ought be driven by the IAB, nor LLC, though of course people on the IAB or employed by the LLC ought contribute, carefully, as evidenced by this exchange:-) >=20 > thanks Jay >=20 >> - what's the best level of (in)dependence?" >>=20 >> Cheers, S. >>=20 >>=20 >> <0x5AB2FAF17B172BEA.asc>-- Rfced-future mailing list=20 >> Rfced-future@iab.org=20 >> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 --------------326BB2A96CE4A4FB0A2BBD5E Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------326BB2A96CE4A4FB0A2BBD5E-- --THhkTI220sLhiSBy3MMVNXm7xCxNRSebt-- --ALYkFzB4Dn3MMbtGHdAwklqAmqHCrVSOv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6kSjAACgkQWrL68XsX K+rbxBAAhePGOJfM+aTxs2jaKSoZsizS7/HUHfQ+JCIG871nUfvijGCGT3pEzuMI HcFgcqdZ1gH2SduzMZeKKGeb2gaRNGL3AZqtnXFhHqkrIHu16Ksz7tCM9YnUW2EK fr1NyGGTy7UfQxJhl0zgCeedOwEbtimvlsy7yecNwMrH/ZxOBRLhb4cNJ2XfGDmm SCutlsFr97JDX8suHVZCoDMhZU82VVeSzn/CBHGjJmfxvIf3+pszqDM/F7kQuUS1 mxTG31gUDa5dp2VseychfL9HLfJGjkCQtyzd4ip9fqLOYXCiIpDU1Mj3bDHb0ubB +TLeGDmIwuXsQoISXyHwl9gcAJcrigpuHdw2w5SgW80MwtQ6yqxlgkCoCAxAh8Rg mTbL6DM8itjHWJuZWxF3sjlkftm3ODyS5xsPnmX6ASb9llcLXXqmJ2HgSosHfqWF NS/hpayWeXBzl+pG1THPJqfxVoeygVMnc1iKsN4XDLdyP1skx+ftxw16EYLxzgaF 9SwfHCEB5p1SY8vrKPjl91vhq+9crtYWzWF18ylxgr7T3wY7lzYFTQqIBippr64G Uc1e9gI05mzOrqDJ2CkgM4E8SZ1sqs8GXOOaFfOA1T2mbZN9Xss366Jbf0DB87Mm 3HuleIS8IfvVK4gjzY9GoHNrutGpMTo7Gqji+2W0Dys7VlecJd8= =lqxg -----END PGP SIGNATURE----- --ALYkFzB4Dn3MMbtGHdAwklqAmqHCrVSOv-- From nobody Sat Apr 25 12:25:11 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E743A142F for ; Sat, 25 Apr 2020 12:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lknnnvsNkJgu for ; Sat, 25 Apr 2020 12:25:06 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A221D3A1430 for ; Sat, 25 Apr 2020 12:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2456; q=dns/txt; s=iport; t=1587842705; x=1589052305; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=KCP2AnF6lo//dD8KJu6EP6RIWwBps2VstB578IEXOVg=; b=hk7ocJe/Z20m+lhb3WNYbDEzHI9t0X1kyla8+CfNW2fx9plm0T8uRLuA nkhoTz9MJAW6SErNQLsV7lA3uxi2kMjNxrJNykdAotvav0ZSi9rxGyfTX ekkewY9q+WtLX5CSDqB9nhn3TLg9TJMqzKgewgx5ql3n4WARDchAsGSIc 4=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBAAKjqRe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBPIFHAoNpIBIqjSCHdSWbWAQHAQEBCQMBAS8EAQGERAKCSjgTAgM?= =?us-ascii?q?BAQsBAQUBAQECAQUEbYViQgEQAYUdAQEBAQIBeQULCxguVwYTFIMSAYJcILA?= =?us-ascii?q?FdIE0hU+FChCBOAGBUosEggCBOAwQgU9QLj6IEoItBJh0mS6CT4JtgSSTbx2?= =?us-ascii?q?QAox5qT2DQwIEBgUCFYFpIoFWMxoIGxVlAYI+PhIYDZ9+PwMwNQIGCAEBAwm?= =?us-ascii?q?FP4lwAQE?= X-IronPort-AV: E=Sophos;i="5.73,317,1583193600"; d="asc'?scan'208";a="25643161" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Apr 2020 19:25:03 +0000 Received: from [10.61.245.121] ([10.61.245.121]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 03PJP2a4021510 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 25 Apr 2020 19:25:03 GMT From: Eliot Lear Message-Id: <77D58EA8-8215-45D0-BE26-E88EF97E6E8B@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CC4360E8-B163-4B31-B2D1-E0DE026300D1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 25 Apr 2020 21:25:01 +0200 In-Reply-To: Cc: Jay Daley , rfced-future@iab.org, Bron Gondwana To: Stephen Farrell References: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> <7c77c0ac-f167-a2fd-bc03-09850a69fc29@cs.tcd.ie> <78920F4E-E153-4A03-BE05-B7710ADF4A22@ietf.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.245.121, [10.61.245.121] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Apr 2020 19:25:09 -0000 --Apple-Mail=_CC4360E8-B163-4B31-B2D1-E0DE026300D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25 Apr 2020, at 16:33, Stephen Farrell = wrote: >=20 > Signed PGP part >=20 > Hiya, >=20 > On 25/04/2020 06:49, Jay Daley wrote: >> Stephen >>=20 >>> On 25/04/2020, at 12:33 PM, Stephen Farrell >>> wrote: >>>=20 >>> Maybe we ought wonder more concretely: "the RSE can be more or less >>> independent of the IETF >>=20 >> Can you explain why you think that is a given rather than something >> to be assessed by analysis? >=20 > I must be missing something because the part of my > statement quoted above seems like a tautology to me. >=20 > Maybe rephrasing it will make that clearer: the level of > independence the RSE has from the IETF could vary. (That's > the tautological bit.) The community, however defined, (*) > should discuss what's the best level of independence. (That > bit isn't a tautology.) >=20 > Does that help? If so, my reason for suggesting the latter > bit is that I think non-crazy members of the IETF community > have wildly different ideas about the right thing here. > This particular discussion might be better earlier or > later in the process though, I'm not sure, but that's what > Eliot gets the big bucks for;-) We do need to have that conversation, and several others; and I will be = prodding people on those points as soon as we sew up what other = questions need answering. Which reminds me. What other questions need answering? ;-) Eliot --Apple-Mail=_CC4360E8-B163-4B31-B2D1-E0DE026300D1 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl6kjo0ACgkQh7ZrRtnS ejMjEQf9GNJ9enEtoFonCgZhumXBrKqLzTB7ej8zhN2LmWCn5MdkEJk+NadyW24E FlAWAQz2VzapHrTewrr4xyO4TQKwcHlvttrL12DPAdnfyXdoU4gSqn06zgM9awua yOywTA1C622mgX/NkfjH3WRonqd/+kahSiJOIQa3aEFimmS4Xi9LJ8CdajOrFaiM cxujDhXvIPUjn2/5a9FKxzNCdJMqZeOGPx/QBnZBFBFJ1xnoY+uHpeIyJPo9Gusa EwzARGSrXDKlpV5KWben/g+Ef4Bng0qoqZwLg7gNJisAewhYPixjHdevTx2QhaB7 AOWRhVI8/vSyP2jlR/LOpHetYjkLwg== =zMP5 -----END PGP SIGNATURE----- --Apple-Mail=_CC4360E8-B163-4B31-B2D1-E0DE026300D1-- From nobody Sat Apr 25 12:30:49 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB793A145B for ; Sat, 25 Apr 2020 12:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2kB2xi9R8Iu; Sat, 25 Apr 2020 12:30:43 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 149C23A1459; Sat, 25 Apr 2020 12:30:41 -0700 (PDT) From: Jay Daley Message-Id: <00F88F18-23BA-4A3D-AC66-06B056482327@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_9B6D2381-4633-4FF0-8DF2-E795E3DBE004" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 26 Apr 2020 07:30:39 +1200 In-Reply-To: Cc: rfced-future@iab.org, Bron Gondwana To: Stephen Farrell References: <33C14223-418F-4E56-A7B4-1ACD7363DE9A@cisco.com> <6faa75c0-6f9b-42d0-9b32-740a65a36250@dogfood.fastmail.com> <7c77c0ac-f167-a2fd-bc03-09850a69fc29@cs.tcd.ie> <78920F4E-E153-4A03-BE05-B7710ADF4A22@ietf.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Apr 2020 19:30:46 -0000 --Apple-Mail=_9B6D2381-4633-4FF0-8DF2-E795E3DBE004 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 26/04/2020, at 2:33 AM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 25/04/2020 06:49, Jay Daley wrote: >> Stephen >>=20 >>> On 25/04/2020, at 12:33 PM, Stephen Farrell >>> > = wrote: >>>=20 >>> Maybe we ought wonder more concretely: "the RSE can be more or less >>> independent of the IETF >>=20 >> Can you explain why you think that is a given rather than something >> to be assessed by analysis? >=20 > I must be missing something because the part of my > statement quoted above seems like a tautology to me. >=20 > Maybe rephrasing it will make that clearer: the level of > independence the RSE has from the IETF could vary. (That's > the tautological bit.) The community, however defined, (*) > should discuss what's the best level of independence. (That > bit isn't a tautology.) >=20 > Does that help? Yes that makes sense - thanks. =20 Jay > If so, my reason for suggesting the latter > bit is that I think non-crazy members of the IETF community > have wildly different ideas about the right thing here. > This particular discussion might be better earlier or > later in the process though, I'm not sure, but that's what > Eliot gets the big bucks for;-) >=20 > Cheers, > S. >=20 > (*) As we've seen the definition of community is a separate > topic of discussion, and of course, none of the discussions > here ought be driven by the IAB, nor LLC, though of course > people on the IAB or employed by the LLC ought contribute, > carefully, as evidenced by this exchange:-) >=20 >=20 >>=20 >> thanks Jay >>=20 >>> - what's the best level of (in)dependence?" >>>=20 >>> Cheers, S. >>>=20 >>>=20 >>> <0x5AB2FAF17B172BEA.asc>-- Rfced-future mailing list=20 >>> Rfced-future@iab.org=20 >>> https://www.iab.org/mailman/listinfo/rfced-future >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc>--=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_9B6D2381-4633-4FF0-8DF2-E795E3DBE004 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 26/04/2020, at 2:33 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 25/04/2020 06:49, Jay Daley = wrote:
Stephen

On 25/04/2020, at 12:33 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:

Maybe we ought wonder more concretely: "the RSE can be more = or less
independent of the IETF

Can you explain why you think = that is a given rather than something
to be assessed by = analysis?

I must be missing something because the part of my
statement quoted above seems = like a tautology to me.

Maybe rephrasing it will make that clearer: the level = of
independence = the RSE has from the IETF could vary. (That's
the tautological bit.) The = community, however defined, (*)
should discuss what's the best level of independence. = (That
bit isn't a = tautology.)

Does that = help?

Yes that = makes sense - thanks.  

Jay

If so, my reason for suggesting the latter
bit is that I think non-crazy = members of the IETF community
have wildly different ideas about the right thing = here.
This = particular discussion might be better earlier or
later in the process though, I'm = not sure, but that's what
Eliot gets the big bucks for;-)

Cheers,
S.

(*) As we've = seen the definition of community is a separate
topic of discussion, and of = course, none of the discussions
here ought be driven by the IAB, nor LLC, though of = course
people on the = IAB or employed by the LLC ought contribute,
carefully, as evidenced by this = exchange:-)



thanks Jay

- what's the best level of (in)dependence?"

Cheers, S.


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


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

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

= --Apple-Mail=_9B6D2381-4633-4FF0-8DF2-E795E3DBE004-- From nobody Sat Apr 25 21:07:49 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE43A0B2B for ; Sat, 25 Apr 2020 21:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjRsBqymuIgX for ; Sat, 25 Apr 2020 21:07:46 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1723F3A09C8 for ; Sat, 25 Apr 2020 21:07:46 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id x26so6875737pgc.10 for ; Sat, 25 Apr 2020 21:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=gEYrANLHPzYAzYpf413moRoBwcowakA3mPW52t7WD2k=; b=R8nrnQ6X71JNjPd3RDjmtXR/giRgs1yRjWsFjImV5RLmxi6MfCQV42ErhzUfPkW2y9 zZ8TgTCDDAOFbugcMJs9qaGAfKpdkzWuvEHmtVA5SPeQYEU/cLQgIDqMMN2zC6fsRgOH EXHOc9eJvA1SmHTSR/ULHLZ6FRSbT4Ke4I+9b7uW6FIiyOZRTPBkkDf4HPw58S8nLpwJ ALfBERodva+oi1JNNyBt2payAnD/aszdubTYUK41wMrH4CyyYEwsXUsIUMZUiKVp/FqG MANhyyniYjG0KgBb7XJaKDCgWGIxplde2iFy3Y7e7miK+VtJW3hZbmgUpiscIF+scd/T pbNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=gEYrANLHPzYAzYpf413moRoBwcowakA3mPW52t7WD2k=; b=NaC/3qIFbyQZ316PzlmQCQ+yLJWgwBtOXWiNXS7+Y+w6SELOh+CWkSRRdAqXMogwXy jGR8CnCyS0iD6GoKSHyOrinew/IaTIpD/o24d2bw0QEj9e2NxgRME8Et8ZDDZTep2OFS 69IpnACZP10SyqAgy9B5kkgajAcj/e7OdNxpbrVasTF6/wzjiDeBq5qXjDX5R1XPo+VC ybgf83PUgvVIDuqk9RYumb0k92/UN8AOo75F5Vw0kDq7wtIG+73DNMwylRwSfCcbnp+J YbHnVf0cqozk4BYbA27mNiBKOidzzRuft3FVyk3Bju4jDOgBmGwi8MAPn+yaBtEun3UW wfzA== X-Gm-Message-State: AGi0PubkJsDt91JgMKOpMU2YJ3W36njB+pY2UdeC7LSpQV97nO32T5u4 oNYJKzYX3bxTTSI7QBHaz0w= X-Google-Smtp-Source: APiQypIIVl3TYOdRHTa40YC9qteSbROnQcP77HzcDrmAwKSL7Jtzuo6DWhD9HYIhxkcoHmEZpXYYgA== X-Received: by 2002:a63:2d8:: with SMTP id 207mr15932143pgc.137.1587874065180; Sat, 25 Apr 2020 21:07:45 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id 30sm2503113pgp.38.2020.04.25.21.07.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2020 21:07:44 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Eliot Lear'" , "'Stephen Farrell'" Cc: , "'Bron Gondwana'" , "'Jay Daley'" Date: Sat, 25 Apr 2020 21:07:42 -0700 Message-ID: <00ec01d61b80$3c78c580$b56a5080$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdYbgDt4GBiS9NXgT0iyhSHH/Tne+Q== Content-Language: en-us Archived-At: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 04:07:48 -0000 A question I've been wondering is the separation of RSE and IANA into totally separate paths. In a "living standard" world, the lines are blurred. -- https://LarryMasinter.net https://going-remote.info From nobody Sat Apr 25 21:20:55 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DC43A0B75 for ; Sat, 25 Apr 2020 21:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 HF9eLDD8EmZO for ; Sat, 25 Apr 2020 21:20:49 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B224F3A0B72 for ; Sat, 25 Apr 2020 21:20:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 498vpn40zmz6GD3v; Sat, 25 Apr 2020 21:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587874849; bh=OXqqxVdED+5eJmpR7l+gIHKcXuYqJ0nXnS9xCwEywfs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mmQ9VxFEjvX8kS6nm/uSTT5/3hg7Zsv3eH55EwTGwHVS1sj5pMylccRBSKpGd3yXF GNd5qM8PIwy0IwNGgkwPk4R7txoKRal5qyBhQZH6uv4viMnIQgAEt794TbNljJ+deS ac6uZZ8rarjAvRSDoZXfDiXlDgHcGkiPr2B1MnTQ= X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 498vpn0RMvz6G9GW; Sat, 25 Apr 2020 21:20:48 -0700 (PDT) To: Larry Masinter Cc: rfced-future@iab.org References: <00ec01d61b80$3c78c580$b56a5080$@acm.org> From: "Joel M. Halpern" Message-ID: Date: Sun, 26 Apr 2020 00:20:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <00ec01d61b80$3c78c580$b56a5080$@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Summary points, tracking, discussing, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 04:20:53 -0000 Even if you asssume (which I do not) THAT rfcs were to become fully dynamic documents instead of archival grade standards, that still would not make the IANA protocol data repository interchangable with the RFCs. The IANA data is the protocol registry. It collects and organizes the assignments from multiple RFCs. It also includes (in an organized an usable fashion) data from other sources when teh registry permits such things. Also remember that IANA tracks number assignments. These were separate well before the other changes in the structure of the RSE. I would hope that we are not going to confuse the process of defining the role or the ~RSE~ (whatever we decide that means) with the IANA functions. Please. Yours, Joel On 4/26/2020 12:07 AM, Larry Masinter wrote: > A question I've been wondering is the separation of RSE and IANA into > totally separate paths. > In a "living standard" world, the lines are blurred. > -- > https://LarryMasinter.net https://going-remote.info > > From nobody Sun Apr 26 21:41:58 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3C83A0ACD for ; Sun, 26 Apr 2020 21:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5EqEh1_DZeK for ; Sun, 26 Apr 2020 21:41:54 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520A13A0AA3 for ; Sun, 26 Apr 2020 21:41:54 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id b6so2256139uak.6 for ; Sun, 26 Apr 2020 21:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=uzLvRzTQAUJpn3jMXWRmQpauSeGa72Im3ITe8q0m0HQ=; b=q+0gK72cS5h3cF9c9AY8++HXvHIOsFoz/Wu0ZWTgb7JqJqdD+nx189v13bgxtncz2O 9irb+noU0gZqkgg69pL2cOnu9dagweRfALhVl88hUJY7wRpGRV68FIT+1x6RzJBL9zR+ MuiIIZD9BhT3NfY7PHviL4/N/RFMlEiF3W5JbFVbSZo1BZwXCNjkZNfb5nwNqUm1y/Gp mhzGNQZivCZdhIcLL/a5315va8auSz+jPRLGRN4iDJahiv0EbsfUfIcLGXe6RioSTAsx BNXt9ikrn3bHD95s8JVAswT3FvdYAwbxigFh95DWdNe6XUO85B/bU3ijmK4kXlt0mziN 8C9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=uzLvRzTQAUJpn3jMXWRmQpauSeGa72Im3ITe8q0m0HQ=; b=gVdVd2xxnZGqc0Xz6J+rIgN2xndDeNyyqERYzZ5DTa+UnB7b/njEmKit0ES4zMNt0H Fmxkfvm1mVc07pWqdakA4CCTOuO2ap3/HiEmHPGi++GC36W73L/ftKbJdIX8tM9vO8mb twp0gBesG0yqiUw24hHcWkmQ+tPilRLUbECgXPAi2DNzRHKo+qyrVhUlaMpDdvpwjlL2 FQn13Z+dTVezrNvI9T6e8GD4urdC+dBmrEM2Rwo0ApEcRQTsf2QKtb/dh9JNbSJu1beb tgo4hDhlv2n1c+9NPXCrRYVtuunYQ7REek2fxhK1yhXezeYvmhwvUNbuXJ/kYfQfFLw6 jsNw== X-Gm-Message-State: AGi0PuZfjwbpZ7bo2iuR7/I5/+mtIQ/ZBc+85SEfecuEqs5UysOx+Uzi Rln0mjhe7YAgGVH7zhm1qqpNEiDHzQ65fRwFNocA26I2 X-Google-Smtp-Source: APiQypKaKrZZdiLVA34RsmkkR7P6wcYxZvO0s0YNS5VF6uiKztP4SpVVrpXpmnlIwprs3Xy2xEXuAP4zZF3DwYu/q7Y= X-Received: by 2002:a67:f4ce:: with SMTP id s14mr13140742vsn.99.1587962513025; Sun, 26 Apr 2020 21:41:53 -0700 (PDT) MIME-Version: 1.0 From: Nevil Brownlee Date: Mon, 27 Apr 2020 16:41:26 +1200 Message-ID: To: rfced-future@iab.org Cc: Nevil Brownlee Content-Type: multipart/alternative; boundary="000000000000816e5805a43e55a0" Archived-At: Subject: [Rfced-future] Some more summary points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 27 Apr 2020 04:41:56 -0000 --000000000000816e5805a43e55a0 Content-Type: text/plain; charset="UTF-8" Hi all: Here are a few more points for this list to consider ... Need for RSE to have publishing experience? Proposed changes to RFC Series - do other publications do anything similar? How could we get feedback from users of the RFC Series? For example, could we find a University to conduct some research on this? How do researchers/developers/IPs/etc actually find out about Standards? Independence of RSE? RSE serves all four Streams, we need to make sure that changes proposed by one Stream don't cause problems for any other Streams, How should proposals for changes in the series be handled? I like Brian's idea of using the rfc-interest list to discuss these, with (my idea) the RSE acting like a "WG Chair" to monitor discussion, determine consensus, and document any agreed changes. Continuing development of xml2rfc? Our 'new format' uses xml for it's canonical form, text, html and pdf versions are generated from the xml. The specifications for xml2rfc v3 (RFCs 7990 to 7990) were developed by a Design Team led by the RSE. Development of tools for v3 was done by the IETF Tools Team. The RFC Publication Centre started using them from about mid-2019, and the Tools folk have been working on problems as they arose. On the rfc-interest list there was discussion about this; it seems to me that it's time we started work on a definitive description of rfc2xml v3bis, so that we have a clear statement that open-source developers could work with. This would be a good initial project for a new RSE (who will clearly need to be xml/html/etc.) Cheers, Nevil ----------------------------------- Nevil Brownlee, Taupo, NZ --000000000000816e5805a43e55a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all:
Here are a few more points for this= list to consider ...

Need for RSE to have publish= ing experience?
=C2=A0 Proposed changes to RFC Series - do other publica= tions do anything similar?

How could we get feedback from users of t= he RFC Series?
=C2=A0 For example, could we find a University to conduc= t some research on this?
=C2=A0 How do researchers/developers/IPs/etc a= ctually find out about Standards?

Independence of RSE?
=C2=A0 RSE= serves all four Streams, we need to make sure that changes proposed
=C2= =A0 =C2=A0 by one Stream don't cause problems for any other Streams,
How should proposals for changes in the series be handled?
=C2=A0 I= like Brian's idea of using the rfc-interest list to discuss these,
= =C2=A0 with (my idea) the RSE acting like a "WG Chair" to monitor= discussion,
=C2=A0 determine consensus, and document any agreed changes= .

Continuing development of xml2rfc?
=C2=A0 Our 'new format&#= 39; uses xml for it's canonical form, text, html and pdf
=C2=A0 =C2= =A0 versions are generated from the xml.
=C2=A0 The specifications for x= ml2rfc v3 (RFCs 7990 to 7990) were developed
=C2=A0 =C2=A0 by a Design T= eam led by the RSE.
=C2=A0 Development of tools for v3 was done by the I= ETF Tools Team.
=C2=A0 =C2=A0 The RFC Publication Centre started using t= hem from about mid-2019,
=C2=A0 =C2=A0 and the Tools folk have been work= ing on problems as they arose.
=C2=A0 =C2=A0 On the rfc-interest list th= ere was discussion about this; it seems
=C2=A0 =C2=A0 to me that it'= s time we started work on a definitive description
=C2=A0 =C2=A0 of rfc2= xml v3bis, so that we have a clear statement that open-source
=C2=A0 =C2= =A0 developers could work with.=C2=A0 This would be a good initial project<= br>=C2=A0 =C2=A0 for a new RSE (who will clearly need to be xml/html/etc.)<= br>
Cheers, Nevil
-----------------------------------
Nevil Brownl= ee, Taupo, NZ
--000000000000816e5805a43e55a0-- From nobody Mon Apr 27 05:54:35 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1C43A094F for ; Mon, 27 Apr 2020 05:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W67dHocZVVLp for ; Mon, 27 Apr 2020 05:54:31 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CFF3A0953 for ; Mon, 27 Apr 2020 05:54:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 601E1300B5A for ; Mon, 27 Apr 2020 08:54:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id e-wuYKqrckk2 for ; Mon, 27 Apr 2020 08:54:26 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id ED339300A51; Mon, 27 Apr 2020 08:54:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: Date: Mon, 27 Apr 2020 08:54:27 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nevil Brownlee X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] Some more summary points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 27 Apr 2020 12:54:33 -0000 Thanks Nevil. I find all of these interesting, and they all need = answers. Currently, the RSE is a liaison to the IETF Tools Team to coordinate = thinks associated with xml2rfc and related tools. Russ > On Apr 27, 2020, at 12:41 AM, Nevil Brownlee = wrote: >=20 > Hi all: > Here are a few more points for this list to consider ... >=20 > Need for RSE to have publishing experience? > Proposed changes to RFC Series - do other publications do anything = similar? >=20 > How could we get feedback from users of the RFC Series?=20 > For example, could we find a University to conduct some research on = this?=20 > How do researchers/developers/IPs/etc actually find out about = Standards? >=20 > Independence of RSE? > RSE serves all four Streams, we need to make sure that changes = proposed > by one Stream don't cause problems for any other Streams, >=20 > How should proposals for changes in the series be handled? > I like Brian's idea of using the rfc-interest list to discuss these, > with (my idea) the RSE acting like a "WG Chair" to monitor = discussion, > determine consensus, and document any agreed changes.. >=20 > Continuing development of xml2rfc? > Our 'new format' uses xml for it's canonical form, text, html and = pdf > versions are generated from the xml. > The specifications for xml2rfc v3 (RFCs 7990 to 7990) were developed > by a Design Team led by the RSE. > Development of tools for v3 was done by the IETF Tools Team. > The RFC Publication Centre started using them from about mid-2019, > and the Tools folk have been working on problems as they arose. > On the rfc-interest list there was discussion about this; it seems > to me that it's time we started work on a definitive description > of rfc2xml v3bis, so that we have a clear statement that = open-source > developers could work with. This would be a good initial project > for a new RSE (who will clearly need to be xml/html/etc.) >=20 > Cheers, Nevil > ----------------------------------- > Nevil Brownlee, Taupo, NZ From nobody Mon Apr 27 08:06:52 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0473A0C88 for ; Mon, 27 Apr 2020 08:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoP6Z8k1uIMb for ; Mon, 27 Apr 2020 08:06:47 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5B33A0C8A for ; Mon, 27 Apr 2020 08:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3523; q=dns/txt; s=iport; t=1588000007; x=1589209607; h=from:mime-version:subject:message-id:date:to; bh=oqT0NoNqOu0ZFd6YA/PLwo9XeBb5Aljy1i1QL0rO+20=; b=QO9V93gmu19I2DZA7wKBCAEWjOIWHHahMuaXPt798QFnOI2yAcIDTb8r 2+2KKyu0BgsIerr9GEw3bRwTy3fnKcIte8WKt+Vir2mOwdZwQ1uzdZSaa el3jMtlJV6iAGgUOHomiWcN8C85vrOKuXcKDenkuJLWb+DVNexEe4MemB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmBwAo9KZe/xbLJq1mHgELHIF4CwK?= =?us-ascii?q?DFFUgEoRJiQGHdJN0iAkLAQEBDAEBIwwEAQGEPwOCUDcGDgIDAQELAQEFAQE?= =?us-ascii?q?BAgEFBG2FVgxCARABhUd1PgKEGAGCfA+jSY4QdoEyhU+FBAaBOAGMVoIAgTg?= =?us-ascii?q?MEIIgAYYFgkUygi0EoiePe4JPBIJphSKPcR2CW4hXhFCMeZlCj3uDQwIEBgU?= =?us-ascii?q?CFYFoI4FWMxoIGxU7KgGCPz0SGA2VJopYPwNlAgYBBwEBAwmFNIloAQE?= X-IronPort-AV: E=Sophos; i="5.73,324,1583193600"; d="scan'208,217"; a="25630658" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Apr 2020 15:06:45 +0000 Received: from [10.61.250.82] ([10.61.250.82]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03RF6h00013362 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 27 Apr 2020 15:06:44 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_2812B059-93DC-4A3E-B646-B91DB6AD297A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <8DFA9B04-CA94-4661-AF9F-D3FD2CFCCD7B@cisco.com> Date: Mon, 27 Apr 2020 17:06:43 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.250.82, [10.61.250.82] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Moving forward with virtual discussions X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 15:06:50 -0000 --Apple-Mail=_2812B059-93DC-4A3E-B646-B91DB6AD297A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi there! Following up on my earlier notes, I would like to propose some times for = discussions. The purpose will be to talk through a subset of the topics = that we have generated. I=E2=80=99m sure you all understand the complexities of holding these = sorts of meetings when we have participants across many time zones; in = particular on the West Coast, East Coast, Europe, Australia, and New = Zealand (a good percentage of active participants, actually!). These = are discussions, and meant to help us zoom in on what we have to solve = for and what we can leave for later. We can discuss here which of the = summary list to start from, or I can try to arrange things in a way that = seems to make sense. I will record and take notes, but I would rather we do our real decision = making here on list, for those who cannot reasonably participate at one = time or another. Here=E2=80=99s a doodle poll: https://doodle.com/poll/thxahm2df9txamxw = Could you please fill it out by Thursday, April 30th? Thanks, Eliot= --Apple-Mail=_2812B059-93DC-4A3E-B646-B91DB6AD297A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi there!

Following up on my = earlier notes, I would like to propose some times for discussions. =  The purpose will be to talk through a subset of the topics that we = have generated.

I=E2=80=99m sure you all understand the complexities of = holding these sorts of meetings when we have participants across many = time zones; in particular on the West Coast, East Coast, Europe, = Australia, and New Zealand (a good percentage of active participants, = actually!).  These are discussions, and meant to help us zoom in on = what we have to solve for and what we can leave for later.  We can = discuss here which of the summary list to start from, or I can try to = arrange things in a way that seems to make sense.
I will record and take notes, but I = would rather we do our real decision making here on list, for those who = cannot reasonably participate at one time or another.

Here=E2=80=99s a doodle = poll:

https://doodle.com/poll/thxahm2df9txamxw

Could you please fill it = out by Thursday, April 30th?

Thanks,

Eliot
= --Apple-Mail=_2812B059-93DC-4A3E-B646-B91DB6AD297A-- From nobody Mon Apr 27 10:37:38 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593843A1242 for ; Mon, 27 Apr 2020 10:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxgtfrNJgNvs for ; Mon, 27 Apr 2020 10:37:33 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16673A1243 for ; Mon, 27 Apr 2020 10:37:33 -0700 (PDT) Received: (qmail 53112 invoked from network); 27 Apr 2020 17:37:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=cf75.5ea71858.k2004; bh=/9ok9OEvEcY2IWz53wo3qEFm10os0s9sFP7mQvJ06L4=; b=kNCZeTeeDnlwIsknur5cJgBLHxNpySJmEYZqzBnhInMS/5nKnbE3L2J8tEjf1/RuMqtVT0PG2u1NAmHt1Ve7iiUNLPcbcuQTrl/FTzWJG9Zt/oxYOaHnTh70yMzi6tMk54xFef+wCNPvnCNug2RwzharIpUiECSCf7Jiedbkd0qIYVtojeKNIqKeAeMn+oZJ2GHKn0u1BMS0po3dSSsmPuyQrUoRL5Lq0Vak2ANUIl0fVTe7DYkPQw8bE5mDWNmN Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 27 Apr 2020 17:37:28 -0000 Received: by ary.qy (Postfix, from userid 501) id EF9761878C48; Mon, 27 Apr 2020 13:37:27 -0400 (EDT) Date: 27 Apr 2020 13:37:27 -0400 Message-Id: <20200427173727.EF9761878C48@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: nevil.brownlee@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Some more summary points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 27 Apr 2020 17:37:36 -0000 In article you write: > On the rfc-interest list there was discussion about this; it seems > to me that it's time we started work on a definitive description > of rfc2xml v3bis, so that we have a clear statement that open-source > developers could work with. ... Julian and I are working on that now. The first step is to document the considerable difference between v3 and the XML that xml2rfc currently accepts. R's, John From nobody Mon Apr 27 12:10:47 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1522F3A19F2 for ; Mon, 27 Apr 2020 12:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se_dtXsrrQpl for ; Mon, 27 Apr 2020 12:10:44 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C543A19F0 for ; Mon, 27 Apr 2020 12:10:44 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id s63so19223844qke.4 for ; Mon, 27 Apr 2020 12:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=GCp00ehgoZ8DMdyrBHPwZRe/EvtkI5Go14Gavy2GByU=; b=Q8yyiH4TfHgJQ5BXqXQlIrWcA+AF3dypPw07IrS/SLia+zsDY/JhDXM1m21pGSZYJT pvacQmXHCeXTaApxz7hhZi+gKJYOrF5teGbJ9t0bucqIvqG93Za6URKQQa2mPYN32+aG 7Vq/1TeWntNtbNxGQJqz32OkgxsEULyixg8CXjoCsffdNwbTenlSTwerxt3tasz4zbj4 OqVt/QqLvFes0FW8KNbMLtEhUWtkaA1j0FXNJiy0Izncof+HZx0YpW5fyQHH+qUAfaNq EVQYtwFEDPTvC8JmOiit96dG0QicvjnDPSIWwCAn5fpufVZglYNaeWtOT6pQmzeke/dF KmTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=GCp00ehgoZ8DMdyrBHPwZRe/EvtkI5Go14Gavy2GByU=; b=YXT9r9h4sKn92AV4rnCfIzMgt53cxP/v86Rer9la1i8rNdKdrQuzdtyeVRQrdpbhJz mWFNyeKwAyP6WSFoGZwRBiCeyKj5CRO5jD3lBT0cr4mBoYBca/x+kEZMA50Jzy5AVQF1 0JnZWkHtaYQB8qnS6P2InJ+OHuq7SNt9FjhaDhsJdauwhTnEDHWWkvNRF9sMjFqkfLIZ vbmZ4WZNjm5WQTml+vYM6sr2DIBS1bkyTuQrIjUcQzq0S1BORISv9CuHhrcWR0s+Osyc Nxb6CJDncKXycglv/1kqyhGCgRtc2tU5uihkAwDXiYdMXtHCqBk54mrM+V0Kue4rD3UN MP+w== X-Gm-Message-State: AGi0PuYBhRR+cbULqky1o4bYFeDVxBs54WzbsvChTgwVs291ZpCyDzYb 0gvI6j3K1KBpXPMHqHZB6rnkrb1hdHWWGQ== X-Google-Smtp-Source: APiQypJycRL/3XYQHhueHPTenYx778WNFwyT0oQ2eTomBbmOmh7oD5naRx+QJDhWVHtRn4DEFb4ULg== X-Received: by 2002:a37:ad0d:: with SMTP id f13mr2770890qkm.7.1588014642867; Mon, 27 Apr 2020 12:10:42 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id c68sm10962212qke.121.2020.04.27.12.10.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Apr 2020 12:10:42 -0700 (PDT) From: Michael StJohns To: rfced-future@iab.org Message-ID: <74d98f83-f807-1051-9b00-2252a0459a13@nthpermutation.com> Date: Mon, 27 Apr 2020 15:10:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Rfced-future] More questions? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 27 Apr 2020 19:10:46 -0000 [I've been staying quiet not so much because I haven't anything to say, but because I've said so much over the last 6 - 8 months on this subject.   Here are the items I believe haven't yet been considered.] Questions: What level of conflicts of interest are we going to be comfortable with going forward?  [Jon/Bob/Joyce all worked for a non-profit organization and their funding for the RFC process was pretty much without strings. Heather was not originally from our community and AFAIK didn't have any contracts that would have placed her in conflict. John is active in the IETF and has an ISOC board position along with - I believe but could be wrong - other contracts directly related to IETF work.  ] What LOE for the RSE will our choices of responsibility prescribe?   [The RSE has generally costed out as just a little over 1/2 FTE - that could vary substantially based on how the RSE model is scoped and divided] What are the appropriate roles for the technical leadership of the IETF (e.g. IAB/IESG) vs appropriate roles for the administrative leadership (e.g. LLC Board and IETF Trust) with respect to the RSE/RFC series/RPC? Would a different home for the RFC series other than the IETF be appropriate (e.g. ISOC or ICANN)? Are there associations of publishers of academic and standards documents that the IETF/RSE should consider being a part of (and for that matter external publication standards to adhere to )? Problems: The selection criterias for the IAB and IESG do not include the skills of contract/employee oversight and the devolution of responsibility for the RSE from the IAB to the RSOC did not cure this problem.  Management of the RSE/RPC by committees of the IESG/IAB  or their designees should probably be a last resort. [The IETF is changing into more of a business-like entity with permanent employees and control of its own finances; perhaps take advantage of that with a look at the general model for non-profit publishing  - maybe as part of the RSE's role. ] Observation: https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPointsMade.md needs to be sorted into tactical and strategic and the tactical items (e.g. time to process, XML implementations, etc) should be deferred with prejudice until we deal with what the RSE actually is/should be/will be.  Those items might provide some flavor to the discussion, but seriously - if you need someone with XML skills to work the project for a time, you let the RSE make a selection and you hire them for a time. Observation:  Focus on the role vs focus on what we want the series to be.  These aren't either/or items, but the discussion is going to be more efficient if we focus on one or the other.  In any event, the items listed as "Do focus on what we want the series to be" are really bug reports rather than "what we want the series to be". Instead: World facing and focused publication vs "The Journal of the IETF"  (aka "Who are the customers that should have a say?") Publication for revenue vs freely available (e.g. IEEE model vs current IETF model) Well-edited vs rubber-stamped (e.g. input criteria and output criteria for the RSE processes). Stable technology vs flavor of the month  (At one point "Word Perfect" was considered the archival format for some DOD documents) Consensus-directed vs Community input with professional oversight and guidance. Mike From nobody Mon Apr 27 12:42:14 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846813A1B47 for ; Mon, 27 Apr 2020 12:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gkeocyy464e for ; Mon, 27 Apr 2020 12:42:08 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE523A1B45 for ; Mon, 27 Apr 2020 12:42:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 255E6300B53 for ; Mon, 27 Apr 2020 15:42:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id diX40vDOwaGj for ; Mon, 27 Apr 2020 15:42:05 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id F25E7300471; Mon, 27 Apr 2020 15:42:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <20200427173727.EF9761878C48@ary.qy> Date: Mon, 27 Apr 2020 15:42:06 -0400 Cc: rfced-future@iab.org, nevil.brownlee@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200427173727.EF9761878C48@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] Some more summary points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 27 Apr 2020 19:42:12 -0000 > On Apr 27, 2020, at 1:37 PM, John Levine wrote: >=20 > In article = = you write: >> On the rfc-interest list there was discussion about this; it seems >> to me that it's time we started work on a definitive description >> of rfc2xml v3bis, so that we have a clear statement that = open-source >> developers could work with. ... >=20 > Julian and I are working on that now. The first step is to document > the considerable difference between v3 and the XML that xml2rfc > currently accepts. Isn't that already in the expired = draft-levkowetz-xml2rfc-v3-implementation-notes? The recent updates may have added more things... Russ From nobody Mon Apr 27 12:54:32 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E153C3A1B79 for ; Mon, 27 Apr 2020 12:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqJ71BO5EZux for ; Mon, 27 Apr 2020 12:54:27 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C32B3A1B70 for ; Mon, 27 Apr 2020 12:54:26 -0700 (PDT) Received: (qmail 91013 invoked from network); 27 Apr 2020 19:54:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16383.5ea73870.k2004; i=johnl-iecc.com@submit.iecc.com; bh=+u0LJ3cTy0qjuFRLNWbrMUjIFrpxC15ISfLXNZ+vYBM=; b=E0ACX7E0eoKtFrcIaSsjsQ0tmVfhSDL7x8suLC0NAmWgNWLLMZkzGHWqcydbZ+tVrvbnA2a+3+Oq02qLI63f4ceWyMVbPlAz3cPsxUcZap9rikBUpndDW3MfGe4AW1fVWDYqJJyXRFQQq+f7KxBMiNAsQbewkPRSX9WN2NT0/k2cqssdTkR5FdC9IY0ZagfxcJGbBF+2CyKNkZiRz637tPP3fxpUBoeEBptm7roDJ1BQtCDP2qG5B4oU0zQSAV2s Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 27 Apr 2020 19:54:24 -0000 Date: 27 Apr 2020 15:54:24 -0400 Message-ID: From: "John R. Levine" To: "Russ Housley" Cc: rfced-future@iab.org, nevil.brownlee@gmail.com In-Reply-To: References: <20200427173727.EF9761878C48@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Rfced-future] Some more summary points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 27 Apr 2020 19:54:30 -0000 >> Julian and I are working on that now. The first step is to document >> the considerable difference between v3 and the XML that xml2rfc >> currently accepts. > > Isn't that already in the expired draft-levkowetz-xml2rfc-v3-implementation-notes? Not even close. I'm encouraging Henrik to update that, too. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Apr 27 20:34:34 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27633A0E85 for ; Mon, 27 Apr 2020 20:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkxg6VnoELD9 for ; Mon, 27 Apr 2020 20:34:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 20E153A0E7E for ; Mon, 27 Apr 2020 20:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588044860; bh=eCMo1OrLfjT6MRnZalM+ewISUP1USx/htPGTROba3vc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=GyxhIyIkeHXfe5oPQIKAlzGqSmxH5gpjZfYhn67Z1fqbyEitSKWygwoV7wU334T56 HzkgW2dKA874ZmRDurVaDmHZ46AZ9ZVrShm1GDLxWFY1DbrZeN8ffekxbDEK2hIN8V os08oBC0jFvb1HugO9TeY3V82CeImVqNn8Ur5lu0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.56.242]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MCbEp-1jJcMK3PO7-009gnT; Tue, 28 Apr 2020 05:34:19 +0200 To: Russ Housley , John Levine Cc: rfced-future@iab.org, nevil.brownlee@gmail.com References: <20200427173727.EF9761878C48@ary.qy> From: Julian Reschke Message-ID: Date: Tue, 28 Apr 2020 05:34:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:WxfcS1nlex1zfo0lZta/BNLi0wosBacNATqYGH/7rAHAyYPLzs6 yIepf4PCVnkTHdTx3VRH0nsR4G1jk1u4h/FiT5xsNP53XmSL6861hVJyCQQdEaZP0EOWufF xvPw3eL//b18ZhguYk5mfJiniV+JP+Pm8lbwW946epOG03ttFbCQo50cJO3emse9/Tf+B2n KoJo4igMxcX4wwo0f0cHQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:uoCl785/Zls=:hNC5XVQ+gxpm1ttSs5M9lG PrzK/zaXBJJM9ziH6Bc0GLVsvH8KkAtJcCzGGw0jV6yVQjG+hsbTT5TQIuFwimoh/dGktzb/g qv1bK+PQwdd+u/oh+Kr91SMRU+igBhinUR0OGRsLlQF471up1j/9GVCWNkplJGYVC8+0UyWfC 8ApqdlLEqXIVtdoSYQ3faLM45WW27I/FnC/KPODz77ut8BjroX+O3bl3K4QAcCWlDgbE37DyQ lEGr+MPfJT6M+HKF3WUv+yAl7x5nJ92gXSgWvaBgfDWpanh4mf81MxNRdwOrnKZ/yacEPOme8 JeOs2QxbBrcltlGcwo1/Rv2H6wl7uvz22hr3GWYfAjYnsKvD0qnAUGsRWxBqfKEzcgvcvJ9Y3 esE4hrzloH08/eRcTrtaTB5wKUTPjen8x+tvxfBVN04+W5hP9yNYrDJjNVanoAdb47utbhqpB mtjEKaM9MqC6wwrRZFNyEt4g/2X4MzpPufQpoC5zBZFmA1Mnt6x3n1hLMjeSFItAGflVzfrHt Tm5KybRMJ+7wFvgOimcEconVWpB0CxRNPrdvlSLpbhHWvRSJ7Gsm1SRXsNOBk4mITWmkWUlQx ahztZeR26uXSkh7iIif6fqb/CZAdnc6mJ0kAgnmNUYC05sFsBpZSGetJftrBrqu+8oJm2f7fh FoAqaejA6NuMGmJzomsk/JWtRuG9BQq3yiSYV8kbFcb865pPtgIfI1ErFkDer55+0/dhGoiQq GI2q4TGv9f8L7Xw4L86WCDvgoYDj+Yxtp8kWrMLJJhYEOQHmTUQPRHI7ja9QV/U18nWD5oKHP Mhl8ealozdukZeR0QgvWoAS1s42EQ8Yz0FGySVWKsbfUBfkflOkxrZRKYEVlHamxyCd5kxaLv EJwRDXV4VsbwWe1toncCR+fYSRcI5opM2kyHL0q52mo1TH5zZxWiUiSqt7lZos9GwDVYSc6uc uRX79jkcmEPxXI/+FMPekdSoKBS+KPYghWAq3BkDuOtald5mCCExkvidDRwMSWYom3vPCzGT0 B3EdEtMN76/zDLB0uTKB0CjFev3NdUtjnV2Ve1NTbYlveUSLX1qRiPmhBDdm2GaBi60mg3ec1 R66RRxllHQec4j/DFDzN+Dq5CtRhrJtFTjyijwGwmX+Gd5cHF6PBT2mpSucSFPZ+YEeWoKaCD hwARejymIxCqboufX7SVCFE/60Im1i6Bq2NVgMPjP7G4pTsfvpZt48dNiq+5ACMhErbpp+ofm jMXh77vLtzYGuFzn1 Archived-At: Subject: Re: [Rfced-future] Some more summary points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 28 Apr 2020 03:34:33 -0000 On 27.04.2020 21:42, Russ Housley wrote: > > >> On Apr 27, 2020, at 1:37 PM, John Levine wrote: >> >> In article you write: >>> On the rfc-interest list there was discussion about this; it seems >>> to me that it's time we started work on a definitive description >>> of rfc2xml v3bis, so that we have a clear statement that open-sourc= e >>> developers could work with. ... >> >> Julian and I are working on that now. The first step is to document >> the considerable difference between v3 and the XML that xml2rfc >> currently accepts. > > Isn't that already in the expired draft-levkowetz-xml2rfc-v3-implementat= ion-notes? > ... It's good that this document exists, but it's a collection of: - bug reports, - description of new elements (partly incomplete, partly controversial), - ideas. It also lacks concrete descriptions of how this affects the other specs (HTML, preptool, etc). Finally, we also need to align all of this with the RFC style guide. Best regards, Julian From nobody Mon Apr 27 20:36:06 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5C43A0E8A for ; Mon, 27 Apr 2020 20:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnyybHEraRKN for ; Mon, 27 Apr 2020 20:36:03 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A9E3A0E89 for ; Mon, 27 Apr 2020 20:36:02 -0700 (PDT) Received: (qmail 80767 invoked from network); 28 Apr 2020 03:36:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13b76.5ea7a4a1.k2004; bh=FCxcEPRp31i5nkWDLTDAR2l6OOw2rnL8C92fYFGh6Ms=; b=HLjFUAmxFl/yRT43oMBZbrUW5Ia+fIUzDiOWhtqi/Wz/kuRamjmyOq6pevjaKqFb67hFnIFdyUJpeBIG3/uYqFde9UeJCMEh4JzxN0vTyR3bNO4CDcmzcgO0O2pKSMo2pa1qUZr1mVHeQoLZDEFGWGnBJxeRr2egR88CDhQlSZ9XBD6i73DowegnRrUjEaq552F3SIGQsFnq40v10kXsNNnrBHH3foPU/TbwvX3Pq9C34vnvUP42UIXjM8Xs58yi Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 28 Apr 2020 03:36:01 -0000 Received: by ary.qy (Postfix, from userid 501) id 2643A187DACF; Mon, 27 Apr 2020 23:36:00 -0400 (EDT) Date: 27 Apr 2020 23:36:00 -0400 Message-Id: <20200428033601.2643A187DACF@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: msj@nthpermutation.com In-Reply-To: <74d98f83-f807-1051-9b00-2252a0459a13@nthpermutation.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] More questions? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 28 Apr 2020 03:36:05 -0000 In article <74d98f83-f807-1051-9b00-2252a0459a13@nthpermutation.com> you write: >contracts that would have placed her in conflict. John is active in the >IETF and has an ISOC board position along with - I believe but could be >wrong - other contracts directly related to IETF work.  ] I'm on the ISOC board appointed by the IAB, which is unpaid. Other than that I'm an unpaid member of the ICANN SSAC, unpaid president of anti-spam advocacy group CAUCE, I have a contract with ICANN to test how well some mail software and services support EAI, and I do some expert witness stuff. The IETF LLC hs a very strong CoI policy so I'll recuse from ISOC board debates about the IETF budget, should there be any. R's, John From nobody Mon Apr 27 21:03:11 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CCD3A076E for ; Mon, 27 Apr 2020 21:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSha9UY04YlR for ; Mon, 27 Apr 2020 21:03:02 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E243A05E2 for ; Mon, 27 Apr 2020 21:03:02 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id y6so550613pjc.4 for ; Mon, 27 Apr 2020 21:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=qslfMQSBRFRsMNrTzsCrdbb7j0lLCWQP97ccWafRwxw=; b=vG234vwNmtIsa7TEQB1RSPV6u7NF4Ske47kqkWhRBADoYX7BH95BD84uazpBdYIyad rZDKCcFVCW6UZtCGaNeXBfYXIoJDNXi+FFd89MsxBEHDG5mpfa/1um04tHsBdsLngX/B V39erYwTx1PMCu1ilBT2o64sDPqOaUv3QqcWndsFR2KjvfT9L0vieU3aXtZL7N8b4oqd 5jaU/XkxwYM6cO9GCGKLnivqHZJkpW4OsiFRgXV3AztfGdz74wOw4FefJ+6ZfItS/LRJ lWAVuFDZQNBnzL37t2y5Axgolazph9KxqN+S5zrpOFdXX//Ag1eD6ke263s+sRDXNffS Qz6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=qslfMQSBRFRsMNrTzsCrdbb7j0lLCWQP97ccWafRwxw=; b=AHVHbHJfU3oD08p4Ja3mu2XAbEOF4KiidKnOsDGlZiOQ6julxuzSuU9vpQkR3+niCA ngVw9lOWO8JtTSciBfi6YzuK8d+zEtnPYJEDp5+akL7r6jQV8tC0sIaJJGmBzU4fITBE xYiwhRFbzL9wn/16bWRjdZ5R52xOawTL9PuYtO6AVSk/HejsmI6Nuo+i3t3jujqyLC9R fRPGAsBi3aBzhvsouwfS7WUZUGILXKbiBk5wO1efgVo7wKIiBs4/g0WPb8HHDMCjV58z c09CjXIAyZTsqwTS9nCk75oAJsCFGkCNnCqmG4RZNREYLQKF/PLj+DXykwp4rkaIaYft Jehg== X-Gm-Message-State: AGi0PubEaL/1qVnKQpQU+nkkweMt13GjmhTGeyRVD7aoXmOChl7Z1zYg 8wmG5HYVD4CbL3nTEl/6Q0U= X-Google-Smtp-Source: APiQypI6/fSIAfZzo3pKV7BKP+wsDyg/TxlQ3viKi/0VCbmFFQd9rCjDH0EzW8Hzeii4ED1juBJNfw== X-Received: by 2002:a17:902:bc8c:: with SMTP id bb12mr25215158plb.142.1588046581248; Mon, 27 Apr 2020 21:03:01 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id y21sm6546209pge.42.2020.04.27.21.03.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2020 21:03:00 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Russ Housley'" , "'Nevil Brownlee'" Cc: , "'Anne van Kesteren'" References: In-Reply-To: Date: Mon, 27 Apr 2020 21:03:00 -0700 Message-ID: <004701d61d11$e8b3b7f0$ba1b27d0$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQCPFQktCcasiexzZ98NPzEUJDE9CQFyLufnqw/mHXA= Content-Language: en-us Archived-At: Subject: Re: [Rfced-future] Some more summary points X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 28 Apr 2020 04:03:09 -0000 > > How could we get feedback from users of the RFC Series? I think the "other SDOs" should be a priority for several additional reasons * There are areas of overlap where the entire suite of standards used by any implementation cross multiple SDOs * There are areas of overlap when there isn't clarity about scope and 'jurisdiction', and specs diverging further over time [1] * There is the problems of versioning and normative references between different series. * They have similar audiences for specs and ideas for how to address them; we can compare notes. For the web I'd ask W3C (process committee), WHATWG, Maybe ECMA (for JavaScript), ISO, Unicode Consortium, IEEE, others? I'd suggest inviting a discussion through liaisons or directly. -- https://LarryMasinter.net https://going-remote.info *The particular case I have in mind is the divergence between RFC series specs and standards vs the URL "Living Standard". https://tools.ietf.org/html/draft-ruby-url-problem-01 From nobody Tue Apr 28 00:15:16 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875933A0D43 for ; Tue, 28 Apr 2020 00:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4-T9hkWcGIu for ; Tue, 28 Apr 2020 00:15:13 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36113A0D41 for ; Tue, 28 Apr 2020 00:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=976; q=dns/txt; s=iport; t=1588058112; x=1589267712; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/4wfLEQdV6oQWWfQZAtTtkeZ5RLOmP6GFF0+Ahw8oA8=; b=iN7G+iwW05nim2FnrabQbQIcOlxIpqtQ9TXGm1kQqJa9P9u05PqC+VFP IqbxeybN6wSedm+NbxRcHzRX2fzonCzq3pYUySn40be8Y0llLT3YIQE8j F7I2b043pydb3alrvqV98HWjLrljb/Www+Zeg11aQUM6zF/d0nTC6vD33 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxBgDh1qde/xbLJq1mHQEBAQkBEQU?= =?us-ascii?q?FATyBRwKDFFUgEiqEH4kBh3QlmXGBZwsBAQEMAQElCgQBAYREAoJMOBMCAwE?= =?us-ascii?q?BCwEBBQEBAQIBBQRthSoGJgxCARABhR0BAQEBAgEjVgULCxoCJgICVwaDOQG?= =?us-ascii?q?CXCAPsgZ2gTKFT4UNBoEOKgGMVoIAgTgMEIJNPoJnAoEwARIBIYMSMoItBLI?= =?us-ascii?q?igk+CbYUij3EdgluNJyeMUplCj3uDQwIEBgUCFYFpImZwMxoIGxVlAYI+PhI?= =?us-ascii?q?YDY9PhVeKWD8DMDUCBgEHAQEDCYU0iWgBAQ?= X-IronPort-AV: E=Sophos;i="5.73,327,1583193600"; d="scan'208";a="25715450" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Apr 2020 07:15:10 +0000 Received: from [10.61.172.32] ([10.61.172.32]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 03S7F8ZJ017193 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Apr 2020 07:15:10 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <74d98f83-f807-1051-9b00-2252a0459a13@nthpermutation.com> Date: Tue, 28 Apr 2020 09:15:08 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <7505E99D-88D3-4789-ADCD-5BE4604C2B4E@cisco.com> References: <74d98f83-f807-1051-9b00-2252a0459a13@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.172.32, [10.61.172.32] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] More questions? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 28 Apr 2020 07:15:16 -0000 Hi Mike, > Observation: = https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandP= ointsMade.md needs to be sorted into tactical and strategic and the = tactical items (e.g. time to process, XML implementations, etc) should = be deferred with prejudice until we deal with what the RSE actually = is/should be/will be. =20 This seems to me a very good and useful approach. We might want to take = one intermediate step: the chicken scratch you read on GitHub requires = just a bit of elaboration, particular in the summary points, to be clear = on what each point means, whether it is worth keeping, and what needs to = be there as well. We have that text in emails, but I=E2=80=99m thinking = that we could use some snippets for each point (a paragraph or two, no = more). That way we know precisely what we=E2=80=99re prioritizing and = deferring. Thoughts? Eliot Ps: I=E2=80=99ve updated that file based on your email.= From nobody Tue Apr 28 13:29:45 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F7F3A0C6B for ; Tue, 28 Apr 2020 13:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWnIBW7La4UV for ; Tue, 28 Apr 2020 13:29:42 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FB13A0C69 for ; Tue, 28 Apr 2020 13:29:42 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id x26so11023298pgc.10 for ; Tue, 28 Apr 2020 13:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=j2yUjXl0qZ7x1hgzyVWx6SMWZqfWfzqaNcyDTto1Pik=; b=clFKDAf1YYzOOfrc8Otk5oTecnaRk19arcLBJHpLQIZ4ZCN2DiylcheCl+tNi+iaK5 ddGBpgQLTv9sGZ9cDSuhWRxX4CPL7OcnnQu+lML8TdDUJMlpFY/iLjzfYTbaLLtCphPu NDB2Ow2UC1BJZ4103UaGL1LeSHgHOooiXl4t2uW7mBRzMIpxMIefchmS3dwYXg26HaBo WpKDycw1+HI8zn7BFlVdJQYVRR/pgT9fGEVqa48tXpPvnKNxpX4XTzS1ZoTrUZZ4wmBt E75w2Ab76NBV6OCnvoSqd3iPEDNOBhH9zPhiS7IMqA6l6K/F/ai+7f4Z/at5C6JvQQHB Avvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding:content-language; bh=j2yUjXl0qZ7x1hgzyVWx6SMWZqfWfzqaNcyDTto1Pik=; b=ahoEmXsV8Kqnf1vNQuK/iB0dXuD4iCvReF9O07Ch0CL0iIJj/3/1Jd+mCpZinMEah3 WNwByEGX1y4W08m2GdmI/f6Qx6s3WMZnpudEtEigxvclKYJKE2wFQ1l7dsloxvtLBQEC 9eK20AG3rdU1Htlvoa/7xdenHHR8/q72+UOLxSZaONziOWmOZl/3UhKfZUVnitfGwm6f t7be3Yehf9qAgEYUh5ECsFlYjJJebfRZd+xIJHtddaKBkrWCJFxrHCX+LrZLMDmP8dMc b9kHz9WP+6UjeghxwUywHn3Ka08iX6FhZLF4HT0Yx+Z0CrquhF5/J3Pr6Jt+uBXR0I/3 reXQ== X-Gm-Message-State: AGi0PuYZMGtoVFCaL7vf1iJya1L4mv9TutUD0YoByA3u5q7jGXLNxCAF IJp2gnqds9MOXj4JFSQgcQiHXEUheyPr X-Google-Smtp-Source: APiQypKjd+zp4NnMn84y7PP4yUU0qDlfhyMlQDM3ZZI61ILuSuC7ZQzTpqUxSDcc0SBwAsA9VsBCpQ== X-Received: by 2002:a63:7b05:: with SMTP id w5mr31015236pgc.220.1588105781494; Tue, 28 Apr 2020 13:29:41 -0700 (PDT) Received: from [192.168.1.7] ([174.27.176.157]) by smtp.googlemail.com with ESMTPSA id bg6sm2743337pjb.21.2020.04.28.13.29.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 13:29:39 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org Organization: http://SoftwareAndServices.NET Message-ID: Date: Tue, 28 Apr 2020 14:29:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Rfced-future] Wow - lots of directions - any needed first? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 28 Apr 2020 20:29:44 -0000 I am on the list because I think it would be great to help the 'I's. My experiences in this area are almost all as a consumer/reader of drafts and RFCs. There are a lot of issues and directions on this list. Personally, I can't determine priority with the lists as I have never done day to day interactions with the RSE. Are there any contractual, personnel, or other immediate priorities? No one has posted any, so I assume the answer is "no". I would think that making sure that any new process flows smoothly and that changes are minimally disruptive to the efficiency and persons doing the work. Upsetting people with too many changes in a short amount of time with little or no training time can cause discourse and this process might have to start over. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Tue Apr 28 14:10:25 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE043A0045 for ; Tue, 28 Apr 2020 14:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYllJJyn1oDz for ; Tue, 28 Apr 2020 14:10:21 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3C43A003D for ; Tue, 28 Apr 2020 14:10:20 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id w18so106680qvs.3 for ; Tue, 28 Apr 2020 14:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=3sBgrVW9gFkozLdTxIciCeobhVcO1bpA/6FEbd6iAIc=; b=VXCJh51ZFop1ia3a1rlInHrHlY3cZqJeb/sLj9XaqYQBICBs5IAtUrTrNz4Krey972 eK2zZSk8cjV7+4vwqEOTdCmJruBG71W3bpOVshZr22lPHCwouy11Y0Ypu+7zFfRIxi4j 5eV57Onxk7yF76hwqQ+ACKAAEslYwG6vqUw+O3ltDJpio9s8BRqlzzzcv/aphZr4gV6W mzf/n4aUwQ5GdFzENeYatlbFoAcfT9mNjbjE+VhVFE3kFqTLmBKMHJfi8x5h3Ybrey8g S7TnqCFeMAi/1r6GUjUG2CS/Fax9wTMjiGBqdGwgDQ1qoDwWwfKdN4SitjgP5h03ZpXP nC1Q== 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=3sBgrVW9gFkozLdTxIciCeobhVcO1bpA/6FEbd6iAIc=; b=a1tgeR44m9IA5KlLA0mNHqcdDBBkgxpXajFqa1YBoufHMX/fknfXuIhGepVS4DQIKQ 1S6jYlUcwnbiITipI4kUm1lqBAF0NWuaKZ3MwwFZMlQ2f+yLCrWff9tKpsiBEPgGPMbt laPE6Zsm2cu/vR1E0ngif9Aa5tZoK3WO02z1rwplC4xvlkbDYtqAAaxcl53l+ED3KrjJ Uz9ay4a/wIZMTBsGOiyJ/foPmivpdL3/9zaV3SNP4jKOuqiUr4s7A8BwIiz14xzB+c+s T90FOz97dBVg7JfAAEWXur1bSpchcKASFmVnJA7NoMPx6KUclVwvLsueFr/koJrEKCTV OYGg== X-Gm-Message-State: AGi0PuYZEk1owxGip7Zv1imdiJT1jxT66k2NGWJWvWIEYJM5/hGbz6l/ gtAvQH2bjDNWZaENdvPk5dWnARCXVxioRg== X-Google-Smtp-Source: APiQypJFDJG5ebsGM8oWEidOxG6DzcbjmQnQwj+XmRF7wX9wnq6VTnGsnl7TZ/w/c+MzbqjUTgftKQ== X-Received: by 2002:a0c:90ef:: with SMTP id p102mr29378826qvp.248.1588108219168; Tue, 28 Apr 2020 14:10:19 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id p47sm14946958qta.44.2020.04.28.14.10.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 14:10:17 -0700 (PDT) To: Eliot Lear Cc: rfced-future@iab.org References: <74d98f83-f807-1051-9b00-2252a0459a13@nthpermutation.com> <7505E99D-88D3-4789-ADCD-5BE4604C2B4E@cisco.com> From: Michael StJohns Message-ID: Date: Tue, 28 Apr 2020 17:10:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <7505E99D-88D3-4789-ADCD-5BE4604C2B4E@cisco.com> Content-Type: multipart/alternative; boundary="------------3BA3ED0F43CE66A5A57F32F4" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] More questions? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 28 Apr 2020 21:10:24 -0000 This is a multi-part message in MIME format. --------------3BA3ED0F43CE66A5A57F32F4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Would you mind going back and taking another whack at integrating my comments: > The selection criterias for the IAB and IESG do not include the skills > of contract/employee oversight and the devolution of responsibility for > the RSE from the IAB to the RSOC did not cure this problem.  Management > of the RSE/RPC by committees of the IESG/IAB  or their designees should > probably be a last resort. (what I wrote) Does not appear to equal > Do the IAB/IESG have the right skill sets to oversee the RSE? > (the above strongly implies that the IAB/IESG by right have the oversight of the RSE which is actually one of the things we need to determine - my problem statement was factual with respect to the first sentence and implies that if either of these groups is involved in "oversight", then the Nomcom selection criteria needs to change.  Personally, I think that would be a bad thing as it would make finding candidate just that much harder or would tend to cede responsibility and authority over the RSE to a subset of those groups in non-optimal ways) Nor does > What are the appropriate roles for the technical leadership of the IETF > (e.g. IAB/IESG) vs appropriate roles for the administrative leadership > (e.g. LLC Board and IETF Trust) with respect to the RSE/RFC series/RPC? Match > What roles are defined and is their relationship to one another? > > * RSE, RSOC, IAB, IESG, Stream managers, LLC, ED, others? > Neither the RSOC, Stream Managers nor ED are technical or administrative leadership (and are certainly not directly responsible to the community), and the relationship of the RSE to those to the technical/admin leadership will inform a) whether there will be an RSOC  or an RSOC like body going forward, b) the relationship of the ED to the RSE, and c) the role of stream managers (as designees of the various technical bodies - IESG/IAB/IRTF) in relationship to those bodies and to community with respect to the series evolution and long-term strategy. E.g. Three of these things are not like the others at this point in time. At this point - with the possible exception of "tooling responsibility", I'm pretty happy with the "role" questions.    The relationships and lines of authority questions are defer-able in the details, but should be broadly sketched among  IETF Technical Leadership, IETF Administrative Leadership, RSE, and RFC community with the caveat that "lines of authority" need to avoid matrix management.  E.g. if the phrase "day to day oversight" shows up at this point, its probably the wrong level of discussion.  Whereas "Acts as the POC for providing guidance on the publication needs of the IETF standards process as interpreted by the technical leadership" - an "ask" vs a "directive" perhaps or somewhere on that spectrum.   I mostly think that the items listed under "what we want from the series" are either bug reports or tactical issues and can be deferred in favor of items that are descriptive of what we want the perception of the series to be (e.g my comment on world publication vs IETF house organ and the other 4 spectrums in that list).  That comment carries forward into the "points made" section.   The list here is all over the place and I'll attempt to do an edit in the next week or so with my suggestions on what we work on first and what can and should be deferred. Mike On 4/28/2020 3:15 AM, Eliot Lear wrote: > Hi Mike, > > >> Observation: https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPointsMade.md needs to be sorted into tactical and strategic and the tactical items (e.g. time to process, XML implementations, etc) should be deferred with prejudice until we deal with what the RSE actually is/should be/will be. > > This seems to me a very good and useful approach. We might want to take one intermediate step: the chicken scratch you read on GitHub requires just a bit of elaboration, particular in the summary points, to be clear on what each point means, whether it is worth keeping, and what needs to be there as well. We have that text in emails, but I’m thinking that we could use some snippets for each point (a paragraph or two, no more). That way we know precisely what we’re prioritizing and deferring. > > Thoughts? > > Eliot > > Ps: I’ve updated that file based on your email. --------------3BA3ED0F43CE66A5A57F32F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Would you mind going back and taking another whack at integrating my comments:

The selection criterias for the IAB and IESG do not include the skills 
of contract/employee oversight and the devolution of responsibility for 
the RSE from the IAB to the RSOC did not cure this problem.  Management 
of the RSE/RPC by committees of the IESG/IAB  or their designees should 
probably be a last resort.
(what I wrote)

Does not appear to equal 

Do the IAB/IESG have the right skill sets to oversee the RSE?
(the above strongly implies that the IAB/IESG by right have the oversight of the RSE which is actually one of the things we need to determine - my problem statement was factual with respect to the first sentence and implies that if either of these groups is involved in "oversight", then the Nomcom selection criteria needs to change.  Personally, I think that would be a bad thing as it would make finding candidate just that much harder or would tend to cede responsibility and authority over the RSE to a subset of those groups in non-optimal ways)

Nor does 
What are the appropriate roles for the technical leadership of the IETF 
(e.g. IAB/IESG) vs appropriate roles for the administrative leadership 
(e.g. LLC Board and IETF Trust) with respect to the RSE/RFC series/RPC?
Match
What roles are defined and is their relationship to one another?
  • RSE, RSOC, IAB, IESG, Stream managers, LLC, ED, others?

Neither the RSOC, Stream Managers nor ED are technical or administrative leadership (and are certainly not directly responsible to the community), and the relationship of the RSE to those to the technical/admin leadership will inform a) whether there will be an RSOC  or an RSOC like body going forward, b) the relationship of the ED to the RSE, and c) the role of stream managers (as designees of the various technical bodies - IESG/IAB/IRTF) in relationship to those bodies and to community with respect to the series evolution and long-term strategy.   E.g. Three of these things are not like the others at this point in time.

At this point - with the possible exception of "tooling responsibility", I'm pretty happy with the "role" questions.    The relationships and lines of authority questions are defer-able in the details, but should be broadly sketched among  IETF Technical Leadership, IETF Administrative Leadership, RSE, and RFC community with the caveat that "lines of authority" need to avoid matrix management.  E.g. if the phrase "day to day oversight" shows up at this point, its probably the wrong level of discussion.  Whereas "Acts as the POC for providing guidance on the publication needs of the IETF standards process as interpreted by the technical leadership" - an "ask" vs a "directive" perhaps or somewhere on that spectrum.   I mostly think that the items listed under "what we want from the series" are either bug reports or tactical issues and can be deferred in favor of items that are descriptive of what we want the perception of the series to be (e.g my comment on world publication vs IETF house organ and the other 4 spectrums in that list).  That comment carries forward into the "points made" section.   The list here is all over the place and I'll attempt to do an edit in the next week or so with my suggestions on what we work on first and what can and should be deferred. 

Mike



On 4/28/2020 3:15 AM, Eliot Lear wrote:
Hi Mike,



Observation: https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPointsMade.md needs to be sorted into tactical and strategic and the tactical items (e.g. time to process, XML implementations, etc) should be deferred with prejudice until we deal with what the RSE actually is/should be/will be.  


This seems to me a very good and useful approach.  We might want to take one intermediate step: the chicken scratch you read on GitHub requires just a bit of elaboration, particular in the summary points, to be clear on what each point means, whether it is worth keeping, and what needs to be there as well.  We have that text in emails, but I’m thinking that we could use some snippets for each point (a paragraph or two, no more).  That way we know precisely what we’re prioritizing and deferring.

Thoughts?

Eliot

Ps: I’ve updated that file based on your email.


--------------3BA3ED0F43CE66A5A57F32F4-- From nobody Wed Apr 29 02:34:20 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AC43A0A96 for ; Wed, 29 Apr 2020 02:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtRmlp-7K1X5 for ; Wed, 29 Apr 2020 02:34:14 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF483A0A93 for ; Wed, 29 Apr 2020 02:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13544; q=dns/txt; s=iport; t=1588152854; x=1589362454; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=fdUYu8yMBCks9yCEqCwC56E5tflIRm23ebnvE90NVQ8=; b=MKvpcs5oyCI07nFjiCjleCuJqtOURDzdfQ7oEtzG3LI240U1nveitSIv 6n+Ys7LKZaV+8cpZGJVURCaN1A+1dbUbsx2aA0QD4eEg9miFqFfsUY1mF 7FLZd51zGTDC9hkb/yuJcen2ECGy8uR/s0NdM8Ra8HSppJD5V/c/B8t3h E=; X-IPAS-Result: =?us-ascii?q?A0CyAQB9Sale/xbLJq1mGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAYIHAoF2gSBUASASKoQhiQGHeCWTT4gLCwEBAQwBASUKBAEBhEQCglA4E?= =?us-ascii?q?wIDAQEBAwIDAQEBAQUBAQECAQUEbYVWDEIBEAGFHQEBAQECASNEBAcHBQsLG?= =?us-ascii?q?CoCAlcGExSDEgGCXCAPsjJ2gTKEOQGBFoUfBoE4AYxaggCBEScMEIJNPoJnA?= =?us-ascii?q?gOEdDOCLQSOFBFBk06QAYJPgm6FJYFxjgMdgluNLI0AmVCPf4NDAgQGBQIVg?= =?us-ascii?q?WkigVYzGggbFTsqAYIKAQEyPhIYDZJHF4hjhUQ/AzA2AgYBBwEBAwmHL4s7A?= =?us-ascii?q?QE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.73,331,1583193600"; d="scan'208,217"; a="23433041" 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; 29 Apr 2020 09:34:09 +0000 Received: from [10.61.173.2] ([10.61.173.2]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03T9Y8vi008116 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Apr 2020 09:34:09 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CBF3A97C-E489-462E-85B7-583DBF70B6C5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 29 Apr 2020 11:34:08 +0200 In-Reply-To: Cc: rfced-future@iab.org To: Michael StJohns References: <74d98f83-f807-1051-9b00-2252a0459a13@nthpermutation.com> <7505E99D-88D3-4789-ADCD-5BE4604C2B4E@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.173.2, [10.61.173.2] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] More questions? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 29 Apr 2020 09:34:17 -0000 --Apple-Mail=_CBF3A97C-E489-462E-85B7-583DBF70B6C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, > On 28 Apr 2020, at 23:10, Michael StJohns = wrote: >=20 > Would you mind going back and taking another whack at integrating my = comments: >=20 >> >>The selection criterias for the IAB and IESG do not include the = skills=20 >> of contract/employee oversight<< and the devolution of responsibility = for=20 >> the RSE from the IAB to the RSOC did not cure this problem. = Management=20 >> of the RSE/RPC by committees of the IESG/IAB or their designees = should=20 >> probably be a last resort. >=20 > (what I wrote) >=20 > Does not appear to equal =20 >=20 >> Do the IAB/IESG have the right skill sets to oversee the RSE? = I=E2=80=99ve added your assertion above in the document (see toward the = bottom). And remember, that document is just meant as a means to = facilitate discussion. The bold is what is captured as a summary = question (as the others are). For everyone=E2=80=99s reference, one can = find the =E2=80=9CDesired Expertise=E2=80=9D for IAB and IESG members = for the 2019 selection process here = . I=E2=80=99ve = added that to the reading list. Note that the IAB role hasn=E2=80=99t = changed all that much since I served.=20 > Nor does=20 >> What are the appropriate roles for the technical leadership of the = IETF=20 >> (e.g. IAB/IESG) vs appropriate roles for the administrative = leadership=20 >> (e.g. LLC Board and IETF Trust) with respect to the RSE/RFC = series/RPC? > Match=20 >> What roles are defined and [what] is their relationship to one = another? >> RSE, RSOC, IAB, IESG, Stream managers, LLC, ED, others? >=20 Others have made comments along these same lines.[1][2][3][4] I=E2=80=99m= trying (perhaps not succeeding) to capture all of that. And again, = these are questions and you can ask others, some of which may be more = important than anything I wrote. > Neither the RSOC, Stream Managers nor ED are technical or = administrative leadership (and are certainly not directly responsible to = the community), and the relationship of the RSE to those to the = technical/admin leadership will inform a) whether there will be an RSOC = or an RSOC like body going forward, b) the relationship of the ED to the = RSE, and c) the role of stream managers (as designees of the various = technical bodies - IESG/IAB/IRTF) in relationship to those bodies and to = community with respect to the series evolution and long-term strategy. = E.g. Three of these things are not like the others at this point in = time. I may have caused some confusion with the summary, which is that it is = intended to help people think about what they want, not so much to = describe where we are today or where we have been. Perhaps I should = clarify that. The point of the question is for people to be able to = answer in their own proposed approaches who the players are, and how = they relate to one another. Nothing more. >=20 > At this point - with the possible exception of "tooling = responsibility", I'm pretty happy with the "role" questions. The = relationships and lines of authority questions are defer-able in the = details, but should be broadly sketched among IETF Technical = Leadership, IETF Administrative Leadership, RSE, and RFC community with = the caveat that "lines of authority" need to avoid matrix management. = E.g. if the phrase "day to day oversight" shows up at this point, its = probably the wrong level of discussion. Whereas "Acts as the POC for = providing guidance on the publication needs of the IETF standards = process as interpreted by the technical leadership" - an "ask" vs a = "directive" perhaps or somewhere on that spectrum. I mostly think that = the items listed under "what we want from the series" are either bug = reports or tactical issues and can be deferred in favor of items that = are descriptive of what we want the perception of the series to be (e.g = my comment on world publication vs IETF house organ and the other 4 = spectrums in that list). That comment carries forward into the "points = made" section. The list here is all over the place and I'll attempt to = do an edit in the next week or so with my suggestions on what we work on = first and what can and should be deferred. =20 Looking forward to it! Eliot [1] = https://mailarchive.ietf.org/arch/msg/rfced-future/x1OMhYw7Rm0fag_LGfCTdKU= Npus/ [2] = https://mailarchive.ietf.org/arch/msg/rfced-future/BVMr_Mo7618VcdTBkx2T3im= -SzA/ [3] = https://mailarchive.ietf.org/arch/msg/rfced-future/nAJlr9e7_ROZqPN1NomTb43= iAWc/ [4] = https://mailarchive.ietf.org/arch/msg/rfced-future/mACM0l8ASnbJkkhPxDfRSyt= Pkww/ --Apple-Mail=_CBF3A97C-E489-462E-85B7-583DBF70B6C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mike,

On 28 Apr 2020, at 23:10, Michael StJohns = <msj@nthpermutation.com> wrote:

=20
Would you mind going back and taking another whack at integrating my comments:

>>The selection =
criterias for the IAB and IESG do not include the skills=20
of contract/employee oversight<< and the devolution of =
responsibility for=20
the RSE from the IAB to the RSOC did not cure this problem.  =
Management=20
of the RSE/RPC by committees of the IESG/IAB  or their designees =
should=20
probably be a last resort.
(what I wrote)

Does not appear to equal 

Do the IAB/IESG have the = right skill sets to oversee the = RSE?


I=E2=80=99ve added your = assertion above in the document (see toward the bottom).  And = remember, that document is just meant as a means to facilitate = discussion.   The bold is what is captured as a summary question = (as the others are).  For everyone=E2=80=99s reference, one can = find the =E2=80=9CDesired Expertise=E2=80=9D for IAB and IESG members = for the 2019 selection process here.  I=E2=80=99ve added that to the reading list. =  Note that the IAB role hasn=E2=80=99t changed all that much since = I served. 

=
Nor does 
What are the appropriate roles for the =
technical leadership of the IETF=20
(e.g. IAB/IESG) vs appropriate roles for the administrative leadership=20=

(e.g. LLC Board and IETF Trust) with respect to the RSE/RFC =
series/RPC?
Match
What roles are defined and = [what] is their relationship to one another?
  • RSE, RSOC, IAB, IESG, Stream managers, LLC, ED, = others?



Others have made = comments along these same lines.[1][2][3][4]  I=E2=80=99m trying = (perhaps not succeeding) to capture all of that.  And again, these = are questions and you can ask others, some of which may be more = important than anything I wrote.


=
Neither the RSOC, Stream Managers nor ED are technical or administrative leadership (and are certainly not directly responsible to the community), and the relationship of the RSE to those to the technical/admin leadership will inform a) whether there will be an RSOC  or an RSOC like body going forward, b) the relationship of the ED to the RSE, and c) the role of stream managers (as designees of the various technical bodies - IESG/IAB/IRTF) in relationship to those bodies and to community with respect to the series evolution and long-term = strategy.   E.g. Three of these things are not like the others at this point in time.

I may have caused some confusion with the summary, = which is that it is intended  to help people think about what they = want, not so much to describe where we are today or where we have been. =  Perhaps I should clarify that.  The point of the question is = for people to be able to answer in their own proposed approaches who the = players are, and how they relate to one another.  Nothing = more.


At this point - with the possible exception of "tooling responsibility", I'm pretty happy with the "role" questions.    The relationships and lines of = authority questions are defer-able in the details, but should be broadly sketched among  IETF Technical Leadership, IETF = Administrative Leadership, RSE, and RFC community with the caveat that "lines of authority" need to avoid matrix management.  E.g. if the = phrase "day to day oversight" shows up at this point, its probably the wrong level of discussion.  Whereas "Acts as the POC for = providing guidance on the publication needs of the IETF standards process as interpreted by the technical leadership" - an "ask" vs a "directive" perhaps or somewhere on that spectrum.   I = mostly think that the items listed under "what we want from the series" are either bug reports or tactical issues and can be deferred in favor of items that are descriptive of what we want the perception of the series to be (e.g my comment on world publication vs IETF house organ and the other 4 spectrums in that list).  That = comment carries forward into the "points made" section.   The = list here is all over the place and I'll attempt to do an edit in the next week or so with my suggestions on what we work on first and what can and should be deferred. 


Looking forward to it!

Eliot


= --Apple-Mail=_CBF3A97C-E489-462E-85B7-583DBF70B6C5-- From nobody Wed Apr 29 09:16:32 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFFF3A137D for ; Wed, 29 Apr 2020 09:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlQkwIHdGsJm for ; Wed, 29 Apr 2020 09:16:29 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B133A1377 for ; Wed, 29 Apr 2020 09:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8126; q=dns/txt; s=iport; t=1588176989; x=1589386589; h=from:mime-version:subject:message-id:references:to:date; bh=/nCu4RQQIVrR3SR73TeE8VyIvM4lBsArMqq7Wh23O/Y=; b=dAOLMJ2jven7d20thuomVoRGEYCdnB5e3uWgwumF9qblWpPd3qqLfKJF XVb9AOf5KyUBPdHmgLdAh54LPeGPg/D6CegnM/BZIozhdsh/5yYG530Tv gMi09egb2orhithFUzJL+j+JpeT0+BUsZ8/ero+d3hZvsQDX4xBMuB21i g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeBQCEp6le/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCBwKDFlQBIBIqhCGJAYgLk0+GJIFnCwEBAQwBARgBDAoEAQG?= =?us-ascii?q?ERAKCUTgTAgMBAQsBAQUBAQECAQUEbYVWDEIBEAGFHQEBAgIBAQEbBksQCxw?= =?us-ascii?q?DAQIrAgInHwcCCBkUgxIBglwgD7JgdoEyhVCFGAaBOAGMWoIAgTgcgU9+PoJ?= =?us-ascii?q?nAQGBMAESAUGCcjOCLQSyNYJPgm6VGRYHgluIW4RRjQCpT4NDAgQGBQIVgWk?= =?us-ascii?q?iZnAzGggbFTsqAYIKATM+EhgNV5IciE6FRD8DMDYCBgEHAQEDCYcviHgtghY?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos; i="5.73,332,1583193600"; d="scan'208,217"; a="25768857" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2020 16:16:24 +0000 Received: from [10.61.246.165] ([10.61.246.165]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03TGGNx6022704 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 29 Apr 2020 16:16:24 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_1A091B89-F6F6-455F-9D70-9E7857F8542D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: References: <158817626483.12757.9903234159000076366@ietfa.amsl.com> To: rfced-future@iab.org Date: Wed, 29 Apr 2020 18:16:23 +0200 X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.246.165, [10.61.246.165] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Fwd: Reminder: Call for nominations: RFC Editor Future Development Program Chair(s) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 29 Apr 2020 16:16:32 -0000 --Apple-Mail=_1A091B89-F6F6-455F-9D70-9E7857F8542D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI. If you have any questions I can answer, I=E2=80=99d be happy to talk. Eliot > Begin forwarded message: >=20 > From: IAB Executive Administrative Manager > Subject: Reminder: Call for nominations: RFC Editor Future Development = Program Chair(s) > Date: 29 April 2020 at 18:04:26 CEST > To: "IETF Announcement List" > Reply-To: iab-chair@iab.org, execd@iab.org >=20 > As previously discussed, the IAB is seeking an additional chair or=20 > chairs for the RFC Editor Future Development Program [1]. >=20 > This program is modeled on an IETF working group, and will use its=20 > mailing list (rfced-future@iab.org) to develop and validate consensus=20= > among the participants.=20 >=20 > The program currently has one chair, Eliot Lear. The current IAB has=20= > received significant feedback from the community that a second chair=20= > needs to be selected, and the IAB is eager to fill that position with = a=20 > great candidate as soon as is practical. The IAB is now seeking at = least=20 > one additional chair from outside the IAB to join Eliot. Together, = these=20 > chairs will set the detailed agenda, manage the program, and call=20 > consensus among the participants. The program also has two liaisons = from=20 > the IAB to assist with logistical matters, Wes Hardaker and Jared = Mauch. >=20 > If you are interested in serving in this role, please send a short = email=20 > message to iab-chair@iab.org and execd@iab.org with your motivation = and=20 > information concerning your familiarity with IETF working groups or=20 > similar processes. The deadline for volunteering is Tuesday, = 2020-05-12=20 > at 2359 UTC. The IAB will then solicit public comments on the = candidates=20 > before making a decision. >=20 > Best regards, > Cindy Morgan, for the IAB >=20 > [1] = >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail=_1A091B89-F6F6-455F-9D70-9E7857F8542D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI.

If = you have any questions I can answer, I=E2=80=99d be happy to = talk.

Eliot

Begin forwarded = message:

From: = IAB Executive Administrative = Manager <execd@iab.org>
Subject: = Reminder: Call = for nominations: RFC Editor Future Development Program Chair(s)
Date: = 29 April 2020 at 18:04:26 = CEST
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Reply-To: = iab-chair@iab.org, execd@iab.org

As = previously discussed, the IAB is seeking an additional chair or
chairs for the RFC Editor Future Development Program [1].

This program is modeled on an IETF working = group, and will use its
mailing list (rfced-future@iab.org) = to develop and validate consensus
among the participants. =

The program currently has one chair, Eliot = Lear. The current IAB has
received significant feedback = from the community that a second chair
needs to be = selected, and the IAB is eager to fill that position with a
great candidate as soon as is practical. The IAB is now = seeking at least
one additional chair from outside the = IAB to join Eliot. Together, these
chairs will set the = detailed agenda, manage the program, and call
consensus = among the participants. The program also has two liaisons from
the IAB to assist with logistical matters, Wes Hardaker and = Jared Mauch.

If you are interested in = serving in this role, please send a short email
message = to iab-chair@iab.org = and execd@iab.org with = your motivation and
information concerning your = familiarity with IETF working groups or
similar = processes. The deadline for volunteering is Tuesday, 2020-05-12
at 2359 UTC. The IAB will then solicit public comments on the = candidates
before making a decision.

Best regards,
Cindy Morgan, for the IAB

[1] <https://www.iab.org/activities/programs/rfc-editor-future-devel= opment-program/>

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail=_1A091B89-F6F6-455F-9D70-9E7857F8542D-- From nobody Wed Apr 29 11:43:17 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CCC3A1190 for ; Wed, 29 Apr 2020 11:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz3dlZD1EqCX for ; Wed, 29 Apr 2020 11:43:13 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311063A118D for ; Wed, 29 Apr 2020 11:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7009; q=dns/txt; s=iport; t=1588185793; x=1589395393; h=from:mime-version:subject:message-id:references:to:date; bh=HclCQ3DJVqg7iq7Z/O1fMb2ab5BVKjOL9Z2Qk3KbyUQ=; b=hTJRvv0ZEAL4rows1W7XrSQcXoSX4qygET0dWvMoCi23KE0uDAoNZFvH B6xBdNwaXnwV5CH1lCVoL62TIDxrORC4Rtc/ACj8pNhQHXntT7YXwDhWK aCRcB3GRfi+cRoe+M3Fn8AQBF4iPqAAUpuwyPuBf3rtUtJmMMawvkl3IH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAACvyale/xbLJq1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBgXUDAQEBAQsBAYMWVAEgEiqEIYkBh2Qlk0+?= =?us-ascii?q?GEIF7CwEBAQwBARgBCgwEAQGERAKCUTYHDgIDAQELAQEFAQEBAgEFBG2FVgx?= =?us-ascii?q?CARABhR0BAQICAQEBIUsQCxwDAQIrAgInJgIIGYMmAYJcIA+ycnaBMoVQhHo?= =?us-ascii?q?GgTgBjFqCAIE4DBCCHy4+gmcBA4IDgnIzgi0EojSQAYJPgm6FJY90HYJbiFu?= =?us-ascii?q?EUY0AmVCPf4NDAgQGBQIVgVkDL4FWMxoIGxU7KgGCPj4SGA2WLYUUhUQ/AzA?= =?us-ascii?q?CNAIGAQcBAQMJhy+LOwEB?= X-IronPort-AV: E=Sophos; i="5.73,332,1583193600"; d="scan'208,217"; a="25773239" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2020 18:43:09 +0000 Received: from [10.61.246.165] ([10.61.246.165]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03TIh8Zs022431 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 29 Apr 2020 18:43:08 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_65463671-B522-4BB9-A581-2934F60A1A18" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: References: <8DFA9B04-CA94-4661-AF9F-D3FD2CFCCD7B@cisco.com> To: rfced-future@iab.org Date: Wed, 29 Apr 2020 20:43:07 +0200 X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.246.165, [10.61.246.165] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Fwd: Moving forward with virtual discussions X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 18:43:16 -0000 --Apple-Mail=_65463671-B522-4BB9-A581-2934F60A1A18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Reminder: Please Doodle by tomorrow at https://doodle.com/poll/thxahm2df9txamxw = if you haven=E2=80=99t = already. Thanks, Eliot > Begin forwarded message: >=20 > From: Eliot Lear > Subject: [Rfced-future] Moving forward with virtual discussions > Date: 27 April 2020 at 17:06:43 CEST > To: rfced-future@iab.org >=20 > Hi there! >=20 > Following up on my earlier notes, I would like to propose some times = for discussions. The purpose will be to talk through a subset of the = topics that we have generated. >=20 > I=E2=80=99m sure you all understand the complexities of holding these = sorts of meetings when we have participants across many time zones; in = particular on the West Coast, East Coast, Europe, Australia, and New = Zealand (a good percentage of active participants, actually!). These = are discussions, and meant to help us zoom in on what we have to solve = for and what we can leave for later. We can discuss here which of the = summary list to start from, or I can try to arrange things in a way that = seems to make sense. >=20 > I will record and take notes, but I would rather we do our real = decision making here on list, for those who cannot reasonably = participate at one time or another. >=20 > Here=E2=80=99s a doodle poll: >=20 > https://doodle.com/poll/thxahm2df9txamxw = >=20 > Could you please fill it out by Thursday, April 30th? >=20 > Thanks, >=20 > Eliot > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_65463671-B522-4BB9-A581-2934F60A1A18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Reminder:

Please Doodle by tomorrow at https://doodle.com/poll/thxahm2df9txamxw if you = haven=E2=80=99t already.

Thanks,

Eliot

Begin forwarded = message:

From: = Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org>
Subject: = [Rfced-future] = Moving forward with virtual discussions
Date: = 27 April 2020 at 17:06:43 = CEST
To: = rfced-future@iab.org

Hi there!

Following up on my earlier notes, I would like to propose = some times for discussions.  The purpose will be to talk through a = subset of the topics that we have generated.

I=E2=80=99m sure you all understand the = complexities of holding these sorts of meetings when we have = participants across many time zones; in particular on the West Coast, = East Coast, Europe, Australia, and New Zealand (a good percentage of = active participants, actually!).  These are discussions, and meant = to help us zoom in on what we have to solve for and what we can leave = for later.  We can discuss here which of the summary list to start = from, or I can try to arrange things in a way that seems to make = sense.

I will = record and take notes, but I would rather we do our real decision making = here on list, for those who cannot reasonably participate at one time or = another.

Here=E2=80=99s a doodle poll:

https://doodle.com/poll/thxahm2df9txamxw

Could you please fill it = out by Thursday, April 30th?

Thanks,

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

= --Apple-Mail=_65463671-B522-4BB9-A581-2934F60A1A18-- From nobody Thu Apr 30 09:21:42 2020 Return-Path: X-Original-To: rfced-future@iab.org Delivered-To: rfced-future@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E77B53A0C19; Thu, 30 Apr 2020 09:21:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF Announcement List" Cc: rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rfced-future@iab.org Message-ID: <158826369987.4698.2558761070632410658@ietfa.amsl.com> Date: Thu, 30 Apr 2020 09:21:39 -0700 Archived-At: Subject: [Rfced-future] RFC Editor Future Development Program Virtual Meeting: 2020-05-14 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 16:21:40 -0000 The RFC Editor Future Development Program will hold a virtual meeting. When: Thursday, 14 May 2020: 21:00 UTC, 17:00 America/New York, 14:00 America/Los Angeles Friday, 15 May 2020: 07:00 Australia/Sydney, 09:00 Pacific/Auckland Duration: 90 minutes Webex Information: https://ietf.webex.com/ietf/j.php?MTID=m6e894a38b5cf6c139af7eca0891907ca Meeting number (access code): 618 351 526 Meeting password: DSnNT3piK67 Provisional Agenda: Elaborate and discuss the issues that have been raised on the rfced- future mailing list relating to goals of evolving the RSE and related functions. We will refine this agenda on the rfced-future mailing list, to which anyone is welcome to subscribe at the link below. The meeting will be recorded for those not able to attend. From nobody Thu Apr 30 11:11:27 2020 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E0D3A0E5B for ; Thu, 30 Apr 2020 11:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YIpee830RVX for ; Thu, 30 Apr 2020 11:11:15 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788113A0E5A for ; Thu, 30 Apr 2020 11:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1446; q=dns/txt; s=iport; t=1588270274; x=1589479874; h=from:content-transfer-encoding:mime-version:subject:date: references:to:in-reply-to:message-id; bh=mjmwofoYdmRe9lFZ4qcVx1O/b0Kkq9ReVj5OiuGEAdI=; b=iBD9rYnLhushBXRTZgkTAg7xOpoxJVNN1Ws+aQeIRQ37W58wuLwKWVte YekZVhE+eAzI6I/GjbUycXUwGWxFZq0wpXqnsl0hZPxWOJzaBUkEJ4OnA DsW31TikGhDQtMlFF7aKNnszYzB4fFYglSkOj5Z7zMHMKuIIel50IvLVW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAAB+E6te/xbLJq1MGhwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIEzBwEBCwGBfIEbVSASKoQiiCFgiAyZYIF7CwEBAQwBARg?= =?us-ascii?q?NCgQBAYREAoJUNAkOAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAQIBAQEhSxA?= =?us-ascii?q?LCxgCAggMDAYCAicwGYMmAYJcIA88skd2gTKDTIcqBoEOKgGMWoIAgREnHII?= =?us-ascii?q?fLj6BBIFjAQMagUlNAoIYKzOCEhsEjmujWYJQgm6FJok2hkAdnRSZYJACg0M?= =?us-ascii?q?CBAYFAhWBUjmBVjMaCBsVOyoBgj4+EhgNVo94DAsVbgEDgkiFFIVEPwMwAjQ?= =?us-ascii?q?CBgEHAQEDCY0cgh8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,336,1583193600"; d="scan'208";a="25806751" 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; 30 Apr 2020 18:11:12 +0000 Received: from ams3-vpn-dhcp747.cisco.com (ams3-vpn-dhcp747.cisco.com [10.61.66.235]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03UIBAW3023245 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Apr 2020 18:11:11 GMT From: Eliot Lear Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 30 Apr 2020 20:11:10 +0200 References: <158826369987.4698.2558761070632410658@ietfa.amsl.com> To: rfced-future@iab.org In-Reply-To: <158826369987.4698.2558761070632410658@ietfa.amsl.com> Message-Id: <69F144B0-D225-4D38-A6CA-2B6C51B2F41D@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.66.235, ams3-vpn-dhcp747.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] RFC Editor Future Development Program Virtual Meeting: 2020-05-14 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 30 Apr 2020 18:11:24 -0000 Hi everyone, Below is the information for our meeting two weeks from today. We can = take some time here to discuss priorities. I think Mike had a great = approach, and I invite others to indicate which of the topics on the = list they=E2=80=99d like to start with, or whether we should try to = triage the list together. Eliot > On 30 Apr 2020, at 18:21, IAB Executive Administrative Manager = wrote: >=20 > The RFC Editor Future Development Program will hold a virtual meeting. >=20 > When: =20 > Thursday, 14 May 2020: > 21:00 UTC, 17:00 America/New York, 14:00 America/Los Angeles > Friday, 15 May 2020: > 07:00 Australia/Sydney, 09:00 Pacific/Auckland >=20 > Duration: 90 minutes >=20 > Webex Information:=20 > = https://ietf.webex.com/ietf/j.php?MTID=3Dm6e894a38b5cf6c139af7eca0891907ca= > Meeting number (access code): 618 351 526 > Meeting password: DSnNT3piK67 >=20 > Provisional Agenda: >=20 > Elaborate and discuss the issues that have been raised on the rfced- > future mailing list relating to goals of evolving the RSE and related=20= > functions. We will refine this agenda on the rfced-future mailing = list,=20 > to which anyone is welcome to subscribe at the link below. The = meeting=20 > will be recorded for those not able to attend. >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future